Full Report
Transparency, Consent and Control (TCC) is a feature for privacy protection in Apple products. A user has to explicitly allow access to particular folder and files via authentication in order to prevent arbitrary applications from accessing sensitive data. The directory ~/Library/Application Support/MobileSync/Backup is protected by TCC since backups contain photos, contacts and other things. However, using the built in utility AppleMobileBackup to make a backup at a custom location completely bypass the TCC check. The service has Full Disk Access rights, apparently, which allows it to write/read to this location without consideration. The bypass was initially fixed by removing the --root flag from the utility in order to prevent the custom mounting of a directory for the backup. This came with some problems though. The stupid bypass is copying the binary from Monterey and rerunning it. Since it still has the flag and is likely signed, it works fine. Second, the utility DeviceLink has the capability of setting the root directory, allowing for the choosing of the mount point still. The author didn't verify these were fixed properly though.
Analysis Summary
# Vulnerability: macOS TCC Bypass via AppleMobileBackup (iOS Backup Protection)
## CVE Details
- **CVE ID:** CVE-2022-32929
- **CVSS Score:** 5.5 (Medium) - *Based on NIST assessment for local privacy bypass*
- **CWE:** CWE-284 (Improper Access Control)
## Affected Systems
- **Products:** Apple macOS (Monterey and Venture Beta)
- **Versions:** macOS Monterey prior to 12.6, macOS Ventura prior to 13.0
- **Configurations:** Systems where iOS devices are connected and backed up via physical connection/system utilities.
## Vulnerability Description
Transparency, Consent, and Control (TCC) is designed to protect sensitive directories, such as `~/Library/Application Support/MobileSync/Backup`, which contains unencrypted iOS device data (photos, contacts, etc.).
The `AppleMobileBackup` utility possesses Full Disk Access rights. The flaw exists because the utility initially supported a `--root` flag which allowed a user to specify a custom, unprotected directory for the backup. By redirecting the backup to a non-TCC protected location (like `/tmp/`), any application or user can access the sensitive iOS data without the required TCC permissions or authentication.
Two subsequent bypasses were identified after the initial fix:
1. **Framework Persistence:** The `DeviceLink` framework still contained the `_DLSetRootDirectory` function, allowing custom mount points through programmatic calls.
2. **Binary Downgrade:** Because the older, vulnerable version of `AppleMobileBackup` from macOS Monterey remained signed, it could be copied to newer versions of macOS (Ventura) and executed to perform the bypass.
## Exploitation
- **Status:** PoC available (Publicly documented)
- **Complexity:** Low
- **Attack Vector:** Local (Requires local shell access and a connected iOS device)
## Impact
- **Confidentiality:** High (Access to all iOS backup data: photos, messages, contacts)
- **Integrity:** None
- **Availability:** None
## Remediation
### Patches
- **macOS Monterey 12.6:** Fixed the initial command-line flag issue.
- **macOS Ventura 13.0:** Addressed the secondary bypasses.
- **iOS 16.1:** Apple implemented a secondary defense requiring the device passcode to initiate backups, preventing unauthorized automated triggers from macOS.
### Workarounds
- **Physical Security:** Disconnect iOS devices from macOS workstations when not in use.
- **Full Disk Access Audit:** Regularly review which applications/binaries have "Full Disk Access" in System Settings.
## Detection
- **Indicators of Compromise:** Presence of `AppleMobileBackup` binaries in non-standard directories (e.g., `/tmp/`, `~/Downloads/`).
- **Detection Methods:**
- Monitor command-line arguments for the use of the `--root` or `--target` flags with the `AppleMobileBackup` utility.
- Check system logs for unauthorized calls to the `DeviceLink.framework`.
- Use Endpoint Detection and Response (EDR) to alert on the execution of old, signed versions of system binaries (Binary Downgrade attacks).
## References
- **Vendor Advisory:** [https://support.apple.com/en-us/HT213488](https://support.apple.com/en-us/HT213488)
- **TheEvilBit Blog:** [https://theevilbit.github.io/posts/cve-2022-32929/](https://theevilbit.github.io/posts/cve-2022-32929/)
- **NVD Entry:** [https://nvd.nist.gov/vuln/detail/CVE-2022-32929](https://nvd.nist.gov/vuln/detail/CVE-2022-32929)