CSAW CTF Quals 2013 - SCP-hack (exploitation 500)

This was the highest scored exploitation challenge at the CSAW CTF qualification round. At the moment of writing these words (still 4 hours of CTF left) only 5 teams have solved it out of 1375 participating, including ours (and it took us a lot of time and a number of attempts). Several people from our team worked on this task, including, among others, hasherezade, mak, fel1x, and myself (gynvael), and we have finally solved it late Saturaday night.

Oh. And by the way, don't expect any actual exploitation - this turned out to be a Networking task.

The task had the following description:

The SCP organization (http://128.238.66.211:45000) wants you to join, accept and see if you can take advantage of their interns sloppy coding and outdated browser.

The website itself (e.g. http://128.238.66.211:45000/?invite=BL9UDG4MZG6S) greeted you with the following message:

Note: the GitHub link led to a python script parser_server.py, mirrored here.

So the first thing to do was to access the website with our invite token (?invite=...) from the required countries (distinguished probably by IP whois information or IP ranges). This could have been done using various methods like proxies, TOR, websites and servers "pinging" given URLs, etc.

In the end after several hours we had only 5/7 required flags lit, and were looking into some more hardcore methods, but to our surprise the rules were simplified to require only 5 flags lit, which we already had (kudos to teams which actually had 7/7).

Once the required amount of flags were gathered, an upload form appeared:

At this moment the focus in the challenge shifts to the script parser_server.py, which turned out to be only a hint anyway - this script wasn't really used in the available version; and to the following hint-text on the website:

If you are invited, try using a link to your photo instead of your 'commonName' in your certificate signing request!

So what you could do now, is upload a certificate request with a link to whatever in the commonName field, and that link would be visited by something that claimed to be MSIE7b:

GET /whatever HTTP/1.1
Referer: http://intern-box.thescpinternational.local/
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)
Accept: */*
Host: myIP:43432
Connection: Keep-Alive

Note: we've done several tests, and determined that's probably just wget or curl pretending to be MSIE.

Thinking that it was curl actually made us go to the curl FAQ website where the curl-supported protocols are listed, and we started going through them one by one, to actually figure out that only 3 worked (yes, these are the ones listed in parser_server.py too): http://, https:// and file://.

Since nothing we tried with HTTP or HTTPS actually worked, we switched focus to file://, which actually is SMB over NetBIOS over TPC. We've set up a tunnel to a Windows 7 VM and observed the traffic in wireshark:

The important information here is:

1. The connection is rejected, because Windows doesn't like to be called other names (like not-its IP address, first part of not-its IP address, or *SMBSERVER)
2. It's UBUNTU. This just proves it wasn't MSIE7b to begin with.

We followed up by changing the name of the Windows 7 VM to helium, and pointing an A DNS record to its external IP with the name helium.whatever.domain.we.own. At that we uploaded a new certificate signing request that pointed to the same host using the new DNS record, and got this:

And yes, that's the flag in the NTLMSSP_AUTH attempt - key=whereisthedirtysmellysauce. Honestly, we have not expected it to be there, but well, that's 500 points for checking :)

To summarize I'll repeat myself - I think this task should be in Networking/Miscellaneous category, and not in the Exploitation one, which was pretty misleading. In the end we're just glad to have solved it.