Actively exploited macOS 0day let hackers take screenshots of infected Macs

Malicious hackers have been exploiting a vulnerability in fully updated versions of macOS that allowed them to take screenshots on infected Macs without having to get permission from victims first.

The zero-day was exploited by XCSSET, a piece of malware discovered by security firm Trend Micro last August. XCSSET used what at the time were two zero-days to infect Mac developers with malware that stole browser cookies and files; injected backdoors into websites; stole information from Skype, Telegram, and other installed apps; took screenshots; and encrypted files and showed a ransom note.

A third zero-day

Infections came in the form of malicious projects that the attacker wrote for Xcode, a tool that Apple makes available for free to developers writing apps for macOS or other Apple OSes. As soon as one of the XCSSET projects was opened and built, TrendMicro said, the malicious code would run on the developers’ Macs. An Xcode project is a repository for all the files, resources, and information needed to build an app.

In March, researchers from SentinelOne found a new a trojanized code library in the wild that also installed the XCSSET surveillance malware on developer Macs.

On Monday, researchers with Jamf, a security provider for Apple enterprise users, said that XCSSET has been exploiting a zero-day that had gone undetected until recently. The vulnerability resided in the Transparency Consent and Control framework, which requires explicit user permission before an installed app can obtain system permissions to access the hard drive, microphone, camera, and other privacy- and security-sensitive resources.

XCSSET had been exploiting the vulnerability so it could bypass TCC protections and take screenshots without requiring user permission. Apple fixed CVE-2021-30713 (as the vulnerability is tracked) on Monday with the release of macOS 11.4.

The vulnerability was the result of a logic error that allowed XCSSET to hide inside the directory of an installed app that already had permission to take screenshots. The exploit allowed the malware to inherit the screenshot permissions, as well as other privileges controlled by TCC.

Piggybacking off parent apps

“Some developers design applications with smaller applications placed within them,” Jamf researcher Jaron Bradley said in an interview. “This isn’t unheard of. But a bug appears to have existed in the operating system logic when it comes to how the TCC permissions are handled in such a situation.”

To locate apps that XCSSET could piggyback off of, the malware checked for screen capture permissions from a list of installed applications.

“As expected, the list of application IDs that are targeted are all applications that users regularly grant the screen sharing permission to as part of its normal operation,” Bradley wrote in a post. “The malware then uses the following mdfind command—the command-line-based version of Spotlight—to check if the appID’s are installed on the victim’s device.”

The post explained how the flow of the AppleScript responsible for the exploit worked:

1. The XCSSET AppleScript screenshot module is downloaded from the malware author’s command and control (C2) server (to the ~/Library/Caches/GameKit folder).
2. Using the osacompile command, the screenshot module is converted to an AppleScript-based application called avatarde.app. When any AppleScript is compiled in this manner, an executable called “applet” is placed in the newly created application bundle’s /Contents/MacOS/ directory and the script that the applet will execute can be located at /Contents/Resources/Scripts/main.scpt.
3. The newly created Info.plist is then modified by the plutil binary, changing the preference setting LSUIElement to true. This allows the application to be run as a background process, concealing its presence from the user.
4. A blank icon is then downloaded and applied to the application.
5. Lastly, the newly created application is placed within the already existing donor application using the following code:

For example, if the virtual meeting application zoom.us.app is found on the system, the malware will place itself like so:

/Applications/zoom.us.app/Contents/MacOS/avatarde.app

If the victim computer is running macOS 11 or greater, it will then sign the avatarde application with an ad-hoc signature, or one that is signed by the computer itself.

Once all files are in place, the custom application will piggyback off of the parent application, which in the example above is Zoom. This means that the malicious application can take screenshots or record the screen without needing explicit consent from the user. It inherits those TCC permissions outright from the Zoom parent app. This represents a considerable privacy concern for end-users.

During Jamf’s testing, it was determined that this vulnerability is not limited to screen recording permissions either. Multiple different permissions that have already been provided to the donor application can be transferred to the maliciously created app.

Now that Apple has fixed the vulnerability, TCC works the way Apple intended, with a dialog message that prompts users to either open the system preferences to allow the app or to simply click the deny button displayed by the popup.

XCSSET isn’t likely to infect Macs unless it has run a malicious Xcode project. That means people are unlikely to be infected unless they are developers who have used one of the projects. The Jamf post provides indicators of a compromise list that people can use to determine if they’ve been infected.