Just another site

Archive for February 2011

Brevity is the Soul of Wit (But Not the CWDP Study Guide)

with 3 comments

The CWDP Study Guide was recently released. The certification is valuable and the study guide is great as a reference, but as a book it is just about unreadable.

Certified Wireless Design Professional (CWDP) is a new certification from the CWNP Program, a group that creates and manages vendor-neutral WLAN certifications. The CWNP Program has long had a Certified Wireless Network Administrator (CWNA) and Certified Wireless Security Professional (CWSP) certifications, and here in 2011 they are adding the CWDP and Certified Wireless Analysis Professional (CWAP) certifications.

The spirit of these certifications is that WiFi professionals often work in very specific disciplines, so the CWNP Program has a certification track for most industry professionals. Work for an equipment vendor? You probably want CWAP. An integrator? Probably CWDP. The NSA? CPP. (I jest, I jest. And if any NSA people read this blog, let me request the pain-free truth serum in advance.)

The CWDP exam is the next exam to be officially released (next Tuesday, to be exact), but the study guide is already available. The study guide does what it’s supposed to do in covering all exam objectives, BUT IT’S NINE HUNDRED PAGES LONG! That is crazy. You simply do not need 900 pages to explain how WiFi networks need to be designed.

Admittedly, I had a negative perception of this book before I started reading it due to its length, but after reading it I must say that I was exactly right. The book seems to cover every contingency the authors could think of (business needs, building types, applications, 802.11 standards, mobility, etc.), but it ends up being overwhelming. The book is great as a reference because you get all the equations, estimates and calculations you’d ever need. As a guide for designing a WLAN in the real world, however, the book needed to be about 1/3 the size.

One of my favorite books I’ve ever read is Story by Robert McKee. I love this book for many reasons, but most prominently because it emphasizes form, not formula. It covers what storytelling for movies/television/theater is and why it works rather than breaking down every possible way to plot a reveal for your second act midpoint. (And if you understand that last sentence, you should be reading John August’s blog instead of mine.) It takes a topic (storytelling) that is brobdingnagian in relation to the topic of WiFi design, and covers it in half the number of pages. That is what I was hoping for from the CWDP Study Guide. Instead, I got a book that contains so much information that it is a must-have for WiFi designers and surveyors, but also unusable as anything but reference material.

Written by sniffwifi

February 25, 2011 at 8:02 pm

Posted in Uncategorized

Chiggity-Check Your Phone (With a Sniffer)

with 3 comments

It should come as no surprise that many WiFi-enabled mobile phones sometimes exhibit behavior that makes them vulnerable to attack. In at least one case, you can use a WiFi sniffer to view such behavior so that the proper changes can be made to your phone.

When a WiFi device associates to an access point, it must first go through the process of Discovery so that it can decide which AP is best (based on SSID, signal strength, etc.). Discovery is done either by listening for Beacon frames or transmitting Probe Request frames in hopes of eliciting a Probe Response frame. The Discovery process reveals the same information about an access point (SSID, channel, rates, security, etc.) whether it is through a Beacon or a Probe Response, it’s just that the probing process can be faster because the station can initiate it at any time.

The problem with the Probe Request/Response sequence is that it could lead to an attack. Hackers running sniffing software (for the types of nefarious purposes not advocated on this blog, that is) may view the SSID carried in the Probe Response as a way of figuring out what networks a station is trying to connect to. Hackers may then search for that SSID at wardriving sites like (perhaps trying to find out where you live or work) or create an Evil Twin access point in hopes of causing your station to make a direct association to the hacker’s laptop. Katy, bar the door if that happens. A hacker that has an unsuspecting station associated to his Evil Twin access point can attempt all sorts of attacks, as has been shown over and over again.

To prevent such post-Evil Twin access point attacks from occurring, it is wise to disable the sending of Probe Requests in station devices, especially if those devices don’t need the faster reassociation that those frames were designed for. In Mac OS X, Windows Vista, Windows 7 and Windows XP SP3 stations, this is trivial. OS X stations only send Probe Requests for a short time after the WiFi radio is turned on, and Windows stations disable the sending of Probe Requests by forcing the user to check a checkbox indicating that the SSID is non-broadcasting in order to enable probing. The fault, dear readers, is not within our laptops, but in our phones; that they are probing.

Solving the problem of phones (and tablets, at least in the case of the iPad) sending Probe Requests can be a complicated task. The WiFi client software used by these devices is often primitive. In the case of iOS devices (iPhones, iPod Touches and iPads), users are not presented with a list of Preferred Networks. When you turn the iOS device on, it just starts probing for every SSID you’ve ever connected to unless you’ve tapped the Forget This Network button before leaving the network. And if you forget to tap Forget This Network? Well, you’re stuck. The iOS device will continue to send Probe Requests containing the SSID, but you won’t be able to Forget the SSID until you connect to it again.

So what to do if you have an iOS device (or any other device that you want to protect from Evil Twin access points)? If you want to know which SSIDs your device is sending Probe Requests for, you just need to run a frame capture and filter on the unassociated probes. Here’s how:

  • In AirMagnet WiFi Analyzer, you go to the Infrastructure screen and select Listed By SSID (I’ll add a screenshot next time I’m in Windows) in the drop box at the top of the screen. Any SSIDs that don’t have an AP underneath them are SSIDs that stations are probing for.
  • In WildPackets Omnipeek, you go to the WLAN screen and look under ESSID Unknown –> BSSID Unknown. SSIDs shown there come from Probe Request frames.
  • In Wireshark, use the filter, “wlan.fc.type_subtype == 0x04”. After applying that filter, scroll through the Probe Request frames and see which SSIDs your station is probing for. 
Once you find out which SSIDs your device is probing for, you can adjust your device to make its operation less vulnerable. If your device has a Preferred Networks list, just go into that list and remove unsafe SSIDs (meaning unencrypted SSIDs or SSIDs that would reveal your location in a Wigle search). If your device doesn’t have a Preferred Networks list (like in iOS), then just configure an access point with the SSID you were probing for, and then after your device sees that SSID, tap that Forget This Network button. It may not solve all of the problems with mobile device security, but it will solve one of them.

Written by sniffwifi

February 21, 2011 at 11:40 pm

Posted in Uncategorized