Nmap scan report for 10.10.10.171 Host is up (0.067s latency). Not shown: 998 closed tcp ports (conn-refused) PORT STATE SERVICE VERSION 8009/tcp open ajp13 Apache Jserv (Protocol v1.3) | ajp-methods: |_ Supported methods: GET HEAD POST OPTIONS 8080/tcp open http Apache Tomcat 9.0.30 |_http-title: Apache Tomcat/9.0.30 |_http-favicon: Apache Tomcat
Straight off the bat it appears the server will be vulnerable to GhostCat (Tomcat 9.0.30) so we’ll hop into Metasploit and see if there’s a module we can use.
We get some creds for Tomcat manager, so let’s see if we can log in.
We can’t, however using this creds we can log into the host manager. It allows us to connect to a virtual host and install an app so they do work. After a bit of Googling we find a curl syntax to upload a revshell that we can create with msfvenom.
curl --upload-file revshell.war -u webdev:'Hgj3LA$02D$Fa@21' 'http://dotjar.thm:8080/manager/text/deploy?path=/' OK - Deployed application at context path [/revshell.war]
Now we can trigger the shell via the URL.
The first thing to do is run Linpeas and see what sticks out, before doing some further digging. There was notably no SSH open on this server so we won’t be able to get a really nice session at any point. We don’t have access to any user flags, so imagining we have to pivot through a couple of users.
Linpeas shows us an interesting backup file, which is literally a backup of /etc/shadow
So with the help of unshadow and john the ripper we very quickly get ourselves some creds for the jdk-admin user.
We can execute any .jar file as root, so all we need to do is create a malicious payload with msfvenom (again!) and we can pop a nice root shell.
There we go, grab the flags and pwn the box. A pretty straight forward room. Glad I didn’t have to anything with Java, phew.