Apple random generated MAC addressing

  • 1
  • Question
  • Updated 4 years ago
  • Doesn't Need an Answer
http://arstechnica.com/apple/2014/06/ios8-to-stymie-trackers-and-marketers-with-mac-address-randomiz...

In adding MAC address randomization during Wi-Fi probing, Apple manages to both eliminate a potential privacy leak and drive companies interested in location-based advertising toward a solution it prefers.
Interesting things on the horizon.
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
  • ubertooth

Posted 4 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Wouldn't the best solution be for wireless devices to simply not probe for any remembered SSIDs that are not hidden?
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
Maybe the last thing in Pandora's box is all we have.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
The only thing that concerns me with their purported approach is that you still get information disclosure from the set of SSIDs that get probed for. They are like a fingerprint for a device that give a pretty high degree of confidence around which you can correlate to get a statistically useful match.

If Apple use a constant randomized MAC address while probing for the set of remembered SSIDs, you are very likely to get a usable fingerprint.

Even if Apple do this better and use a different randomised MAC address for each discrete SSID, if these are at regular intervals or you can perform triangulation against a client that is probing, this can be worked around.

They only proper solution to me seems to be to not probe and rely on the beacons to know that a BSS is available for clients to attempt to connect to.

I actually think Apple should drop support for hidden SSIDs, forget about randomizing MAC addresses and simply stop probing.

Nick
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
I was under the impression that each probe was sent with a new MAC address. Assuming (heh) that these addresses are properly randomized, wouldn't this stymie fingerprint attempts?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Yup... This is even more egregious on iOS devices as you cannot easily manage the list of networks, only choose to reset the settings so that they're all lost.
(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Still a step in the right direction, though.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Is it though if it gives a false sense of security and just requires tracking software to be reworked? And why not simply just stop probing relying instead on beacons?

It is really not adding up for me.

Your home SSID, your work SSID and those of a few places you alone visit in aggregate will likely provide a unique key for your device. Even if not unique, with location tracking and habits, you'll quickly be able to assign a high confidence.
(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
It's certainly more difficult to correlate the randomized MAC addresses, at least in theory, though it'd be interesting to see a PoC of device fingerprinting with the new scheme.

Also, w/r/t ending probing entirely, that's an interesting point. Let's extrapolate to an entire deployment of devices that no longer probe. Does this seem to cause any issues? I'm not really familiar enough with the guts of probing to answer that question.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
It is more involved to track without a MAC address but I wouldn't go so far as saying it is more difficult in the sense you're suggesting though, which is that it is prohibitive in a barrier to entry sense. The techniques for big data, Bayesian style analytics is already here and it only has to be written by or for a company once and it can be distributed to many.
(Edited)
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Is this not going to severely break load-balancing and band-steering capability?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Band steering is only necessary where the client does not behave well to begin with.
Apple's devices with the recent iOS releases are normally pretty aggressive at trying to use 5 GHz. They could ensure simply ensure they behave well here in iOS 8.

We have 802.11k for better load balancing in the newer Apple devices. Of the iOS devices that will have 8.0 available, only the iPad 2 lacks this.
(Edited)
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Don't disagree with regards to band-steering - it's very hit and miss anyway depending on the client's behaviour, though in some instances even Apple devices need some encouragement from band-steering.

Load-balancing is more of a problem though...
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
The feature as Apple have presently implemented it won't be affected:

https://community.merunetworks.com/merunetworks/topics/will_meru_networks_virtual_cell_stuff_break_w...
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
That makes sense. Probe "anonymously" to see what SSIDs are available and then probe "non-anonymously" once we see an SSID to which we'd like to connect.

There's still a potential problem I guess. Band-steering in particular relies on the AP determining that a client is 5GHz capable by "noticing" scanning probes from the same MAC address transmitted on both radios. This put the MAC address in a table of 5GHz-capable devices (see "show band-sterering status") which would then allow an AP to ignore probes and association requests on the 2.4GHz radio for clients that it knows are 5GHz-capable.

If we can't identify a client from its scanning probes, then we have less time/information to establish that a client is 5GHz capable. I can still see this potentially making band-steering less easy to accomplish.

It shouldn't cause a problem for load-balancing though.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
My expectation was that no device should send SSID-specific probes for non-hidden SSIDs. Why would they need to firstly, and secondly it would be incredibly inefficient to do so as well as being a big security risk (advertising to the world that I would LOVE to connect to an SSID called XXXX) - this is why hiding SSIDs is very bad for security - it forces clients to have to send SSID-specific probes and advertise what they are trying to connect to.

Just to confirm this, I have done a quick network capture and I only see iOS devices behave the same as other operating systems, i.e. SSID-specific probes are sent only for:

Hidden SSIDs
The SSID to which the device is currently connected

which is what I would expect.

Otherwise, the probes they send regularly (with a frequency that varies depending on whether the device is in active use or in a sleep state) are "Broadcast" probes (i.e.with the SSID Parameter Set field empty) which result in a probe response from an AP for every SSID.

So the anonymisation of probe requests would not allow correlation through fingerprinting the SSIDs being proved for, because (non-hidden) SSIDs are not probed for specifically.

Disabling support for hidden SSIDs would cause a lot of problems as so many people have implemented hidden SSIDs falsely believing it improves security when in fact it reduces security and efficiency.

With regards to band-steering and load-balancing, I had forgotten that Aerohive made a change in their implementation a few releases ago where in addition to selectively not-responding to probe requests from clients, ASSOCIATION requests to the 2.4GHz radio would be actively refused (by the AP pretending it cannot support any more clients). Unfortunately this broke Android Samsung devices pretty badly (due to a Samsung bug, which has since been fixed in later Android releases) and may cause unexpected behaviour with other devices, but it would allow band-steering and load-balancing to function even if probes are being sent from a randomised MAC.

It seems that the change in behaviour I mention above was either deliberately done to accommodate this upcoming change in behaviour of Apple devices or was quite a prescient change.
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Disabling support for hidden SSIDs would cause a lot of problems as so many people have implemented hidden SSIDs falsely believing it improves security when in fact it reduces security and efficiency.
I know that (as of at least a year ago) that was still Cisco recommended best practice. Thanks!
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
It's still on many "best practice" lists, though I haven't seen it recommended by any Enterprise vendor for many many years, basically from the point where client devices started providing a way to automatically connect to "remembered" hidden SSIDs (e.g. Microsoft as of XP SP2).

I'd genuinely be interested in knowing where you've seen it recommended as best practice by Cisco - if they were recommending it a year ago, they must have had schizophrenic tendencies as I've looked through a dozen configuration best practice guides on their website going back many years as well as a couple of their security white papers and nowhere can I see that being their recommendation (all the config examples have SSID broadcast enabled) and indeed their security white papers explicitly recommend against it.

It used to be a requirement in the PCI DSS standard too until they realised it was not such a good idea (PCI DSS v1.2 onwards, so six years ago).

Microsoft also used to recommend hiding SSIDs as "best practice" at one point but are no longer doing so and instead explicitly recommend against (as of 7 years ago!) http://technet.microsoft.com/library/bb726942

There are a few situations where hiding SSIDs has some small benefit from an aesthetics/usability perspective, but there are many more situations where it has no benefit or is actually detrimental.

The primary reason against hiding SSIDs is that if a client is configured to automatically connect to a hidden SSID, it must actively transmit non-broadcast probes for that SSID. That means as you sit in Starbucks drinking your coffee, your device is actively advertising to all within earshot that it would dearly love to connect to SSID x. If I want to try to hack into your laptop, you've just given me a useful piece of information, namely that if SSID x were available, you would connect to it - so I can set up an SSID on my laptop (pretending to be an AP) to try to get you to connect.

For "Open" SSIDs, it is then trivial. You will connect and I can see all your traffic and possibly, depending on how secure the rest of your laptop is, gain access to your laptop itself.

For encrypted SSIDs, I can also have a go at tricking you into connecting. The worst case (for you!) is if you are expecting to connect to an SSID configured for WPA(2)-Enterprise mode and your client settings are not set to authenticate the RADIUS server (in Windows, this is the checkbox that says "Validate the identify of the RADIUS server"). In that case, I just advertise the SSID and when you try to authenticate I just say "Access Granted" regardless and I've got you. That is why it is SOOOO important that clients are configured to authenticate the RADIUS server certificate is signed by the expected CA and has the expected subject name. I've lost count of how many times I've seen devices with these settings unconfigured!

From an efficiency perspective, sending those non-broadcast probes just wastes air time. The more such SSIDs a client has in its list, the worse it is.




(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
I'd genuinely be interested in knowing where you've seen it recommended as best practice by Cisco 
It was in their CCNA Discovery curriculum, though as I understand it they've updated since then, and I no longer know what they say in particular there.