Are these broadcasts viable for tracking (it seems like they would be)? Is there anything I can do as a user to mitigate the effects (other than turning off WiFi)?
IOS, like the linux's NetworkManager (and probably whatever android, didn't check), just assume that the AP could be hidden and try to connect to it anyway. Those people, that did something as stupid as that(for "user convenience"), later implemented MAC randomization in their network managers. Windows has a checkbox for hidden networks.
>Are these broadcasts viable for tracking (it seems like they would be)? Is there anything I can do as a user to mitigate the effects (other than turning off WiFi)?
Yes. No. MAC address randomization helps somewhat, as per glancing at pdf.
All in all just fire up airodump-ng and see for yourself.
The only way to prevent this behavior entirely is to shut off WiFi.
https://play.google.com/store/apps/details?id=eu.chainfire.p...
You can also set specific MACs per-AP so it'll defeat probe-based attacks too theoretically. This should get it by 4/5 attacks here.
Their RTS/CTS method in particular sounds like it'll be impossible to defeat without Wifi chipset manufacturers simply removing their hardcoded MAC and switching to letting the OS pick it - unless there's a possibility of triggering that change via a driver already, might be time to start looking at datasheets on wifi chips.
- Onboard SPROM: easily modified by a driver, but shouldn't be rewritten to achieve randomized MACs; you'll blow through your flash write cycles.
- Onboard OTP (one-time programmable memory): also easily modified, but it's one-time writable; you can only set bits to 1, never 0.
- External NVRAM / NVRAM image (e.g. supplied by the driver): totally controlled by the driver/host OS, can be set to whatever you want.
Changing this behavior would require changing the firmware image uploaded to the WiFi chipset by the driver.
At the very least, I expected a discussion of arp for IPv4 and ICMPv6/NDP/RA/SLAAC/DHCPv6 for IPv6. But beyond that, I really need to see some discussion on the effect of randomization on L2 security mechanisms like limiting MAC learning on ports. A smart thing to do if you're a network admin concerned about security is to limit the number of MACs that can be learned on a given port/vlan. So randomizing MACs on devices would cause some devices to just drop connection occasionally. The authors don't address this.
It's almost like they don't even realize that MAC addresses are used for things in networks besides invading people's privacy. There might be very good reasons why manufacturers of mobiles do things the way they do them. However, it doesn't look like the author's reached out vendors at all to ask.
The authors aren't proposing the use of randomization while associated to a network. Instead they're showing how current implementations aren't achieving their intent.
It also brings up another question I have which is what about roaming? And what about setups where there are L2 switches between radios and the devices that handle the 802.11 authentication? How does randomization affect learning in those environments?
In general I would have appreciated more discussion on on how randomization affects L2 switches and the protocols I mentioned. Either that, or ask someone at Google why Android behaves the way it does.
Their method to track all devices requires actively sending packets for every single MAC address that is being tracked. The (imperfect) passive tracking techniques can be used to reduce the number of MAC addresses you have to try though. Nice finding overall! And it will likely be hard to patch this issue..
Sometimes there are also silly driver bugs that allow you to get the real MAC address of a device when the user is using a spoofed MAC address :) http://www.mathyvanhoef.com/2013/11/unmasking-spoofed-mac-ad...
