Apache Struts is a free, open source framework for creating Java web applications. It’s widely used to build corporate websites in sectors including education, government, financial services, retail and media.

In early March 2017, Apache released a patch for the Struts 2 framework. The patch fixes an easy-to-exploit vulnerability that allows attackers to execute random code by the web server. A Metasploit module was released very soon afterwards, making it fairly easy for miscreants to abuse the vulnerability.

The disclosure of the Struts 2 vulnerability, which was listed as CVE 2017-5638, along with the easy access to a module to compromise vulnerable systems, made it a very lucrative target for cybercriminals. Furthermore, the exploits available work on both Windows and Linux systems.

This is not the first time we witnessed attacks towards the Struts framework: Back in 2014, there was CVE-2014-0094.

Inside the Struts 2 Vulnerability

The vulnerability, located in the Jakarta Multipart parser, allows unauthenticated attackers to run arbitrary remote code on a vulnerable server. An attacker can exploit the flaw by sending an invalid value that causes the software to throw an exception. Instead of merely displaying the cause of the exception, the code that was added by the attacker in the request gets executed.

This means an attacker can send a faulty code sample to the vulnerable application. When the framework then tries to display the error, the code added by the attacker is executed as the system user running the framework. As such, systems that run the framework as a super user will suffer more from a successful exploit.

The versions of Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 are deemed vulnerable. It’s important to note that the vulnerability is not related to the numerous issues reported in the Java runtime environments on end-user workstations.

Attackers can make use of this vulnerability in multiple ways. They can, for example:

• Use the vulnerable systems to be part of a network to distribute different types of malware and spam, which could potentially put your system on a blacklist;
• Disrupt the vulnerable system, causing financial or reputation loss for the system owners; and
• Use the system as an attack point to move laterally within the organization, causing havoc on your systems.

Disruption has been demonstrated through reports of the Struts exploit installing ransomware on vulnerable systems, rendering them unusable and the data inaccessible. The payload that gets installed is a flavor of the Cerber ransomware.

Prioritizing Patch Management

What should you do to remediate this threat? In short, patch. According to the Apache security advisory, you should upgrade to Struts 2.3.32 or Struts 2.5.10.1. The advisory also suggested switching to a different implementation of the Multipart parser and listed a number of workarounds to validate the submitted requests, thus bypassing the vulnerable code.

Regardless of your approach, the disclosure of this vulnerability stressed the need to set up a proper patch management process within your organization. A good patch management process starts with knowing your assets and having an up-to-date inventory of your infrastructure. Once your network becomes more complex, you will need more than a simple spreadsheet to keep track of all your assets. The inventory, or asset directory, should be kept updated through automation.

The asset discovery service can alert you to changes within your infrastructure. Once a change has been found, you can start the vulnerability management process to scan the new or changed asset and receive a report of any found vulnerabilities. The whole process of discovering new assets, scanning them and reporting findings has to be automatic and continuous to be most effective.

Of course, simply knowing what vulnerabilities exist in your environment does not resolve them. You cannot patch everything at once, so you will need to set priorities by considering a combination of business and technical decisions. Define what is important to your business and assess the potential impact of system downtime.

You should also take into account the actual severity of a vulnerability. There are a number of scoring mechanisms that you can use to calculate the severity, such as the Common Vulnerability Scoring System (CVSS). Every organization must determine its thresholds for prioritizing a patch cycle. An organization might declare, for example, that everything above CVSS 8.0 must be patched within one week.

Finally, remember to validate that a patch has been properly applied and the system is no longer vulnerable.

Learning to Love Layered Security

Unfortunately, not every vulnerability is immediately patched by the vendor. Sometimes it takes time to come up with a patch, sometimes the product is no longer supported and sometimes the patch interferes with your business requirements.

Even when a patch is available, you may not have the required resources to immediately apply it. This means that although your vulnerability management process indicates that an asset in your environment requires patching, your process cannot apply the necessary measures.

This is where layered security and best practices can help to mitigate the exposure of such a vulnerability and, eventually, prevent exploitation. This is no substitute for patching, but it can buy you some valuable time. To stay in line with these layers of security, you should:

• Use the principle of least privilege and do not run processes as a super user.
• Apply a whitelisting strategy for allowed applications.
• Use firewalls, antimalware and antivirus solutions, both on the systems and the network layer.
• Apply proper inbound and outbound filtering rules.
• Make sure there are tested backups and assume that you will need these backups to recover from hardware and software failures.
• Use encryption, both in transit and for storage.
• Use a filtering device that can implement so-called virtual patching.
• Make use of intrusion detection or prevention systems.

Monitor, Detect and Respond

An intrusion detection or prevention system can help you to monitor your environment and block possible attacks. These systems do have their limits, however, and attackers can sometimes bypass them. It is important to monitor the behavior of your systems and establish a baseline of normal behavior.

Logging should take into account all the possible event sources available, going from application and system sources to user data and network information. Combining this information with a proper analysis process allows you to detect incidents and respond to them. The incident response process should not happen in an ad-hoc modus; it requires a well-defined playbook that allows you to detect the incident, collect incident indicators, mitigate the consequences, eradicate the source and recover from the event.

Once the incident has been dealt with, you can use the notes taken during it to extract lessons learned and improve the entire process. This enables you to provide input to other processes on what could have been improved and survey what security controls need a review or update. These insights are critical in the endless battle against threats such as the Apache Struts 2 vulnerability.