TCC and Gatekeeper Bypasses
Wojciech Reguła (September 2021, tweet):
I was looking for code injection opportunities that may allow reaching TCC bypasses. My simple shell script discovered a potential victim -
/System/Library/CoreServices/Applications/Directory Utility.app. It had (and has) the following private TCC entitlement[…] This entitlement allows the Directory Utility to modify the user’s records stored in the/var/db/dslocal/nodesdirectory.[…]
After some time I stumbled across the above-mentioned Matt Shockley’s article on how he was able to bypass TCC only by changing the
$HOMEdirectory vialaunchctl. I was really curious about how Apple fixed that vulnerability so I started reversing the TCC. Turns out that now TCC takes the information about the user’s home directory from thegetpwuidfunction.[…]
I was really shocked that Apple decided that this vulnerability is not eligible for the bounty. [They later changed their mind.]
Wojciech Reguła (March 2022):
This post shows how to bypass the macOS privacy framework (TCC) using old app versions.
[…]
Summing it up - there is no version information. It is exactly the same architectonical problem as the macOS Keychain has. In most cases it is possible to get an older version of the “donor” application (without the hardened runtime flag), inject to it, and thus abuse its TCC permissions.
Phil Stokes (March 2023):
The scourge of ransomware attacks that has plagued Windows endpoints over the past half decade or so has, thankfully, not been replicated on Mac devices. With a few unsuccessful exceptions, the notion of locking a Mac device and holding its owner to ransom in return for access to the machine and its data has not yet proven an attractive proposition for attackers.
However, the idea of stealing valuable data and then monetizing it in nefarious ways is a tactic that is now common across platforms. On macOS, threat actors will quietly exfiltrate session cookies, keychains, SSH keys and more as malicious processes from adware to spyware look to harvest data that can be recycled and sold on various underground forums and marketplaces, or used directly in espionage campaigns and supply chain attacks.
[…]
Session cookies can be stored anywhere, but typically they are in locations which can be accessed by the user or a process running as the user. Some locations, such as the User’s Library Cookies folder, may be restricted by TCC unless the parent process has Full Disk Access or uses one of the many known TCC bypasses. Real world attacks (e.g., XCSSET) and researchers have consistently shown that TCC, while often a nuisance to users, does not present a significant obstacle to attackers.
Mickey Jin (January 2024):
Last year, I discovered a full user TCC bypass issue in the macOS Sonoma beta version. There was a CVE number assigned at the beginning, but removed by Apple in the release of macOS 14.0. Instead, I got the credit in their Additional Recognitions.
According to the Apple Security Bounty program, this report should have been rewarded with an additional 50%. Unfortunately, the truth is that I was cut off 50%.
This vulnerability was disclosed at Black Hat Europe 2022 in the talk Knockout Win Against TCC - 20+ NEW Ways to Bypass Your MacOS Privacy Mechanisms. The technique used an old Launch Services function LSSetDefaultRoleHandlerForContentType that allowed (without any restrictions) to register arbitrary applications for handling specified UTI handlers. After the UTI handling app registration, the exploit simply opens juicy files (like AddressBook or iMessages database) and TCC happily grants access to them. At that time TCC couldn’t recognize correctly if a file was opened by launch services or double-clicked by a user.
The technique relied on an SQLite environment variable respected by
libsqlite3.dylibwhich made apps using the standard SQLite system API log all the SQL queries. As such queries may contain sensitive user data normally protected by the TCC - I started researching all the problematic occurrences.
Apple states that user-installed unarchiving tools preserve quarantine. As we can see in the following examples, there are some third-party archive tools that do not enforce that, which means that Gatekeeper won’t scan the extracted files.
[…]
In VMware Fusion, when copying a file from a host machine to a guest macOS virtual machine (VM) using VMware tools, the quarantine extended attribute will be dropped from the copied file as shown in Figure 4. This means Gatekeeper won’t scan any files copied into the virtual machine.
Microsoft Threat Intelligence:
The vulnerability, which we refer to as “HM Surf”, involves removing the TCC protection for the Safari browser directory and modifying a configuration file in the said directory to gain access to the user’s data, including browsed pages, the device’s camera, microphone, and location, without the user’s consent.
[…]
Our exploit involves the following steps:
- Change the home directory of the current user with the dscl utility, which does not require TCC access in Sonoma (At this point, the ~/Library/Safari directory is no longer TCC protected).
- Modify the sensitive files under the user’s real home directory (such as /Users/$USER/Library/Safari/PerSitePreferences.db).
- Change the home directory again so Safari uses the now modified files.
- Run Safari to open a webpage that takes a camera snapshot and trace device location.
Osama Alhour (PDF, tweet):
This paper seeks to provide a comprehensive technical analysis of how TCC works internally, how it interacts with other system components, and it’s impact on both how developers shape their applications as well as user control granting sensitive data to applications.
Previously:
- No Bounty for Kaspersky
- No Bounty for Kernel Vulnerability
- Reporting a Full Disk Access Bug to Apple
- Powerdir macOS TCC Vulnerability
- Overview of TCC Bypasses by Accident and Design
- TCC Bypass in XCSSET Malware
1 Comment RSS · Twitter · Mastodon
I hate TCC so, so, so much. It has been nothing but a thorn in my side ever since it was introduced. Perhaps if it actually *worked* and all of its security functions were properly designed to be for the user, with complete control given to the user, then I wouldn't hate it. I might even have liked it. The idea of being able to control exactly who has access to, say, my camera and microphone is a good thing.
But as it stands, it wrestles control away from the user, is buggy to high hell, makes life miserable for developers who have to work around it, its bugs, and its shitty poorly documented incomplete API, and to add insult to injury, it doesn't even stop motivated attackers from breaking through its ostensible protections.
We hates it! We hates it, Precious! It is one of the major things that has ruined macOS.
