Malicious hackers exploited a vulnerability in fully updated versions of macOS that allowed them to take screenshots on infected Macs without first obtaining the victims’ consent.
The zero-day was exploited by XCSSET, a piece of malware discovered last August by security firm Trend Micro. XCSSET used what were then two zero days to infect Mac developers with malware that stole browser cookies and files; injected backdoors into websites; information stolen from Skype, Telegram and other installed apps; screenshots taken; and encrypted files and showed a ransom note.
A third zero day
Infections came in the form of malicious projects the attacker wrote for Xcode, a tool Apple makes available for free to developers who write apps for macOS or other Apple operating systems. Once 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, SentinelOne researchers found a new library of trojan code in the wild that also installed the XCSSET surveillance malware on developer Macs.
On Monday, researchers at Jamf, a security provider for Apple business users, said XCSSET is leveraging a zero-day that has gone unnoticed until recently. The vulnerability was in the Transparency Consent and Control framework, which requires explicit user consent before an installed app can gain system permissions to access the hard drive, microphone, camera, and other privacy and security sensitive resources.
XCSSET had exploited the vulnerability to bypass TCC protections and take screenshots without user consent. Apple fixed CVE-2021-30713 (as the vulnerability is being tracked) on Monday with the release of macOS 11.4.
The vulnerability resulted from a logical flaw that allowed XCSSET to hide in the folder of an installed app that already had permission to take screenshots. The exploit allowed the malware to take over screenshot rights, as well as other privileges controlled by TCC.
Piggyback on parent apps
“Some developers design applications with smaller applications in them,” Jamf researcher Jaron Bradley said in an interview. “This is not unheard of. But there seems to be a flaw in the operating system logic when it comes to handling the TCC permissions in such a situation.”
To locate apps that XCSSET could piggyback on, the malware checked for screen creation permissions against a list of installed applications.
“As expected, the list of application IDs targeted is all applications that users regularly grant permissions to share the screen with as part of 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 app IDs are installed on the victim’s device.”
jamf
The post explained how the flow of the AppleScript responsible for the exploit worked:
- The XCSSET AppleScript screenshot module is downloaded from the malware author’s command and control (C2) server (to the ~/Library/Caches/GameKit directory).
- Using the osacompile command, the screenshot module is converted into an AppleScript-based application called avatarde.app. When an AppleScript is compiled in this way, an executable file called “applet” is placed in the /Contents/MacOS/ directory of the newly created application bundle and the script that will run the applet can be found in /Contents/Resources /scripts/main. scpt.
- The newly created Info.plist is then modified by the plutil binary, changing the preference LSUIElement to true. This allows the application to run as a background process, hiding its presence from the user.
- An empty icon is then downloaded and applied to the application.
- Finally, the newly created application is placed in 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 as follows:
/Applications/zoom.us.app/Contents/MacOS/avatarde.app
If the victim’s computer is running macOS 11 or later, it will sign the avatarde application with an ad hoc signature, or a signature signed by the computer itself.
Once all the files are in place, the custom application will piggyback on its parent application, which is Zoom in the example above. This means that the malicious application can take screenshots or record the screen without the user’s explicit consent. It inherits those TCC permissions directly from the Zoom parent app. This represents a significant privacy issue for end users.
Jamf’s testing also determined that this vulnerability is not limited to screen recording permissions. Multiple different permissions already provided to the donor application can be transferred to the maliciously crafted app.
jamf
Now that Apple has fixed the vulnerability, TCC is working as Apple intended, with a dialog box asking users to either open System Preferences to allow the app or simply click the “decline” button that appears through the popup.
XCSSET is unlikely to infect Macs unless it has run a malicious Xcode project. That means people are unlikely to get infected unless it’s developers who used one of the projects. The Jamf post provides indicators of a compromise list that people can use to determine if they are infected.