Robots Exclusion Committee Writeup – 2013 CTF

The challenge:


This is very punny, as you will see later

The link takes you too this page:

Entering in real credit card info should lose you points in CTFs

Entering in real credit card info is clearly the solution ;)

Looks very legit, after you fill in some filler junk into the form you get this page:</p>


Oh! You mean that wasn’t it? Hey that’s not very polite either! Apparently robots aren’t the only ones without hearts.

Here is the source for the main page, nothing too interesting here…

Not much to see here

Not much to see (except for the warning about the money stealing thing!)

I tried checking the CSS to see if it referenced any elements not seen in the two pages we have so far. Suffice to say they don’t but they did have this comment for us:


Taunting in CTF is always fun (or frustrating when you just can’t get it!)

So, let’s think like a robot – where would we check?

Oh right, robots.txt maybe?



Those fools! It’s the first place an evil robot would check! This site is clearly ill prepared for any sort of robo-attack


So from this we can glean that WallE is not welcome here and that we _shouldn’t _check out the /vault page…

Not sure what I expected


Now, let’s have an honest talk. I was stuck here for quite a while, when I think of HTTP basic authentication I usually thing .htaccess/.htpasswd files and nothing more. All static files and not much to go on except bruteforcing. It took me a while to think about fuzzing this input right here (idioticly so, perhaps).

This is not the case, however. This is actually completely dynamic and not only that but it’s SQL injectable – by setting my password to ” OR 1=1– I was able to null authenticate and get to the vault page.

Like I said, took me far longer that it should’ve to realize that.


A secret! But remember we don’t want secret #2 – we want secret #1!


Before I continue, it’s obviously time for a relevant XKCD on this topic:


Yes, they really have done everything haven’t they?

Moving forward, we know that the HTTP basic authentication script they are running is SQL injectable. Let’s roll with that – we are going to be taking a page from one of my previous posts titled “CSAW 2013 WidgetCorp Writeup, with bonus coolness”. TL;DR we will setup a “proxy” page to do the heavy lifting of encoding the SQL injection payload and set it up as a local server. Once we’ve done this we can point any SQL injection tool at it and wallah!

Testing the script with a bad password

Testing the script with a bad password


Attempting our SQL injection like before but through our proxy page – all looks good!

Great, now that all seems to be functioning correct we’ll point sqlmap at our local page and crack away!


That's not it!

That’s not it!


Ooh! Looks like what we're after :)

Ooh! Looks like what we’re after :)

Once the injecting has completed we get a dump of their database. This yields two base64 encoded PNG files (secret #1 and secret #2!)

Sweet, sweet victory!

Sweet, sweet victory!

When you decode this base64 you get the following image:


I suggest you re-read the challenge text for a full understanding of the puns missed initially 😛

Overall a very cool challenge, learned a very important lessons about assuming things. I’ll try to remember that for future CTFs!

Until next time,


Matthew Bryant (mandatory)

Matthew Bryant (mandatory)
Security researcher who needs to sleep more. Opinions expressed are solely my own and do not express the views or opinions of my employer.