iPhones Have Been Exposing Your Unique MAC Despite Apple's Promises Otherwise (arstechnica.com) 69
Dan Goodin reports via Ars Technica: Three years ago, Apple introduced a privacy-enhancing feature that hid the Wi-Fi address of iPhones and iPads when they joined a network. On Wednesday, the world learned that the feature has never worked as advertised. Despite promises that this never-changing address would be hidden and replaced with a private one that was unique to each SSID, Apple devices have continued to display the real one, which in turn got broadcast to every other connected device on the network. [...]
In 2020, Apple released iOS 14 with a feature that, by default, hid Wi-Fi MACs when devices connected to a network. Instead, the device displayed what Apple called a "private Wi-Fi address" that was different for each SSID. Over time, Apple has enhanced the feature, for instance, by allowing users to assign a new private Wi-Fi address for a given SSID. On Wednesday, Apple released iOS 17.1. Among the various fixes was a patch for a vulnerability, tracked as CVE-2023-42846, which prevented the privacy feature from working. Tommy Mysk, one of the two security researchers Apple credited with discovering and reporting the vulnerability (Talal Haj Bakry was the other), told Ars that he tested all recent iOS releases and found the flaw dates back to version 14, released in September 2020. "From the get-go, this feature was useless because of this bug," he said. "We couldn't stop the devices from sending these discovery requests, even with a VPN. Even in the Lockdown Mode."
When an iPhone or any other device joins a network, it triggers a multicast message that is sent to all other devices on the network. By necessity, this message must include a MAC. Beginning with iOS 14, this value was, by default, different for each SSID. To the casual observer, the feature appeared to work as advertised. The "source" listed in the request was the private Wi-Fi address. Digging in a little further, however, it became clear that the real, permanent MAC was still broadcast to all other connected devices, just in a different field of the request. Mysk published a short video showing a Mac using the Wireshark packet sniffer to monitor traffic on the local network the Mac is connected to. When an iPhone running iOS prior to version 17.1 joins, it shares its real Wi-Fi MAC on port 5353/UDP.
In 2020, Apple released iOS 14 with a feature that, by default, hid Wi-Fi MACs when devices connected to a network. Instead, the device displayed what Apple called a "private Wi-Fi address" that was different for each SSID. Over time, Apple has enhanced the feature, for instance, by allowing users to assign a new private Wi-Fi address for a given SSID. On Wednesday, Apple released iOS 17.1. Among the various fixes was a patch for a vulnerability, tracked as CVE-2023-42846, which prevented the privacy feature from working. Tommy Mysk, one of the two security researchers Apple credited with discovering and reporting the vulnerability (Talal Haj Bakry was the other), told Ars that he tested all recent iOS releases and found the flaw dates back to version 14, released in September 2020. "From the get-go, this feature was useless because of this bug," he said. "We couldn't stop the devices from sending these discovery requests, even with a VPN. Even in the Lockdown Mode."
When an iPhone or any other device joins a network, it triggers a multicast message that is sent to all other devices on the network. By necessity, this message must include a MAC. Beginning with iOS 14, this value was, by default, different for each SSID. To the casual observer, the feature appeared to work as advertised. The "source" listed in the request was the private Wi-Fi address. Digging in a little further, however, it became clear that the real, permanent MAC was still broadcast to all other connected devices, just in a different field of the request. Mysk published a short video showing a Mac using the Wireshark packet sniffer to monitor traffic on the local network the Mac is connected to. When an iPhone running iOS prior to version 17.1 joins, it shares its real Wi-Fi MAC on port 5353/UDP.
"A bug" (Score:4, Insightful)
"this feature was useless because of this bug" .. a bug, yeah, it was a bug .. wink .. wink
Re: (Score:3)
Apple = Backdoor(s).
Yeah, no.
UDP Port 5353 is used under RFC 3927 for Multicast DNS (mdns) Services to support Bonjour, AirPlay, Home Sharing and Printer Discovery.
Hardly some super-secret "Backdoor".
https://support.apple.com/en-u... [apple.com]
Not a gigantic Security Hole, and one that potentially exists in every single device on every single platform that supports RFC 3927 Discovery Services (which is obviously like a lot); but indeed "Not as Advertised".
However, also trivial to fix without compromising those Services, as Apple has now
Re: (Score:2)
one that potentially exists in every single device on every single platform that supports RFC 3927 Discovery Services
That's why you do apt purge avahi-daemon on every GUI install (if you were lazy and started with canned task metapackages to start with).
Usefulness of staining dead trees has pretty much ended; remaining uses are 99% related to govt-related paperwork which needs MS Office as well -- and that has no expectation of being secure anyway.
Re: (Score:2)
one that potentially exists in every single device on every single platform that supports RFC 3927 Discovery Services
That's why you do apt purge avahi-daemon on every GUI install (if you were lazy and started with canned task metapackages to start with).
Usefulness of staining dead trees has pretty much ended; remaining uses are 99% related to govt-related paperwork which needs MS Office as well -- and that has no expectation of being secure anyway.
I personally rather enjoy being able to use AirPlay to throw a video up on the TV thru my AppleTV box, without having to go through the manual IP Addressing Configuration equivalent to setting Serial Port IRQs with DIPswitches. mdns can't be Routed outside of my LAN, anyway; so whogivesashit?
Besides, this issue is now fixed.
Re:"A bug" (Score:4, Informative)
"this feature was useless because of this bug" .. a bug, yeah, it was a bug .. wink .. wink
Actually, TFS is misleading. It isn't just iOS 17 that was Patched.
Apple actually patched this Vulnerability in all of it's current iOS, iPadOS, macOS tvOS and watchOS versions, as well as several prior Version-levels on October 25, 2023.
See:
https://support.apple.com/en-u... [apple.com]
Re:"A bug" (Score:4, Funny)
When they built new verison iOS, Microsoft OS, and anything Google, they shoved tons of hidden spyware in so that in case any of those spywares is discovered by 3rd party, they call it malware meaning there's a new update coming up to "fix" it. Rise and repeat until every spywares are exhaused like the 10 Little Indians then finally data sniffing companies demand to build next new OS verison with newer and better hidden spywares.
Who's the "They", Mr. Paranoid?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:WINNING! (Score:5, Funny)
Does this mean Melania will be single soon? Asking for a friend.
Re: (Score:2)
with apple you never know (Score:1, Insightful)
Re:with apple you never know (Score:4, Insightful)
if its malevolence or incompetence. They are masters of both.
How does the saying go? Something like one should not attribute actions to malevolence when incompetence will suffice.
To show Apple, or any corporation, is acting out of evil intent would require considerable evidence to show this. For one thing any large corporation will have lawyers, accountants, and so on, all watching out for something that could get the company in trouble with the government. That's not saying what is legal is also moral but given that people tend to write laws based on what they views as moral and ethical there's at least a moderate correlation between the two. For a corporation to do something evil would require a lot of people colluding on the evil practice, and keep the evil acts within the law or somehow out of sight of any government entities that are motivated to stop any evil acts. The government is motivated to stop malevolent corporations because they get rewarded for this by voters and taxpayers to do so.
Then come public relations to put an end to any malevolence. It is not good business to be known as malevolent so a corporation will want to keep good public relations by not doing things that could get them a bad reputation. Since we have a culture with a mistrust of large corporations we reward people that point out malevolent acts from corporations in various ways, and punish those that participate in such malevolence. We discourage incompetence too but in ways different than malevolence. People found to be incompetent would be treated far less harshly than the malevolent, and if the incompetence comes from ignorance or some kind of handicap (and I use a very wide definition for "handicap") then the response may be to educate or some other correction that is hardly a real punishment.
Apple could have said or done nothing about hiding MAC addresses if they were trying to maliciously track iPhone users. By claiming they had a feature to hide MAC addresses from tracking they put themselves under scrutiny if it didn't work as advertised. Maybe this is incompetence stacked on malevolence by getting caught but that gets back to my earlier points that they'd have to know that if they got caught then they could face bad PR and potentially some kind of punishment from government regulators.
Apple has a history of respecting privacy, to a point that it makes some of their products of lower quality than the competition. Google Maps will track people to gather information on traffic and such so it can build better maps. Apple Maps doesn't do this, and so it doesn't have the same level of optimizations on finding the most efficient path. That's not saying Google is acting with malice by tracking people, they just have a different idea on what it means to do the best for their customers. To Google the most good comes from tracking how people move so it can offer the best maps to others. Some people are willing to trade some privacy to get the better maps, others are not.
By advertising they offer a feature to hide the WiFi MAC address of their iProducts it looks to me that at least Apple is trying to protect the privacy of their customers, which is better than what many of their competitors are offering.
Re: (Score:3)
Re: (Score:2)
You have to wonder how it wasn't picked up in testing. They must not have had sufficient automated tests in place to catch it.
Reminds me of the years and years of alarm clock bugs that caused iPhones to fail to wake users on certain dates. If I were one of the developers I'd have written a test script that tried out every second of every day for the next 100 years at least. I'd have run it on a real iPhone too.
Re: (Score:2)
Re: (Score:2)
That looks to be a good idea and maybe Apple could use that too, assuming they don't already. I see downsides to the tactic chosen by Android, because there's not likely to be any perfect solution we are just going to have to choose the least bad option. For people that want data but don't want to pay for it by turning off WiFi away from trusted networks they are using slow cellular data that they pay for than free faster WiFi. By generating a random MAC address on public WiFi there's some privacy with t
Re: (Score:2)
The thing is when you're away from trusted WiFi networks, meaning ones you have an existing relationship with, you're not connecting to anything via WiFi so there's no need to have it on. I have a few trusted-network locations (home, work, a few friends places) that get WiFi turned on, and anywhere else I'm not connecting to anything so there's no need to have WiFi on. The few times I need to connect to a public AP, usually one-offs, I typically need to click through a disclaimer on connect anyway so ther
Re: (Score:2)
Re: (Score:1)
Both Android and iOS use adjacent WiFi networks (regardless of whether you connect to them) for location services.
But they do not connect to those networks for that.
Re: (Score:2)
That looks to be a good idea and maybe Apple could use that too, assuming they don't already. I see downsides to the tactic chosen by Android, because there's not likely to be any perfect solution we are just going to have to choose the least bad option. For people that want data but don't want to pay for it by turning off WiFi away from trusted networks they are using slow cellular data that they pay for than free faster WiFi. By generating a random MAC address on public WiFi there's some privacy with the fast free data, assuming the random MAC address is actually random which in this case we find out is not true.
Then comes problems like possible man-in-the-middle attacks that come with any WiFi that can't be trusted. I see adverts for VPN services all the time so there's people willing to provide some protection against this, for a price of course.
Doesn't Apple iProducts have the feature to not connect to WiFi networks that the user hasn't marked as "trusted"? That sounds similar to the app you describe, and it is built in to the OS. There's many variations on the Android theme so there's likely someone offering something better than what Apple has.
On iOS, "Known" Networks (those you have Connected-to before) are assumed to be "Trusted". This seems logical.
There are 3 levels of Permissiveness when it comes to iOS Attaching to Unknown WiFi Networks (assuming it is not already connected to a Known WiFi Network) :
1. Off: Unknown Networks are Ignored. No Notification to the User.
2. Notify: Unknown Networks are Connected-to Automatically. The User gets a Notification.
3. Ask: Unknown Networks generate a Pop-up Dialog, "Connect to WiFi Network 'BobsFreeWiFi'
Re: (Score:1)
2. Notify: Unknown Networks are Connected-to Automatically. The User gets a Notification.
Something like this I have never seen.
Why would any device automatically connect to an unknown network.
None of my Macs does it nor my iPhones not my Androids, not my Windows laptop.
3. Ask: Unknown Networks generate a Pop-up Dialog, "Connect to WiFi Network 'BobsFreeWiFi'?". Tap "Ok" or "Cancel". This is the Setting I use.
Serisously? What strange OS is that?
You have to pick the network by hand. There is no "pop up: do yo
Re: (Score:2)
2. Notify: Unknown Networks are Connected-to Automatically. The User gets a Notification.
Something like this I have never seen.
Why would any device automatically connect to an unknown network.
None of my Macs does it nor my iPhones not my Androids, not my Windows laptop.
3. Ask: Unknown Networks generate a Pop-up Dialog, "Connect to WiFi Network 'BobsFreeWiFi'?". Tap "Ok" or "Cancel". This is the Setting I use.
Serisously? What strange OS is that?
You have to pick the network by hand. There is no "pop up: do you want to connect to this network, yes or no?" There never was.
You're wrong.
Re: (Score:2)
2. Notify: Unknown Networks are Connected-to Automatically. The User gets a Notification.
Description of "Notify" mode from iOS settings: "Known networks will be joined automatically. If no known networks are available, you will be notified of available networks."
None of the three settings (Off, Notify, Ask) will result in your iDevice connecting to an unknown network without you telling it to.
Re: So Basically Tails? (Score:2)
Re: (Score:1)
There is no device on the planet that connects to random Wifi networks.
You have to pick the network by hand, and then you have an option: auto (re) connect.
Re: (Score:2)
There's actually a really easy fix for Android, there are a bunch of apps that turn off all WiFi unless you're in a specific location, e.g. home or work, that way absolutely nothing gets out at any point since the WiFi is physically shut off. I use one called WiFi Automatic [google.com]. Saves a bit of battery power too if you're not constantly broadcasting/probing for WiFi.
Android lets Apps turn WiFi On and Off?!?!?
Doesn't that seem like a gigantic potential Security Hole unto itself???
Seriously.
Re: (Score:2)
>android lets apps turn wifi on and off without user manually digging through settings to grant said permission explicitly to a specific app?
if it had the above behavior it would be certainly a cause for concern
fortunately the only behavior that does exist is s/without/with
if you want to pretend the latter is a cause for concern though, clown away
incidentally android added faux MAC years before ios
Glad to hear that Google isn't that stupid.
But what MAC address does Android provide on UDP Port 5353? Spoofed, or Real?
Re: (Score:1)
None.
As ports do not see/know MAC addresses.
Why are you asking this nonsense repeatedly?
Re: (Score:2)
None.
As ports do not see/know MAC addresses.
Why are you asking this nonsense repeatedly?
Why don't you understand the difference between a logical Port and a Protocol that uses that logical Port?
Do you understand how the Bonjour zeroconf Discovery Service works? It has only been around since the earliest days of AppleTalk, FFS!
https://developer.apple.com/bo... [apple.com]
https://en.m.wikipedia.org/wik... [wikipedia.org]
Look at this, under "Vulnerabilities":
https://networkinterview.com/w... [networkinterview.com]
Re: (Score:2)
How would YOU do it? Recompile the kernel without WiFi when you don't need it? Pull the WiFi card out (if possible at all)?
Re: (Score:2)
How would YOU do it? Recompile the kernel without WiFi when you don't need it? Pull the WiFi card out (if possible at all)?
No.
Just don't expose that particular Control to Apps .
Or doesn't Android have any way to do that?
Re: (Score:2)
You're aren't answering the question, HOW do you do it without having an app flipping that control. I offered two options, because this is what I see, both kind of outrageous. Do you ANYTHING AT ALL that isn't?
Re: (Score:2)
You're aren't answering the question, HOW do you do it without having an app flipping that control. I offered two options, because this is what I see, both kind of outrageous. Do you ANYTHING AT ALL that isn't?
Do you know what an API is?
Do you know that APIs can have Public and Private Methods?
Just like a random App on iOS can't, say, turn up the System Volume, or invoke Night Mode (I think!), or Initiate a FaceTime Call, because there are no Public API Methods for those things; so could Android not allow random Apps to turn WiFi On and Off.
Re: (Score:2)
You still didn't answer HOW DO YOU TOGGLE ANYTHING if you don't use an app for that? Yes, the app will use some API, protected by certain permissions in the kernel and so on. But again, you are flabbergasted by USING AN APP, how do you do it WITHOUT AN APP?! I offered TWO options:
1. recompile a kernel with different support
2. unplug the hardware.
Do you have ANY OTHER OPTION, that's even vaguely reasonable?
Re: (Score:2)
Re: (Score:2)
Must not have been very obvious (Score:4, Interesting)
It took three years for this vulnerability to be discovered; so I doubt an exploit exists in the wild.
It does seem potentially quite serious, though.
Did the recently-released iOS 16.7.2 Update also fix this? I assume so; since Apple just updated every iOS version back to iOS 15, as well as macOS, tvOS and watchOS on 25-Oct-2023:
https://support.apple.com/en-u... [apple.com]
Re: (Score:3)
It took 2 years for Heartbleed to be discovered in 2014. Most serious security flaws are not "obvious" and require focused effort to discover. That's what makes them so dangerous.
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
It took 2 years for Heartbleed to be discovered in 2014. Most serious security flaws are not "obvious" and require focused effort to discover. That's what makes them so dangerous.
https://en.wikipedia.org/wiki/... [wikipedia.org]
Well, at least it's Patched.
Re: (Score:2)
I noticed this happening a few years ago when looking at my WiFi AP's logs. I figured it was just supposed to work that way, maybe something about it using the same MAC for the same network or something. I should have looked more closely and reported it!
I thought it was crap at the time, because my Android devices rotated MAC addresses regularly and thus were incompatible with any kind of MAC address filtering/pinning.
Re: (Score:2)
I noticed this happening a few years ago when looking at my WiFi AP's logs. I figured it was just supposed to work that way, maybe something about it using the same MAC for the same network or something. I should have looked more closely and reported it!
I thought it was crap at the time, because my Android devices rotated MAC addresses regularly and thus were incompatible with any kind of MAC address filtering/pinning.
From what I read, iOS is supposed to generate a one-time random, but persistent, MAC address per network. That way, you actually can use MAC triggering/filtering on a particular network; while still thwarting attempts to track your Device as you roam from network to network while "out and about".
Apple's scheme is actually more nuanced than Android's, in that it doesn't break desirable local network MAC Triggering/Filtering schemes; but someone at Apple simply forgot to expose the "fake MAC" to the mdns Bonj
Re: (Score:2)
On Android the behaviour depends on the network type since Android 12. For open networks they get a random MAC address every time. For networks that take a key, the random MAC address is persistent, unless an app told the OS to use a non-persistent one.
To me that's non optimal, but better than what iOS was doing.
Queue "you are broadcasting you MAC address" ads (Score:3)
The MACs were never secret on that layer, just the opposite, for decades. Color me surprised if one developer put it in some place without a care in the world and another one who had the job to remove it never knew it's there.
Re: (Score:2)
Of course your MAC address is visible, that's required for the network to function. The problem is that the MAC is unique to the device, and by being unique it allows tracking of that device over multiple networks and therefore the movement of the user of that device over multiple locations.
MAC addresses must be universally unique (as opposed to locally unique like IP addresses used behind NAT) in order to assure there's no improper routing of packets on any network. That's great to keep a large network f
Re: (Score:2)
The problem is that the MAC is unique to the device, and by being unique it allows tracking of that device over multiple networks and therefore the movement of the user of that device over multiple locations.
Not really.
As the MAC is only relevant inside of your network. Outside of the LAN, aka behind the router, no one even sees it. The only way would be a malicious router, recording MAC addresses and sending them "elsewhere".
I guess one could set up "spoof" routers at airports for example, which show up on
Re: (Score:1)
Yes, but data-link-layer protocols don't usually have an equivalent for DHCP. So if you want any device to be able to connect to any network (without the network administrator having to tell the user what IP address to use in their settings), the address has to be unique enough that the odds of an address collision (each time a new device is added to the network) are low enough to not be a problem in practice. The original intended solution to this w
Re: (Score:2)
Except that's what IS happening.
There are companies that buy up this MAC data because it's
Re: (Score:1)
That basically only happens if you are either in the network or are at least having Wifi and Bluetooth on.
I for my part do not do that, unless I need it.The original post was that the MAC address is somehow posted via IP protocols, which is hardly possible or plausible.
Re: (Score:1)
Android core generates random MAC addresses (Score:2)
Re: (Score:2)
FYI, Android core generates random MAC addresses making this kind of tracking impossible.
But does it use them on UDP Port 5353?
Please provide a Citation.
Re: (Score:1)
MAC addresses have nothing to do with ports.
Media Access Controll.
What ever is behind what ever port: never sees your MAC.
Re: (Score:2, Interesting)
MAC addresses have nothing to do with ports.
Media Access Controll.
What ever is behind what ever port: never sees your MAC.
You are an idiot.
Part of the Bonjour Protocol Discovery Packet structure is the MAC Address. That traffic goes over UDP Port 5353.
See RFC 3927.
Re:MAC and Ports (Score:2)
MAC addresses are part of level 2 ethernet protocol, which does not have ports.
Level 3 IP protocol, which defines ports, does not use MAC addresses.
The confusion comes about from an application using level 3 IP protocol sending data over UDP Port 5353 that contains the MAC address. In this instance it's simply data on a port. In principle it could have been anything but the developers chose to use the value of the MAC as the data to be sent.
Re: (Score:2)
@angel'o'sphere is correct!
MAC addresses are part of level 2 ethernet protocol, which does not have ports.
Level 3 IP protocol, which defines ports, does not use MAC addresses.
The confusion comes about from an application using level 3 IP protocol sending data over UDP Port 5353 that contains the MAC address. In this instance it's simply data on a port. In principle it could have been anything but the developers chose to use the value of the MAC as the data to be sent.
Ok; we're both correct.
You are generally correct that Ports, per se have nothing to do with MAC Addresses; but I am correct in stating that the mdns Discovery Protocol", which, yes, is but Data, is nonetheless kind of inextricably-linked to UDP Port 5353, to carry out the mdns "Hail". And that Negotiation ended-up Exposing the Device's *real* Hardware MAC Address, instead of the per-network random address generated by the OS.
Everybody up to speed, now?
The criticism sounds really stupid (Score:2)
Whenever your phone goes on the phone network, the base-station gets your IMEI. It also gets the ID of your SIM card, and it has to because otherwise billing does not work. So the second thing that happens is that your wireless provider knows exactly where you are, because they get the ID of that base-station at the same time. And you people are concerned about MAC addresses? Seriously?
Apple and honesty (Score:2)
Remember those Apple commercials touting how it had better security than Android? It was clearly a lie. The inability to add an antivirus app to the iPhone is the primary reason why I would never depend on one for daily use.