reader comments
1 with 1 posters participating
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 zeroday was exploited by XCSSET, a piece of malware discovered by security firm Trend Micro last August. XCSSET used what at the time were two zerodays 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 zeroday
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 zeroday 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.
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:
- The XCSSET AppleScript screenshot module is downloaded from the malware author’s command and control (C2)server (to the ~/Library/Caches/GameKit folder).
- 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.
- 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.
- A blank icon is then downloaded and applied to the application.
- 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.
