[CTF] HTB Tabby write-up walkthrough

This is my write-up and walkthrough for the Tabby (10.10.10.194) box user flag. Tabby is a Linux machine with some interesting web app CVEs to play with. I enjoyed using the Pwnbox feature in my last hackthebox write-up so decided I'd give it another go on this one. When commencing this engagement, Tabby was listed in HTB (hackthebox) with an easy difficulty rating.

Walkthrough

I spun up a new Pwnbox instance from the HTB dashboard and installed my VPN server key for my region.

Once the VPN server key was installed, I then pinged the target 10.10.10.194 to check if my instance could reach the Tabby machine.

To make things easier moving forward, I always opt to add the target machine IP address to my /etc/hosts file.

To do this I navigated to the /etc/hosts file.

And I added the target IP address and assigned it an identifier label tabby

Now this was set, I could begin some basic recon.

As part of my standard recon routine I used Nmap, which is an open-source network scanner designed to discover hosts, services, and open ports. My objective was to identify what ports might be open on the target machine.

I ran Nmap with the flags sudo nmap -sS -sC -sV tabby -oN scan

These flags told Nmap to do the following:
-sS - Instructs Nmap to not complete the three-way handshake so the connection attempt is not logged on the target.
-sC - Instructs Nmap to scan with default NSE scripts, which is useful and safe for discovery.
-sV - Instructs Nmap to determine the version of any services running on the ports.

The Nmap scan results indicated ports 22, 80, and 8080 were open. This confirmed the server was running a web service and SSH.

I visited the IP address in my browser (port 80).

I had a look around and noticed that the statement at the bottom of the landing page relating to a data breach hyperlinked to the address http://megahosting.htb/news.php?file=statement

As this was unreachable, I added the domain to my existing hosts file for 10.10.10.194 so I could also reach it at tabby

I was unable to find anything of interest in the page content for the issued statement, but noticed the requested statement was being passed in the file parameter. I wondered if it might be vulnerable to path traversal or SQLi.

I decided to use Burp to automate a fuzzing technique demonstrated in my previous path traversal attack tutorial. This fires a list of common path traversal attack strings as requests and compiles a list of the HTTP status code responses. After reviewing this list, I could see there were some anomalies indicating traversal was possible.

The first location I reached was the /etc/passwd located at http://tabby/news.php?file=../../../../../../../../etc/passwd

I could see at the bottom of the file, the users tomcat and ash existed.

The next location I reached was the /etc/hosts located at http://tabby/news.php?file=../../../../../../../../etc/hosts

This confirmed information I already knew and concluded my port 80 recon so I moved on to port 8080 and visited http://tabby:8080 to see if it was reachable.

This confirmed the server was running Apache Tomcat 9 and at the bottom indicated more user information might be present at http://tabby/news.php?file=../../../../../../../../etc/tomcat9/tomcat-users.xml

However, when I tried this file location it didn’t exist. I was also conscious at this point that my earlier path traversal fuzzing had not enumerated this path and file location in the results. I then tried manually amending the path until I reached a blank page at http://tabby/news.php?file=../../../../../usr/share/tomcat9/tomcat-users.xml

Viewing the source of this page then gave me the XML file markup.

This file provided user credential information for the user tomcat with password $3cureP4s5w0rd123!

I got stuck at this point for a while so ended up looking back at my notes and searching on Google to see if there were any vulnerabilities in Apache Tomcat 9 that might help me get a shell.

My research showed me that Apache Tomcat 9 uses WAR (Web Application Archive) files to deploy web apps via servlets. These are a bit like JAR files, but contain everything the web app needs (such as JavaScript, CSS, etc), and according to Apache Tomcat 9 support documentation are controlled via commands from the manager application located here:

There was evidence in the public domain that Apache Tomcat 9 was previously vulnerable to a malicious WAR file upload vulnerability, but I had no idea if the specific version running on this server was patched or not. I decided to try anyway.

My first step was to search for a module I could use in Metasploit, then see if I could leverage that to craft and upload a tailored WAR file backdoor. I went for the java/jsp_shell_reverse_tcp module and configured a reverse shell to listen for a connection from my machine 10.10.14.62 on port 1338.

I then used curl to push the newly generated WAR file to the Apache Tomcat 9 manager application using the credentials I had found before.

However, before I executed this, I needed to setup a listener using netcat on my own machine to listen for connection requests on the desired port 1338

Now I could execute the reverse shell.

netcat confirmed the reverse shell was active and I could see I was connected as the user tomcat

I then spawned a tty shell to help me navigate and interact.

I had a look around and moved into the /var/www/html/files directory which listed what appeared to be a backup file.

I converted the compressed file to base64 and copied the verbose output, then used echo to rebuild the file locally on my machine.

When I attempted to access the file I could see it was password protected.

I fired up frackzip and ran it against the famous rockyou.txt wordlist to see if I could bruteforce the password.

After about 15 seconds, frackzip found the password admin@it

Recognising that passwords are sometimes shared, I then went back to my shell and tried to use this password for privilege escalation.

I found it worked successfully on the user ash. I then listed the contents within the directory and opened the file user.txt which gave me the user flag.

Follow Jacob Riggs

Jacob Riggs

Jacob Riggs is a Security Lead based in the UK with almost a decade of experience working to improve the cyber security of media and third sector organisations. His contributions focus on expanding encryption tools, promoting crypto-anarchist philosophy, and pioneering projects centred on leveraging cryptography to protect the privacy and political freedoms of others.

E3FE 4B44 56F5 69BE 76C1 E169 E3C7 0A52 9AEF DB6F