Last weekend was the BSides Cape Town conference, currently ZA’s only hacker con. It’s a cool little con with big dreams that get a little closer each time. This year was a lot a fun and well put together, congrats to all of the speakers organisers and volunteers.
SP gave some talks; Charl spoke about where we’re headed in a talk entitled Love Triangles in CyberSpace; a tale about trust in 5 chapters. Chris discussed his DLL preloading work and released his toolset. Finally, Darryn & Thomas spoke about exploiting unauth’ed X sessions and released their tool XRDP, it was also their first con talk ever.
The first hint that the challenge existed was on the challenge portal:
This pointed to the food tickets everyone was given to redeem for food and drink. They looked a little like this:
There were fives types of tickets. The left has what looks like a QR code. However, most QR code readers can’t read them. That’s because the colours have been inverted. This required collecting pics of all the lunch ticket codes, which in-turn required you to speak to some people, since not everyone had all the tickets. Given the low numbers, vegetarians would have been the most popular. These decode to:
left right, up up, skip BA, down down, , left right again
The oldies among us, or those using a simple Google will recognise that as parts of the Konami code. The “skip” part was due to the fact that I read badge code really badly and I thought it didn’t have a B or A button. Then later I hoped it could be used to prevent people just guessing the Konami code (i.e. you type the Konami code, you get one thing, you type the truncated one, you get another). Unfortunately, time was short.
Typing in the real, truncated Konami code; up-up-down-down-left-right-left-right, displayed a sort of riddle;
There's a wifi net you can't see. It's hidden not easy.@JP_14c
This tells you three things, the first is the next part is to do with wifi (although anyone who knows me should have guessed), the second is that it’s hidden in someway, and the third is that there’s a twitter account. The name of the Twitter account was itself a hint, but just in case it had only one tweet that directed people to this link.
In case you didn’t get it, it’s pointing to the fact that there’s a wifi network running on channel 14, a frequency only available in Japan’s regulatory domain.
I had a ton of fun setting this network up. Not only was it running in very low power and on channel 14, so most devices couldn’t see it at all, I also had it doing 802.11n which is not something that should be possible (in Japan it’s only allowed to do 802.11b (i.e. no OFDM). If you’re interested the code to comment out is here. And finally, it was running mana’s proportionality ACLs, so it wouldn’t even respond to probes from other devices. Initially, I did a bunch of editing to wpa_supplicant’s code to get it to connect, but eventually, it turned out that with the right regulatory settings it connects just fine.
However, none of that detail is really necessary, because airodump-ng in it’s default configuration spots the network just fine. The idea with the next part was to teach participants some wifi hacking.
Initially, the network ESSID was http://bit.ly/1Gm8CGe which points to the aircrack newbie guide, with tutorials on how to capture wifi traffic. The intention was to have two data requests going over the network, the first was an HTTP GET request to aircrack’s writeup of packetforge-ng. The second was a UDP packet to the badge challenge server with the string ‘1234567890’ and a varying response containing the cryptographic challenge hash. My hope was that someone would be able to grab the UDP packet, modify it to use their badge number, and re-inject it into the network spoofing the existing connected client. This could be done using three steps:
- Capture & extract the packet
- Modify it to use your badge number
- Re-inject it into the network
Capturing the packet can be done with airodump-ng and the -w switch to write the packets to a file. Just make sure you’re not channel hopping (-c14 would fix it) and ideally filter for just that network with the –bssid switch. The packet can be extracted using wireshark.
Modifying the packet is a three step process. The first is to use your favourite hexeditor to change the badge number from 1234567890 to your badge number. Then re-open it in wireshark, where it will inform you the checksum is wrong, and what it should be. Armed with this, re-edit the capture to change the checksum to the right value.
Re-injecting the packet can be done using aireplay-ng -3 -r <single packet capture> -h <MAC of the actual client connected> -c <BSSID of the AP> -j <injection device>. The response could be captured in the same way as the initial packet was captured.
Unfortunately, due to a bizarre string of technical failures, I was unable to replicate it on the day. Also, everybody I spoke to told me it was too advanced. So I changed the ESSID to another bit.ly link pointing to an Internet-connected, HTTP-version of the badge server. Now all that was needed was to modify the GET request with a new badge number.
Upon completing the challenge, the wifi scanner would be unlocked on the badge, allowing you to scan for wifi networks using just your badge (nice work Andrew).