Just another site

Archive for May 2013

Wardriving: Problemo o No Problemo?

leave a comment »

Happy (belated) Cinco de Mayo!  In honor of Mexico (whose El Tri I actually like a heck of a lot less than Les Bleus), today’s discussion of Guerra de Conduccíon has a Spanish language title.  

As noted by noted sarcastor Keith R. “The R Stands for Reassociation” Parsons, in some ways wardriving is a topic whose time has passed.  We’ve known about it for years.  Wardriving tells hackers where your network is.  Most WiFi networks are encrypted.  What else is there?  Hackers can try to connect, but if you use a long WPA2 Personal passphrase, they won’t be able to.  Hackers can try to sniff, but if you’re using WPA2 Enterprise, then decryption of data frames is impossible (as far as us non-NSA employees know).

But imagine you are an NSA employee.  Or the CEO of a noted defense contractor.  Or holder of some other high-profile job where the nation’s prosperity is dependent on your secrecy (like USC’s head football coach).  Then if a hacker knows where you live or work, it could be a problem even if your WiFi is encrypted.  Maybe.

The topic is of interest to the author after a recent discussion with a person who is, in fact, an employee of a noted defense contractor.  The author’s position is that Wardriving could be a problem.  His position is that it isn’t.

Yours truly’s scenario lays out as follows.  Important Person gets on an airplane.  Important Person opens her laptop and dutifully attaches her laptop privacy screen.  After browsing adult videos for an hour (that’s what Important People really do behind those screens, isn’t it?), Important Person does a little bit of work, all the while ensuring that she doesn’t connect to the airline’s potentially-unsecure WiFi.

What Important Person may be unaware of is her laptop is revealing her location.  Check out the capture of probe request frames I got on a recent MCO-LAX (WiFi-enabled) flight:

Highlighted in that Wireshark screenshot is a probe request frame looking for the SSID of “BHNTG862G2332”.  That means that somebody somewhere connected to a WiFi network with that SSID some time prior to fleeing Orlando.

If an enterprising hacker were to take advantage of wardrivers’ data, an enterprising hacker could pin down the location of this Important Person’s home or work.  Check out what Wigle shows when querying the SSID of “BHNTG862G2332”:

Eso mapa (returning to our Mayo de Mejico theme) tells us that somebody on the author’s flight lives pretty darned close to 2450 Euston Road, Winter Park, FL 32789.  

The argument that wardriving doesn’t matter boils down to this: What’s the hacker do now?  The hacker possibly has no idea which person has the probing device.  And even if the hacker does, additional information would be required to make this a National Security issue.

Still, “nadie sufre mas que un hombre pobre o una mujer fea” (I tried to find the Spanish cliché equivalent of “it’s better to be safe than sorry”, with no luck).  If you don’t like the idea that someone can find out where you work or live and you think that wardriving is un problemo, then you can do the following:
  • Disable WiFi when it’s not in use.  (Because no WiFi means no probing.)
  • Broadcast your SSIDs.  (Because most non-Android devices only probe for Hidden SSIDs.  With Android devices you’re unsecure no matter what.)
  • Avoid unique SSIDs.  (If our flyer on his/her way to America’s finest [or second-finest, depending how much you like Milwaukee] city had used a generic SSID like “Radius” at home, then a bunch of wardriving results would’ve popped up on Wigle.  That makes it near impossible for a hacker to narrow down a home or work location.)
Preventing your WiFi devices from revealing your location via wardriving data requires such simple steps.  Home users can just log in to their wireless routers/modems and make sure they have a generic SSID that is broadcasting.  Changes an enterprise’s WiFi configuration to make it tougher for hackers to know where your office is may take some work, but it’s a good idea to at least make that part of the plan the next time the WLAN gets an update.
Of course, all of this is moot if you’re an Android user.  Android smartphones and tablets probe for all saved WiFi networks, whether hidden or broadcasting.  With Android phones, the only way to keep hackers from get information that could reveal the location of su casa is to keep the WiFi turned off when it’s not in use.

Written by sniffwifi

May 23, 2013 at 8:55 pm

We Rally ‘Round The Sniffer (With A Pocket Full Of Cards)

leave a comment »

Ahh, the good ol’ days.  The days when USC was beating UCLA by 50 points, AirTran was flying nonstops from LAX to Milwaukee and WiFi sniffing folks only had to carry one USB card for 802.11 protocol analysis.  Those days are gone, my friends.  It’s time to update which cards we need for which applications.

December of 2011 was a time yours truly looks back on with fond memories for the reasons cited above.  In the wireless world, the good news was that WildPackets OmniPeek had begun supporting monitor mode capture from Atheros-based 802.11a/b/g/n chipsets, thus allowing one USB adapter to be used for any good WiFi sniffing app.

Things change, and when WLAN infrastructure vendors began selling APs that support three-stream spatial multiplexing (thus rendering high rate data frames un-sniffable to the D-Link DWA-160 802.11a/b/g/n USB adapter), the handwriting was on the wall.  The halcyon days of only needing one USB adapter for wireless protocol analysis were numbered.  For a while most client/station devices continued to use one-stream or two-stream spatial multiplexing, thus keeping my old USB friend relevant.

Today, too many devices use three-stream spatial multiplexing for it to be ignored.  If you try to run a protocol analyzer using an adapter that only supports up to two streams, you may end up with a worthless capture.

We can capture three-stream data if we have a three-stream adapter that is compatible with our Wi-Fi sniffing software, but there’s a problem.  No single USB adapter works will every application.  If you want to be ready to use any protocol analyzer, you’ll have to carry around a pocket full of capture devices.

It is doubtful that you come to this-a-here blog [DiCaprio-in-Django-Unchained voice] to see me whine about changin’ tech-nol-gy (see, with a ludicrous Southern Gentleman accent, I can both add syllables and subtract).  So here, then are the current top options for getting a three-stream wireless data capture into a quality Wi-Fi sniffer:

  • WildPackets OmniPeek: Still my favorite Wi-Fi sniffer, and now it has a simple option for capturing 450 Mbps data.  The OmniWiFi adapter is a dual-band 802.11a/b/g/n USB adapter that supports three-stream capture.  
  • Fluke AirMagnet WiFi Analyzer: AirMagnet is still great software, but the capture options stink.  You’re best bet is a laptop with an Intel 6300 internal Wi-Fi interface.  The problem is that rules out virtual machines (since USB adapters are available in virtual machines, but internal adapters are not) and Apple laptops (which use a Broadcom-based Wi-Fi interface).
  • Wireshark for Mac OS X: You can capture using the internal three-stream interface on a MacBook Pro (not MacBook Air) using Wi-Fi Diagnostics and open the captured .pcap file in Wireshark.
And this is even leaving out Wireshark for Linux, which works with the old DWA-160.  I’m unsure if there is a three-stream USB adapter that has monitor mode drivers for Linux Wireshark, but if anyone knows of one leave a comment or email me.
The hard truth is that this re-scattering of capture capabilities is annoying to a person like me, but may not matter as much to a WLAN administrator.  If you’re just going to use one WiFi sniffer, then you can just choose the appropriate card option and go with it.

Written by sniffwifi

May 10, 2013 at 5:02 am

Posted in Uncategorized