Using ModSecurity to Virtually Patch Apache Struts CVE-2017-5638

Many security vulnerabilities are found in libraries used by application code. When it’s impractical to quickly deploy a fix to code in a library, you may be able to use ModSecurity to intercept an exploit, “virtually patching” the affected code until you can upgrade the affected libraries.

The Apache Struts application library vulnerability (CVE-2017-5638), which led to the breach of 143 million accounts at Equifax, is an example of exploit that can be virtually patched. The signature of the vulnerability is the presence of #cmd= or #cmds= strings in the Content-Type, Content-Disposition, or Content-Length HTTP headers. (For more details, see below.)

Using ModSecurity, we can create a virtual patch with a simple rule that searches for the malicious strings in the affected HTTP headers:

Why Virtual Patch?

In a lot of cases it’s quicker to deploy a rule in ModSecurity than to patch the affected code, re‑test, and then deploy to production.

Consider the Apache Struts vulnerability as an example: because Struts is an application library and not an operating system package, updating it in an enterprise production environment can take some time. As part of upgrading to a new version of Struts, each Struts‑dependent application needs to be rebuilt and tested with the latest Struts library. A large organization might have hundreds of applications, each with its own version of the Struts application library, making it vulnerable until every single application is updated.

With the ModSecurity custom rule in place, you can then patch the production software carefully, and on a reasonable schedule, without the pressure of being vulnerable. Once all the affected software is updated, the custom rule can be decommissioned.

How the CVE-2017-5638 Exploit Works

Apache Struts CVE-2017-5638 is a remote command execution (RCE) vulnerability. This type of vulnerability allows the attacker to run arbitrary commands, such as /bin/bash or cmd.exe, on target systems. With that ability, the attacker can then search the file system and the network for sensitive data, with the same level of access as the Java application server. For example, if the Java application server is running as root, then the attacker has root privileges on the target system.

According to the official CVE, the vulnerability occurs when an attacker sends a malformed Content-Type, Content-Disposition, or Content-Length HTTP header. Apache Struts throws an exception when those HTTP headers don’t match any of the expected values. The problem occurs because the exception‑handling code attempts to print the unescaped, invalid header. (In this context, “unescaped” means that the suspect commands are not prepended with characters that prevent them from being executed – escape characters – as is normally done when printing code.)

The attacker can put an Object Graph Navigation Library (OGNL) expression into the Content-Type header. OGNL has the ability to run system commands. When the unescaped, invalid header is printed, the OGNL expression is evaluated, and any system commands within the OGNL expression are executed.

The key syntax is in the second half of the command: one instance each of the strings #cmd= and #cmds= (highlighted above). Each of the strings is followed by the system command to run.

Summary

The preferred solution is always to patch vulnerable software right away. But patching production software can be time‑consuming, and rushing updates can be risky. Creating a virtual patch for vulnerable software with ModSecurity can buy time.

With virtual patching, you create a custom ModSecurity rule to block traffic that might exploit the security vulnerability, such as CVE-2017-5638. By doing so, you protect your site from the attack. You can then patch the production servers carefully, and on a reasonable schedule, without the fear of being victimized in the meantime.

Have a Cookie? :)

Our site uses cookies to provide functionality and performance as well as for social media and advertising purposes. Social media and advertising cookies of third parties are used to offer you social media functionalities and personalized ads for NGINX content and offers. To get more information about these cookies and how we process personal data, check our Privacy Policy. Do you accept the use of cookies and the processing of personal data involved?

Your Cookie Settings

Site functionality and performance

These cookies are required for NGINX site functionality and are therefore always enabled. These include cookies that allow you to be remembered as you explore the NGINX site, help make the shopping cart and checkout process possible as well as assist in security issues and conforming to regulations. To use the NGINX website, you have to consent to these cookies and the processing of personal data according to the NGINX website terms of use and privacy policy.

Social media and advertising

Social media cookies offer the possibility to connect you to your social networks and share content from our website through social media. Advertising cookies (of third parties) collect information to help better tailor NGINX advertising to your interests, both within and beyond NGINX websites. De-selecting these cookies may result in seeing advertising that is not as relevant to you or you not being able to link effectively with Facebook, Twitter, or other social networks and/or not allowing you to share content on social media.