Recon

I started by adding soccer.htb to my /etc/hosts file, by appending the line: 10.10.11.194 soccer.htb. This means that http://soccer.htb will work in our browser, as it will know where to look.

I kicked off basic reconnaissance within Pākiki Proxy while I took a look at the website - which appeared to be a static website with not a lot of dynamic functionality to test:

The reconnaissance didn’t return anything of interest. Next I used the Fuzz functionality in Pākiki Proxy to brute force the directories to see if there was any other functionality on the server which isn’t directly exposed. For the payload list, I used the Raft Small Directories Lowercase list. By sorting by status, I can quickly see the successful requests, which included a directory called tiny:

Initial shell access

That appeared to be a small web application called Tiny File Manager. I Googled for the application and found the default credentials (admin:admin@123), which worked, and presented us with a directory listing of the web server:

From there, I used the file manager to upload a reverse shell from Pentest Monkey, and got access to the web user (www-data) - woo!

Looking around on the file system, I noticed a file at /etc/nginx/sites-enabled/soc-player.htb:

server {
	listen 80;
	listen [::]:80;

	server_name soc-player.soccer.htb;

	root /root/app/views;

	location / {
		proxy_pass http://localhost:3000;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection 'upgrade';
		proxy_set_header Host $host;
		proxy_cache_bypass $http_upgrade;
	}

}

This indicated that there was a second website (hosted in root’s home directory) called soc-player.soccer.htb. So I added that to my /etc/hosts file, with 10.10.11.194 soc-player.soccer.htb and took a look at that site.

Player website

At first glance, it has the same functionality as the main “public” website, but also has match scores, registration and login. So I started to look for vulnerabilities which would give us access to data, as we know this server is also running as www-data, so remote code execution type vulnerabilities won’t give us any additional access.

I jumped to the login form and attempted SQL Injection on it, with no luck. I then registered to see what functionality was exposed, and after logging in, you’re presented with a form which allows you to check your ticket numbers:

Taking a look at the source code/traffic, I could see that it was using a websocket to check each ticket number. I wanted to see if that was vulnerable to SQL Injection, so I manually tried a number of payloads and found that it was. I did this by observing that my known ticket number was valid, and that 4 OR 1=1 was also a “valid ticket”, but invalid SQL syntax resulted in the ticket not being found. So we had Blind SQL Injection :)

The next step was to use a tool like sqlmap to dump the database. Theoretically it has built in support for websockets, but I couldn’t get it to work, so I searched online and found a tool called sqlmap-websocket-proxy, which exposes websocket messages via regular HTTP. I installed that with sudo pip3 install sqlmap-websocket-proxy and then ran it with sqlmap-websocket-proxy -u ws://soc-player.soccer.htb:9091/ -p '{"id": "%param%"}' --json. Then I used sqlmap against that proxy. After some discovery of the schema, I was then able to run sqlmap -u "http://localhost:8080/?param1=1" --dump-all -D soccer_db -T accounts:

And that password worked for SSH access, so we had user level access, and the flag. Woo!

root flag

I normally start by checking if I’ve got access to do anything with elevated privileges with sudo, by issuing sudo -l, and then I normally take a look around the file system for anything usual in my home directory, /opt and the cron jobs. None of these found anything interesting.

I then checked for SUID binaries, which are the executables on the system which have the ability to escalate their privileges, and I noticed that a tool called doas was installed in /usr/local/bin/ which is not common on Ubuntu systems:

player@soccer:~$ find / -perm -4000 2>/dev/null #Find all SUID binaries
/usr/local/bin/doas
/usr/lib/snapd/snap-confine
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/eject/dmcrypt-get-device
<snip>

A quick Google showed that this was an alternative to sudo to run commands as a different user. A check of its config file showed:

player@soccer:~$ cat /usr/local/etc/doas.conf 
permit nopass player as root cmd /usr/bin/dstat

So the player user, is able to run /usr/bin/dstat as root. A quick Google showed that privilege escalation with dstat is possible, by creating a custom module. So I followed the guide online here, and got the root flag. Woo!

Lastly, I cleaned up after myself.

Summary

Overall this was a fun box, there were no points where I was really feeling like I was struggling. It was a fun couple of evenings hacking away at it and then writing it up.