Why Bother, Why Should I Care?

Most people have a misconception about WiFi and assume that the Access Points are always broadcasting somehow to make themselves visible to devices. When device's see a familiar SSID they join, right?

Wrong! Sort of...

Most of the packets flying around which govern Access-Point-to-Client connectivity do indeed originate from the Access Points. However, the 802.11 specification (...WiFi) also allows personal devices to send out 'Probe Requests' blindly around them in the hope that a nearby familiar access point will realise "Hey, that's me! I better Beacon again myself so that device can see me and then elect to connect to me".

But what is a 'familiar access point'? Well, every time you add a new WiFi network to your phone, you essentially add it to your 'favourites'. Most people then forget this and build up a massive list of 'Saved Networks'. Take a look now on your Android or iOS phone, the list is usually in the WiFi settings somewhere.

When your device has WiFi enabled but is not connected to an Access Point it sends out probe requests, sometimes Broadcasts (to 'anyone' who is an access point to respond to), but other times it will explicitly list the name of the network it wishes to connect to. That is what I am interested in, as not only can you 'fingerprint' someone by their unique list of 'advertised' saved networks their phone progressively iterates through broadcasting, you can see where they've been in the real world. If you believe you know someone's phone via MAC Address, you can see their past advertised networks and use a tool like Wigle to see where that network has been recorded in the real world. This is BAD from a security perspective, which is why I find it really interesting, and this will be explained shortly.

Additionally, I had a genuine interest in this subject. I also had to run a Security event stand for prospective Degree Apprentices and thought it would be highly engaging and interactive if I were able to show some that their phone gave away information about them.

How is the Data Acquired (tell me how you do this)?

Acquiring this data is ridiculously easy (it's flying all around you for a start...). I only know how to do this on Linux systems although there may well be Mac and Windows tools I don't know about. Windows certainly supports Monitor Mode.

Does the device support 'Monitor Mode'?

The 'Monitor Mode' functionality, A.K.A. 'RFMON' allows a computer with a wireless network interface controller to monitor all traffic received from adjacent wireless access points and client devices. It is differentiated to the more commonly known promiscuous mode in that in addition to regular packet-sniffing, an assocation with an Access Point or Point-to-Point network is not required. Monitor mode is one of seven modes that the IEEE 802.11 specification allows devices to operate in. For interest the others are Master, Managed, Ad Hoc, Mesh, Repeater and Promiscuous.

Unfortunately, it is not always possible to enable the Monitor Mode on a wireless device, often due to the OS drivers for a particular device not supporting it. Fortunately, my on-board Intel wireless chip does support it and the Linux Kernel drivers support interacting in this methodology. I also have a USB wifi dongle which is what I actually use for scanning since the chip supports it, but also because it allows me to browse the internet and scan at the same time. This is because when you enter Monitor mode on a wireless device it kills any and all connections and the ability to use traditional Access Points. You can absorb traffic, but you can't transmit. Two WiFi chips gets me around this problem, but if it's on-hand then a regular Ethernet cable does the same job.

The easiest way in Linux to check if a device has the RFMON/Monitor mode capability is to run:
sudo iw list.
If the card lists 'Monitor' under the Supported Interface Modes section then you're sorted. Here is an example, see * monitor in there?

Enabling the Monitor Mode Functionality

Really easy. Remember if you want to keep Internet functionality to plug in a cable or have another WiFi device. Then:
sudo ifconfig #address-of-device# down && sudo iwconfig #address-of-device# mode Monitor && sudo ifconfig #address-of-device# up

(For me on Fedora, #address-of-device# is wlp3s0, check with iw dev or ip link sh)

The first command takes the device offline so that we can ... use the second command to re-assign the 'mode' of the Wi-Fi chip and then ... use the third command to bring that chip back up so the OS can interact with it.

Scooping up usable Data!

Now fire up Wireshark and start recording from your Wi-Fi Device. Make sure the 'Monitor' box is checked as shown below and then hit 'Start'.

Depending on how busy the environment is around you, packet data will start flying past. This is more or less everything that is being transmitted around you so expect CPU usage to rise and the packet number in the bottom right of the screen to fly up.

How do we filter out just Beacons and Probes?

This took me suprisingly long to figure out, but having the 802.11 Pocket Reference guide was extremely handy. Look to the left hand side of that guide and you'll see filter commands for 'Beacon' and 'Probe Request'.

Back to things being easy. Click on what looks like a search bar at the top of the Wireshark screen and enter wlan.fc.type_subtype eq 4. This tells Wireshark to filter out only Probe requests (those are the interesting ones which originate from Client devices. However, these Probe requests can be targeted to specific Access Points the device has seen in history (what you're likely interested in!) or they can be generic and 'broadcast' in the hope of triggering nearby access points to respond. We don't care about generic broadcast probes so we can filter this out with this slightly extended Wireshark query.
wlan.fc.type_subtype eq 4 && wlan_mgt.ssid != "". Along with the initial query, we are now adding the rule of not showing 'empty' SSIDs caused by the Broadcast beacons.

Enjoy!

That's more or less it really. You can continue hoovering up packets to your heart's content. Of course if you want to flip things on your head and see the Access Points announcing themselves, swap the '4' in your filter rule to an '8' to see Beaconing. Therefore, wlan.fc.type_subtype eq 8. I can tell you now there will be a lot of them to view.

Statistics and Interesting Findings

I've now run and recorded many different sets in a view different locations. Each time was in a public area such as a coffee shop or an exhibition. I noticed an interesting pattern though, and created the table below to quickly illustrate.

The interesting finding is that besides the Work Office recording, Client devices beaconing out for old access points make up approximately 1% of traffic! This is far more than I expected, and of course it will vary depending upon whether the networks around me are relatively 'idle' or very data intensive. More data will be coming soon.

Why it's bad from a Security perspective...

Alerting when people are nearby

It's very easy to put a script together which will alert someone when a MAC address is seen sending out probes. This allows someone with unpleasant motives to record when someone is nearby or enters a certain 'bubble'.

You can single people out easily

This is easier to do than I thought. It does help slightly if you know someones recent history though. Spot the device type and begin filtering in your Probe results for that specific manufacturer. Then if you know they are an employee of a certain company or have Broadbrand with a certain provider etc., they're easily be filtered out of the noise.

Map where people have been

Not sure quite how useful this is, but as I said earlier you can map SSID's to a geographical location using the Wigle tool. This probably isn't that useful unless you really care where somebody has been in their past.

Degree Apprenticeship Day Successes

I mentioned in the intro that part of doing all of this was so that I would have something to run as a demo for a Security Stall during a recruitment day where I work. Fortunately the overall stand was a success, with this Wi-Fi demo forming a key element. Hilights included:

• One student told me their MAC and I filtered it, showing their device was sending Probe Requests for a lone WiFi network. They looked very confused, saying it was from where they'd recently been on holiday. Sure enough I put the SSID into Google and up came the name of the place they'd stayed.
• I saw a 'Windows Phone' MAC fly by with our office WiFi SSID... Putting two and two together I figured pretty quickly that it was one of my helper's work-phones and added a filter for just her MAC, spooking her by showing all the other access points her work phone was probing for.
• Nearby rapid-broadcast or 'noisy' devices like Sonos' can make finding Probe Requests from personal devices very difficult. Part of it is using filters to hide that spam (I elected to apply a "don't show this MAC source" filter). The other part is I'm fairly sure that with all the Sonos' screaming, other devices were holding back on their transmissions, as I definitely saw fewer probe requests despite the number of devices in the room.
• People turn off their WiFi QUICK when you tell them what you are doing.