DEV Community

nekohige
nekohige

Posted on Edited on

HTB - Sau Writeup - no Metasploit

#ctf #htb #security

Summary

  • The target was running an outdated version of request-baskets, which allowed us to perform SSRF.
  • Through SSRF, we were able to reach an internal service at 127.0.0.1:80, which turned out to be Maltrail.
  • Maltrail was also running an outdated, vulnerable version that allowed RCE, giving us an initial shell.
  • Checking sudo -l as the low-privileged user revealed we could run systemctl via sudo without a password, which we leveraged — via a technique documented on GTFOBins — to escalate to root.

Recommendation

  • Regularly update software to the latest patched versions.
  • Avoid granting low-privileged users passwordless sudo access to commands unless strictly necessary, and scope any such access as narrowly as possible.
  • Before granting sudo access to any command, check whether it appears on GTFOBins and could be abused for privilege escalation.

Enumeration

Let’s enumerate the open ports on the machine using nmap. I usually use nmap in 2 steps. First, I take a quick full-port sweep.

sudo nmap -sS -Pn -p- --open -n --min-rate 5000 -oA scan_all 10.129.15.205
Enter fullscreen mode Exit fullscreen mode

Second, it’s time to dig deeper into the open ports.

ports=$(grep -oP '\d+/open' scan_all.gnmap | cut -d/ -f1 | paste -sd,)
sudo nmap -sS -Pn -p "$ports" -A -oN scan_deep.txt 10.129.15.205
Enter fullscreen mode Exit fullscreen mode


Port 22(TCP) and 55555(HTTP) are open. 55555(HTTP) seems interesting.

sudo nmap -sU -Pn --top-ports 100 -oN scan_udp.txt 10.129.15.205
Enter fullscreen mode Exit fullscreen mode

No interesting UDP pors are open.

Exploitation

Let's check the Port 55555(HTTP).
http://10.129.15.205:55555/web

It is indicated that it uses request-baskets | Version: 1.2.1

Searching on the internet, there is a known vulnerability on request-baskets | Version: 1.2.1: Server-Side Request Forgery.
https://github.com/advisories/GHSA-58g2-vgpg-335q

The following site has a clear explanation on it.
https://notes.sjtu.edu.cn/s/MUUhEymt7

The following site has a PoC.
https://packetstorm.news/files/id/174128

I tried viewing 127.0.0.1:8080 and 127.0.0.1:80 through the SSRF, and found a web application running on 127.0.0.1:80.

We can see that Mailtrail (v0.53) is running.

The following site gives PoC for RCE on Mailtrail (v0.53).
https://packetstorm.news/files/id/174129

We got a shell!

cat /home/puma/user.txt
Enter fullscreen mode Exit fullscreen mode

Privilege Escalation

First, I checked sudo -l, which showed that the user puma can run a specific command with sudo without a password.

sudo -l
Enter fullscreen mode Exit fullscreen mode

GTFOBins shows a way to spawn a shell. The Inherit section shows that it inherits from less, so I ran the sudo command and used !/bin/bash to escape into a shell.
https://gtfobins.org/gtfobins/systemctl/

https://gtfobins.org/gtfobins/less/


sudo  /usr/bin/systemctl status trail.service
Enter fullscreen mode Exit fullscreen mode

I got the root shell!

Lessons Learned

  • SSRF allowed me to make requests that should only be possible from the server side, from what should normally be a controlled client-side position. In this case, I was able to connect to an internal service at 127.0.0.1:80. Depending on the target, other schemes like file:// might also have been usable. I’ll remember SSRF as this kind of technique — making the server issue requests on the attacker’s behalf, reaching places the attacker couldn’t normally reach directly.

Top comments (0)