Beyond TCC: Exploiting macOS Location Services for Stealthy Tracking

Introduction

Privacy on macOS is often synonymous with the Transparency, Consent, and Control (TCC) framework—those familiar prompts asking if an app can access your microphone or photos. However, beneath the surface of macOS lies a separate, more complex system specifically for Location Services. While Apple has made significant strides in hardening the operating system via System Integrity Protection (SIP), architectural gaps still exist that allow determined attackers to pinpoint a user's location without their consent.

In this post, we delve into the research presented by Wojciech Herguła, exploring why Location Services are the 'forgotten' privacy subsystem and how technical oversights in code signing verification can lead to total privacy compromise. This analysis is essential for macOS power users, red teamers, and security researchers aiming to understand the nuances of Apple's privacy architecture.

The Architecture of Privacy: TCC vs. LocationD

To understand the vulnerability, one must first understand the divide in macOS architecture. Most privacy permissions (Contacts, Calendar, Full Disk Access) are managed by tccd (the TCC daemon). This daemon references two primary SQLite3 databases: one at the system level and one per user.

However, Location Services are different. They are managed by locationd, which ignores the TCC database entirely. Instead, it uses a property list (PList) file located at /var/db/locationd/clients.plist. This file tracks which applications are authorized to see your coordinates. Because the storage format and the managing daemon are different, security improvements made to TCC do not always propagate to Location Services, leaving a legacy of older, potentially weaker verification methods.

Technical Deep Dive: The Code Signing Loophole

Understanding the Vulnerability

The primary weakness lies in how locationd validates an application's identity. When an application requests location data, the system checks its "Code Signing Requirement." This requirement typically includes the Bundle Identifier and the Team ID (a unique string assigned to a developer).

The Root Cause: Missing Version Checks The critical flaw is that these requirements almost never specify a minimum version of the application. This opens the door to Downgrade Attacks. An attacker can replace a modern, secure version of an app (like a browser or utility) with an older version from years ago. If the older version lacks the "Hardened Runtime" (which prevents dylib injection), the attacker can inject their own code into that trusted process. Since the Bundle ID and Team ID match, locationd sees the old, compromised version as the legitimate, authorized app and hands over the user's location.

Step-by-Step Exploitation Scenarios

1. Dylib Injection via Downgrade:

   • Identify an app with location permissions (e.g., com.apple.weather).
   • Check its signing requirements using codesign -d -r - /Applications/Weather.app.
   • Swap the binary with an older version that doesn't enforce code injection blocking.
   • Inject a custom .dylib that calls CLLocationManager to exfiltrate data.

2. Abusing Browser Instrumentation:

   • Browsers like Google Chrome often have location access.
   • Using the remote debugging feature (often used by Selenium), an attacker can launch Chrome and force it to execute navigator.geolocation.getCurrentPosition() via a script.
   • This is particularly dangerous because it uses a legitimate feature to bypass the need for a zero-day exploit.

3. Intercepting iCloud Tokens:

   • Applications like GarageBand and iMovie have entitlements to access iCloud data.
   • By injecting code into these apps, an attacker can steal iCloud session tokens.
   • These tokens can then be used to query Apple’s "Find My" API directly from a remote server, bypassing the local machine entirely.

Mitigation & Defense

Defending against these attacks requires a multi-layered approach that goes beyond simply clicking "Deny" on prompts:

• For Users: Regularly audit the "Privacy & Security" section in System Settings. If an app doesn't strictly need location access, revoke it. Be wary of applications that are not sandboxed (downloaded outside the App Store).
• For Blue Teams: Monitor for the execution of older versions of system applications. Specifically, look for the use of the --remote-debugging-port flag in browser processes, which is a common indicator of unauthorized instrumentation. Detection should also focus on unexpected dylib loading in processes that typically utilize Hardened Runtime.
• For Developers: Always ensure Hardened Runtime is enabled and avoid using sensitive entitlements unless absolutely necessary. Use the library-validation flag to prevent unauthorized code from being loaded into your process space.

Conclusion & Key Takeaways

The research into macOS Location Services reveals that even the most robust privacy frameworks have blind spots. The reliance on PList-based databases and the lack of version-specific code signing requirements provide a persistent path for privacy leaks.

Key takeaways:

• Location Services on macOS are architecturally distinct from TCC.
• Lack of versioning in code signing requirements allows for successful downgrade attacks.
• Browser instrumentation is a highly effective, low-trace method for location exfiltration.
• Security isn't just about the latest patch; it's about the legacy architecture that remains accessible to attackers.

As macOS continues to evolve, the bridge between locationd and TCC must be strengthened to ensure that "consent" remains a meaningful barrier against unauthorized tracking.