MacOS Location Privacy Red Pill: A Rabbit Hole Resulting in 24 CVEs

# Presentation outline and time planning ### Introduction and technical overview (10 min) 1. **Welcome, whoami and Agenda** (2 min) 2. **Motivation** (3 min) 3. **Technical foundations: SIP and TCC in macOS** (3min) 4. **Previous work & scope of research project** (2 min) ### Body of presentation (28 min) 5. **Vulnerabilities in the macOS Persistence layer and caches** - 5 min 6. **Information disclosures within application state restoration files and logs** - 3 min 7. **Forcing network error log messages by strategically disrupting network connections** - 5 min 8. **Reconstruction of precise user location by utilizing user interface metadata** - 5 min 9. **CVE-2023-28195: Hidden deep link + information disclosure resulted in potential 24/7 location surveillance - tracking your iPhone from your Mac!** - 5 min 10. **User localization via logic vulnerability within the CWWiFiClient Apple developer API - CVE-2023-40384** - 5 min ### Summary & conclusion (7 min) 11. **Summary & deployed mitigations** 2 min 12. **Underlying design issues & security architecture review** 4 min 13. **Special thanks** 1 min ### Thanks for coming, contact & Q+A. (15 min time for questions) # Detailed presentation description ### Introduction 1. ##### **Welcome, whoami and Agenda** - Hello & welcome everyone! - My name is Adam, an independent security researcher focusing on macOS Security, application security and security architecture. I have an university degree in computer engineering and I am a former senior software engineer. I enjoy making music and doing all kinds of outdoor sports in my free time. - Agenda: [Show compact overview of the outline as presented above] 2. ##### **Motivation** - Previous investigations and research have shown that data brokers sell location data and movement profiles of literally everybody [1] – including US military personal [2] – for as little as 12 cents [3]. This practice has raised concerns, as it’s regarded as a threat to privacy & national security by law makers and researchers [3] [4]. - Regulators, privacy engineers and developers struggle to keep up with pace of the tracking & analytics industry – as the data analytics market size is projected to grow with a mean annual growth rate of 29.4% [5]. [Graphic_1] *Source: [5]* - Tracking and ad-revenue based companies are quite creative & aggressive in expanding their data retrieval strategies. Numerous application SDK’s collect sensitive data, often without the knowledge of the developers who link those into their macOS Applications. - Location information is inherently privacy sensitive as it reveals a lot about us: Where do we work and live? Which cities, organizations & institutions do we visit? How does our weekly routine look like? When are we on a vacation and not at home? 3. ##### **Technical foundations: SIP and TCC in macOS** - **S**ystem **I**ntegrity **P**rotection (**SIP**) protects sensitive parts of the macOS operating system. Not even root privileges will grant you the right to read or write SIP protected directories. - The TCC-database (**TCC** = **T**ransparent, **C**onsent and **C**ontrol), stores the rules dictating which applications are able to access which data and sensors of the system (e.g. location, microphone, contacts etc.) in a database protected by SIP. In other words, TCC as a privacy feature builds on top of the security guarantees provided by SIP. - [Show graph visualizing the security architecture & how SIP and TCC work together to enable privacy promises] - Privacy protections such as TCC are absolutely critical measurements to protect user location privacy and enabling the user to make an informed decision before tracking and data retrieval occurs. [Show example of TCC in action: macOS asks for user permission for location access] - [Show graphic showing different kinds of location access requests and granularity] 4. ##### **Previous work & scope of research project** - Previous impressive research has shown, that macOS security mitigations enabling privacy promises such as SIP & TCC need further hardening, as shown by Patrick Wardle in 2016 [6], Wojciech Reguła & Csaba Fitzl in 2021 [7], Mickey Jin in 2022 [8]. - Both macOS and iOS position the Location Services restrictions in the privacy menu at the very top of their Settings view – underlining their prioritization and sensitivity. Furthermore Location Services controls are very fine granular and can be enabled and disabled for all kinds of System Services: [Graphic_2] - Many Apple applications and system services have privileged access to Location Services, but much of this extended user space attack surface seems to be undiscovered. - **Main ideas guiding my research project:** **Can we retrieve precise current & historic user location data by attacking applications and system services that hold special privileges instead of attacking SIP or TCC itself? If so, how can the architecture of the relevant components be re-engineered to be further strengthened?** ### Body of presentation 5. ##### **Investigation of macOS Persistence layer and caches** - Many Apple applications with special entitlements (= specific privileges on macOS) store location data in databases or caches. - Apple’s main persistence framework Core Data builds on top of sqlite3. - **Simply opening an entitled Apple application with special privileges and executing basic SQL queries** with the sqlite3 utility command, allowed to first **refresh** the user location data and then **retrieve** the updated entries, which were hidden in these application and system databases. - Note: Applications can be opened in a hidden state — thus the user will not be alarmed. * **CVE-2023-42957**: Retrieval of precise user location from the location query cache of the Maps app. - While reverse engineering the Maps application, I have found an interesting cache database, that has contained many geographic coordinate pairs. - This "location query cache" caches the geographic coordinates of recently viewed locations within the app. - Further analysis has shown, that It was possible to influence the behavior of the application cache mechanisms by **corrupting this cache database or simply deleting it altogether**. - Corrupting/deleting this Maps app cache leads to an exception handler call re-building the database the at the next application start. - By triggering a new data fetch right after startup, only one geographic coordinate pair will be in the Maps location query cache – the **current user location** coordinate pair. * **CVE-2022-32875**: Retrieval of long term movement patterns of users via Weather widget database. - This issue was particularly problematic: A not sufficiently enough protected database of the Weather widget has allowed for retrieval of historic user location data of **up to 3 months in the past**. [Show video exploit retrieving of historical locations of last 3 months]. - Storing this geographic location data in that high precision was absolutely unnecessary for its purpose within the app – a reduction of precision whenever possible should be desired. - Apple has fixed this issue just within 6 weeks after my report – which is very fast compared to other submissions to the program. - The issue has been fixed by restricting access to this database, which is now protected by System Integrity Protection (SIP). 6. ##### **Information disclosures within application state restoration files and logs** - The new macOS Weather app – introduced in macOS Ventura – has brought its own custom state restoration mechanism, containing current user location information within cached data - fully unprotected. **CVE-2022-42866** - Some applications simply logged location data in cleartext when refreshing certain user data, such as TV (**CVE-2023-42830**), Weather and Maps (**CVE-2022-46703**) – which could be triggered by other malicious applications. - WeatherKit REST API design is very problematic: User location stored in URL parameters instead of request or response body (**CVE-2023-23511**). This is a bad practice in general as this location data most likely gets logged unprotected on the load balancer and API server side as well. - Most *unfortunate* vulnerability, which was exploitable with one single command: **CVE-2023-32392: ContextStoreD logged your location every 30 minutes into the debug logs automatically – by default!** It doesn’t happen often that your scanning zsh script becomes the exploit itself, but this is essentially what has happened here. [Show grep command] 7. ##### **CVE-2023-32415: Forcing network error log messages by strategically disrupting network connections** - Most application refresh their data upon starting up. - As the **timing of app start is attacker controlled** – we can open an application and roughly measure the amount of time it needs for sending its initial HTTP requests. - We can then interrupt the internet connection right after the HTTP request has been sent, but **before** the HTTP response has returned. - The PoC exploit needs a couple of rounds within a loop to achieve this reliably – 10 rounds have resulted in a success rate of roughly 95%. - [Show graphic showing timing of HTTP request, connection interruption and expected response time] - Forced Network error of this exploitable network “race condition” reveals the precise user location. 8. ##### **CVE-2023-38605: Reconstruction of precise user location by utilizing user interface metadata** - Many macOS applications utilize Apple’s MapKit framework to visualize the user location. - MapKit uses a transformed coordinate system, which is supposed to simplify route and distance calculations by mapping the earth surface on to a flat surface transformation within a 2 dimensional coordinate system only consisting of positive values. - The Weather app and the Find My Widget both logged these special MapKit map mapping values into the logs. - This user data was enough to reconstruct the internal state of the MapKit objects used within those applications. - More importantly: As both of these applications displayed the user position in predictable parts of their map views, this became an exploitable issue. - As an attacker, we can reconstruct a (hidden) *shadow MapKit map*, initialize it with the exact same state by using the retrieved metadata and then use the MapKit APIs of this shadow copy to extract the precise user location out of that MapKit object. - MapKit stores the user precise location in Double format. Thus the location retrieved through MapKit API’s is very precise even if the map is zoomed out to continent level. [Show Screenshot of reversed application demonstrating location information is lossless]. - [Show exploit video targeting MapKit map of the Weather application] - A variant of this exploitation strategy was **CVE-2023-23537**, which was a similar MapKit metadata disclosure in the Find My widget, leading to another TCC Location services bypass by targeting the victim’s AirTags. [Graphic_3] *Find My Devices Feature - source: https://support.apple.com/en-my/guide/findmy-mac/welcome/mac* 9. ##### **CVE-2023-28195: Hidden deep link + information disclosure resulted in potential 24/7 location surveillance - tracking your iPhone from your Mac!** - The Find My application on macOS displays the position of all the people who share their location with you, all devices and all the items to which you have attached an AirTag. - Spooky: The devices tab in the macOS Find My application has leaked **all geographic coordinates of all Find My devices of that user into the logs!** - This alone was not enough for exploitation, as the application usually doesn’t start in that tab. We need to a) open Find My in a hidden state and b) navigate to the devices tab in order to exploit the issue. - Sometimes, the universe aligns all stars for you: Reversing the Find My application revealed one undocumented deep link, allowing us to open the application and switch to the devices tab in one step – exactly what we needed! - Why does this deep link exist in the first place? I can only speculate here, but it may have been implemented in order to bypass the app tutorial during automated UI testing and unfortunately has made its way into production code. Alternatively it could be a deep link another Apple app or service uses to refer to certain Find My enabled devices of the user. - This bug was quite problematic, as the information disclosure continues, even when the Mac is sleeping. Thus a malicious application could have monitored user behavior and then open the Find My application in a hidden state, just before the Mac is put to sleep to not raise user suspicion. - Actual user location got updated every 2-5 minutes – thus these movement patterns were very precise. - This means, an attacker could have **tracked not only your current Mac location, but all your steps 24/7** by tracking the location of your **iPhone, Apple Watch, AirPods or whatever else you own which has Find My enabled.** - It’s worth noting, that iPhone offers an opt-in feature, allowing Find My tracking **even when the device is turned off.** - This vulnerability demonstrates the security engineering challenges of distributed localization systems: An ecosystem in which all your devices work & communicate together might be very convenient, but it also introduces unique exploitation opportunities for the attacker side. - [Show exploit video displaying current & historic locations of the user’s Mac and iPhone]. 10. ##### **CVE-2023-40384: User localization via logic vulnerability within the CWWiFiClient Apple developer API** - The **CWWiFiClient** developer API is part of the Apple Core WLAN module (available for macOS 10.6+ & Mac Catalyst 13.0+). It is “A wrapper around the entire Wi-Fi subsystem that you use to access interfaces and set up event notifications.” [9]. - More specifically, the class object **CWInterface** [10] – which can be retrieved via a shared CWWifiClient object and basically wraps an IEEE 802.11 network interface – has a method called *scanForNetworks(withName:)* [11]. - Interestingly, calling this method indeed has resulted in access to **all nearby Wi-Fi access point SSIDs** (SSID = Wi-Fi name) including the corresponding signal strength, security settings and Wi-Fi transmission channel – **without** raising TCC precise user location permission prompt. - In contrast to an access point BSSID (= MAC address), however, an access point SSID is not unique. - In this particular scenario it will *still* be possible for an attacker to reconstruct the precise location, because the likelihood of two fully equal sets of 10-20 Wi-Fi access point SSIDs existing in two different geographic locations is extremely unlikely. From that perspective, a large set of nearby SSIDs should be seen as a **unique geographic fingerprint** and the respective signal strengths as the apartment number of an address. - As we are able to map every SSID to its corresponding (unique) BSSID, which geographic coordinate mappings are publicly accessible, classic Wi-Fi trilateration is trivial for an attacker. [Graphic_4] - An attacker would not even need to implement this himself: There are two public Wi-Fi location database API’s, which allow for direct SSID look ups, as stated by the following table [12]. - Thus, precise user localization by any malicious application or attacker was possible simply by using this Apple Developer API – right from the application sandbox! ### Summary, conclusion & special thanks 11. ##### **Summary & deployed mitigations** - **Privacy engineering** for user location privacy **is hard**: Location information can be represented in various forms and hide in all kinds of corners across the operating system. - The amount of vulnerabilities found, however, indicate fundamental deficiencies in Apple’s macOS privacy architecture and protection strategy for location data on macOS. - Every part of the stack from persistence, application cache, network layer, application logic and even user interface structures as well as symmetric design principles have contributed to the security vulnerabilities presented here – highlighting the need of teams across all layers to design and develop with privacy & security in mind. - The more interconnected our desktop and mobile devices become, the more artifacts and traces will be created and stored on them – thus making it even harder to defend user location privacy. - Apple has introduced new mitigations in macOS Sonoma in order to protect persisted application data – this alone will **not be enough** as we have seen. 12. ##### **Underlying design issues & security architecture review** - Access to log stream for everyone is questionable. Very high bandwidth data stream, disclosure of sensitive information thus likely. Apple could introduce TCC protection for accessing logs. Alternatively: Most developers, security engineers and admins utilize the logs, but average users usually don’t. Tie application access to logs to installation of Xcode developer tools or developer mode. - Some of the vulnerabilities that I have found indicate that an increase of **privacy focused integration testing** coverage within developer build pipelines could have been quite beneficial. A notable challenge: MacOS virtual machines unfortunately do not support Location Services due to their virtualized network bridges, thus automation in cloud environments remains difficult. - Localization API’s and the locationD daemon are codebases with a long history. The core architecture and developer API’s were not designed for TCC with the macOS non-sandboxed application environment in mind. Location privacy guarantees are significantly stronger on iOS. - In many cases, storing the user location in the highest possible precision was simply unnecessary — as it was the case within the Weather widget database. Reducing precision whenever possible would have made certain issues non-exploitable. - Need to shift responsibility away from developers and towards the framework level: When logging [CLLocationCoordinate2D](https://developer.apple.com/documentation/corelocation/cllocationcoordinate2d?language=objc) objects in the logs, these entries should **redact themselves automatically by default**. In fact, most geographic coordinates on the system should be considered privacy sensitive. - Alternatively, a sustainable and scalable future mitigation of TCC Location Service bypasses could be an API architecture refactoring of CoreLocation API’s in Swift and design “*privacy sensitive*” protocols implemented by CoreLocation classes. This would enable a more granular and precise way of enforcing sensitive information redaction at compile time – even if these sensitive class or struct variables are nested deep inside other objects. [Show architecture enhancement and small class protocol code example to illustrate this idea]. 13. ##### **Special thanks** - **Special thanks to:** Patrick Wardle, Csaba Fitzl, Wojciech Reguła, Mickey Jin and Thijs Alkemade and many others in the macOS Security Research community who have inspired me to start this macOS security research project. Without you much of this work would have not been possible. Thank you for sharing your knowledge and methodology in all of your great blog posts, informative conference talks and awesome books. - **Thanks to the Apple Product Security team** as well as all **software, privacy & security engineers** at Apple who have worked with me to get all of these issues fixed – your work is highly appreciated! - Over 90% of these 24 CVEs have been rewarded with a generous bounty payment. A part of these bounties have been donated to charity — which Apple **doubles** if donating through the program — resulting in a total donation sum of $41.000 USD in the scope of this research project. 14. ##### **Thanks for coming, contact & Q+A.** ### References [1] https://www.eff.org/de/issues/location-data-brokers#:~:text=Our%20location%20privacy%20is%20under,of%20private%20and%20state%20actors. [2] https://techpolicy.sanford.duke.edu/data-brokers-and-the-sale-of-data-on-us-military-personnel/ [3] https://news.bloomberglaw.com/privacy-and-data-security/brokers-sell-military-members-data-for-pennies-study-finds#:~:text=Data%20brokers%20are%20selling%20the,raises%20serious%20national%20security%20concerns. [4] https://www.technologyreview.com/2024/01/15/1086513/the-ftcs-unprecedented-move-against-data-brokers-explained/ [5] https://www.precedenceresearch.com/data-analytics-market [6] https://objective-see.org/blog/blog_0x14.html [7] https://i.blackhat.com/USA21/Wednesday-Handouts/US-21-Regula-20-Plus-Ways-to-Bypass-Your-macOS-Privacy-Mechanisms.pdf [8] https://www.trendmicro.com/en_us/research/22/l/a-technical-analysis-of-cve-2022-22583-and-cve-2022-32800.html [9] https://developer.apple.com/documentation/corewlan/cwwificlient [10] https://developer.apple.com/documentation/corewlan/cwinterface [11] https://developer.apple.com/documentation/corewlan/cwinterface/1426416-scanfornetworks [12] https://en.wikipedia.org/wiki/Wi-Fi_positioning_system#Public_Wi-Fi_location_databases