A Worm in the Apple: Wormable Zero-Click RCE in AirPlay Impacts Billions of Apple and IoT Devices

A Worm in the Apple: Wormable Zero-Click RCE in AirPlay Impacts Billions of Apple and IoT Devices

Speakers: Avi Lumelsky, Lead AI Security Research, Oligo; Uri Katz, Lead Researcher, Oligo

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=Dh9HJ-Yn-Rg

Overview

This talk, presented by Avi Lumelsky and Uri Katz from Oligo, unveiled a critical collection of vulnerabilities dubbed "Airborne," affecting Apple's widely used AirPlay protocol. The research uncovered 23 distinct vulnerabilities, 17 of which were assigned CVEs, that when chained together, allow for zero-click remote code execution (RCE). Crucially, these exploits are wormable, capable of propagating across networks without user interaction, impacting not only billions of Apple devices but also a vast ecosystem of third-party Internet of Things (IoT) devices that integrate the AirPlay SDK.

The significance of this research lies in its unprecedented scope and potential for widespread compromise. AirPlay, a ubiquitous media streaming protocol, is often enabled by default, making a massive attack surface readily available. The discovery of multiple novel attack vectors, including physical proximity and browser-based exploitation, highlights deeply overlooked security assumptions in modern network and device interactions. The presentation serves as a stark reminder of the shared responsibility between platform developers and third-party vendors in securing the interconnected digital landscape.

Background

▶ Watch: Introduction: Wormable zero-click RCE in AirPlay (0:00)

The journey into AirPlay's security began as an offshoot of previous research presented by the speakers, which focused on a vulnerability dubbed "0000 day." This earlier work explored how public websites could communicate with local services running on a user's network, a commonly overlooked attack vector. During this research, the team noticed that port 7000 was open on every MacBook in their office, and, critically, it was accessible from a browser even under a public domain. This observation piqued their interest, prompting a deeper investigation into the protocol listening on that port: AirPlay.

AirPlay, initially known as AirTunes in 2004, was rebranded to AirPlay in 2010, with AirPlay 2 being the prevalent version today. It functions as a seamless media streaming protocol, primarily for audio, but also supporting video and images between certified devices. For this seamless operation, AirPlay relies on a network discovery protocol called mDNS (Multicast DNS). mDNS broadcasts a device's presence, including its hostname and listening ports, over the local network. While convenient for users, this broadcast mechanism effectively publishes information that attackers would typically gather through port scanning, simplifying reconnaissance.

The AirPlay protocol itself, unlike mDNS, is closed source, necessitating reverse engineering efforts. The speakers explained that AirPlay leverages both HTTP and RTSP (Real Time Streaming Protocol), with RTSP employing HTTP-style methods such as GET, POST, TEARDOWN, and SETUP. A key data format used within AirPlay is the Property List (PList). PLists consist of type-value pairs and can be serialized into either an XML-like string format or a more efficient binary format, common in the Apple ecosystem. The protocol defines various command types, categorized into pre-authentication, authentication, session setup, and session commands (e.g., playback speed, audio mode). The distinction between these command types proved crucial, as the research revealed that many commands intended for post-authentication use were unexpectedly accessible without prior authentication.

Key Findings

▶ Watch: AirPlay protocol basics and MDNS discovery (4:45)

The initial phase of the research, surprisingly, began with a remarkably simple fuzzer—a mere 20 lines of Python code. This straightforward approach quickly yielded critical insights into AirPlay's vulnerabilities.

The first significant finding was an Access Control Bypass. AirPlay on macOS offers three main configuration options, with "Current User" being the strictest, theoretically allowing communication only from devices linked to the same Apple ID. However, the researchers discovered that many commands intended for use after the authentication step were actually accessible at all times. This dramatically expanded the attack surface, enabling a simple client without any Apple ID to communicate with numerous internal routes. Demonstrating this, they were able to play a full-screen video on macOS devices across the network without any form of authentication.

The second key finding was a Syslog Leak. Despite Apple's general diligence in protecting Personally Identifiable Information (PII), a simple get log command was sufficient to retrieve the entire syslog of any macOS device on the network. This syslog contained highly sensitive information, including the device's hostname, running processes, boot time, and other internal details, all without requiring authentication.

Finally, the fuzzer uncovered a Control Center crash triggered by the FP setup 2 command. On macOS, the AirPlay server runs under the Control Center service. Sending this specific command caused the entire Control Center to crash due to a memory corruption issue. While this particular crash wasn't immediately exploitable for RCE, its ease of discovery strongly suggested the presence of deeper, more severe vulnerabilities within the AirPlay implementation, prompting the researchers to delve into reverse engineering.

Technical Deep Dive

▶ Watch: AirPlay request structure using HTTP/RTSP and PLists (6:20)

Motivated by their initial fuzzing successes, the researchers embarked on a comprehensive reverse engineering effort. Given that AirPlay is a closed-source protocol, they had to extract the AirPlay binaries and libraries directly from the dyld cache directory on macOS. This provided them with the raw code to analyze. Their process involved manually tracing function calls and pattern matching within the disassembled code to identify which functions were responsible for handling specific AirPlay commands. This meticulous approach allowed them to map the protocol's logic and pinpoint potential weaknesses.

Their deep dive revealed two predominant types of vulnerabilities across the 23 reported issues: Type Confusion and Null Dereference vulnerabilities.

A classic example of Type Confusion was found in the get property command, which uses an HTTP POST method. The code handling this command expected a dictionary as input but failed to perform proper type validation. If an attacker sent a string or an integer instead of the expected dictionary, the process would crash. This vulnerability highlighted a critical lack of robust type checking, particularly in commands that were inadvertently exposed before a full session had been established. The speakers hypothesized that Apple might not have intended these "session commands" to be accessible pre-authentication, leading to the omission of necessary type checks.

Null Dereference vulnerabilities were also common. One instance was identified in the audio mode command. This command accessed a derived storage variable, a global structure that holds session parameters. However, if this command was called before a session was fully established, the media audio session within derived storage could be null. Attempting to access a property like rate on a null session object would then result in a null dereference, crashing the process.

The sheer volume of vulnerabilities (16 initially) reported to Apple's ticketing system actually caused it to block the researchers, a "funny" situation that forced them to slow down their reporting.

The research also differentiated between AirPlay's implementation on official Apple devices versus its use through the AirPlay SDK by third-party manufacturers. Hundreds of vendors integrate the AirPlay SDK, often alongside a dedicated MFI (Made For iPhone/iPad/iPod) chip for authorization. While the SDK is based on the same core code, it offers limited functionality. Interestingly, only two of the 23 vulnerabilities were found to impact the SDK, but these were particularly severe: an exploitable Stack Overflow (made possible by the absence of stack canaries on the target devices) and an Integer Overflow. The researchers expressed surprise at finding such fundamental memory corruption vulnerabilities still effective in modern systems.

To research the SDK without incurring the cost of numerous certified devices, Uri Katz ingeniously simulated a real certified device firmware on a Raspberry Pi. An Arduino was used to fake the MFI chip's hardware identities, allowing the firmware to boot successfully. This innovative setup proved the viability of their exploits, and only then did they purchase actual certified devices for real-world testing. This led to achieving root privileges on a Bose home speaker, demonstrating how such a compromised device, with its Wi-Fi connectivity and microphone, could serve as a pivot point for a worm to propagate further on the network. The same stack overflow vulnerability, with minor modifications, was then successfully used to exploit a CarPlay head unit. The speakers noted that Apple's public CVE description for this SDK vulnerability was ambiguous, stating "unexpected app termination" instead of RCE, which they believe might have contributed to slower patching by third-party vendors, leaving many devices still vulnerable.

The most critical finding for Apple devices was a Use-After-Free (UAF) vulnerability on macOS. This UAF was discovered during the exploit development phase for another UAF, leading to the reporting of five additional CVEs. The UAF was located within the highly obfuscated FairPlay decryption flow, which handles encrypted audio streams. By reconstructing function names from old code snippets and headers, the researchers identified a flaw in the decryption process:

1. A decrypt function is called, using an encryption context.
2. If decryption fails, a tear down function is called, which correctly frees the encryption context.
3. However, a pointer to this now-freed encryption context within a global derived storage variable (which stores session parameters) was not zeroed out.

This left a dangling pointer in derived storage pointing to a freed heap chunk. The absence of heap spray protections on macOS allowed the attackers to spray the heap, effectively replacing the freed encryption context with their own custom data. Subsequent calls to decrypt would then operate on this attacker-controlled context, yielding a powerful write-what-where primitive. This primitive, in turn, allowed them to write arbitrary data to any memory location on the heap, culminating in full RCE on macOS devices.

A final hurdle for the macOS RCE was the user interaction required by the AirPlay pop-up, which prompts for user approval. The researchers found a bypass by identifying an internal flag, is remote control only, within the AirPlay handshake. By setting this flag, the pop-up notification was suppressed, transforming the UAF into a zero-click, wormable RCE on macOS—the first of its kind to their knowledge.

Demo / Proof of Concept

▶ Watch: Pre-authentication vs. session AirPlay commands (8:00)

The presentation included compelling demonstrations of the exploits in action, showcasing the tangible impact of the discovered vulnerabilities.

The first demonstration targeted a CarPlay system. The speakers highlighted how Wi-Fi credentials could be seen in plain text on the device. They then launched their exploit, which leveraged the previously discussed stack overflow vulnerability. The demo successfully gained root user privileges and established a reverse shell on the CarPlay unit. To visually confirm the compromise, the attackers downloaded an image and displayed it directly on the CarPlay screen. The speakers humorously elaborated on the potential malicious uses, ranging from serious implications like spying on the driver via GPS or microphone access, to more annoying pranks such as playing "shitty music" on a loop.

The second demonstration focused on the macOS Use-After-Free (UAF) vulnerability. Here, the attackers used their write-what-where primitive to overwrite a critical memory address associated with the Music app. The exploit was initiated remotely from the network, simulating an attack originating from a compromised Bose home speaker. After spraying the heap to control the freed memory region, the demonstration showed that the next time the Music app was launched by the user, instead of opening the music interface, it executed the attacker's arbitrary code—in this case, opening a custom image. This vividly illustrated the RCE capability and underscored the effectiveness of the zero-click bypass, as no direct user interaction was required on the macOS device for the exploit to be delivered and persist until the Music app was opened.

The presenters also briefly mentioned that browsers continue to be an overlooked attack vector for local services, citing Cisco as an example of a vendor that patched 63 products impacted by these vulnerabilities due to their use of the AirPlay SDK.

Defensive Implications

▶ Watch: Initial findings: Simple Python fuzzer success (8:50)

The research revealed several critical attack vectors for AirPlay vulnerabilities, underscoring the broad threat landscape:

1. Internet: Hundreds of thousands of outdated AirPlay-enabled devices are directly exposed to the internet, discoverable via tools like Shodan and Censys. These public-facing devices represent easily accessible targets for remote exploitation.
2. Intranet: Any attacker on the same local network (e.g., public Wi-Fi in a coffee shop or airport) can exploit these vulnerabilities to compromise devices.
3. Web Browser: Leveraging the "0000 day" vulnerability, public websites can communicate with local AirPlay services listening on port 7000 (which resolves to localhost on Unix-like systems, including macOS). This allows for browser-based exploitation, where simply visiting a malicious webpage could trigger an attack. DNS rebinding and other techniques further expand this attack surface.
4. Physical Proximity: Perhaps the most novel and insidious vector, this attack requires only close physical proximity (Wi-Fi or Bluetooth range) between the attacker and victim. It exploits Apple's proprietary network interface, AWDL0 (Apple Wireless Direct Link), which is always listening and accepting connections, even if devices are not on the same network. This allows for "drive-by" attacks, reminiscent of James Bond movie scenarios, where exploits can be delivered by merely being near the target.

Regarding patching status, Apple has released patches for its devices almost a year prior to the talk (meaning late 2023/early 2024). Users are strongly encouraged to keep their macOS and other Apple devices updated. However, a significant concern remains for SDK-based IoT devices. Many third-party vendors have not yet patched their firmware, leaving billions of devices vulnerable. The speakers highlighted the "shared responsibility model," emphasizing that while Apple develops the SDK, it is the integrating vendor's responsibility to release and distribute patches for their specific products. They pointed out the common user behavior of rarely, if ever, updating devices like smart speakers.

For end-users, the speakers offered practical defensive recommendations:

• If a device is not intended to be used as an AirPlay receiver (i.e., you don't cast content to it), it is highly advisable to disable the AirPlay receiver function to significantly reduce the attack surface.
• If a device must act as an AirPlay receiver, the "Current User" setting is the safest option. This setting restricts AirPlay communication to only those devices logged in with the same Apple ID, offering a layer of authentication that mitigates some of the pre-authentication bypasses found.

Key Takeaways

• Persistent Vulnerability in IoT Ecosystem: Many AirPlay SDK-integrated devices from third-party vendors are unlikely to ever receive patches, leaving billions of devices perpetually vulnerable due to slow update cycles and lack of vendor support.
• Shared Responsibility Model: While Apple provides the AirPlay SDK, the onus is on the individual manufacturers to integrate security fixes into their product firmware and ensure timely distribution to users. It's not solely Apple's responsibility to patch every device using their SDK.
• Widespread Impact from Single Codebase: The same underlying vulnerable code in the AirPlay SDK affects a vast array of devices, from macOS and CarPlay systems to home speakers, demonstrating how a single flaw can have global implications across diverse hardware platforms.
• Embrace AirPlay with Caution: AirPlay remains an efficient and state-of-the-art protocol. Users are encouraged to continue using it but should be diligent in managing their device settings, specifically disabling the AirPlay receiver if not needed and utilizing the "Current User" option for enhanced security.
• Effective Responsible Disclosure: Apple's product security teams worked closely and professionally with the researchers for an extended period, prioritizing user safety and coordinating patches to avoid premature disclosure that could aid malicious actors.
• Overlooked Attack Vectors: The research brought to light several overlooked attack vectors, including browser-to-local-service communication and physical proximity via AWDL0, which do not require traditional network access.

About the Speaker(s)

Avi Lumelsky is the Lead for AI Security Research at Oligo. His work spans various aspects of security, including the "0000 day" browser vulnerability research that indirectly led to the AirPlay investigation.

Uri Katz is the Lead Researcher at Oligo and was the primary force behind the discovery and exploitation of the AirPlay vulnerabilities discussed in this talk. His innovative approaches, such as simulating certified device firmware, were crucial to the success of the research.

Both speakers noted that neither of them had prior experience researching Apple devices, making their extensive findings a testament to their dedication and methodical approach. They expressed pride in their achievements and their collaboration with Apple to secure users.