TCC (Transparency, Consent and Control) is a mechanism in MacOS that helps restrict access to protected folders on a system. This helps a user make informed consent whenever an application seeks to access files in a folder (eg Desktop). A more indepth discussion about TCE can be found here.

From an attacker’s perspective, he would want to find out as much information that belongs to the victim when he manages to get a RAT (Remote Access Trojan) on the system. TCC blocks this as it prevents important folders such as the user’s Desktop, Documents and Downloads folders from being accessed by any process without permission. This blocking works even if the RAT is running as a root process. In order for an attacker to access those folders, he would either need to “reveal” himself to the user by sending such a prompt such as the one below:

This could alert the user that something is up. Thus, if the attacker can borrow preexisting TCC permissions from another application, or pretend to be another application while requesting such permissions, the user might be more amenable to granting it and also not raising any alarms.

Hardened Runtime

To enhance the security of MacOS, the Hardened Runtime security feature was introduced in Mojave (MacOS 10.14). Enabling Hardened Runtime is necessary in order to get an application notarised. Notarisation is a key requirement for an application to be executed smoothly by users without unnecessary prompts and it gives users confidence that the app has been checked by Apple for malicious components.

However, due to the restrictiveness of Hardened Runtime, Apple allows developers to uncheck certain settings (or in other words, set different entitlements) that may make sense for their applications.

The 2 entitlements that are interesting to us in this case (and this CVE), are com.apple.security.cs.allow-dyld-environment-variables and com.apple.security.cs.disable-library-validation.

com.apple.security.cs.allow-dyld-environment-variables

This entitlement, if enabled, allows the DYLD environment variables to affect the libraries loaded by the application, in other words, dylib injection.

com.apple.security.cs.disable-library-validation

This entitlement, if enabled, allows any dylib to be loaded and executed by the application. In normal cases, only dylibs that are signed with the same certificate as the application can be loaded.

These 2 entitlements, if enabled at the same time, allow a third party to inject their own dylib into the process space of the victim application.

Putting it together

In my previous post on TCE, certain DYLD environment variables can allow arbitrary dylibs to be executed together with an application.

A way that we can execute our dylib together with an application is a command such as this:

DYLD_INSERT_LIBRARIES=libDylibTest.dylib  WeakDylibApp.app/Contents/MacOS/WeakDylibApp

This runs the WeakDylibApp while also loading our dylibtest.

CVE-2023-40299

With all the preamble out of the way, it’s time to discuss this CVE.

Kong Insomnia 2023.4.0 was distributed with the previously discussed entitlements enabled.

This allows an attacker to load whatever dylib he wants in the same process as Insomnia, and also inheriting whatever TCC permissions that Insomnia has. As a trusted developer app, a user would generally have no issues in granting it if the application requests for it.

The video below describes the attack. An arbitrary dylib that enumerates the user’s Documents folders is loaded together with Insomnia, this fires up a TCC prompt if no such permission was granted before, the user would generally be inclined to allow the operation since it is issued by Insomnia, an application that he installed.

This was reported to Kong and fixed here.