This is a continuation of my write-up of the BSides SF 2013 CTF.
Level 5: Phone Work
This level required that we find a phone number on the Absurdistani snoop's computer and gain access to the voicemail box associated with the number. Finding the number was straightforward -- there was an email draft that contained the signature of the snoop, and in that signature was his phone number and voice mail box number. (This also lets us know his name is Marco.) Calling the phone number and entering the VM box number, we're asked for the PIN of the voicemail box. After trying some obvious things (the VM box number, the last 4 digits of the phone number, 1234, 0000, etc.) I started looking through his machine for any clues, but his machine was very sparsely populated with files. So, off to the internet for a list of the most common pins. Yeah, humans are predictable... the top 20 PINs (20/10000 =~ 0.2% of pins) represent a whopping 27% of PINs in use. Turns out Marco was that predictable too. One of the top 10 and we're in! The voicemail tells Marco that his new secure key is available on the secure keyserver, which he can retrieve using the 15 digit project access code.
Level 6: Crypto
I need to get access to the keys from the keyserver, and I'm lucky that Marco's workstation contained a couple of other interesting files. One of those files was a PDF describing the format of requests to a secure keyserver for getting the keys. It described a format like <epoch_time>|key=<key_id>|public=<0|1>|private=<0|1> that was "signed" with a 15 digit key. Along with the PDF, there was a logfile of a transaction with the keyserver that revealed the client-side of a single request to the keyserver: MTM2MTY2NTYyM3xrZXk9NThiMDI3OXxwcml2YXRlPTB8cHVibGljPTE=|sig:3f8296f8b84b8981cdfdcdc1964fb570958f9523. A quick nmap got the port number to talk to. I hit the server with netcat, and copied in the request from the logfile, and it turns out that the server was definitely vulnerable to replay attacks -- instantly I had an SSH public key.
The next flag asks for the private key. It was pretty easy to see that the replayed request had a base64 encoded portion, followed by |sig:, and then a hex-encoded signature. Given the length of the signature (160 bits), it's a pretty safe bet that we're dealing with SHA-1, and while SHA-1 has some weaknesses, nothing that will allow us to easily retrieve the 15 digit key. Let's see what the first part looks like:
echo -n "MTM2MTY2NTYyM3xrZXk9NThiMDI3OXxwcml2YXRlPTB8cHVibGljPTE=" | base64 -d 1361665623|key=58b0279|private=0|public=1
So it's exactly the format that was described earlier. Let's see just how good the signature validation is. I switched public to 0 and private to 1, re-encode with base64, and try to resend the message... Nope, Invalid Signature. Maybe it only validates a certain number of bytes, so I try to append an additional |private=1, encode, and send, but still... Invalid signature. So I vaguely recall that there's some sort of length-extension attack on poorly formed signatures using Merkle–Damgård hash functions. I start Googling and find some code from VNSecurity for Codegate 2010, doing almost exactly the same thing. I decide to give it a try and see if simply appending an additional |private=1 will work. A few moments later, I have a newly signed request which I send off to the keyserver... and there it is, the SSH private key. MD5SUM into the scoring system, and I'm off to Level 7.
Level 7: The Wireshark Firewall?
I didn't manage to make it through Level 7, but the premise was that the SSH gateway was secured by a firewall that was controlled by (of all things) Wireshark. The host in question was completely inaccessible -- a blackhole of packets. I tried a few Wireshark DOS attacks that I had handy (Metasploit) but none of them seemed to make a dent in the system. Unfortunately, the clock ran out before I could find the magic sauce to get into that system and through to future levels.
In my next post, I'm going to talk about some lessons I learned and things I wish I had done differently -- there are definitely many things I could've done better and hope I'll do better in my next CTF.