iPhones have been exposing MAC addresses despite Apple’s promises otherwise
arstechnica.com
arstechnica.com
I don't know if all Android version do this by default, the one on my phone does: Whenever it connects to an AP, it generates a new random Fake-MAC. So, it's not a per-SSID permanent MAC, but a new one on each reconnect.
Now, at Bahrein Airport the WiFi coverage is somewhat spotty. Due to this you have lots of devices reconnecting. And each time they register with a new MAC.
The DHCP server behind their WiFi has a least time of 14 days. And even with them having chosen a /16 IP range for their DHCP, at an airport you can already imagine that those limits are not clever.
And even worse: The system is self-DDoS'ing. This is because every time a phone connects, and the DHCP server has run out of IPs, after a couple of seconds the phone will disconnect, and then try to reconnect - with ANOTHER random MAC address.
The solution I used myself (and showed to a couple of other people in the lounge was) was disabling the privacy feature. This way your MAC would stay the same. You then would keep hammering the AP until one of the thousands of leases had timed out and a IP was available again. You'd then get this IP, and due to your MAC staying constant having reconnects to it (for example because you went to the toilet) also aren't a problem.
So, let this be a lesson to those administrating large public WiFis: Now that devices use random MAC addresses, consider to make your DHCP pool larger, and the lease time much shorter. Unless you are Tom Hanks, you would not typically stay 14 days in an airport terminal. :)
Their IT defines a MAC address as a connection. If your device uses random MACs, plan on disabling that in advance or spending half an hour on the phone with their tech support to get your device back online.
Reminder to self: bring my own AP next time.
ipconfig /all
ipconfig getpacket <interface>
cat /var/lib/dhcp/dhclient.leasesI do not even have this as an option except in the developer settings. I get either a per-SSID permanent MAC (the default) or the device's actual hardware MAC.
Enabling that setting (which, as noted, is enabled by default) gives you a permanent per-SSID MAC address that is used for that connection. It's listed under "Network details" on the same screen, as the "Randomized MAC address". For my local home network, my "randomized", in the sense of being more fixed and eternal than the stars, address is 76:78:c9:94:2a:94, and I cannot change it, other than by changing the setting. The only other MAC-address-related option on this screen is "Use device MAC". If I switch the randomized MAC off, and then switch it back on, I still have exactly the same "random" address that I am required to have for all of time.
However, if you enable the developer options, you can find the option for "Wi-Fi non-persistent MAC randomization". It says "When this mode is enabled, this device's MAC address may change each time it connects to a network that has MAC randomization enabled."
(This is all on stock Android, on a Pixel phone.)
You shouldn't confuse the name of a setting with the behavior that setting controls. The name of the setting is lying to you.
Sqlite's "autoincrement" column modifier is another good example of this phenomenon. It's named "autoincrement", but as the documentation for the modifier notes, you will get autoincrement functionality on a primary key column regardless of whether that modifier is set, and the behavior controlled by the setting is something entirely different. ("Autoincrement" means that values in that column, once they have ever existed, may never exist in another row, even if the row in which they originally existed has been dropped. You may notice that this has nothing to do with the meaning of the word "autoincrement". Other people have noticed that too.)
Or adopt IPv6 with NAT64! All mobile devices support this now since many large mobile networks are adopting it, Apple requires apps support it to be approved for the App Store, etc.
Devices reporting their MAC is standard practice. All these apple devices did it as standard practice as well before iOS 14. Yet, they added the buggy feature in iOS 14, and get a high severity CVE in return. Just fascinating. How does this work? Does it imply other devices that report their true MAC address are deserving of a high CVE as well?
If I'm using HTTP, and my traffic is unencrypted, there isn't a vulnerability.
If I'm using HTTPS, and my traffic is unencrypted or can be decrypted, there's a serious vulnerability!
If I'm connecting to WiFi normally, and expecting that I can be tracked, there isn't a vulnerability.
If I'm connecting to WiFi using this privacy feature, and expecting NOT to be trackable, yet someone is still able to track me, there is a serious vulnerability!
The HTTP comparison helped me understand the issue.
This has to do with a bug seriously compromising a feature. It does not reflect the overall security rating of the entire device. If I have a one-way data diode sending telemetry from the flight controller to a passenger's entertainment console, it works as intended - which is why they put in a layer1 one-way diode. When you have a feature, you use that feature for a scenario where it is useful.
If the flight controller data diode has a second fiber and allows it to be hacked from a passenger seat entertainment center, that is a high severity. It does not mean every network switch has a high severity security issue, because we don't put those into flight controllers that hook up to entertainment centers.
Let's do a car example. If I rent a Uhaul to move my piano, and it splits in half from the weight, this is a serious malfunction. It does not mean the mini-coop croaking from a piano loaded on it's hood is also a serious malfunction.
Let's do a food example. If I put an empty metal frying pan on a stove and it bursts my house into flames, this is a serious problem with the frying pan. If I put it in the microwave and it does that, that's not a problem with the frying pan.
You can apply this anywhere:
FDE being broken.
Zero days being used on journalists.
Security theater post 9/11.
Your 4 y.o. choking on a toy deemed unsafe for age 0-3.
I started toying around with the FakeAP, pretty impressed by the huge list of networks with random names that were now appearing and dissapearing.
But then, I was struck with horror. Something must've happened inside the hardware, because the network names were not random anymore. It was still advertising new networks like crazy, but they had the SSIDs of the networks I had connected to in the past. From the work network, to all the coffee places I went to, friend networks, etc.
I have my beef with Apple, and the fact that they store the networks you connect to on a chip is just a part of it. There's no good reason (for the users) to do this, and it shows a complete disregard for privacy.
There's no good reason (for the users) to do this
macOS too, at least previous version (not sure if still). I know this from installing a Pineapple (which has the same feature [1]) and seeing my SSID from home in it while the machine was at that point connected to wired, and not at home at all. This was approx 4 years ago, a few months before Covid pandemic.
Either way, don't have Auto Join on. And, wired as much as possible. I guess in some point in future we only end up using mmWave and no more 2.4 GHz.
[1] Nowadays you can do this too with a Flipper Zero e.g. with wlan dev board.
Did you? Sounds like you're using MacOS. GP said he wiped MacOS and installed Linux, but sees SSIDs which persist from MacOS. Like those SSIDs got saved in hardware.
I am convinced there is definitely a Reality Distortion Field but that it works both ways.
That is the first I've ever heard of such a thing, and it sounds implausible.
If network SSID history is/was stored on the T2 chip, then it could likely be removed using MacOS settings before installing another operating system.
https://blog.quarkslab.com/reverse-engineering-broadcom-wire...
Wasn't passive sniffing the primary issue being defended against? So it sounds like it actually did the most important job.
I am really curious how it managed to put the real MAC into this particular mDNS packet though, when presumably all other network traffic uses the randomized per-network MAC.
"please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html
Also, "Macs" in the submission title makes it look like Apple Macintosh rather than Media Access Control address.
but point taken, will edit
I mean, yes, I suppose the title is technically correct. But phrased another way: there was a security vulnerability which someone found and reported to Apple, and Apple fixed it. Isn't that how things are supposed to work? Unless you expect everyone to write perfect software on the first try.
If your company is prioritizing security and privacy, no, this is not how it's supposed to work.
This shows a failure of the process. By design/default, this MAC address should not be available to system or user processes in IOS. In general, even the randomized MAC address should not be available. The fact that it was available to the mDNS process indicates that there was no security/privacy review of its existing access, no technical measure implemented to break that access until a review or exception was put into place, and no test plan that validated that the MAC address is never sent on the WIFI radio.
"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."
Makes you wonder if there’s anything else that might be missed.
Then you don't have to care what some daemon does with that random number.
Instead of worrying about handling these unique identifiers, solve the problem at its source: get rid of the unique identifier. Much more reliable solution. The baseband firmware is the lowest level of software at which this fix can be made (everything below it is hardware). If you fix it at some higher level you can never be sure the fix hasn't been circumvented.