Nobody apparently cared?
So it took 3 years for someone to whip out Wireshark and ask "does this really work?"
Three years after Apple introduced a menu setting called Private Wi-Fi Address, a way to spoof network identifiers called MAC addresses, the privacy protection may finally work as advertised, thanks to a software fix. "To communicate with a Wi-Fi network, a device must identify itself to the network using a unique network …
Downvoted for the simple reason that just because a piece of code is described as doing A, B and C, unless you thoroughly test this, you're making assumptions about the competence of the programmer and management who give it the green light
Worldly experience has taught me that we have neither competent programmers or competetent manglment, if we did, CVEs wouldnt be a thing
I have to disagree on the CVE comment.
No-one would deny that a LOT of CVEs come from code that should have been written more securely (field length checks etc.) and thus could have been easily avoided. There will always be the CVEs that are generate due to a system being used in a way that was not envisioned ("I mean, how would use it THAT way!?!") and thus not accounted for.
It's not that nobody cared. In a way it's worse than that. It's that customers just trusted Apple. They were selling a feature that didn't work and customers just assumed it worked. Consumers shouldn't have to check that this stuff actually does what it says on the tin.
The really important question here is how long did somebody at Apple know about this. I'm not suggesting that senior management knew, but somebody down the line probably knew, but didn't think it was worth mentioning it to somebody more senior.
Never attribute to malice what can be explained by stupidity.
As for "consumers trusting apple", well of course. Consumers aren't trained to do otherwise. The question you want is why security researchers didn't find this before, and the answer is - of course - there are only so many hours in the day.
(for what it's worth I've written an mDNS implementation, and I recall having it respond to changes in IP address on an interface was something I considered. I didn't consider changes in MAC addresses, not until now)
The really important question here is how long did somebody at Apple know about this. I'm not suggesting that senior management knew, but somebody down the line probably knew, but didn't think it was worth mentioning it to somebody more senior.
Whatever it is (lack of test coverage, not prioritising the fix, project/middle management sitting on it because they don't know what it is and something more shiny has to get done first), they haven't improved since goto fail nearly a decade ago.
"somebody down the line probably knew, but didn't think it was worth mentioning it to somebody more senior."
Probably not. The team that made private MAC addresses tested their new feature to make sure that, when they connected to networks, the random one was sent to the network equipment and the real one was never used in addressing. Both of those tests passed, so they figured that was all that they needed to do. Meanwhile, the AirPlay team that wasn't even thinking about the feature change because network connection is abstracted away from them didn't think about the fact that what they were doing with MAC addresses was going to cause problems, and the network connection group didn't know about or think they had to deal with code that was used for a completely different protocol. There's a lot of cracks between those two groups for this to fall between. It's not even a thing that simple testers would notice, since the packets sent for AirPlay will have two MAC addresses attached: one where a MAC address normally is which contains the correct, random one, and one encoded in the payload which is the one that shouldn't be there. A testing group would have sent lots of packets and looked for the MAC address resetting to the hardware one, but they probably wouldn't be doing payload inspection to see if it was being leaked in there.
"Didn't know or didn't think about" doesn't work here.
The original iOS MAC randomization worked only in the discovery phase. Around 2016, iOS 14, they were talking about adding MAC randomization in the WiFi communication phase, and in 2020 they were making MAC randomization the default behavior in the WiFi communication phase.
So, two points:
1) They have known for more than 10 years that there was MAC leakage in different phases of the process and different parts of the stack, and have been working on it.
2) They've gone **backwards** in leaking MAC during the discovery phase.
Probably not. The code that changed was in the networking stack, and that worked as expected. The code for detecting AirPlay devices probably didn't change, so there was nothing to indicate that a new error could be in there. The latter point is not guaranteed, but the alternative is that the AirPlay team wasn't thinking about the privacy changes made by those who write the networking stack, which doesn't leave anything obvious in the code.
This has got me thinking, years back I used the Agnitum Outpost Firewall, it included a credentials filter, so that say credit card details (ie. A number sequence I had entered as not wishing to leak) couldn’t be transmitted in the clear, I wonder whether it or the modern security suite replacements would if given a MAC address have detected and thus prevented this leak…
Agree, however, a (good) stateful firewall and security suite is a lot more invasive.
The mDNSResponder isn’t part of the on chip network protocols but an application that would use one of network APIs hence its interactions with the network stack should be accessible to a firewall, if it were correctly designed.
"Regression wouldn't show the blunder in this case. Per the description, the real MAC address was included in an optional field."
Which makes me wonder if the MAC address might have been stuck in that optional field as part of testing, perhaps so that testers could see which traffic belonged to which device. Then when testing was done maybe somebody just forgot to remove the code that struck the MAC address in that field.
The more I think about this the more plausible it seems. And also the worse it makes the screwup seem.
...if they themselves didn't know about it, is there any evidence that anyone else did and had already been exploiting this hole?
I can imagine this might be the case if the entity in question was a state-level actor, but if it were the usual surveillance capitalism parasites tracking consumers in a shopping centre, I'd have thought it'd have become publicly-known already.
(Then again, I wouldn't discount the possibility of it being both, i.e. the former exploiting the convenient tracking possibilities of the latter and legally gagging them to keep their mouths shut).
Well, the purpose of the feature is to somewhat anonymize access to wifi networks, so the 'exploit' would just be monitoring the MAC address of every device that attempts to identify the network rather than just monitoring every device that successfully connects. If you're already doing that then it doesn't seem like this would be much of a hole because presumably you're also monitoring all of the traffic coming in to range of your network. This whole feature seems like the level of anonymity that one used to get by using a payphone, if the people you're trying to avoid already know where you are then it's a fairly surface-level obfuscation and you still need to use VPN and DNS tunneling and so on to actually achieve some level of data security.
Wireshark…
Remember the packet headers are generally sent in the clear.
So it doesn’t stop spoofing, it raises the bar on the ease with which it can be done.
I would assume if you’ve gone to the effort of implementing MAC address whitelisting, you’ve also using WPA2/3 Enterprise ie. Certificates, and not PSK.
"When an iPhone joins a network, it sends multicast requests to discover AirPlay devices in the network. In these requests, iOS sends the device's real Wi-Fi MAC address."
I remember a wi-fi network for client going down because somebody connected an iPhone who was constantly multicasting and saturated that network.
Sky Q set-top boxes did a similar thing until they were patched a couple of years ago. They sent out multicast SSDP requests, slowly at first but then the rate ramped up until the WLAN was swamped. It was easy to see with Wireshark. Until they acknowledged the problem, Sky was telling subscribers to reboot the box every night, but in their forums people were spending money on switches with VLANs, new routers, homeplugs etc. I was lucky as I have a UnifiAP on which I can stop multicasts on the LAN becoming broadcasts on the WLAN.
Did I understand this properly? Did someone say that my laptop MAC address is being usd as an identifier OVER THE INTERNET?
Really?
If that is the case, the people in Cheltenham and Fort Meade must be DELIGHTED!! Yup.....really DELIGHED!!!
But then again, I may have misunderstood.
It is unique, but usually it doesn't make it through to the general internet. Most online fingerprinting attempts don't get to see that address, and therefore can't use it against you. This problem is specifically about devices that are on WiFi networks, which can see the MAC addresses of any devices using WiFi. You have no guarantee that networks you connect to are keeping that address private and not either doing local tracking based on the address or sending it to someone else who is correlating it. That's why Apple and Google decided to use random ones to make this more difficult, but Apple implemented it incorrectly here.