Saturday, April 18, 2015

BSidesCharm15 Wireless CTF

We've been participating in wireless CTF's for the past two and a half years with the first being at BSidesDC '13. After Shmoocon '15, noticing how the wireless CTF's were growing to include SDR and complex wireless challenges, we decided to go after wireless competitions with the similar focus as any other competition. This focus and preparation allowed us to take first place at BSidesCharm'15.


Research

There's a lot of information about previous wireless CTFs on their resources page. What I did was look through the slide decks of previous competitions to get a sense of what challenges to expect. I took this information to research how to solve each challenge and stand up a lab to practice until perfection.

I also grabbed BSSIDs of the devices they used for previous Fox and Hound, and Hide and Seek challenges. They give this information out at the CTF, but you never know if you can learn something as they do gear checks or communicate with the foxes. OPSEC fail favors the prepared mind.

With the event being so close to us, we decided to visit the location a week prior to survey the wireless emissions in the area, so that we could determine what activity was "normal", and what activity to investigate during the competition. We also had a copy of the map and analyzed various routes a fox may take to evade capture.

    Organization

    Since we had a large organized team for this event, we split the groups into squads with dedicated tasks based on the types of challenges we expected to face. With everyone assigned to various squads with squad leaders. Everyone knew what task to focus on, or who to ask for direction. This reduce duplication of effort, and ensured coverage for various challenges.

    Alpha Team
    Primary Objective: Cracking and Pwning Wifi
    Secondary Objective: Hide and Seek Triangulation

    The wifi cracking portion had two WEP challenges, one WEP challenge that was client only, four WPA2 challenges, and a chromecast challenge.

    Cracking wifi at a ctf doesn't require anything more than a single wifi adapter that can monitor radio packets. This doesn't mean that you shouldn't get multiple adapters dedicated to different channels, just that you don't need to in order to participate at the CTF. I was able to collect the traffic needed to crack 5 of the 7 challenges.in the first half of the first day using a single adapter rotating multiple channels.

    Additionally, if you're always monitoring, you don't need to inject packets or perform any other attack. Let other teams do the heavy lifting, as long as you capture every packet. Of course if everyone is monitoring and not attacking, then no one gets what they need.

    For our team, I took care of the monitoring, restarting the monitoring process each time I captured a new batch of IVs or a handshake. Then uploaded the latest batch to our team server for anyone to attempt cracking. Next to me, I had teammate who is still learning wifi hacking, so I was able to mentor him with the various commands and perform the injections. While these challenges could easily be done solo, learning and teaching are their own rewards.

    One thing I like about the wireless competitions, is that they try to avoid "puzzle" challenges and instead focus on real world scenarios. This often means adding different technologies such as Zigbee and SDR to keep the competition interesting. The challenge I had been looking forward to at this competition involved hijacking a Chromecast.

    Hijacking a Chromecast isn't that difficult, everything you need to know is in this one video. One of the dangers of doing a Chromecast challenge is identifying which Chromecast is part of the competition in the case there are multiple Chromecasts. While we only identified one Chromecast, there was no way to ensure we didn't miss seeing the "correct" Chromecast. Possibly annoucing the device's mac address could possibly help prevent any accidents.

    You can identify potential targets by their station's OUI. Chromecast devices use AzureWave Technologies for their network adapter, and we had collected a few known Chromecast OUIs prior to the event. After the Chromecast challenge had been announced, I began looking for any stations that match the OUIs. Initially, I didn't find any candidates in my currently running capture, but I found it in my initial capture (showing a great example of why to split your captures).

    I provided this detail to the judges and they determine that the Chromecast had been bumped and lost power. With the Chromecast powered back up, I was able to quickly grab control using the Android Chromecast app. When setting up a Chromecast, I needed to associate it to an access point that our competition couldn't connect to, then connect to that access point myself to continue configuration.

    My first choice was WCTF05, which we had just cracked the password of. Sadly, none of the WCTF access points had an Internet connection, and the Chromecast needed updates. We had to reset the Chromecast and snatch it quickly, this time associating it to a teammates phone in XXX mode. This worked, but the bandwidth was painfully low, forcing us to wait three hours for the Chromecast to update.

    At the end, our patience had been rewarded and we were able to play a song on the Chromecast required to complete the challenge.

    Bravo Team
    Primary Objective: Fox hunt
    Secondary Objective: Hide and Seek Triangulation

    We expected the fox hunts and hide and seek challenges to happen all weekend long and dedicated members specifically for these challenges. However, the judges decided to start these challenges on day two of the competition. Having completed most of the wifi cracking and SDR challenges on day one, we were able to have most of our team assist in the hunting.

    The first fox challenge was tagged by a teammate by being at the right place at the right time. She was checking out the TOOOL Lockpick village when she noticed WCTFfox1 with a very strong signal on her phone. She was able to turn around and zero in on the fox who was a TOOOL member.

    The Hide and Seek challenge proved to be a bit more elusive. This was a wireless object located somewhere on the premises. Quickly we noticed a strong signal at one wall of the competition room, but with no sign of a wireless device. We came up with the idea that the device may have a directional antenna pointing at the room from another location.

    With this idea, I first began surveying the directional strength I was receiving in each room, and marking the results on a floor map in hopes that the directions would lead me to the object. This did not work as well as I had hoped. Signals are affected by refraction, diffraction, scattering, reflection, and absorption. Together, these effects cause signals and their strengths to behave in typically unpredictable ways.

    As an example, here is a simulation of an access point's propagation in an apartment.
    For more information, I recommend the following links:

    My second idea was to use other access points as a reference signal. I knew that the chromecast was in the competition room, so as I compared its signal strength to the Hide and Seek device. I noticed that both signals would rise and fall together as I moved about the venue and changed directions. This helped me confirm that the device was in the room with the Chromecast device. Sadly another team beat us to the device before I was able to narrow the search further.

    The second fox challenge had no chance to evade. When this challenge was announced, we quickly cornered it in a Track 1 talk. As a talk was going one, we had to bide our time, with three of our members waiting outside the door for the fox to pass through, and three of our members inside coordinating their signal strengths to pinpoint the fox. We were not alone for long, as other teams soon descended upon the room. As soon as the talk was over, the teammate closest to the fox was able to tag him. 

    Charlie Team
    Primary Objective: SDR challenges
    Secondary Objective: At-Large

    The rest of this section is a write-up of the SDR challenges as provided by Corey.

    When the CTF opened up Saturday morning, I set up my HackRF One and loaded GQRX. I immediately jumped to the 2 meter amateur radio band. The 2m (144-148 MHz) band would have been a likely candidate for people running the challenge to put a signal. Right away I noticed something out of the ordinary; a poorly modulated wide-band FM signal. I started playing the signal out of my laptop speakers, but I could not make out anything useful. My teammate Usako suggested I get headphones. After I got the headphones I was able to make out an automated voice which was reciting the first CTF key. I searched around the 1.25m band and the 70cm band as well. I came across what I thought were more keys, however they were just harmonics of the first transmission.

    After some scrolling and trolling around the bands, I stumbled across a familiar sound in the 6m band. That is the sound of a slow scan television signal. I had installed QSSTV, however I was having problems with it. I used my phone to grab the image using an app called Robot36. I did not get a full clear copy on the image, because I had just placed my phone's microphone by the speaker on my laptop, but it was enough to get the key.



    The next day I used MMSSTV running in Wine to get the full image.
    I imagine this flag was chosen because the ISS was scheduled to transmit SSTV this weekend. SSTV is a popular amateur radio mode used mainly in the HF bands. You can find it most days and nights on 14.230 MHz.

    The next signal was a POCSAG signal in the 33cm (900 MHz band). POCSAG is commonly used by pager systems. Many people who have played with the RTL-SDR dongle may have decoded POCSAG at one time or another to read the message traffic in the local area. When I decoded it using multimon-ng, I noticed the message was “Number 60, your order is ready.” At first I thought this may have just been real pager traffic in the local area. The signal wasn’t as strong as the others after all. However the signal was very repetitive. After seeing the same thing at least 10 times I decided it was time to submit it as a key.

    Finally I came across a signal that was a burst type transmission in the 2m band. It lasted less than a second and repeated about every 10 seconds. To me it sounded like an AFSK1200 signal. I ran it through multimon-ng using the AFSK1200 decoder and got nothing. I toyed with different software, different encoding types, and did all I could to clean up my audio signal for the last few hours. I got nothing. This was very bewildering to me. It should have been an easy decode. Usako said she got an audio sample (the one linked above). I asked her to send it to me. While I was sitting at home I decided to run it through multimon-ng with every decoder enabled. At last I showed me a key.

    How? With what encoding? Simply getting the key was not enough for me. I had to know more. I grabbed my trusty old ICOM R7000 and lugged it to the con. In my opinion nothing beats analog equipment. I used an audio cable to hook it to my computer and ran the signal through multimon-ng again. Much like before, it gave me the key. One by one, I removed decoders until it no longer gave me the key. What was it? Multimon recognized it as something called “UFSK1200.”

    Google doesn’t really say much about what UFSK really is. All the results are based around multimon-ng’s help text. The people running the CTF were actually surprised when I told them I got the message using multimon-ng. They said it was encoded using a program called “minimodem.” Minimodem’s output is known to not be compatible with multimon-ng. That explains why the standard AFSK1200 decoder was not working.

    Along with the four primary SDR challenges, they also had a game during the competition. The object of the game was to find a particular signal before everyone else to claim the points for your team. I claimed the prize for the team during several rounds. I accomplished this by using the FFT on GQRX and opening up my HackRF One to see it’s full 20MHz bandwidth at one time. Once they said “go” I would go up 10MHz at a time. The second I saw the carrier they were transmitting I would raise my hand. In the time it took for them to walk over to me I was able to determine the exact frequency of the carrier and claim the points for my team.

    The main take-away from this CTF was that being able to identify signals is a must have skillset. The best way to get this skillset is to practice, practice, practice. Get some SDR hardware, whether its a cheap RTL-SDR dongle, or a fancier piece of hardware like the Hack RF. Use a good receiver tool like GQRX (Linux and Mac) or SDR# (Windows) and probe the air-waves around you.

    Look at everything and go, “OOOO, what is that?” and try different demodulators on it. If it does not come out as voice, it is probably some sort of digital transmission. Use a site like the Signal Identification Wiki to try and match up the signal you are looking at with something in the known signals list. You may also have to distinguish real signals from random spikes internal to your SDR hardware. It can also be helpful to attend local amateur radio club meetings and learn about the popular digital modes that are being used.

    The Journey Ahead

    Winning is very fun, but it doesn't mean we're done, instead it shows that we're going in the right direction. We didn't complete all the challenges, nor did this competition include all the challenges from other competitions. Certain factors made this competition easier, such as the size of the venue. Additionally other large teams we've seen in the past weren't present at this competition. So there is still definitely room to learn and grow.

    Lastly, I want to say how grateful I am to my teammates. Teams like this aren't thrown together at the last minute, rather they take dedication to learn from our mistakes and practice those lessons until we make it look easy.


    No comments:

    Post a Comment