CVE-2017-9791: Analysis of RCE in the Struts Showcase App in Struts 1 Plugin

On July 7^th, a new security vulnerability was published in Apache Struts 2 CVE-2017-9791 (S2-048[1]). Struts 2.3.x users with Struts 1 plugin, which includes the Showcase app, are vulnerable.
Once again, this vulnerability enables a Remote Code Execution (RCE), which is the most commonly exploited Apache Struts vulnerability. In this case, as in many other cases of RCE in Apache Struts, the attacks observed in the wild are also carried in the form of Object-Graph Navigation Language (OGNL) expressions.[2]
Like the recent Struts 2 RCE CVE-2017-5638, Imperva customers are protected against current variations of the attack using the zero-day attack detection mechanism in either SecureSphere or Incapsula. The zero-day attack detection mechanism protects against malicious traffic regardless of a specific web exploit.

The Vulnerability

Based on Apache release notes, “it is possible to perform a RCE attack with a malicious field value when using the Struts 2 Struts 1 plugin and it’s a Struts 1 action and the value is a part of a message presented to the user”. The message presented to the user is processed by the “ActionMessage” routine and returned back to the user by the “message” function as follows:

messages.add("msg", new ActionMessage(the_message));

Lacking proper validation before execution, the message (the_message) processed by the server may potentially cause a remote code execution. To fulfill its execution potential, a remote entry point is required for the message. Following the route of the vulnerable code leads to this location:

/struts2-showcase/integration/saveGangster.action

Poking around the webpage reveals several inputs controlled by the user, including name, age, and description (see Figure 1):

Figure 1: Vulnerable Apache Struts application
When submitting the “Gangster” data the server processes the user’s input with the vulnerable “ActionMessage” routine and returns a message to the user (see Figure 2):


Figure 2: Request to the vulnerable page and result
As can be observed, the processed message is integrated with the user’s input data (“Gangster a added…”) which means now the input data can be modified to include arbitrary code execution (see Figure 3). For instance, the RCE payload can add a custom header to the response message or use an OGNL mechanism to run malicious code (see the second payload in “Attacks in the Wild” section):

Figure 3: Exploitation of the vulnerable application

Imperva Zero-Day Protection

As mentioned earlier, Imperva customers are protected against this new Apache Struts vulnerability using zero-day detection mechanisms from either SecureSphere or Incapsula, which detect incoming traffic with malicious content, regardless of a specific vulnerability or exploit.
The zero-day detection technique prevents the new attack using two complementary deterrence layers:

• First, since the exploit includes an arbitrary remote code to be executed, customers are protected out-of-the-box to most attack variations using a generic Remote Command Execution mitigation mechanism (see Figure 4):

Figure 4: SecureSphere blocking a generic RCE

• Then, in the second layer of defense, SecureSphere and Incapsula both detect potential OGNL expressions which are used to manipulate Java objects, and are commonly used by attackers to inject remote code in vulnerable Apache Struts servers, including in this attack (see Figure 5):

Figure 5: SecureSphere blocking a generic OGNL-based RCE
Nevertheless, to be on the safe side, a few hours following the release of this critical vulnerability our security teams published a dedicated mitigation guideline and virtually patched Imperva customers.

×

Nov 7 Upcoming Webinar

Elevate your Security Posture by Balancing Effectiveness and Efficiency

Register Now

Attacks in the Wild

An increasing amount of attack attempts have been seen since the publication of this new Struts vulnerability, mostly as hard copy replication of PoCs published shortly after the first announcement, and refer to reconnaissance attempts to track vulnerable servers. Below are details on two common payloads seen in the wild.

Payload #1: Custom Header Insertion Attempts

HTTP headers are easily parsed and extracted with automated scripts, therefore validating the existence of a new custom HTTP header is very straight forward for the attackers to implement and can be used as a reconnaissance request before the actual attack – i.e., the actual RCE which will take over the server.
In most cases attackers will use this kind of reconnaissance as part of a vulnerability scanning tool on predefined IPs range, facilitating bots to effectively scan a wide range of addresses. Based on our classification analysis, IPs that were registered in this attack are known to generate mostly bot traffic (~96%).

Payload #2: OGNL Expression Execution Attempts

Decoding the URL’s payload injected to the name parameter unveils the following RCE (see Figure 6):

Figure 6: OGNL-based RCE (URL Decoded)
The payload in this case refers to an attempt to execute OGNL expression, as an entry point to the attack. Again, in this case it is only a reconnaissance attempt before the attack, in which the attacker echoed a random generated number “89159112” to match when processing the response message.
It will be interesting to monitor the trending exploits over time and to see if and how the reconnaissance trend gradually shifts to actual exploitation attempts of these servers.

Stay Protected

Based on the official advisory this vulnerability does not affect applications using Struts 2.5.x series or applications that do not use the Struts 1 plugin. Meaning that an update is required for those who use the earlier vulnerable patches. It is also mentioned that even if the Struts 1 plugin is available while excluding certain code parts, the application is safe.
An alternative to the formal advisory, which could be costly and time consuming, is virtual patching. Instead of leaving a web application exposed to attack while attempting to modify code after discovering a vulnerability, virtual patching actively protects web apps from attacks, reducing the window of exposure and decreasing the cost of emergency fix cycles until you’re able to patch them.
In addition to virtual patching, zero-day detection mechanisms such as those mentioned above protect sites by detecting and blocking new strains of attack prior to its release without any modification to systems.
Learn more about protecting web applications from vulnerabilities using Imperva Incapsula WAF or Imperva SecureSphere WAF.
[1] https://cwiki.apache.org/confluence/display/WW/S2-048
[2] https://www.imperva.com/blog/2017/01/remote-code-execution-rce-attacks-apache-struts/