back to article Apple Private Wi-Fi hasn't worked for the past three years

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 …

  1. Gene Cash Silver badge

    Nobody apparently cared?

    So it took 3 years for someone to whip out Wireshark and ask "does this really work?"

    1. Clausewitz4.0 Bronze badge
      Black Helicopters

      Re: Nobody apparently cared?

      Now you know how many bugs are lurking around in millions of servers/computers/networks, just waiting to be exploited.

      1. Natalie Gritpants Jr

        Re: Nobody apparently cared?

        Now you know how many people who care about privacy use Apple devices.

    2. Headley_Grange Silver badge

      Re: Nobody apparently cared?

      That would require testing. When I used to manage development projects there was always whingeing about the cost and time taken to test, but at least we did it. Today it seems that testing is more and more being devolved to customers.

    3. Geoff Campbell Silver badge
      Facepalm

      Re: Nobody apparently cared?

      I do a lot of Wireshark testing on Apple devices. Perhaps ironically, the first thing I do is turn off private networking so that I can be sure they get the same IP address every time.

      GJC

      1. Anonymous Coward
        Anonymous Coward

        Re: Nobody apparently cared?

        Private networking generates a different mac address per WiFi network. It doesn't generate it on the same WiFi network. So turning it off, while you test, to ensure the device gets the same IP, doesn't seem to make sense...

        1. Anonymous Coward
          Anonymous Coward

          Re: Nobody apparently cared?

          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

          1. Alumoi Silver badge

            Re: Nobody apparently cared?

            You can have all the competent programmers and competent manglment you want, it's the accountants that fuck everything up. And nobody, not even HR, dares to stand up to them.

            After all, they pay the big fat bonuses to the CEO.

          2. Psion1k

            Re: Nobody apparently cared?

            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.

        2. Anonymous Coward
          Anonymous Coward

          Re: Nobody apparently cared?

          Some iterations of it do.

          Source : IP, MAC address table on my home router

        3. Geoff Campbell Silver badge

          Re: Nobody apparently cared?

          You're assuming many things. It's way easier to just turn it off, and get a consistent MAC address for the DHCP server to glom onto.

          GJC

        4. Anonymous Coward Silver badge
          Facepalm

          Re: Nobody apparently cared?

          And what if you have multiple SSIDs on your network, with one DHCP server behind them. Perhaps a different SSID for 5GHz vs 2.4GHz? Really not that uncommon in domestic settings let alone where someone is explicitly testing things.

    4. Roland6 Silver badge

      Re: Nobody apparently cared?

      Longer,

      As obviously the original Apple developers didn’t use Wireshark…

    5. jollyboyspecial

      Re: Nobody apparently cared?

      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.

      1. Suburban Inmate

        Re: Nobody apparently cared?

        "somebody down the line probably knew, but didn't think it was worth mentioning it to somebody more senior getting the sack or losing out on promotion."

        IMHO this whole thing stinks of shady workplace culture.

        1. Androgynous Cupboard Silver badge

          Re: Nobody apparently cared?

          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)

        2. Roland6 Silver badge

          Re: Nobody apparently cared?

          They probably did mention it to someone, however (*), that person was a recruiter for Google, so job offer swiftly followed and all were happy…

          (*) https://www.theregister.com/2023/10/26/register_kettle_insider_threat/

      2. Dan 55 Silver badge

        Re: Nobody apparently cared?

        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.

      3. doublelayer Silver badge

        Re: Nobody apparently cared?

        "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.

        1. david 12 Silver badge

          Re: Nobody apparently cared?

          "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.

    6. The Man Who Fell To Earth Silver badge
      FAIL

      Re: Nobody apparently cared?

      Don't you know? Everybody was holding it wrong.

  2. Anonymous Coward
    Anonymous Coward

    See also: regression testing

    Yes, device makers. That means when you introduce a new feature, you repeat the previous tests on the old ones. It may seem very 1960s but then so was the never-since repeated moon shot.

    1. Clausewitz4.0 Bronze badge
      Black Helicopters

      Re: See also: regression testing

      Regression wouldn't show the blunder in this case. Per the description, the real MAC address was included in an optional field.

      1. MatthewSt Silver badge
        Coffee/keyboard

        Re: See also: regression testing

        If anything, if this was working properly it should have caused the regression test to fail.

        Maybe when the dev wrote the feature they had to add the original MAC address in to make the test pass

      2. Headley_Grange Silver badge

        Re: See also: regression testing

        Code review/inspection should have picked it up, shouldn't it?

        1. doublelayer Silver badge

          Re: See also: regression testing

          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.

      3. Roland6 Silver badge

        Re: See also: regression testing

        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…

        1. Anonymous Coward
          Anonymous Coward

          Re: See also: regression testing

          Filtering credit card details would have been application layer inspection of payload data. Mac addresses are layer 2, application leyer firewalls wouldn't touch them

          1. Roland6 Silver badge

            Re: See also: regression testing

            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.

      4. jollyboyspecial

        Re: See also: regression testing

        "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.

  3. Michael Strorm Silver badge

    This doesn't excuse Apple's incompetence, but...

    ...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).

    1. fromxyzzy

      Re: This doesn't excuse Apple's incompetence, but...

      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.

      1. The Man Who Fell To Earth Silver badge
        Happy

        Re: This doesn't excuse Apple's incompetence, but...

        Good thing it was a shitty as most other Apple security features, as the WiFi networks I manage all use Mac Address Whitelisting in addition to WPA2 and WPA3 logins.

        1. Mr Tumnus

          Re: This doesn't excuse Apple's incompetence, but...

          It's trivial to spoof mac addresses,so your mac address whitelisting is broadly pointless

          1. Anonymous Coward
            Anonymous Coward

            Re: This doesn't excuse Apple's incompetence, but...

            If you don't know the address to spoof, how do you spoof it?

            1. Roland6 Silver badge

              Re: This doesn't excuse Apple's incompetence, but...

              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.

              1. Anonymous Coward
                Anonymous Coward

                Wireshark

                “You keep using that word. I do not think that word means what you think it means” – Inigo Montoya

              2. Anonymous Coward
                Anonymous Coward

                Re: This doesn't excuse Apple's incompetence, but...

                Seems that even if you've scanned the Wifi spectrum to identify a MAC to spoof, you still aren't on the network to use that spoofed MAC.

  4. Anonymous Coward
    Anonymous Coward

    Testing?

    Did Newton reattach the apple to the tree?

    1. Will Godfrey Silver badge
      Coat

      Re: Testing?

      Too late. He'd already eaten it by the time he thought about it.

  5. Potemkine! Silver badge

    "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.

    1. Fred Dibnah

      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.

  6. Anonymous Coward
    Anonymous Coward

    Confused old person reading The Register....again.....

    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.

    1. doublelayer Silver badge

      Re: Confused old person reading The Register....again.....

      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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like