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
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 😀
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.
Well this simple task of reproducing a Metasploit exploit is turning out to be a HUGE learning experience.
To quickly recap. We want to brute force an Apache Tomcat 5.5 servers login. Then use those credentials to upload a malicious payload to Tomcat which will then be executed to give us a shell into the system.
I don’t know why I thought this would be simple because it’s certainly not the easiest thing ever. That said, I am making some good progress. This was going to be a two parter but it looks like it will be a three parter. As you may remember from my last post we have credentials. Now we need a way to upload a payload. So this tool that I built tonight does just that.
Before we can upload, we need to see what is actually being sent in the request. To do this, I logged into the Tomcat management console, opened up burp and took a look at what got sent over the wire and where when I uploaded a file.
There’s a lot going on in this photo but here is the gist of it. The row that I have selected is the request that was made when I clicked deploy. The information at the bottom is the actual raw contents of that request. The important things to look at here are the headers. Immediately a few stood out to me.
‘Authorization: Basic dG9tY2F0OnRvbWNhdA==’
‘Content-Type: multipart/form-data: boudary=….’
In the end, this was 99% of what I needed to make this successful. Let’s start with the easy one. The post path is what gets tacked onto our base URL and port. When crafted it will look something like http://192.168.1.65:8180/manager/html/upload. No problems here.
Next we need to look at Authorization. This one’s a little trickier but still pretty easy. The double equal sign is a dead give away that this is a base64 encoding.
A quick online decoder confirms this
As you can see, when decoded we get tomcat:tomcat which is username:password. This is going to come in useful later.
Finally, the biggest pain in the ass ever. The Content-Type of multipart/form-data and its boundary. When I first started trying to make this work I crafted everything by hand. I put the file in the post data payload and sent it off. This failed horribly.
Uploading to the server turned out to be a little more tricky than I expected. Since I am crafting the request in python it needs to be precisely what the server is expecting. Otherwise you get erroneous errors like “Upload Failed – No File” or “Authorization Required”. As fun as these were to mess with, I found it frustrating after about 2 hours of the same error outputs.
So then I started looking at what multipart/form-data actually was and how to craft it in python. Surprisingly the python documentation online is pretty bad ass. I wish MSDN was as clean and easy to read.
I will also say using WireShark to inspect my calls and being able to line them up to burp made this SUPER easy (once I thought to do it) Had I done this from the start I probably would have cut my dev time down to 10% as long as it took me. Hey, that’s the learning process though.
Another thing that hung me up for a REALLY long time is the file name. Notice in the WireShark image below it says name=”file”; this is incorrect and is what held me up the longest. I didn’t catch that it was doing that. The correct value should be ‘deployWar’. You will see how it should be crafted in the next section.
Putting it all together
So let’s put all our info into a request and send it. First we will encode the username and password
Next we grab our file
Then we can build our request, set the headers and send it off.
Finally we just check our response for some keywords to see if we got a valid response or not
Execute the payload and we get profit!!
One final touch I added was including a path that the user can click to activate the payload. (or so we hope) At this point it’s untested with a real payload so that is what’s going to be in the next post.
Okay, that was super educational. I learned a ton there. I am getting better at this python thing and I am excited to try and craft a payload tomorrow. If I get that to work then we will put it all together into one big application and see if it works!
So after my last post about getting into Tomcat with Metasploit I decided that Metasploit was fun to mess with but if I actually want to learn then I needed to actually do what Metasploit was doing for me.
In order to do this I had two major goals. First, I needed to brute force Tomcat’s login page. I decided to write this in python and to make it reusable. The second goal was going to be getting a reverse shell. This is going to wait for tomorrow though.
Wow, what a week! I spent no less than 30 solid hours this week (in my free time) going through these books a little more and boy is there a lot to cover. Let’s start with my gripes. As you remember I am going through “The Hacker Playbook 2”, “Metasploit, the Penetration Tester’s Guide” and “Penetration Testing, a Hands-On introduction to Hacking”.
Anyone that knows me knows I love a good hardware hack. The thing about working with hardware, especially hardware that you didn’t build, is that it isn’t always easy to figure out what lines go to what and where you need to tap your project into.
Saleae Logic 4 to the rescue. This logic analyzer allows you to tap into a circuit and see what is being transmitted over it. It’s extremely useful and I can anticipate this being in my hardware hacking tool kit for the foreseeable future. To demonstrate the potential of this device I setup a little Arduino project.
Setting up the Arduino project is simple. This just consists of the basic Arduino blink example with one addition. In the code if you look you will see I am also outputting serial data.
The Serial line is set to a baud rate of 9600 (this will be important later in this tutorial). Every time the code loops, it prints “Hello Anthony to the serial line and also toggles the LED either on or off.
With this basic code we can demo both the Digital reading capabilities of the logic analyzer but also the analog capabilities as well.
As you can see in these photos, I have attached some leads to our Arduino project. I have a lead connected to the positive pin of the LED, a lead attached to a wire coming out of TX on the Arduino and finally a lead connected to the ground of the Arduino.
These leads are connected to our Saleae Logic Analyzer and will allow us to pump data back into their software on my dev machine. Then we can analyze the data to debug it or look for specific identifiers that will help us identify the lines we are attached to.
Once we record the data we can analyze it in the provided software. This software will automatically decipher serial data for you. As pictured below, you can see that the text Hello Anthony is being deciphered above the actual analog readings that we recorded. How cool is that!
This device is incredibly cool. I highly recommend anyone attempting to reverse engineer devices pick up one of these analyzers. They’re very easy to use and honestly, they are pretty fun to play with.
Author: Anthony Russell
Professional .NET developer
Author: Anthony Russell
Author: Anthony Russell