Hacker News Reader

Comment by karma_pharmer | Hacker News Reader

Most wifi baseband firmware "helpfully" leaks the true eeprom-written MAC address in places like management frames and beacons:

https://news.ycombinator.com/item?id=13839540

As of 2017 the authors of the paper above found MAC leaks in a shocking 96% of all android phones. And the remaining 4% aren't proven to be leak-free -- they simply hadn't noticed any leaks by the time they wrote the paper.

Unless you have fully open-source firmware on your baseband, like ath9k_htc, there's really no way to prevent this leakage. Or even be sure if it's happening.

https://wiki.debian.org/ath9k_htc/open_firmware

With open source baseband firmware you can guarantee that the baseband never even has access to the hardware MAC address. You can even reflash the MAC address eeprom (on every boot if you like!)

View on HN

We actually have an intern researcher working on a path towards an open source implementation of 802.11 for wifi 6 cards but do not have an ETA when our first proof of concept will be released.

We've also reported mac leaks to vendors -- we found stations would transmit packets with their non randomized state in certain scenarios, we'll blog about it when vendors release their fixes.

But more importantly I also want to say that I do not expect the MAC leaks are happening in most beacons & probe responses, which is what Apple and Google and others collect for their positional database with wi-fi SSIDs and BSSIDs. There's still ways to fingerprint, from digital fingerprints, to signal fingerprints unique to the radio and antennas and board, where machine learning can cluster and classify devices that are going to be very hard to anonymize for privacy.

Projects like https://www.nzyme.org/ actually apply fingerprinting techniques for defense to detect Rogue APs that could manifest in an actively attacked environment. They can pick up wifi implants as well as the Rogue AP attacks.

an open source implementation of 802.11 for wifi 6 cards

For which baseband chip, specifically?

I mean this would be great, but I have a very hard time believing any baseband vendor gave you enough documentation to achieve that -- especially not without an OSS-prohibitive NDA. Would love to be wrong about that. It happened once, but that was back when Atheros was an independent company -- before they were Qualcommized.

Also, aren't all the wifi 6 baseband firmwares cryptographically signed? Best case it'll be as "open source" as Tivo was.

We've also reported mac leaks to vendors

That's good, but I don't think the whack-a-mole approach inspires much confidence. There have been so many of these problems that at this point we really need to take the car keys away from the drunkard and have the baseband chip and the MAC-bearing eeprom be separate devices which can only communicate via the CPU. Or just have the CPU derive the MAC from the CPU's own serial number. Or maybe just not have hardware MAC addresses at all.

Not all are cryptographically signed, no. We have no special documentation but we are also not directly modifying closed firmware either. We are working with mediatek cards and will post more updates this summer. We last posted about our approach 6 months ago, https://www.supernetworks.org/pages/blog/barely-ap-surfaces.

So the randomization bugs we have reported are specifically about stations, namely: mobile smart phone devices failing to randomize their WiFi MAC address.

As for the study this thread's topic concerns, I do not have reason to believe that there are bugs with MAC randomization in cards running as APs that would make the randomization of BSSIDs fail.

The probe responses and beacon contents appear to consistently use their randomized MAC address in the cards we have tested. There could be underlying actively triggered bugs an active attacker could uncover, to get the non randomized address, but I do not expect such bugs would affect the BSSID + Positional databases of this study.

> I do not have reason to believe that

This phrase has no place in security research.

My comment is not unsubstantiated. When implementing the feature we verified Probe Responses, Beacons, & EAPOL Handshakes work as expected with the randomized MAC for the BSSIDs.

Reply on news.ycombinator.com