Jerry
Nmap Scanning
$ nmap -A -T4 -p- 10.10.10.95 -Pn
Only 1 port is open: port 8080. We have the Apache Tomcat server version 7.0.88 running on it. Could that be a default webpage? Let's navigate to http://10.10.10.95:8080 and have ourselves a look.
Yap, we have a default webpage. This is dangerous because we can log in to the web server using the Manager App button highlighted in the screenshot above. Especially if default credentials have not been changed.
After some googling, I find a github page with default credentials for Apache Tomcat.
We will use Burp Suite to perform a brute force attack with the default credentials we have found.
After setting up our proxy, we click on the Manager App button and as a test, we provide tomcat:tomcat as our credentials.
When we press OK, this is what we view on our Burp proxy:
The credentials we have provided get encoded as base64. We can tell by the last 2 equal signs at the end. Let's right-click and select Send to Decoder. We will highlight the last line and select Decode as Base64. We can now see the credentials we provides, tomcat:tomcat.
When we forward the request, it doesn't work. So the credentials tomcat:tomcat don't work. Let's input manager:tomcat then intercept the request. Once we do that, let's right-click and select both Send to Repeater and Send to Intruder.
Let's copy the credentials from the github page and save them to a file named tomcat.txt. We will replace the space with a colon as shown below. Use ctrl+H.
Since the credentials being sent are encoded as base64, we also need to convert our credentials to base64. We will do some bash scripting to help us achieve this.
$ for cred in $(cat tomcat.txt); do echo -n $cred | base64; done
The script above will convert all the credentials in our file to base64.
Let's copy all of them. Now, let's head to our Burp Intruder. Highlight the encoded base64 credential, then click the Add button on the right hand-side. Once done, it should look as below:
Then head over to the payloads tab and click Paste to paste all the encoded base54 credentials we just copied.
Ler's scroll to the bottom and turn off url enocde characters. If we don't turn it off, it will attempt to url encode our base64 credentials (specifically the = signs) and our attack will fail. Once we do that, let's start our attack.
Once the attack is finished, we receive our results. It's always a good idea to check what's out of the norm by filtering based on status, length, or error. We can do that by clicking on them.
Let's decode the credentials for line 20 in the screenshot above since we got a status code of 200 (OK) and the length is significant. When we do that, we discover that our credentials are tomcat:s3cret. We will go login to the Manager app with those credentials.
And it's a success.
When we scroll to the bottom, we find a button to upload a WAR (Web Application Archive) file. We also get back further information regarding the machine.
We can probably upload a WAR file to the server, execute it, and get a reverse shell. I find a nice article with example templates for generating a malicious payload using msfvenom. Since the machine we are attacking needs a WAR file, we scroll to the bottom to locate it.
Let's generate our malicious WAR file, then set up our listener using netcat.
Let's go and upload the WAR file. Once uploaded, let's click on the highlighted /shell on the screenshot below to execute our malicious file.
And we get a connection :) To make matters better, we are authority\system.
Let's go retrieve our flags.
Lessons Learned
To get SYSTEM on this box, we exploited two vulnerabilities.
Use of Default Credentials. There was an exposed port that was running Apache Tomcat. The administrator had used default credentials for the manager interface. This allowed us to access the interface and deploy a war file that gave us access to the server. Since default credentials are publicly available and can be easily obtained, the administrator should have instead used a sufficiently long password that is difficult to crack.
Least Privilege Violation. Tomcat doesn’t need SYSTEM privileges to function properly. Instead it should have been run under a tomcat user account that has limited privileges. This way, even if we did get access to the box, we would have needed to find a way to escalate privileges, instead of immediately getting SYSTEM access without having to work for it. The administrator should have conformed to the principle of least privilege.
Last updated
Was this helpful?