Scavenger is a hard difficulty machine and the first I have attempted on HackTheBox. It tests your knowledge in basic enumeration, SQL injection, more enumeration, DNS service exploitation, uhuh more enumeration, yet more enumeration, even more enumeration, basic reverse engineering/debugging.
Be sure to checkout the Basic Setup section before you get started.
Like always, enumeration is our first port of call. Let’s take a look at the machine and see what we are dealing with.
Navigating to port 80 show us the page:
As we can see from the nmap scan the whois service on port 43 gives us the vhost http://www.supersechosting.htb.
Adding this to our /etc/hosts reveals the page:
This page gives us some extra info and tells us that a LAMP stack is preinstalled with SSH and FTP access.
From the information we gather from the page as well as our nmap scan we have all versions for the stack:
Linux - Debian 10 (Buster)
Apache - 2.4.25
MySQL - MariaDB10.1.37
PHP - 7
Along with OpenSSH 7.4p1 and vsftpd 3.0.3.
We also see a couple more domains listed for the DNS server dns.supersechosting.htb and WHOIS server whois.supersechosting.htb. Let’s add those to our /etc/hosts incase we need them.
Since this is a hosting service and also self proclaimed First authorized registrar for new .htb top level domain we can assume there may be some other sites laying about.
Considering we know that the whois service is running MariaDB and we can see it is potentially suscpeptible to SQL Injection from the output 1267 (HY000): Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'like' we will start with this service.
Using the whois command we can cause MariaDB to error out confirming SQL Injection:
We can see here from the error output that the query contains a parantheses ).
Admittedley I tried to use a 1=1 query but I must have used the -H flag which hides the legal disclaimers but also filters the extra output. However, a fellow HTB user kindly informed me that it does in fact work without that flag.
So using the following command we can dump extra domain entries from the database:
To be honest I am quite happy I missed this because I learnt a lot going the long winded way as follows.
With the error information we can start mapping our structure with union:
The outputted error tells us that there is more than one column.
We keep adding null to map out our entry point:
Adding two null inputs gives us no output at all. Adding three causes another error. So two it is!
Now we test to see which position is vulnerable:
As we can see the query has returned our input so we know that this entry is vulnerable. Testing the other position returns no output so it is not vulnerable.
With this information we can now try to dump some information:
Our query reveals a database called whois.
Now let’s see if we can find some tables:
Within this output we find a table called customers.
We will also list the columns:
Looks like we have three columns. The domain column will hopefully point us to some other domains to enumerate!
Finally, with the inforamtion we have gathered let’s dump the data:
Nice! We find a bunch of domains.
Let’s add these to our /etc/hosts. We find that we need to include www like we did for supersechosting.htb.
In doing so we can now go check them out!
Taking a look we see that justanotherblog.htb is under construction:
The domain pwnhats.htb is a PrestaShop store:
And rentahacker.htb is a Wordpress site:
From a quick glance at exploits relating to these Prestashop and Wordpress the most recents require Admin access. So we may be looking for creds.
Taking a closer look at rentahacker.htb we notice a few comments on the post http://www.rentahacker.htb/2018/12/10/rent-a-hacker/:
The comment by 31173 HAXXOR team hints at a bug tracking webapp that apparently has already been hacked. We may need to enumerate for subdomains.
From this we can probably say that we have also found our theme relating to the box name.
We may have to scavenge for things the previous hacker has left behind!
Since we know that supersechosting.htb offers DNS resolution services as per their website let’s try finding some info through port 53 with the dig command.
We will use the AXFR protocol which is used for DNS zone transfers and will hopefully allow us to dump all information about the given domain:
We see that we reveal the subdomain sec03.rentahacker.htb.
Let’s add that to our /etc/hosts (the list is getting long now) and see what we can find:
So we have found the site that 31173 HAXXOR team said they hacked. They mentioned it was a bugtracking webapp.
Knowing that the webapp is potentially written in PHP navigating to index.php redirects to the Mantis Bug Tracker login page at http://sec03.rentahacker.htb/login_page.php:
At the login page we see the message: Warning: You should disable the default 'administrator' account or change its password. This tells us that the default credentials may not have been changed!
Trying the default login administrator:root we get access:
Taking a look around we don’t find anything interesting and checking the exploits available for the version reveals no vulnerabilities.
While we look around a bit more let’s setup Burp Suite’sintruder and enumerate for directories as well as filenames:
And from the payloads tab we can load our wordlist. We will use big.txt.
Our results reveal a file called shell.php:
Alternativley we can use wfuzz:
Looks like we have a webshell! Trying a few common parameters returns nothing!
Let’s once again setup Burp Suite’sintruder this time looking for the webshells parameter:
And from the payloads tab we can load our wordlist. Once again using big.txt.
Our results reveal the parameter hidden:
Alternatively using wfuzz:
Finally we have RCE with the user ib01c03:
Now that we have access to the Mantis BT and Wordpress files let’s get the database creds to see if there has been password reuse:
Using the database username and password we can access ib01c03FTP account but we just have the same access.
Since we will be working with the webshell let’s make life a little easier by creating ourselves a limited shell:
Short and nasty but does the job!
Looking in the home directory we find the following:
Taking a look around we find something in /var/mail.
We find the following email containing some credentials:
Logging in via FTP we find a directory called incident that contains two other directories called ib01c01 and ib01c03.
We are more interested in moving to another user so we will check out the ib01c01 directory first:
Let’s download the files with the get command and see what we have got. The pcap will be our main area of focus!
From our enumeration of apache configuration files we know that the ib01c01 user runs the http://www.pwnhats.htb website. Also as per our enumeration we know that website is running PrestaShop. We will be looking for the administration backend.
Opening up the pcap file in Wireshark we set the filter http.request.method == POST and quickly see our target location.
We right click and slect Follow and then TCP Stream:
We then see our POST request with the email and password:
We can confirm the credentials at http://www.pwnhats.htb/admin530o6uisg and logging in with the details.
During enumeration of the filter http.request.method == GET in WireShark we also see something of interest referencing root.c:
Taking a look at the TCP Stream of these items we see a Makefile which looks like it is to do with Kernel modules and the root.c files that contains C code for what seems to be performing privilege escalation:
Straight off the mark there is a line that seems quite distinct MODULE_DESCRIPTION("Got r00t!.");. A quick search online reveals a forum post detailing the privilege escalation.
We see that a device is created called /dev/ttyR0 and the permissions 666 is set. A check on the machine reveals that we in fact have that device with those permissions:
To execute the privilege escalation the attacker does a simple command but it does not seem to work:
Taking a look into the code g0tR0ot is meant to be a “magic” string that is a backdoor. Obviously this magic string has been changed hence why it does not work.
Further reading shows that root.c compiles to root.ko a Kernel module that is loaded with insmod.
A quick search of the system does not show a file with that name so we can safely assume it is most likely within ib01c01’s home directory.
Although we know that the version of PrestaShop installed is vulnerable we will check if there has been a case of password reuse with user ib01c01:
We find that we have FTP access and grab the user.txt flag! Now on to root.
In the above FTP directory listing we notice a folder somewhat “disguised” with the name ...
Moving in to the directory we find our file:
We can download it and investigate further.
Looking again at the code for root.c we know that we are interested in the root_write() function where the magic string is declared:
Taking a look at root.ko in IDA we can take a look at the function and the pseudocode for it:
We see three strings:
Since we know that the two strings g3t and Pr1v are not in the original code we can safely assume that these two strings are concatenated together to make the “magic” string. Looking further down the pseudocode we see that this is the case.
Let’s go try it out back at our limited shell for ib01c03:
Sure enough we can execute commands as root!
Now to take the flag:
That’s it. Another box rooted and my first hard difficulty machine!