I would have expected this for iOS, but for macOS this is quite jarring. I don't think just designing good products is too innovative and that extends to the M1 chips. The negative side of such manufacturers is quite predictable and this is just plainly bad software behavior through and through. Apple isn't user oriented, it just assumes its users won't notice.
IOS still tracks you. Just setup your router though a linux computer with 2 ethernet ports set up to forward traffic, connect to your wifi on your phone, and capture the traffic on the computer. You will see all the DNS requests to Apple endpoints.
installing lulu (application-level firewall) let's you see most (all?) of it. i just wish there was a definitive list of what the endpoint services are. for instance, i have no interest in icloud photo storage, so i'd love to block all those connections at the IP level (not just dns), but i really like using imessage on my mbp, so want to let those through. i'm currently having to figure this out via trial and error (and lots of error, at that).
Who really knows any more. A couple years ago Apple prohibited kernel level firewalls (for security) and rolled out their ContentFilterExclusionList which whitelisted many Apple services, but also created a huge opportunity for attacks. It was quite an appalling gesture on Apple's part.
Since then, attacks surfaced, and they backtracked on their terrible idea.
>> Apple has removed a controversial feature in its macOS operating system that allowed more than 50 of its own apps to completely bypass third-party security tools like firewalls and virtual private networks (VPNs).
>> The ContentFilterExclusionList, introduced in macOS 11 Big Sur, was flagged by the security community and developers late last year as being a potential security risk. This list’s existence in macOS meant traffic generated from Apple software such as Maps and iCloud couldn’t be blocked by a socket filter firewall.
>> Researchers have speculated that Apple excluded its own apps from the oversight of third-party firewalls in the name of overall security. For example, if excluded, these services may continue to receive updates when all web traffic is blocked.
don't be daft the users of this platform implicitly, unequivicably trust that apple is not doing anything bad with this... </sarcasm>
Frankly I'm (unfortunately) not shocked and nor should any other user of any other platform be, this is the norm in the industry right now. I'd like to be able to turn around in 5 years and say I'm glad they turned off all those servers and disabled all that tracking but I'm not counting on it...
I wonder if it's HTTP because of certificate validity problems, wasn't there a case where a Mac couldn't boot to "Online Recovery" mode when the date on the machine is wrong (and therefore it treated the server's certificate as invalid)?
I guess a fix for the above issue would be to first query a server for the current time/date.
>Apple CEO Tim Cook today delivered the keynote speech at the Global Privacy Summit in Washington D.C. The conference, hosted by the International Association of Privacy Professionals, is focused on international privacy and data protection.
Apple is Spyware. I use it out of sheer need.....not desire. it's a crappy ecosystem. it's a dictators wet dream....
Apple is the cause of millions of deaths of year....and they have no intent on fixing themselves. this is what made them big.....support from the global industrial complex..
There are no non-OTA updates available for macOS any longer, AFAIK.
You can download full installers, and do a full reinstall on each point release, but that is prohibitively time-consuming (and still requires internet access to reactivate the device following a drive wipe, which transmits your ECID and other information to Apple at albert.apple.com).
I understand that it may also optionally drop executables on your system at reinstallation time (based on device serial) for devices enrolled in Apple's DEP, which allows for no-click MDM enrollment for serials registered with Apple to an organization, so who knows if Apple can also be compelled at that point to target specific devices with police malware.
There is no good way to set up a new Apple system in a really trustworthy way, as it absolutely requires phone-home during wipe/reinstall (to check to make sure your serial isn't marked as stolen in someone else's iCloud account, among other reasons). I have written about this before.
This is a lot of hyperbole apart from the fact that the data here is transmitted in plain text, which is dumb and more likely to be an oversight. I fail to see how Apple would have something to gain by letting others see this data.
It can be a bit annoying to try and extract the interesting technical stuff from articles with quite a bit of conspiracy-shaded noise in them, but the dumbed-down summary is:
- Apple devices request signatures in order to perform software updates
- Those requests include the device's ECID, which is fixed per-device and used to generate the signature
- Those requests are sent in plaintext to the signing server
- As a result, it would be possible for someone snooping on internet traffic on something like a backbone to correlate an ECID with the IP address the request was sent from, and over time track the movements of a unique device between different IP addresses.
It is worth noting that the ECID is not considered secret information, though it is unique and unchangeable. This is also not a surprising revelation; the functioning of TSS and SHSH blobs has been well-known since the early days of iOS reverse-engineering.
The interesting technical point here is one about the plain-text nature of the request, which could potentially leak (admittedly pretty low-resolution) information about the physical location of a device. Encryption would obviously have no effect on Apple's ability to access the data, so that's a bit of a red herring.
My understanding from the Apple security documentation is that they explicitly opted for using HTTP "rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmware’s attack surface." I'm having a bit of a hard time figuring out how it would be possible to bootstrap an HTTPS session in that environment anyway, though I'm sure some kind of challenge-response process would allow the ECID to be encrypted either way.
But I can't see a reason that requests wouldn't be made over HTTPS outside of this environment by default; it might not eliminate the attack surface but would curtail it quite a lot. It would be interesting to know if there's a specific reason behind that decision. I don't really find it that convincing that it might be done deliberately such that essentially "someone watching a network backbone might be able to figure out what city your ECID is in".
> I'm having a bit of a hard time figuring out how it would be possible to bootstrap an HTTPS session in that environment anyway
The request does not come from the firmware. It's a full on normal macOS application process, in normal macOS, on the main CPU that's doing the HTTP requests. They could easily use TLS.
This is why it strikes me as so odd that Apple is still using plaintext here.
(I don't even think there is internet access available to the ASPs in the traditional sense.)
> The interesting technical point here is one about the plain-text nature of the request, which could potentially leak (admittedly pretty low-resolution) information about the physical location of a device.
There is a set of organizations in the United States which have access to unencrypted backbone traffic, all credit card processing transactions in the country[1] (since 2010 at least!), and every flight record in the country (via the ironically named "Secure Flight") program.
It's not a lot of database querying to take this "pretty low-resolution" data and begin to narrow down which ECIDs map to which PNRs map to which payment cards (which, thanks to BSA/PATRIOT, always map to government ID without exception) with $1000+ payments to Apple for shiny new M1 macs. It's even fewer if you can query Apple's sales database directly without a warrant or probable cause via FAA702.
If you don't think that sort of information is ripe for abuse, you're not thinking very creatively.
23 comments
[ 3.4 ms ] story [ 74.3 ms ] threadhttps://objective-see.com/products/lulu.html
Who really knows any more. A couple years ago Apple prohibited kernel level firewalls (for security) and rolled out their ContentFilterExclusionList which whitelisted many Apple services, but also created a huge opportunity for attacks. It was quite an appalling gesture on Apple's part.
Since then, attacks surfaced, and they backtracked on their terrible idea.
https://www.itpro.co.uk/security/firewalls/358338/apple-drop...
>> Apple has removed a controversial feature in its macOS operating system that allowed more than 50 of its own apps to completely bypass third-party security tools like firewalls and virtual private networks (VPNs).
>> The ContentFilterExclusionList, introduced in macOS 11 Big Sur, was flagged by the security community and developers late last year as being a potential security risk. This list’s existence in macOS meant traffic generated from Apple software such as Maps and iCloud couldn’t be blocked by a socket filter firewall.
>> Researchers have speculated that Apple excluded its own apps from the oversight of third-party firewalls in the name of overall security. For example, if excluded, these services may continue to receive updates when all web traffic is blocked.
Frankly I'm (unfortunately) not shocked and nor should any other user of any other platform be, this is the norm in the industry right now. I'd like to be able to turn around in 5 years and say I'm glad they turned off all those servers and disabled all that tracking but I'm not counting on it...
Third choice: Use a VPN if you're concerned about this, until Apple transmits this unique hardware ID in a secure way
I guess a fix for the above issue would be to first query a server for the current time/date.
>Apple CEO Tim Cook today delivered the keynote speech at the Global Privacy Summit in Washington D.C. The conference, hosted by the International Association of Privacy Professionals, is focused on international privacy and data protection.
Apple is the cause of millions of deaths of year....and they have no intent on fixing themselves. this is what made them big.....support from the global industrial complex..
"MacOS sending HTTP requests with hardware unique identifiers in plaintext is bad because..." would be an example.
You can download full installers, and do a full reinstall on each point release, but that is prohibitively time-consuming (and still requires internet access to reactivate the device following a drive wipe, which transmits your ECID and other information to Apple at albert.apple.com).
I understand that it may also optionally drop executables on your system at reinstallation time (based on device serial) for devices enrolled in Apple's DEP, which allows for no-click MDM enrollment for serials registered with Apple to an organization, so who knows if Apple can also be compelled at that point to target specific devices with police malware.
There is no good way to set up a new Apple system in a really trustworthy way, as it absolutely requires phone-home during wipe/reinstall (to check to make sure your serial isn't marked as stolen in someone else's iCloud account, among other reasons). I have written about this before.
https://sneak.berlin/20201204/on-trusting-macintosh-hardware...
- Apple devices request signatures in order to perform software updates
- Those requests include the device's ECID, which is fixed per-device and used to generate the signature
- Those requests are sent in plaintext to the signing server
- As a result, it would be possible for someone snooping on internet traffic on something like a backbone to correlate an ECID with the IP address the request was sent from, and over time track the movements of a unique device between different IP addresses.
It is worth noting that the ECID is not considered secret information, though it is unique and unchangeable. This is also not a surprising revelation; the functioning of TSS and SHSH blobs has been well-known since the early days of iOS reverse-engineering.
The interesting technical point here is one about the plain-text nature of the request, which could potentially leak (admittedly pretty low-resolution) information about the physical location of a device. Encryption would obviously have no effect on Apple's ability to access the data, so that's a bit of a red herring.
My understanding from the Apple security documentation is that they explicitly opted for using HTTP "rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmware’s attack surface." I'm having a bit of a hard time figuring out how it would be possible to bootstrap an HTTPS session in that environment anyway, though I'm sure some kind of challenge-response process would allow the ECID to be encrypted either way.
But I can't see a reason that requests wouldn't be made over HTTPS outside of this environment by default; it might not eliminate the attack surface but would curtail it quite a lot. It would be interesting to know if there's a specific reason behind that decision. I don't really find it that convincing that it might be done deliberately such that essentially "someone watching a network backbone might be able to figure out what city your ECID is in".
The request does not come from the firmware. It's a full on normal macOS application process, in normal macOS, on the main CPU that's doing the HTTP requests. They could easily use TLS.
This is why it strikes me as so odd that Apple is still using plaintext here.
(I don't even think there is internet access available to the ASPs in the traditional sense.)
There is a set of organizations in the United States which have access to unencrypted backbone traffic, all credit card processing transactions in the country[1] (since 2010 at least!), and every flight record in the country (via the ironically named "Secure Flight") program.
It's not a lot of database querying to take this "pretty low-resolution" data and begin to narrow down which ECIDs map to which PNRs map to which payment cards (which, thanks to BSA/PATRIOT, always map to government ID without exception) with $1000+ payments to Apple for shiny new M1 macs. It's even fewer if you can query Apple's sales database directly without a warrant or probable cause via FAA702.
If you don't think that sort of information is ripe for abuse, you're not thinking very creatively.
[1]: https://www.wired.com/2010/12/realtime/
If these calls are blocked, the update will fail, as they are required.