Just another site

Archive for the ‘Android WiFi’ Category

Galaxy Tab 2.0: Probing Done Right (I Think)

with 5 comments

When we last left off, yours truly had noticed that an Android tablet was probing for Wi-Fi networks even when associated.  This behavior would have been unusual, as consumer-grade Wi-Fi devices historically would probe when unassociated and stop probing once a connection is made.  After a little bit more investigation, it appears there was an extenuating circumstance that was causing all of the extra probing.

I wondered if the Android tablet I have (Samsung Galaxy Tab 2.0 with 65 Mbps 802.11b/g/n WiFi) might have its probing behavior affected by movement, and sure enough it does.

I’ll try to amend this blog post later to add screenshots of my captures, but for now here is a summary of what I saw:

I associated my Galaxy Tab to a WLAN that is on channel 1.  Then I captured on channel 11.  My hypothesis is that an associated device should stop probing on other channels as long as the signal is solid.

Sure enough, once I was associated on channel 1, I stopped seeing Probe Requests coming from the Galaxy Tab on channel 11.  In fact, channel 11 showed no sign of the Galaxy Tab whatsoever.  (What was also interesting that is the only SSIDs I saw in the Probe Requests before the Galaxy Tab associated were hidden SSIDs.  Maybe Android has taken the Windows/Apple iOS approach and enabled probing only for hidden SSIDs.  That’ll be another investigation for another time.)

I started walking with the Galaxy Tab, but made sure that I walked only in areas where the received signal was strong (meaning well above -70 dBm).  My channel 11 capture then started lighting up with Probe Request frames from the Galaxy Tab.  The probing was exclusively using the SSID of the WiFi network I was associated to.

The conclusion I reached (at least so far) is that the Galaxy Tab is doing the right type of probing.  The harm of Probe Requests is that they take up valuable channel time and may open up devices to hijacking attacks.  The value of Probe Requests is that they aid mobility.  It appears that when the Galaxy Tab senses movement, the positive aspect of probing is used.  When the device lies still, the negative aspect of probing is avoided (as long as the Galaxy Tab stays associated).


Written by sniffwifi

June 13, 2013 at 11:09 pm

That Android is Quite the Prober

with 2 comments

No bold type introducing today’s post, as I’m going to keep things short.

I was doing some work last week looking at Android devices (specifically, a Samsung Galaxy Tab 2) and I noticed some very heavy probing behavior.  We were checking out the device’s behavior when it moves from AP to AP, so I set a capture for the target second AP.  I did the test (things went fine, but the WiFi Analyzer app in particular seems to really make Android devices stick to their currently associated BSS) and looked at the capture.

Seeing a ton of Probe Requests from the Tablet was expected.  What wasn’t expected was the Android tablet probing even while associated to the first AP.  Even when the received signal was strong (in the -50 to -63 dBm range), the Android was going off channel to probe and probe excessively.

At this point I’m still trying to figure out if physical motion or an app (or lack thereof) caused the probing.  One thing I am pretty confident in saying already is that updates to Android OS and iOS (the one for iPads and iPhones, not the Cisco one) have really seen the two leaders in mobile operating systems take divergent paths concerning WiFi overhead.  Apple seems to be making their smartphones and tablets probe less, while Android devices are probing just as much, maybe even a little more.

Written by sniffwifi

June 3, 2013 at 10:36 pm

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