Do a firmware update for your AirPods – now

tldr: There’s a security vulnerability (CVE-2024-27867) in the firmware of Apple AirPods. Anyone who knows the Bluetooth MAC address (which is somewhat public) can connect to your AirPods and listen to the microphone or play music. Even while the AirPods are connected to your phone (although music would stop playing in case somebody turns on the microphone).

Update: Just to clarify, the vulnerability is not present while the AirPods are inside the closed charging case (or Smart Case for the AirPods Max), as then they are in a state where the radio is inactive and no connections at all are possible.

A firmware update is available for AirPods 2, 3, Pro, Pro 2, Max, and some Beats headphones. See here for how to update.

A story of stumbling upon a vulnerability in an Apple product

A few months ago I got a pair of AirPods 3. After some initial amazement at how magically they worked together with my (Apple) phone and (Apple) laptop, I switched back to my everyday world and rebooted the laptop back into Linux. And while the AirPods worked somewhat fine there too, they now refused to connect to both my phone and laptop at the same time.

That got me interested: It just worked when I was using macOS, but it didn’t work with Linux on the exact same laptop. I figured that they’re probably using a bunch of special Apple-specific protocols to get all of these fancy features that other Bluetooth headphones don’t have. So I decided to take a closer look and re-implement a few of them, to see if I could get all the functionality working on Linux as well.

In the process of all this (I’ll talk about the specifics in another blog post), I found a vulnerability in the “Fast Connect” feature that Apple has for connecting Bluetooth peripherals. Fast Connect is a proprietary and US-patented protocol by Apple that creatively uses the “ping” feature of the Bluetooth specification. Its main purpose seems to be reducing the time it takes to establish a connection between two Apple devices from roughly 1 second down to about 0.5 seconds.

The basic way Fast Connect works is that before authenticating with the device you’re connecting to (ie. the AirPods), both devices exchange L2CAP ping messages (think of them like normal pings in networking), and Apple puts protocol messages into the payload of the ping. With this trick, they can establish that both devices are speaking the Fast Connect protocol without violating the Bluetooth specification, and then go on to exchange 3 more back-and-forth messages, negotiating all the things necessary to fully connect the two devices.

The fact that this only takes 4 messages back-and-forth in total is what makes Fast Connect fancy, because usually in Bluetooth the phase of wiring up the individual channels for a connection is quite a complex negotiation and involves sending various SDP descriptors that describe which protocols/features both sides support.

The vulnerability

Turns out that Apple (most likely) forgot to do some checks in the separate code paths that implement Fast Connect. Some very important ones: The AirPods forget to check the security level of the connection, i.e. “did the other side actually authenticate itself and turn on encryption?”

Authentication and enabling encryption is a step that is supposed to happen after the initial Fast Connect message. Of course iOS and macOS do that perfectly fine, but if an attacker decides to skip that step when connecting, the AirPods will happily continue on with the Fast Connect. This authentication step is somewhat implicit if you connect the AirPods without Fast Connect (ie. the way all non-Apple Bluetooth devices would connect), and that’s probably the reason why they forgot to add an explicit check for that in the Fast Connect code paths.

So yeah, with this vulnerability, anyone can connect to your AirPods, as long as they know the fixed Bluetooth MAC address of the AirPods. This address is not exactly private information, it’s advertised on the air when your Bluetooth device is in pairing mode, and it can be easily obtained on the air while the AirPods are active using hardware like the Ubertooth One.

Once connected, an attacker can do everything a legitimate device can do, listen to the microphone, play music, see and pause the music that is currently playing from another connected device, or do various things the AAP protocol can do (like changing settings, crashing the AirPods by sending badly formatted messages, and a lot more things I haven’t looked into).

The fix – and the Android problem

Apple has released various firmware updates with fixes for this vulnerability over the past few days, so if you own AirPods, you should make sure the firmware is up to date.

Of course this is all especially problematic for people who use AirPods without iOS or macOS devices (hello Android, Windows, or Linux users). That’s because AirPods auto-update their firmware by themselves, but only when they’re used together with an iPhone or MacBook, so Android users have no easy way to update their firmware. If you’re one of those users, it seems like you can go to an Apple Store and they will update the firmware for you.

Thanks

Finding and reporting all this was quite the journey. I’d like to give a special thanks to Jiska Classen from University of Potsdam for helping with a bunch of Bluetooth questions and tips about the disclosure process.

And of course a big thank you to the whole Linux community! Without awesome tools like BlueZ it wouldn’t have been possible to find any of these issues.