Security is too often an afterthought in the software development process. It’s easy to understand why: Application and software developers are tasked with getting rid of bugs and adding in new features in updates that must meet a grueling release schedule. 

Asking to include security testing before an update is deployed can bring up problems needing to be fixed. In an already tight timeline, that creates tension between developers and the security team. 

If you’re using traditional pentesting methods, the delays and disruption are too great to burden the development team, who are likely working a continuous integration and continuous delivery process (CI/CD). Or if you’re using an automatic scanner to detect potential vulnerabilities, you’re receiving a long list of low-level vulns that obscures the most critical issues to address first. 

Instead, continuous pentesting, or even scanning for a particular CVE, can harmonize development and security teams. And it’s increasingly important. A shocking 85% of commercial apps contain at least one critical vulnerability, according to a 2021 report, while 100% use open-source software, such as the now infamous Log4j. That’s not to knock on open-source software, but rather to say that a critical vulnerability can pop up at any time and it’s more likely to happen than not. 

If a critical vulnerability is found–or worse, exploited–the potential fines or settlement from a data breach could be astronomical. In the latest data breach settlement, T-Mobile agreed to pay $350 million to customers in a class action lawsuit and invest additional $150 million in their data security operations.

This is why many companies are hiring for development security operations (DevSecOps). The people in these roles work in concert with the development team to build a secure software development process into the existing deployment schedule. But with 700,000 infosec positions sitting open in the United States, it might be hard to find the right candidate. 

If you want to improve the security of your software and app development, here are some tips from Synack customers: 

• Highlight only the most critical vulns to the dev team. The development team has time only to address what’s most important. Sorting through an endless list of vulns that might never be exploited won’t work. Synack delivers vulnerabilities that matter by incentivizing our researchers to focus on finding severe vulnerabilities.

• Don’t shame, celebrate. Mistakes are inevitable. Instead of shaming or blaming the development team for a security flaw, cheer on the wins. Finding and fixing vulnerabilities before an update is released is a cause for celebration. Working together to protect the company’s reputation and your customers’ data is the shared goal. 

• Embrace the pace. CI/CD isn’t going away and the key to deploying more secure apps and software is to find ways to work with developers. When vulns are found to be fixed, document the process for next time. And if there’s enough time, try testing for specific, relevant CVEs. Synack Red Team (SRT) members document their path to finding and exploiting vulnerabilities and can verify patches were implemented successfully. SRT security researchers can also test as narrow or broad a scope as you’d like with Synack’s testing offerings and catalog of specific checks, such as CVE and zero day checks.

Security is a vital component to all companies’ IT infrastructure, but it can’t stand in the way of the business. For more information about how Synack can help you integrate security checkpoints in your dev process, request a demo.

The post Testing Early and Often Can Reduce Flaws in App Development appeared first on Synack.

A Vulnerability in an Oracle WebLogic Server Allows Attackers to Perform Remote Code Execution via HTTP Request

In this installment of Exploits Explained, we’re going to demonstrate a vulnerability in an Oracle WebLogic Server that allows attackers to perform remote code execution via a single HTTP request.

Exploit teardown credit goes to Jang on medium.

To see the vulnerability in action, read on, or check out this video walkthrough:

This vulnerability was recently encountered by one of our Synack Red Team researchers during a web application penetration test. 

Here’s why this vulnerability is such a big deal:

1. It’s a Remote Code Execution (RCE) Vulnerability, which is the root cause of many modern Ransomware attacks
2. It affects a widely distributed application
3. There’s a public exploit available
4. It’s not hard to pull off and requires no authentication

While this particular vulnerability has already been patched, we’ll walk you through how an attacker would be able to exploit this in the wild. 

Oracle WebLogic Server sets an auth flag based on URL paths in requests. Attackers were able to determine the allowed paths via the values set in “WebAppSecurityWLS.getConstraint ()”.  In this attack, the path is set to /css/, and when the web application evaluates the request, it sets the value of “flag unrestrict”  to true. This allows the request to be passed along unauthenticated. The attacker then utilizes the path traversal to access the console.portal endpoint.

The console.portal portion of the web application can use a constructor called ShellSession.exec () which allows for system commands on both Linux and Windows systems.

These commands are sent via an MVEL expression under the handle “com.tangosol.coherence.mvel2.sh.ShellSession”In the publicly available exploit, the MVEL expression contains a function to evaluate the value of an HTTP header value named cmd and uses this value for the command to be executed. As seen here:

The output of the command is then written into the server’s response where the attacker can see the results of the command sent.

The server’s response for the commands whoami and ipconfig can be seen here:

This was patched in the October 2020 Critical Patch Update or CPU. These are some of the affected versions:

10.3.6.0.0
12.1.3.0.0
12.2.1.3.0
12.2.1.4.0
14.1.1.0.0

Organizations running these versions of Oralce WebLogic Server should review logs for HTTP requests made to the console.portal endpoint or any requests containing the double url encoded value for ../ (%252E%252E%252F)

Organizations should also check for any suspicious processes spawned by the application. This typically includes cmd.exe ( for windows) or /bin/sh (for *nix systems).

It’s critical that organizations check to make sure they can’t be compromised by this vulnerability by performing penetration testing. We recommend taking a crowdsourced penetration testing approach for higher quality results and to achieve a true adversarial perspective. 

Stay tuned to the Exploits Explained series for further walkthroughs of vulnerabilities encountered by the SRT in the field. 

Learn more about the SRT, or about Synack’s crowdsourced penetration testing at www.synack.com

The post Exploits Explained Part 2 – Remote Code Execution (RCE) via a Single HTTP Request appeared first on Synack.