Yesterday on 1 Feb 2021, Apple released macOS 11.2 (Big Sur .2), which removes the
ContentFilterExclusionList that prevented user content filtering applications from blocking Apple first-party apps from accessing the network. This misfeature, originally introduced on 12 November 2020 in macOS 11.0 (the only OS available on the new M1/ARM “Apple Silicon” macs) and initially publicized on Twitter by Patrick Wardle, creator of LuLu, was a major privacy violation, permitting Apple apps to phone home even when you used a firewall like LuLu or Little Snitch to block them.
Fortunately, it’s now removed, and users like me who don’t use iCloud, the App Store, Siri, iMessage, or FaceTime (and have Apple’s analytics disabled) can now upgrade to Big Sur, knowing that it is possible to prevent the device from constantly sending usage data across the network to the manufacturer.
There are several privacy/usage leaks remaining in the OS, but now they can be effectively blocked without affecting the overall operation of the device.
The following testing occurred today, using an M1 Macbook Air with Wi-Fi MAC
The system was booted from 11.2 USB installer media, and
diskutil zeroDisk force /dev/disk0 was run from terminal.
nvram -c was used to wipe all stored NVRAM settings, including network configuration and credentials. The system upon reboot was missing its OS as well as its macOS and system recovery partitions (as expected), and booted to the “exclamation point in a circle” awaiting OS and firmware restore.
The machine was placed in DFU mode, connected with a cable to another machine running
Apple Configurator 2, and
7315f657df2a14b838b9d51eb49cdfff5be090e7) was dragged directly onto the “DFU” icon for the USB2-attached MBAir, restoring the firmware and OS.
On first boot, the system did not connect to the previously-automatically-connected available Wi-Fi network, suggesting successful clearing of NVRAM (which normally persists your Wi-Fi password across reinstalls/OSes).
The system completed the out-of-box-setup (initial country selection, user account creation, et c) without being connected to the network. Location services, analytics, “Screen Time”, Siri, and Touch ID were all declined.
(Has anyone else noticed that Apple’s setup wizards are getting more and more aggressive about prompting you to enable their services, even after you click no?)
The desktop appeared, and the system was connected to a dedicated wi-fi network for the purpose,
DeviceUnderTest. 60 seconds or so of “no activity” simply staring at the desktop elapsed, and the system was rebooted, automatically reconnecting to the test network.
Wi-Fi was then disabled. The pcap on the gateway was filtered thus:
tcpdump -lne -r 2021-02-02.firstboot-unfiltered-11.2.pcap \ -w 2021-02-02.firstboot.filtered-b92a01-11.2.pcap ether host 18:3e:ef:b9:2a:01
The following is all packets to or from
In this few minutes, the system generated 38 megabytes of network traffic.
The following is a list of all hostnames queried in DNS by Big Sur in this pcap:
nostromo:~$ tshark -r 2021-02-02.firstboot.filtered-b92a01-11.2.pcap \ -T fields -e dns.qry.name | sort | uniq | grep -v "_tcp.local" | grep -v "_dns-sd" | grep -v "in-addr.arpa" 1-courier.push.apple.com 1-courier.sandbox.push.apple.com 46-courier.push.apple.com 49-courier.push.apple.com a1051.b.akamai.net a1864.gi3.akamai.net a2047.dscb.akamai.net a239.gi3.akamai.net albert.apple.com albert.gcsis-apple.com.akadns.net api.apple-cloudkit.com api.smoot.apple.com apple-finance.query.yahoo.com appleid.apple.com bag-smoot.v.aaplimg.com bag.itunes.apple.com c.apple.news captive.apple.com captive.g.aaplimg.com cdn.apple.com.c.footprint.net cf.iadsdk.apple.com configuration.apple.com configuration.ls.apple.com cs9.wac.phicdn.net e10499.dsce9.akamaiedge.net e11408.d.akamaiedge.net e12919.dscd.akamaiedge.net e1329.g.akamaiedge.net e16126.dscg.akamaiedge.net e17437.dscb.akamaiedge.net e5977.dsce9.akamaiedge.net e673.dsce9.akamaiedge.net e6858.dsce9.akamaiedge.net e6987.a.akamaiedge.net e6987.e9.akamaiedge.net gateway.fe.apple-dns.net gateway.icloud.com gdmf.apple.com gdmf.apple.com.akadns.net geo-applefinance-cache.internal.query.g03.yahoodns.net get-bx.g.aaplimg.com gsa.apple.com gsa.apple.com.akadns.net gsp-ssl.ls.apple.com gspe1-ssl.ls.apple.com gspe21-ssl.ls.apple.com gspe35-ssl.ls.apple.com help.apple.com iadsdk.apple.com init-p01md.apple.com init.ess.apple.com init.itunes.apple.com init.push-apple.com.akadns.net init.push.apple.com internalcheck.apple.com lcdn-locator-usnkq.apple.com.akadns.net lcdn-locator.apple.com mesu.apple.com ocsp.apple.com ocsp.digicert.com pancake.apple.com pancake.g.aaplimg.com pds-init.ess.apple.com stocks-sparkline.apple.com swcdn.apple.com swdist.apple.com swscan.apple.com time.apple.com weather-data.apple.com weather-edge.apple.com weather-edge.news.apple-dns.net www.apple.com xp.apple.com nostromo:~$ tshark -r 2021-02-02.firstboot.filtered-b92a01-11.2.pcap \ -T fields -e dns.qry.name | sort | uniq | grep -v "_tcp.local" | grep -v "_dns-sd" | grep -v "in-addr.arpa" | wc -l 74 nostromo:~$
All of these 73 hostname lookups happened without launching any apps: no App Store, analytics off, no iTunes, nothing. No Apple ID has been used on the device. The device was set up, analytics and network services declined, connected to network, sat at desktop, rebooted, sat at desktop, and then shut down.
Let’s see what happens when we launch some apps:
nostromo:~$ ssh email@example.com "tcpdump -s 9999 -i ens3 -w - ether host 18:3e:ef:b9:2a:01" | pv > 2021-02-02.applaunch.11.2.pcap
The system is reconnected to Wi-Fi, and rebooted.
One by one, the following apps are launched (via the command-space launcher, which also sends each and every keystroke typed into it over the network):
The “we’re going to upload your hardware serial number” non-consent “consent” screen on these was clicked through, and then the splash pages were permitted to load, and then the apps were closed. The system was shut down.
An additional 47 megabytes of traffic was generated in this additional 2-3 minutes: 2021-02-02.applaunch.11.2.pcap.gz.
nostromo:~$ tshark -r 2021-02-02.applaunch.11.2.pcap -T fields -e dns.qry.name | sort | uniq | grep -v "_tcp.local" | grep -v "_dns-sd" | grep -v "in-addr.arpa" tshark: The file "2021-02-02.applaunch.11.2.pcap" appears to have been cut short in the middle of a packet. 1-courier.push.apple.com 1-courier.sandbox.push.apple.com 26-courier.push.apple.com 34-courier.push.apple.com a1806.dscb.akamai.net a1838.dscb.akamai.net a1864.gi3.akamai.net a1956.dscb.akamai.net a2047.dscb.akamai.net amp-api.apps.apple.com api-edge.apps.apple.com api-glb-den.smoot.apple.com api-glb-usw2c.smoot.apple.com api.apple-cloudkit.com apple-finance.query.yahoo.com apple.com apple.comscoreresearch.com appleid.apple.com apps.mzstatic.com ax.itunes.apple.com bag.itunes.apple.com books.apple.com buy.itunes.apple.com c.apple.news captive.apple.com captive.g.aaplimg.com cdn.smoot.apple.com cdn.smoot.g.aaplimg.com cdn2.smoot.apple.com cf.iadsdk.apple.com client-api.itunes.apple.com configuration.apple.com configuration.ls.apple.com cs9.wac.phicdn.net e10499.dsce9.akamaiedge.net e11408.d.akamaiedge.net e12919.dscd.akamaiedge.net e1329.g.akamaiedge.net e14313.g.akamaiedge.net e16126.dscg.akamaiedge.net e17437.dscb.akamaiedge.net e3925.dscx.akamaiedge.net e5949.dscg.akamaiedge.net e5977.dsce9.akamaiedge.net e673.dsce9.akamaiedge.net e673.dscx.akamaiedge.net e6858.dsce9.akamaiedge.net e6987.a.akamaiedge.net e6987.e9.akamaiedge.net e8143.dscb.akamaiedge.net gateway.fe.apple-dns.net gateway.icloud.com gdmf.apple.com gdmf.apple.com.akadns.net geo-applefinance-cache.internal.query.g03.yahoodns.net get-bx.g.aaplimg.com gsp-ssl.ls.apple.com gspe1-ssl.ls.apple.com gspe19-ssl.ls.apple.com gspe21-ssl.ls.apple.com gspe35-ssl.ls.apple.com help.apple.com humb.apple.com iadsdk.apple.com init.itunes.apple.com init.push-apple.com.akadns.net init.push.apple.com is1-ssl.mzstatic.com is2-ssl.mzstatic.com is3-ssl.mzstatic.com is4-ssl.mzstatic.com is5-ssl.mzstatic.com itunes.apple.com js-cdn.music.apple.com mesu-cdn.origin-apple.com.akadns.net mesu.apple.com news-assets.apple.com news-client.apple.com news-client.news.apple-dns.net news-edge.apple.com news-edge.origin-apple.com.akadns.net news-events.apple.com news-events.news.apple-dns.net ocsp.apple.com ocsp.digicert.com pancake.apple.com pancake.g.aaplimg.com pds-init.ess.apple.com play.itunes.apple.com s.mzstatic.com sb.tv.apple.com se-edge.itunes.apple.com sf-api-token-service.itunes.apple.com smoot-api-glb-den.v.aaplimg.com smoot-searchv2-usw2c.v.aaplimg.com stocks-sparkline.apple.com support-sp.apple.com swscan.apple.com time.apple.com uts-api.itunes.apple.com weather-data.apple.com weather-edge.apple.com weather-edge.news.apple-dns.net www.apple.com xp.apple.com nostromo:~$ tshark -r 2021-02-02.applaunch.11.2.pcap -T fields -e dns.qry.name | sort | uniq | grep -v "_tcp.local" | grep -v "_dns-sd" | grep -v "in-addr.arpa" | wc -l tshark: The file "2021-02-02.applaunch.11.2.pcap" appears to have been cut short in the middle of a packet. 106 nostromo:~$
105 unique hosts looked up this time. Again, this is on a system that does not opt in to any Apple services: no iCloud, no FaceTime, no iMessage, no App Store apps, no Siri, no analytics.
The system was reconnected to the network, and 11.2-block-apple-hosts.sh was downloaded and executed, placing the combined list of hosts into
/etc/hosts in an attempt to perform some simple hostname-based blocking. The system was then shut down.
The system was booted to the desktop, the cursor moved around, and rebooted to the desktop once more.
The same apps were again one by one launched in order and terminated:
The system was shut down and the resulting file: 104KB (~one tenth of a megabyte) comprising 2021-02-02.hostblocking.11.2.pcap.
It’s still sending DNS traffic trying to look up the following hostnames:
nostromo:~$ tshark -r 2021-02-02.hostblocking.11.2.pcap -T fields -e dns.qry.name | sort | uniq | grep -v "_tcp.local" | grep -v "_dns-sd" | grep -v "in-addr.arpa" tshark: The file "2021-02-02.hostblocking.11.2.pcap" appears to have been cut short in the middle of a packet. 24-courier.push.apple.com 36-courier.push.apple.com a1806.dscb.akamai.net a1864.gi3.akamai.net api-edge.apps.apple.com api-glb-usw2c.smoot.apple.com apple-finance.query.yahoo.com apple.comscoreresearch.com apps.mzstatic.com c.apple.news captive.apple.com captive.g.aaplimg.com cf.iadsdk.apple.com configuration.apple.com configuration.ls.apple.com e10499.dsce9.akamaiedge.net e11408.d.akamaiedge.net e12919.dscd.akamaiedge.net e1329.g.akamaiedge.net e17437.dscb.akamaiedge.net e5977.dsce9.akamaiedge.net e673.dsce9.akamaiedge.net e673.dscx.akamaiedge.net e6987.a.akamaiedge.net e6987.e9.akamaiedge.net gateway.fe.apple-dns.net gateway.icloud.com gdmf.apple.com gdmf.apple.com.akadns.net geo-applefinance-cache.internal.query.g03.yahoodns.net get-bx.g.aaplimg.com gsp-ssl.ls.apple.com gspe1-ssl.ls.apple.com gspe19-ssl.ls.apple.com gspe35-ssl.ls.apple.com help.apple.com iadsdk.apple.com init.itunes.apple.com init.push-apple.com.akadns.net init.push.apple.com mesu-cdn.origin-apple.com.akadns.net mesu.apple.com news-edge.apple.com news-edge.origin-apple.com.akadns.net ocsp.apple.com pds-init.ess.apple.com play.itunes.apple.com push.apple.com smoot-searchv2-usw2c.v.aaplimg.com swdist.apple.com.edgekey.net swscan.apple.com xp.apple.com nostromo:~$
All in all I think that’s a pretty good improvement. I’m going to be blocking all/most of these hostnames/third-level domains at NextDNS, my DNS provider, and I imagine you could accomplish much the same in Pi-Hole or some similar project. This, coupled along with a (now working) user firewall (I intend to use LuLu) should be sufficient for my purposes.
It will be interesting (read: time-consuming and toilsome) work trying to figure out which hostnames beyond the obvious ones (such as
swscan.apple.com) will need to be unblocked to receive OS security updates. Apple, if you’re listening (like you apparently were last time), putting critical OS patches/checks on a small number of consistently named hostnames, and publishing/documenting that list, would be hugely beneficial for those of us who want to avoid vulnerabilities while hard opting-out from Apple’s other nonconsensual network services.
Blocking this list of hostnames, coupled along with the fact that macOS will now no longer prevent LuLu and Little Snitch from working against Apple’s own embedded OS spyware in 11.2 means that I’m saved from having to switch to KDE and the shitshow that is PC laptop hardware for at least a few more months. (Did you know there are precisely zero good GUI email clients for Linux?!)
(I recently received an XPS 13” for testing, and while the 300+ ppi screen is amazing (also, it’s an option), you’re fooling yourself if you think this thing can compete with Apple laptops.)
The quest for a computer that allows me to boot, open a local text editor, write some words, save them on a disk, quit the program, and shut down without snitching to the network continues. (This is mild hyperbole: Pop! OS on the XPS 13 is already there; I just can’t stand the plasticky keyboard, the shitty GPU, and the terrible desktop environments available for Ubuntu-alikes.) Winston Smith would be proud, I think.
I’m starting a video series soon that’s going to highlight these sorts of widespread, invisible processes that happen with our tools and technology, generally without our knowledge. It’s a scary thought, but Apple devices and software, while chock-full of network surveillance, are actually some of the least intrusive in the industry. Make sure you sign up at sneak.berlin/list to be notified when my video series launches if you’re interested in this kind of stuff.
If you’re really concerned about privacy for these things, do what I do, and keep it behind a separate VPN router at all times (a VPN client on the device itself is insufficient). At my home and office I have a dedicated vlan/ssid for such things, with a PC Engines apu2 as WireGuard client and gateway, and on the road I have a GL.iNet GL-E750 which takes a SIM card, speaks LTE/4G to the tower, runs OpenWRT and a WireGuard client (on which I have root and access to iptables/tcpdump!), has a battery, and provides Wi-Fi. I don’t put SIM cards in any of my Apple devices any longer, nor do I ever connect them to the unfiltered, un-VPN’d internet. My iPhone 12 Pro (sadly, my last) has never had a SIM card in it, and never will.
This may seem a bit extreme, but all iPhones/iPads (and now Macs!) maintain a persistent connection to Apple at all times (to APNS, for the receipt of push notifications), with a unique identifier, which permits Apple to construct a detailed track log of your device via the geolocation of the client IP that connects to the service. This, coupled along with the unique identifier, lets them (and any other service your devices frequently connect to with a unique ID) see when you switch from your home ISP to your mobile carrier, from your mobile carrier to your work ISP, or when you go to a different city or town. I’ve nothing to hide, but I’d prefer that the people who constructed my laptop not forever receive a realtime log of when I’m at or away from home; that strikes me as unreasonable. Apple’s marketing around privacy seems to assume that people desire privacy from everyone but Apple themselves.
Stay safe out there, and keep in touch.
Jeffrey Paul is a hacker and security researcher living in Berlin and the founder of EEQJ, a consulting and research organization.