Unauthorized access to iCloud: analyzing an iOS vulnerability that could expose sensitive data to attackers

Research led by: 08Tc3wBB

Recently, Jamf Threat Labs discovered a TCC bypass vulnerability affecting FileProvider in both macOS and iOS; if successfully exploited, the vulnerability could result in an app that is able to access sensitive data without the end user’s knowledge. We reported our findings to Apple, and in macOS 15 and iOS 18, Apple patched the vulnerability, assigning it CVE-2024-44131.

File Provider

​​An extension other apps use to access files and folders managed by your app and synced with remote storage.

Just like macOS, iOS implements the TCC mechanism to notify users when an application tries to access sensitive information such as photos, GPS location, contacts and more. Users are provided with an option to either grant or deny access to specific data on a per-application basis. When a vulnerability in the TCC mechanism allows a third-party application to access this data without regard for the user-specified policy, it is known as a TCC bypass.

In this blog, we will delve into the details of the iOS TCC bypass vulnerability (CVE-2024-44131) that allows a malicious application to copy extensive user data from iCloud. Alarmingly, this exploitation occurs without leaving any trace of the data accessed, posing a threat to user privacy and overall data security.

What is the TCC bypass vulnerability?

Across Apple’s ecosystem of operating systems, Transparency, Consent and Control (TCC) serves as a crucial security framework, prompting users to grant or deny requests from individual apps to access sensitive data such as photos, contacts and location details. A TCC bypass vulnerability occurs when this control fails, allowing an application to access private information without the user’s consent or knowledge.

Jamf Threat Labs recently uncovered a TCC bypass vulnerability affecting File Provider on both macOS and iOS. This vulnerability, now known as CVE-2024-44131, allows apps to sidestep these TCC controls and access user data without any notification. Jamf promptly reported this vulnerability to Apple, which has since patched the issue in iOS 18 and macOS 15.

This discovery highlights a broader security concern as attackers focus on data and intellectual property that can be accessed from multiple locations, allowing them to focus on compromising the weakest of the connected systems. Services like iCloud, which allow data to sync across devices of many form factors, enable attackers to attempt exploits across a variety of entry points as they look to accelerate their access to valuable intellectual property and data.

Why does this vulnerability matter?

User privacy compromised

This TCC bypass allows unauthorized access to files and folders, Health data, the microphone or camera, and more without alerting users. This undermines user trust in the security of iOS devices and exposes personal data to risk.

Cross-platform threat vectors

This is a powerful indicator that threat actors are evolving and developing attacks that can be applied to both desktop and mobile platforms. It reinforces that mobile security must be taken just as seriously as desktop security, especially when sensitive data is synced across platforms.

Organizational data at risk

For mobile-enabled businesses, this vulnerability shows that mobile devices should not be considered “safe” or low-risk endpoints. The reality of mobile threats underscores the importance of treating all endpoints — whether desktops or mobile devices — with the same security rigor, especially as remote work and corporate mobility programs continue to expand.

How does the TCC bypass work?

Vulnerability summary

The vulnerability relies on an exploit involving symlinks, using Apple’s Files.app and the fileproviderd system process. Here’s how it plays out:

• When a user moves or copies files within the Files.app, a malicious app running in the background can intercept these actions and redirect files to locations under the app’s control.
• By taking advantage of the elevated privileges of fileproviderd, the malicious app can hijack file movements or copies without triggering a TCC prompt.
• This exploitation can happen in the blink of an eye, entirely undetected by the end user.

Key components to exploit

The core issue revolves around how Apple’s Files.app and the fileproviderd system process manage file operations. Specifically, when a user moves or copies files or directories using Files.app within a directory accessible by a malicious app running in the background, the attacker can manipulate symlinks to deceive the Files.app.

Existing symlink checks are flawed

When a privileged process performs file or directory copying, moving or deletion within an app-accessible directory (such as NSDocumentDirectory), it is critical to guard against tactics that attempt to exploit symlink race conditions or implement path traversal attacks. Many file operation APIs offer options to check if the source/destination file is a symlink; if a symlink is involved, then the process will not proceed.

However, we discovered that instead of creating the symlink at the final portion of the path before starting the operation, inserting the symlink at the second-last directory level midway through the operation completely bypasses these existing checks.

For instance, consider a path provided to a privileged process for copying files within an app’s folder, such as the example in Figure 1. The names highlighted in red indicate symlinks. The old method would fail because a symlink present in the path would be detected. The new symlink attack method first copies an innocent file, providing a detectable signal to a malicious process that the copying has started. Then, a symlink is inserted after the copying process is already underway, effectively bypassing the symlink check.

Abusing elevated privileges

This exploitation allows the malicious app to abuse the elevated privileges of the fileproviderd system process to move or copy the user’s sensitive data into a directory under the attacker’s control. Once data has been copied, the attacker can then hide directories or upload it to a remote server. Crucially, this entire operation occurs without triggering any TCC prompts.

The type of data that can be accessed depends on which system process is executing the file operation. In the case of a user copying a file within an app’s directory, it is the Files.app that initiates the final rename() system call. However, when the user moves a file, it is the /System/Library/Frameworks/FileProvider.framework/Support/fileproviderd system process that performs the final rename() operation. Both Files.app and fileproviderd have special entitlements that provide them with privileges not accessible to regular applications.

Identifying vulnerable data and directory paths

For fileproviderd

For Files.app

fileproviderd has access to /var/mobile/Library/Application Support/FileProvider/AccessControl.db, which contains a list of apps that have interacted with the Files and Folders system. This information could potentially be leveraged by malicious actors.

While Files.app is designed to access all content under /var/mobile/Containers, including the local data of all installed apps, this data is protected by directories with randomly assigned UUIDs.

UUID

A universally unique value to identify types, interfaces, and other items.

What data is at risk?

Our research demonstrates that the exploit only works when the UUID — a universally unique value that is used by developers to identify types, interfaces, and other items — is known.

For instance:

• Attempting to copy all content under /var/mobile/Containers/Data without authorization will be blocked by the system.
• However, targeting a specific directory, such as /var/mobile/Containers/Data/Application/779D0B71-2BF4-4084-A523-DE3396BD6A55, will succeed if the UUID is known.

Similarly, external cloud data tied to services like Dropbox, Google Drive and Microsoft OneDrive is protected by unique UUIDs, which differ across devices, making them inaccessible through this exploit.

For example, the path /var/mobile/Containers/Shared/AppGroup/94FFAB7F-D571-47A4-82EA-A6F3312ED1DD/File Provider Storage/ is protected by a random UUID.

In contrast, iCloud data stored in /var/mobile/Library/Mobile Documents is not protected by UUIDs. The directory structure for a specific app is constant across devices and versions, making it more vulnerable.

Example paths are:

1. /var/mobile/Library/Mobile Documents/com~apple~Pages

2. /var/mobile/Library/Mobile Documents/com~apple~CloudDocs

3. /var/mobile/Library/Mobile Documents/57T9237FN3~net~whatsapp~WhatsApp

The com~apple~Pages directory contains backup documents created by Apple’s Pages app. Meanwhile, com~apple~CloudDocs is a common storage space for files manually synced by the user, including the Downloads folder, where personal files can be found.

The directory 57T9237FN3~net~whatsapp~WhatsApp contains backup data uploaded by WhatsApp. Although the identifier 57T9237FN3 may appear randomly generated, this value actually remains constant across different devices, app versions and user accounts. As a result, an attacker can use this exact path to target the user’s WhatsApp backup data. If the user has enabled WhatsApp’s backup feature, the files can be accessed and copied to a location under the attacker’s control without the user’s authorization.

This same vulnerability extends to any other apps utilizing iCloud Drive for storage. Some instances of folder name are:

Stealthy access to data

Because TCC prompts are not triggered, the user has no indication that data is being accessed or moved to attacker-controlled directories. The malicious app then has the option to hide, delete or even upload this data to a remote server, putting personal and potentially sensitive data at risk.

Sensitive data affected

The data affected includes photos, GPS location data, contacts and more — depending on which system process (Files.app or fileproviderd) is executing the file operation. Both processes have special entitlements allowing privileged access to data that standard applications don’t have.

Potential exploitation and risks

This vulnerability gives attackers several pathways to exploit:

• Data access and redirection: The vulnerability allows sensitive data to be moved to directories controlled by the malicious app, putting it directly in the hands of the attacker.
• Data exfiltration: With control over the data, attackers can then hide, manipulate or exfiltrate it to remote servers without any traceable activity or user notifications.

Can this vulnerability be demonstrated?

To demonstrate the potential impact of an attacker exploiting this vulnerability, we built a proof of concept. Our POC is a regular iOS application that monitors a file within its document folder and prompts the user to use the Files app to perform copy or move actions on this path.

As soon as our app detects the start of a copying or moving action, we apply the above technique to execute a symlink attack, allowing us to leverage the Files app’s privileges to copy or replace sensitive files. In the screenshots below, we illustrate how the PoC (Proof of Concept) app is able to leak data from WhatsApp stored on iCloud.

Remember that the severity of these vulnerabilities depends on the privileges of the targeted process. This reveals a gap in access control enforcement for certain data types, as not all data can be extracted without alert due to this race condition. For example, data within folders protected by randomly assigned UUIDs and data retrieved through specific APIs remain unaffected by this type of attack.

Can this vulnerability be mitigated?

Apple has responded to this discovery by patching CVE-2024-44131 in iOS 18 and macOS 15. For end users, the most immediate and effective step is to update to these latest OS versions to safeguard against this vulnerability.

Organizations should consider deploying dedicated security solutions that monitor app behavior and prevent unauthorized data access. While Apple’s OS updates address specific vulnerabilities, having proactive endpoint protection can detect and block unexpected behaviors or abnormal requests.

Need for a comprehensive security strategy

This discovery is a wake-up call for organizations to build comprehensive security strategies that address all endpoints. Mobile devices, as much as desktops, are critical parts of any security framework. Extending security practices to include mobile endpoints is essential in an era where mobile attacks are increasingly sophisticated.

Jamf has a long-standing reputation for providing security across macOS and iOS devices and helping organizations monitor, detect and prevent risks on Apple devices. Comprehensive management combined with endpoint protection from Jamf allows organizations to maintain visibility and control across all endpoints, offering peace of mind in a complex threat landscape.

As mobile threats continue to evolve, organizations cannot afford to overlook the security of their mobile devices. Mobile and desktop endpoints are increasingly interconnected, and so are the threats targeting them. The iOS TCC Bypass Vulnerability highlights the need for a security strategy that spans all device types, securing sensitive data wherever it resides.