The wireless network at the DEF CON hacker conference has been called the most dangerous in the world. Members of the press were warned beforehand that "This is a Hacker Con, so consider the public network at DEF CON profoundly hostile! ... keep your Wi-fi and Bluetooth disabled as much as possible." The press room at the conference offered a private Ethernet connection to the outside world. I heard that staff at the DEF CON hotels (Paris and Bally's in Las Vegas) were telling guests to turn off their Wi-Fi.
In the days after the conference, I ran across four articles from people who attended DEF CON, all with a common theme of avoiding the Wi-Fi.
My defensive stance was taking a Chromebook to the conference. I used the machine, offline, to take notes, saving a copy both to a thumbnail sized USB flash drive and the internal Chromebook storage.
There were two Wi-Fi networks at DEF CON, one was totally open and the other locked down with WPA2/ 802.1x (a.k.a WPA2 Enterprise).
Perhaps I'm naive, but I felt no danger connecting the Chromebook to the public, open, unsecure network. Of course, I would only do so in Guest Mode.
Guest Mode in Chrome OS lets anyone use the machine - no password or Google account needed. It also hides all files stored on the machine by other users. When you log out of Guest Mode, anything you changed (such as saved files, bookmarks, etc.) is un-done.
Of course, I was wary of any web page delivered by the open network. All open Wi-Fi networks are ripe for data manipulation, so if CNN reported that Martians landed at the White House, I would have seen it for the prank it was.
And, I was pranked indeed.
When I first connected to the open network, I went to see what DNS servers I had been assigned. Malicious DNS servers are one of the oldest tricks in the Wi-Fi hackers book. My favorite site for this is DNS leak test and I was shocked when Chrome warned that "The site ahead contains harmful programs". The site was trustworthy both before and after DEF CON. My only clue as to the nature of the hack is that the "https" displayed by Chrome was gray rather than the normal green and there was no lock icon. This combination of indicators is not supposed to happen.
The network deserves its reputation.
Hacking open Wi-Fi networks was all the rage in Vegas, both a DEF CON and the B-Sides conference that preceded it. It was enough already. I found the other Wi-Fi network much more interesting.
This was my first encounter with an 802.1x protected wireless network. All I knew about Enterprise level Wi-Fi was that each Wi-Fi user got their own unique userid/password and that it was complicated to setup because you needed a RADIUS server to authenticate users.
For whatever reason, none of those articles that I referred to earlier about safe computing at DEF CON even mentioned the 802.1x protected network. Strange.
I was a bit lost dealing with the network. While the conference provided instructions for choosing your userid/password, there were no instructions for connecting with a Chromebook, let alone an introduction to Enterprise Wi-Fi for newbies like me.
Connecting from a Chromebook is not as simple as merely entering the WPA2-Enterprise userid/password. There are also certificate-related choices that need to be made, and I was out of my element.
Shortly after my initial attempts to logon to the DEFCON 802.1x network failed, I found myself at a talk in the Wireless Village about Enterprise networks. The presenter asked us to try and login to his test network but, he too, was unprepared for a Chromebook.
Back at my room, search engine research led nowhere. Half of what I read was about problems with a Chromebook on Enterprise networks, the other half was documentation, mostly from schools, about how to logon to their 802.1x network with a Chromebook. At one University, the instructions said to be patient, that it was normal for a Chromebook to take over 10 minutes to make the initial connection.
Google's documentation was disappointing to say the least. It's one thing to say nothing, but when they let Arneil write that a Chrome OS device can connect to "WEP-Enterprise networks" it shows how little they care.
The next day, seeking an expert, I went back to the Wireless Village, but got there too early. Wouldn't you know it, one last try while I was waiting, succeeded.
Judging by some old comments at defconnetworking.org, dealing with digital certificates on the 802.1x secure network has been an issue well before Chromebooks. This year, attendees were instructed to download two certificates, one of which was a root for DigiCert. Android seemed to be a particular problem this year:
It seems like there is a number of Android devices that have issues validating the server certificate for 802.1x authentication. We did some research and it seems like it is a common issue with different Android OS and hardware flavors. We can’t put our finger on it but it seems like it is the native 802.1x supplicant within Android. There are 3rd party supplicants but at this point this is not one that we can recommend. We do not encourage anyone to connect to the ESSID “DefCon” without validating the server certificate.It turns out, that was exactly what I had done on my Chromebook. I had connected it to the 802.1x network without validating any certificates.
I don't know how to install a new certificate into a Chromebook and neither, apparently does DigiCert. Their page on How to Install an SSL Certificate covers everything but.
Fortunately, I was able to discuss this with Luiz Eduardo who ran the DEF CON NOC (Network Information Center). In English, this means he ran the DEF CON network, heading up a team of about a dozen volunteers.
Eduardo has been going to DEF CON since 2001. In the beginning, he said, there was a single open network built with ad-hoc consumer equipment. At some point, the conference needed to get serious about its network and they purchased professional equipment. DEF CON 23 employed about 50 Aruba Access Points and the network was run by an Aruba 7210 controller. This was the third year that Eduardo headed up the networking group.
This years Wi-Fi certificate problem stemmed from the fact that their RADIUS server had its certificate signed by DigiCert (in prior years DEF CON had used a different Certificate Authority). For some reason, Android devices could not validate the certificate. At first, Eduardo's team offered instructions for installing both a root certificate for DigiCert and the RADIUS server certificate but, in the end, they couldn't get this working on Android.
After the conference, I found that an Android 4.4.2 device had three certificates for DigiCert in its root store (Settings -> Security -> Trusted Credentials) and an Android 5.1 device had eight (same click trail). According to their website, DigiCert has 10 root certificates.
I asked Google about this and received no response. DigiCert acknowledged my emails, but has not offered an explanation about what went wrong.
My Chromebook was able to get on the WPA2-Enterprise network only when it was configured to bypass certificate checking. The danger in that, Eduardo explained, was that I might connect to an evil twin network. With all the WiFi Pineapples around, this was not a good idea.
Just as with HTTPS, the certificate provided by the RADIUS server, lets a Wi-Fi client validate the identity of the server. Without this validation, a DEFCON attendee can create a Wi-Fi network, give it the same name as the secure network, and trick someone into connecting to it. WPA2 would still be providing over-the-air encryption, but that would be meaningless while connected to a malicious network.
WPA2-Enterprise networks can only defend against evil twins if the client is configured correctly. My Chromebook was not.
The best defense is turning off Wi-Fi when not in use. After spending a week at security conferences, I will never leave home with Wi-Fi enabled on any device I'm carrying.
Next time, the main defensive tactic that Eduardo and his team employed to protect the DEF CON network.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.