Scavenger just retired today. It was a very interesting box and I had lots of fun exploiting a box that was already pwned by an (imaginary) attacker. Also, I loved the Silicon Valley theme. Its IP address is 10.10.10.155 and I added it to /etc/hosts as scavenger.htb. Without further ado, let’s jump right in!
Scanning & Web App Enumeration
A light nmap scan offered me enough information to get started:
After reading the results, I tried to access port 80 to search for vulnerable applications. I was surprised when I got an error:
That error seemed rather familiar to me, as I once had an issue with an app I built. Basically, apache (and maybe other software) has the ability to serve multiple web addresses on the same port. This application-separated hosts are called virtualhosts.
The error basically told me that I first needed to find a valid domain and point it to the box’ IP address (and, as you will see later, there are multiple valid domains). Before I started enumerating the other ports, I read the nmap report again and noticed an interesting line:
I added supersechosting.htb to /etc/hosts and tried to access it in a browser:
It worked! However, I wasn’t able to find anything interesting on the site, so I moved on and started enumerating the other ports.
Finding More Domains
I knew that I should probably be looking for new domains, so I focused my energy on port 43 (WHOIS) and 53 (DNS). I found port 43 to be quite interesting, as I couldn’t find the software that was running on it:
Theoretically, the word ‘query’ (and the banner that included the server’s MariaDB version) should have tipped me off that the app is vulnerable to an SQL injection, however, I have to admit that I found the vulnerability by mistake wjile testing for something else.
I leveraged the new-found vulnerability and retrieved the version of database software that the server was running:
Next, I listed all the user-created databases:
There was only one table called customers, so I went further and started enumerating its columns:
After that, I listed all entries of the domain column hoping to find new vhosts:
It turned out there were 3 more domains. I tried exploiting the SQL injection further, but I had no success.
The 3 Domains
I added the newly-discovered domains in my /etc/hosts file and quickly inspected all of them to see if I could find any vulnerability.
The first one, justanotherblog.htb, only hosted an ‘Under Construction’ page:
The second one, pwnhats.htb, was pretty funny, as it hosted a hacker hat store named PWNHats:)
The last site, rentahacker.htb, was using a default WordPress theme and offered ‘heap hacking services’:
The comment section of the last site was pretty interesting to me:
In the last comment, the ‘31173 HAXXOR team’ stated that they had successfully compromised the system. They also mentioned a bug tracker, so I started searching for it, hoping to find the remains of the above-mentioned hack (the box name is ‘Scavenger for a reason 🙂 )
DNS Enumeration & The Bug Tracker
After running dirb with multiple wordlists and extensions, I didn’t manage to find any bug tracker, so I concluded that it was hosted on another subdomain. I first tried to ask the DNS server for all the sub-domains and it worked:
The sec03.rentahacker.htb sub-domain was the one defaced by the hackers:
After discovering that page, I rand dirb again, this time on the newly found sub-domain:
shell.php caught my attention immediately. I thought that attackers could have used this file to execute commands, but I didn’t know what parameter was used to pass the command. I used wfuzz to discover it:
When I tried supplying the hidden parameter to shell.php, the command I provided was executed and the output was returned in plaintext:
It worked! However, ib01c03 does not have a user.txt file in ~ 🙁
After some initial enumeration, I found an interesting mail in /var/spool/mail/ib01c03:
I used the credentials provided in the mail to connect to the FTP server:
I immediately noticed that there were 2 folders made for 2 different users. However, I could access both of them. ib01c03’s folder was empty, however, I found some interesting files in ib01c01’s folder:
The ‘notes.txt’ file revealed that there was another attack that targeted another client (ib01c01):
The first lines of the ‘access.log’ file revealed that ib01c01 was the owner of ‘pwnhats.htb’:
In order to find the valid password, I simply used strings on the pcap file:
The password for ‘email@example.com’ was ‘GetYouAH4t!’. I tried using the credentials to access the admin panel, but the dashboard was very slow. I also tried exploiting the vulnerability the attacker used, but I wasn’t able to do that either. After a lot of thinking, I tried using the same password for ib01c01’s FTP and it worked:
As always, I won’t post the user proof here; I will only say that it starts with ‘6f’.
Finding the rootkit
After getting the user.txt file, I started searching for a privesc method, but I got stuck. After going through everything again, I found a TCP stream (tcp.stream eq 26) in the pcap file that contained some of the attacker’s commands:
Basically, the attacker downloaded some files and then upgraded his shell to a SSL-encrypted one. After some searching, I was able to locate the source code of root.c:
The source code was clearly copied from this site. Basically, any process that would write a magic string to /dev/ttyR0 would get root privileges. However, the default string wouldn;t work, because the attacker probably changed the magic string to something else (I called it magic string because that;s how the author of the code named it; it doesn;t have anything to do with unicorns).
I knew that I needed to get the .ko file or the modified source code in order to find the modified magic string, however, I had a very hard time doing that, mainly because I used shell.php to try and locate it. As it turned out, the file was hidden inside ib01c01;s files:
Did you see it? Read the folders again, this time more carefully. Still didn;t see it? Well, me neither. However, after reading that list a lot of times, I finally realised that … is a user-created directory:
After downloading root.ko, I opened it in ghidra and read the root_write function, which compared the data written to the character device with the magic string. You can find below a snippet of the code:
Basically, the magic variable (which holds the magic string, duh) starts with the value ‘to0Rt0g’, which is g0tR0ot read backwards. However, before the comparison, it is modified to the concatenation of a and b. If a represents ‘t3g’ and b ‘v1rP’, the concatenation would be ‘g3tPr1v’ (don’t forget to read a and b backwards!). I used shell.php to execute the command that would elevate my shell’s privilege:
For those of you who don;t want to urldecode online, I just executed ;echo g3tPr1v > /dev/ttyR0; id;