macOS 中的零点击日历邀请漏洞链

研究人员发现 macOS 日历应用程序中存在一个漏洞，允许未经授权访问和操纵用户的敏感数据，例如存储在 iCloud 中的照片。该漏洞分两个阶段发生：首先，通过零点击技术，攻击者可以通过发送带有特制文件名的恶意日历邀请，将受感染的文件插入日历系统。然后，这些受感染的文件可以在无需用户干预的情况下执行，从而导致潜在的数据盗窃或系统受损。该缺陷最初存在于 macOS Montery 中，但在后续更新中得到了解决。其次，研究人员利用这个最初的漏洞在系统更新过程中安装了未被检测到的恶意应用程序。通过操纵应用程序的设置，攻击者可以获得对用户 iCloud 帐户中存储的私人照片数据的访问权限。苹果公司在发现后解决了这两个漏洞，但强调了定期更新软件以确保最高安全级别的重要性。

A researcher identified a vulnerability in the macOS Calendar application allowing unauthorized access and manipulation of user's sensitive data such as photos stored in iCloud. This vulnerability occurs in two stages: First, through a zero-click technique, attackers can insert infected files into the Calendar system by sending malicious calendar invitations with specially crafted filenames. These infected files can then be executed without user intervention, leading to potential data theft or system compromise. The flaw was initially present in macOS Montery but was resolved in subsequent updates. Second, the researchers took advantage of this initial vulnerability to install a malicious application undetected during the system update process. By manipulating the application's settings, the attacker can obtain access to the user's private Photos data stored within their iCloud account. Apple addressed both vulnerabilities after the discovery, but it highlights the importance of regularly updating software to ensure the highest level of security.

I found a zero-click vulnerability in macOS Calendar, which allows an attacker to add or delete arbitrary files inside the Calendar sandbox environment. This could lead to many bad things including malicious code execution which can be combined with security protection evasion with Photos to compromise users’ sensitive Photos iCloud Photos data. Apple has fixed all of the vulnerabilities between October 2022 and September 2023.

If you like to see my presentation video about this, you can check my Disobey 2024 presentation: https://www.youtube.com/watch?v=9NlQXLLQrvk

Phase 1: Arbitrary file write and delete vulnerability in Calendar (CVE-2022–46723)

An attacker can send malicious calendar invites to the victim that include file attachments. The filename of the attachment is not properly sanitized. The attacker can exploit this to conduct a successful directory traversal attack by setting an arbitrary path to a file in the ATTACH section with: “FILENAME=../../../PoC.txt”.

This will cause the file to be added to ~/Library/Calendar/PoC.txt instead of ~/Library/Calendar/[CalendarID]/Attachments/[eventid]/ .

If the attacker-specified file already exists, then the specified file will be saved with the name “PoC.txt-2”. However, if the event/attachment sent by the attacker is later deleted the file with the original name (PoC.txt) will be removed. This vulnerability can be used to remove existing files from the filesystem (inside the filesystem “sandbox”).

Vulnerability seems to exist at least in latest macOS Montrey 12.5. MacOS 13.0 beta4 doesn’t seem to be vulnerable anymore.

Phase 2: Leveraging the arbitrary file write vulnerability to gain Remote Code Execution (RCE)

When this vulnerability was found Ventura was about to be released. macOS version upgrade process can be leveraged to gain remote code execution via the Open File functionality in Calendar.

In order to gain RCE we will exploit the previously discovered arbitrary file write vulnerability to infect the calendar with multiple files. When combined, they will trigger the RCE exploit when macOS Monterey is upgraded to Ventura.

Injected file #1: 000Hacked-$RANDOM.calendar

This file contains calendar data which looks like “Siri Suggested” -calendar.

Suggested repeating event with alert-functionality. This will open other injected files.

Injected file #2: CalendarTruthFileMigrationInProgress file

This file will make sure that existing calendars in the old calendar format will be upgraded and merged to the new database.

Injected file #3: CalPoCInit.dmg

An alert embedded in the Calendar event in the injected file #1 will trigger opening the file ~/Library/Calendars/CalPoCInit.dmg

CalPoCInit.dmg includes a reference to a background image which will point to an external samba server. This reference is a Bookmark in the .DS_Store. It’s stored inside the root of this image file. Mount will happen without a quarantine flag even though CalPoCInit.dmg mount is in quarantine.

Injected file #4: stage1.url

Second alert from the calendar event embedded in the injected file #1 will open the file ~/Library/Calendars/stage1.url

This file stage1.url includes an URL to an application inside the previously mounted samba mount triggered by the injected file #3. This URL is file:///Volumes/CalPoCPayload/MyMidiTest.app.

Malicious application

This will cause Finder to open /Volumes/CalPoCPayload/, which will automatically trigger indexing. This will cause MyMidiTest.app to be indexed. This is needed for the unique URL registration to happen.

Inside our application bundle the MyMidiTest.app/Contents/Info.plist file includes a trigger that will cause a handler to be registered for a custom URL Type:

        <key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLName</key>
<string>MyMidi URL</string>
<key>CFBundleURLSchemes</key>
<array>
<string>mymiditest</string>
</array>
</dict>
</array>

Injected file #5: stage2.url

Third and the last alert from from the calendar event embedded in the injected file #1 will open the file ~/Library/Calendar/stage2.url which includes a reference to the custom url “mymiditest://” which will launch our malicious application without any user interaction whatsoever.

This is possible because the application is inside the samba mount from our exploit which does not have a quarantine flag.

mymiditest app will write files needed for the Phase 3 to /var/tmp/ and launch the script in Terminal with “open /var/tmp/PhotosPoC.sh”. The objective is to make a bit more room on our sandbox.

In order to demonstrate the superpowers gained by the previous two phases of the exploit chain, I chose to abuse Photos to leak sensitive user data, namely private pictures. Access to users’ sensitive files like Photos should be restricted and blocked by TCC. However, by having the exploit change the configuration of Photos it is possible to get access to pictures which are stored on iCloud. This is done by changing the System Photo Library to point to a path which is not protected by TCC.

The attacker can create a configuration file for Photos which uses a different System Photo Library for Photos. Configuration can be imported via “defaults import”.

Phase 2 of this PoC exploit chain has prepared and automatically dropped a configuration which uses /var/tmp/mypictures/Syndication.photoslibrary as a System Photo Library for Photos, cloudphotod and photolibraryd. You can find these malicious configurations created automatically in Phase 2 from the /var/tmp/mypictures/*.plist.

When the exploit chain runs PhotosPoC.sh, all running Photos-related applications will be killed and a new configuration will be imported with defaults.

Original configuration will be backed up to /var/tmp/mypictures/*-orig.plist

Malicious configuration will be imported from /var/tmp/mypictures/ .

New photo library will be opened by the exploit chain in Photos with “open /var/tmp/mypictures/Syndication.photoslibrary.

Syndication.photoslibrary is an empty template library.

Now Photos will be running with the new System Photo Library and iCloud sync will be enabled and original files will be downloaded to an unprotected directory.

When those files are synchronized to disk they will be copied to a new directory in /var/tmp/PoCLoot$RANDOM/. This sensitive and private data could also be copied to external resources and data could be posted to external web-servers with the curl command by the exploit with trivial modifications.