Overview
I thought this box was really cool, and deserved a higher rating. In general, boxes heavy on enumeration will rate lower because people tend to find them tedious, but I found scavenger presented a large number of interesting puzzles that came together to make a really fun box.
Recon
This time, lets start with a full port scan using masscan, then run a targeted scan on the results with nmap:
Some interesting results. Notably, there appears to be a DNS server running on both UDP and TCP, which might be an indication that it allows zone transfers. We also get a hint as to a potential hostname.
Web
Checking out the web service, it looks like knowledge of a host will be handy:
Let's try adding www.supersechosting.htb to our /etc/hosts file:
Great! At this point I started running a subdirectory bruteforce:
And a virtualhost bruteforce:
In the meantime, let's see what we can get from the other services.
DNS
So, how about those zone transfers?
A few interesting results. Nothing that hints at web subdomains, but I will add them to my hosts file nonetheless in case some of the other services are performing virtual host routing.
Whois
Our nmap results also indicate that the server is running a whois service. It's likely that you have interacted with a whois server before, for example if you have ever wanted retrieve information relating to a particular domain. Many linux distros come with a whois client pre-installed. We can use this to run queries against the servers whois service like this:
So no results for the machines own ip address. We can however see that the server is built on top of MariaDB, and we get the specific version. We can try searching for the server's own base domain:
Interesting! Given that the service is running on top of MySQL, let's see if it might be possible to abuse it.
Let's pass it the deadly ':
Not only can we confirm our injection, but we also leak part of the structure of the query. Next I tried:
whois -h 10.10.10.155 "%') limit 100 -- -"
in order to hopefully leak all of the subdomains stored in the DB. The service returned results for
- justanotherblog.htb
- pwnhats.htb
- rentahacker.htb
We can keep this sqli in the back of our minds and come back to it later if need be. For the time being however, I'll add these domains to my hosts file and start to look through them. You can start to see why this box is so enumeration heavy.
Digging deeper
I started by running subdirectory bruteforces on all the new domains. We can also perform zone transfers on them too see whether there are any atypical subdomains we might be able to attack. rentahacker.htb returns an interesting result:
Browsing to it we see:
Hmm, we aren't the first here! Browsing back to www.rentahacker.htb we see this comment on the wordpress page:
The box name starts to make sense now. It sounds like we need to follow someone else's chain of exploitation.
The next thing I did was perform another directory fuzz on the new subdomain. This turned up two things of interest:
index.php: Browsing here shows that this subdomain is running a instance of Mantis Bug Tracker.shell.php: Very suspicious. Browsing here returns a blank page.
We can reasonable guess that shell.php looks something like this:
<?php
system($_GET['cmd']);
?>The problem is we don't know the name of the parameter that might have been used. We can use wfuzz to try to find the parameter:
Great! Next I tried to get an interactive shell, however I wasn't able to get a reverse shell to connect back. Even just getting a connection back via nc didn't work. If we check the iptables rules it becomes apparent why this is the case:
So we have to perform some enumeration manually via the webshell. The first interesting piece of information was in the mantis config file:
After a lot of searching, we also come across mail for our user in /var/mail:
We can use these credentials to authenticate to the FTP server.
FTP
Once in the FTP server, the only files are in /incidents/ib01c01:
The note reads:
After checking the logs and the network capture, all points to that the attacker knows valid credentials and abused a recently discovered vuln to gain access to the server!This seems to imply that the pcap file will contain credentials. Opening it up in wireshark, we can filter to look for POST requests to narrow down our search for log ins. We find the password quite easily:
These credentials allow us to log into the www.pwnhats.htb admin panel.
If we keep digging through the pcap, we can find how the previous attackers were able to get a reverse shell on the box. We come across this request:
Unfortuneately, we're unlikely to be able to leverage this same method for a shell due to the iptables rules I mentioned earlier.
Looking further through the pcap, we can see the attackers upload a .c file:
We can see that they are downloading it form their own python http server. If we run a unique looking string from the file into google, we quickly find this link, a blogpost on writing kernel rootkits. The gist of the post is that the kernel module adds a device that allows you to easily escalate to root, like this:
I tried this in the web shell from earlier, but couldn't get it to work. Assuming the rootkit exists on the system, this might mean that the passphrase used has been changed.
Next I tried the credentials we found in a few other places. They dont work on SSH, however they do work on ftp for user ib01c01:
We finally have our user flag!
Now before reading on, take a careful look at the picture above and try to find something that isn't quite right. Do you see it?
Beneath the . and .. directories, there is a ... directory! Inside it:
A kernel module, hidden in a suspiciously named directory. Let's take a look in IDA.
It seems that the g0tR0ot password from before is being overwritten by g3tPr1v.
Let's try for root in our webshell again with a payload like:
echo g3tPr1v > /dev/ttyR0;whoami
And we're executing commands as root! From here a root shell is trivial. Simply add an iptables rule that allows us to get a reverse shell.