Writeup: 0x00sec CTF - Exercise #5

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 :wink:

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="">

<input type="hidden" name="p" value="aHR0cHM6Ly9pcGluZm8uaW8vODcuMTIzLjE2Mi4zOQ==">

Now let’s decode the base64 string:

➜ echo "aHR0cHM6Ly9pcGluZm8uaW8vODcuMTIzLjE2Mi4zOQ==" | base64 -D


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/

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.


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 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 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


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.


Very cool vulnerability which can be abused in a lot of ways.


Bro, capture the request in the Burp and and then use this payload to get the script, ZmlsZTovLy9ldGMvcGFzc3dk (file:///etc/passwd)

Yep, you can totally do this in Burp or any other proxy.

However, I try to avoid Burp in my write-ups. Simply because you do not need it to solve the CTFs. Furthermore these CTFs are designed for beginners. So it is always good to know the basics and how to handle this without tools like burp.