[HN Gopher] iPhones have been exposing MAC addresses despite App...
___________________________________________________________________
iPhones have been exposing MAC addresses despite Apple's promises
otherwise
Author : coloneltcb
Score : 145 points
Date : 2023-10-26 21:59 UTC (1 days ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| dmd wrote:
| So its _only_ function all this time has been making using hotel
| and airline wifi networks difficult!
| tedunangst wrote:
| Odd that it took three years for anyone to notice, if they cared
| that much.
| lapcat wrote:
| The article title is "iPhones have been exposing your unique MAC
| despite Apple's promises otherwise".
|
| "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.
| coloneltcb wrote:
| didn't editorialize, this is what auto-populated when I
| submitted via the HN bookmarklet
|
| but point taken, will edit
| Wowfunhappy wrote:
| I think the original title is baity, though.
|
| 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.
| avidiax wrote:
| > Isn't that how things are supposed to work?
|
| 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.
| wannacboatmovie wrote:
| HN auto-incorrects all-caps acronyms in titles when submitting
| a link. It is a very annoying "feature" with questionable
| purpose because it's nearly always wrong.
| eduction wrote:
| Headline should be MACs not Macs
| move-on-by wrote:
| I don't wish to trivialize this CVE, CVE-2023-42846, but it is
| fascinating that it received a High severity and a base score of
| 7.5.
|
| 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?
| Wowfunhappy wrote:
| The threat model changed.
|
| 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!
| 7e wrote:
| This CVE does not allow decryption (or non-encryption) of
| HTTPS.
| DANmode wrote:
| The point is the expectation not meeting reality - nothing
| about that specific technology.
| rekoil wrote:
| Just strange to use HTTP for comparison when the actual
| problem works just fine.
|
| 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!
| fooker wrote:
| That's what comparisons and analogies are for.
|
| The HTTP comparison helped me understand the issue.
| rasz wrote:
| Pre 14 phones leak MAC to all people around, post 14 phones
| only expose it inside encrypted network phone was allowed to
| connect.
| leventonportera wrote:
| It implies that other devices that are not supposed to report
| their MAC, but do, deserve a high CVE as well.
|
| 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.
| mkj wrote:
| It's best to avoid reading much meaning into CVE scores. So
| much depends on the perennial question "what's your threat
| model?"
| Fnoord wrote:
| This question and many more can be applied on using CVSSv3.
| So a pentester doesn't have to use CVE scores as holy bible
| in their report. A risk assessment can be worked upon by
| those who are going to consider the recommendations in the
| report.
| FireBeyond wrote:
| I don't understand this. By that logic you could go from HTTP
| to a new but buggy and flawed HTTPS (when that was in its
| infancy) and rather than that being considered a vulnerability,
| you could say "Well, everyone else is just using HTTP so they
| deserve a CVE too..."
| teaearlgraycold wrote:
| Should we not mark insecure protocols with tremendous numbers
| of CVEs?
| eberkund wrote:
| No, because the advertised additional security may cause
| people to do things that they would not otherwise have done
| had they not falsely believed the security claims on the
| newer protocol.
| Fnoord wrote:
| Because after iOS 14, users have an expectation of being more
| private when they weren't.
|
| 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.
| lunatuna wrote:
| I get the concern here but probe requests leak so much info on
| who is where even with random MAC numbers that I'm not sure this
| feature matters.
| lilyball wrote:
| > _In fairness to Apple, the feature wasn 't useless, because it
| did prevent passive sniffing by devices such as the above-
| referended CreepyDOL._
|
| 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.
| ikekkdcjkfke wrote:
| So it was an Apple eco-system feature?
| _andrei_ wrote:
| A few years ago I was trying out mdk3's FakeAP feature. It had
| the ability to create thousands of fake APs and crash some
| devices. I was playing around with it on a MacBook that didn't
| have OS X for a few months, as I completely erased it and
| installed a Linux distro on it.
|
| 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.
| staplers wrote:
| There's no good reason (for the users) to do this
|
| Apple has compromised user privacy in the past (China) to avoid
| govt crackdown. I wouldn't be surprised if high-level agencies
| routinely mandate specific "functionality".
| zelon88 wrote:
| I abused this "feature" once to get a machine that had fallen
| out of MDM to connect to a network I controlled. The SSID I
| used was "Apple Store".
| Fnoord wrote:
| Yeah, I witnessed this as well.
|
| 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.
| KirillPanov wrote:
| This is why you use ath9k hardware, folks. You get the source
| code that implements the MAC _and management_ layers so you can
| see exactly what they are doing.
| Fischgericht wrote:
| Here is a somewhat related anecdote:
|
| 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. :)
___________________________________________________________________
(page generated 2023-10-27 23:00 UTC)