Today it is time to solve another challenge called “Mustacchio”. It was created by zyeinn. It is available at TryHackMe for penetration testing practice. The challenge is an easy difficulty if you have the right basic knowledge and are attentive to little details that are required in the enumeration process. The breakdown of the Machine with redacted flags is as follow:

Level: Easy

Penetration Testing Methodology

• Network Scanning
  • Nmap Scan
• Enumeration
  • Enumerating HTTP Service
  • Directory Bruteforce using dirb
  • Enumerating database file
  • Cracking the password using John the Ripper
  • Enumerating Source Code
  • Enumerating Backup file
• Exploitation
  • Testing XXE Vulnerability
  • Extracting Private key using XXE
  • Deciphering the key using John the Ripper
  • Logging in SSH as Barry user
  • Reading User Flag
• Privilege Escalation
  • Enumerating SUID Permissions
  • Exploiting Path Variable on the tail
  • Getting Root Shell
  • Reading Root Flag

Walkthrough

There are two flags in this machine to discover. After Booting up the target machine from the TryHackMe: Mustacchio Page, an IP will be assigned to the machine and will be visible on that page as well.

IP Address: 10.10.74.246

Network Scanning

We will start a Nmap scan with the -sV for performing a Version Scan and -sC for default scripts on the target machine.            

nmap -sC -sV  10.10.74.246

We have two services running on the target machine. We have 22 (SSH) and 80 (HTTP). Since we don’t have the credentials for accessing the SSH service at this moment we will be our enumeration with the HTTP Service.

Enumeration

To enumerate the HTTP service, we open the IP address of the target machine in the Web Browser and found a Web page. It was mostly a template. There was not much to go on from. Speaking of the HTTP service, we tried to perform multiple formats of the Nmap scan and found that there is another HTTP service running on port 8765.

http://10.10.74.246

Enumerating another HTTP Service running on port 8765 we can see that it is an authentication panel. We tried to log in using some default credentials but were unsuccessful.

http://10.10.74.246:8765

Unable to gather any information from the two web pages, we thought to try enumerating the web directories by performing a Directory Bruteforce. We used the dirb tool for this task. After running for a while, we found a directory by the name of custom.

dirb http://10.10.74.246

Browsing the custom directory, we found two other directories. One was the CSS directory. It contained various style files that are required to format the web pages. There was nothing much to go on from them. We went back to the custom directory and decided to enumerate the js directory.

http://10.10.74.246/custom

Inside this directory, we found a JavaScript file by the name of mobile.js. It didn’t contain anything useful. We tried to open the users.bak file and found that it is a database file. To explore it we need to take a closer look.

http://10.10.74.246/custom/js

To enumerate the users.bak file, we downloaded it to our local machine using the wget command. Since it was a database file, we decided to use the SQLite browser to look for the tables and entries that might be stored inside this database file.

wget http://10.10.74.246/custom/js/users.bak
sqlitebrowser users.bak

We found encrypted credentials for the user admin in the database file. We selected the Browse Data tab inside SQL Lite Browser.

We created a file and saved the encrypted password for the user admin. This encryption may be SHA1 due to the length of the text. We used the john the ripper with the rockyou wordlist and the raw-sha1 format. We were able to decrypt the password as bulldog19.

nano file
john --wordlist=/usr/share/wordlists/rockyou.txt --format=raw-sha1 file

We tried to log in as SSH using these credentials but we were unsuccessful. That means that these credentials must belong to the authentication page that we found earlier. Upon entering the password, we found the Admin Panel. Here, we found a Text field that is supposed to accept the comment for the website.

http://10.10.74.246:8765
admin
bulldog19
http://10.10.74.246:8765/home.php

We checked the source code of this page to find the work or any hidden comments. We found two comments in the source code of this page. The first one hinted at another backup file inside the auth directory. It was named dontforget.bak. Another comment mentions the user Barry and it also hints that the user Barry can log in on SSH with the help of his key. This means that we need to locate the key for the user Barry.

source:http://10.10.74.246:8765/home.php

Using the hint that was provided, we wanted to take a closer look at the backup file by the name of dontforget.bak. We used the wget command to download the file to our local machine. We used the file command to find out the type of this file and found that it is an XML file. Based on the assessment of the adding command mechanism that we found earlier and the contents of this file it is clear that the web application accepts the XML input and this is an example of the comment that can be sent to the web application. With the help of this file, we can be certain that there are 3 entities of the XML that are accepted by the application. This includes the <name>, <author> and <com>.

wget http://10.10.74.246:8765/auth/dontforget.bak
file dontforget.bak
cat dontforget.bak

Exploitation

We twerked the XML file that we were enumerating and since the web application accepts the XML as input. We had suspicions if the application was vulnerable to XXE. We used the structure of the XML file and introduced the external entity name and pointed it towards /etc/passwd file. Then added the reference of the name entity inside the <name> as demonstrated in the image below.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
   <!ELEMENT data ANY >
   <!ENTITY name SYSTEM "file:///etc/passwd" >]>
<comment>
  <name>&name;</name>
  <author>Pavandeep</author>
  <com>Hacking Articles</com>
</comment>

When we hit the submit button, the XXE attack worked and we were able to read the contents of the /etc/passwd file.

Based on the hint that we discovered in the comments of this page, we know that user Barry is able to login using the SSH key. By default, the key will be located inside the home directory of barry inside the .ssh directory. Using the XXE vulnerability, we tried to get the id_rsa key for the barry user.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
   <!ELEMENT data ANY >
   <!ENTITY name SYSTEM "file:///home/barry/.ssh/id_rsa" >]>
<comment>
  <name>&name;</name>
  <author>Pavandeep</author>
  <com>Hacking Articles</com>
</comment>

Our trial was successful. We were able to locate the Private key for the user Barry. To prevent changing the formatting web browser the source code of the page and then copied the private key.

We saved the contents of the private key into a file named key. Since the key was encrypted and will ask for a password if tried to log in directly, we used the ssh2john.py file to convert the contents of the key into to crackable hash. Learn More about ssh2john here.  Again, we used john the ripper to crack the hash with the rockyou wordlist. We were able to crack the password for the key to be urieljames.

nano key
/usr/share/john/ssh2john.py key > hash
john --wordlist=/usr/share/wordlists/rockyou.txt hash

Since we need to connect to SSH using the key, we need to modify the permissions otherwise it will be rejected as a key. We used the key to log in as the Barry user. We found the user flag inside the Barry user’s home directory.

chmod 600 key
ssh [email protected] -i key
urieljames
cat user.txt

Privilege Escalation

Since we have exploited the machine, it’s time to elevate the current privileges and get the root user access. We start by enumerating the SUID permission using the find command. We found a file inside the home directory of joe user by the name of live_log. Checking the permission for the file we found that it is owned by root and it is possible to use this file to elevate our access.

find / -perm -u=s -type f 2>/dev/null
ls -la /home/joe/

Since we will be able to execute the live_log file, we used the strings command to take a closer look at this binary file. We found that this binary file runs the tail command without using its absolute path. This means that we will be able to exploit it by creating our version of the tail command.

strings /home/joe/live_log

We moved to the tmp directory since we will have the write and execute permissions. We created our version of the tail command but made it in such a way that it invokes the bash.  We changed the permissions so that we are allowed to execute the file. Next, we need to export the path so that when executed by the live_log, our version of the tail gets executed instead of the original tail. We executed the live_log file as Barry and got the root access. We read the root flag located inside the home directory of the root user.

cd /tmp
echo "/bin/bash" > tail
chmod 777 tail
export PATH=/tmp:$PATH
/home/joe/live_log
cd /root
cat root.txt

Author: Pavandeep Singh is a Technical Writer, Researcher, and Penetration Tester. Can be Contacted on Twitter and LinkedIn