2024 has barely started, and a researcher has already publicly disclosed several vulnerabilities related to Bluetooth HID that allow attackers to take control of devices. Marc Newlin disclosed at ShmooCon 2024 a series of vulnerabilities that impact almost every major OS. They join a large list of Bluetooth vulnerabilities and attacks that have been found over the last few years.
Marc found several related vulnerabilities in multiple devices through fuzzing and experimentation. He had previously disclosed wireless exploits in wireless mice called MouseJack a few years ago. What’s amazing is that these issues are broad, impacting multiple platforms:
- Windows – if a Bluetooth keyboard was previously paired with a computer, and the keyboard is powered off or out of range, it’s possible to attack and masquerade as that keyboard
- macOS – If the computer is paired to a Magic Keyboard, it’s possible to extract keys and inject keystrokes
- iOS – if the iPhone or iPad is paired to a Magic Keyboard it’s possible to extract keys and inject keystrokes
- Android – Vulnerable if Bluetooth is enabled. Allows injecting keystrokes
- Linux – vulnerable if Bluetooth is discoverable and connectable. Allows injecting keystrokes
These Bluetooth vulnerabilities were publicly disclosed with the following CVEs:
- CVE-2023-45866 – BlueZ Bluetooth Stack HID vulnerability
- CVE-2024-0230 – Apple Bluetooth pairing key extraction vulnerability
- CVE-2024-21306 – Microsoft Bluetooth Driver spoofing vulnerability
Before we discuss the vulnerabilities, let’s talk a bit about Bluetooth HID and how it works so we can understand where the issues are.
Bluetooth Vulnerability in HID Overview
HID is an acronym for Human Interface devices. You can think of keyboards and mice as HID devices, though there are others like joysticks for example. HID is typically running on USB(wired mice and keyboards).
To enable wireless devices like wireless mice and keyboards, the Bluetooth SIG created the Bluetooth HID profile, which is specified in the Bluetooth HID Profile Specification.
Both wired and wireless HID rely on what are called Reports. Reports are periodic messages with a specific format that are transmitted by an HID device and processed by the host. For example, a mouse HID report contains the mouse movement and button presses. There’s actually three types of HID reports:
- Feature HID reports are used by a host device to discover the features of the HID device
- Input HID reports include input data like keyboard keypress and mice movements / button clicks
- Output HID reports are commands sent to the HID device to configure it or change settings
What’s critical about Bluetooth HID is that if you can get a connection to a system by emulating a keyboard, you can issue commands that the system will interpret as if they were typed by the actual user. This can mean any system can be breached because those commands can, for example, create new users, connect to unsafe websites, download malware, etc.
Bluetooth L2CAP and HID
Many devices use Bluetooth Classic as the transport for HID reports. On a low level, once you have a basic Bluetooth connection, your system forwards packets to the Bluetooth L2CAP layer. Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) supports higher level protocol multiplexing, packet segmentation and reassembly, and dealing with QoS. It’s one of the many layers of Bluetooth Classic, and it’s the entry point to send data to the system.
L2CAP uses fixed channels, which Are just reassigned 16-bit numbers. Some are pre-allocated by the Bluetooth SIG while others can be used freely by the system implemented. The Bluetooth HDI specification uses two particular channels:
- L2CAP Channel 0x0011 (17) – HID Control which allows sending of feature reports and is high latency
- L2CAP Channel 0x0013 (19) – HID Interrupt which allows sending input and output reports with low latency
The key here is that if we are able to send packets with the right format to the HID control and interrupt channels, that means we are acting as if we’re a keyboard or mouse.
Accessing the Bluetooth L2CAP HID channels requires pairing with the device. Pairing involves connecting and exchanging cryptographic data to secure the connection. For the user this usually involves selecting the device from a list and pressing connect.
Now that we understand Bluetooth HID better, let’s discuss how these vulnerabilities can happen and why.
Bypassing pairing authentication
So if pairing needs the user to accept, how can these attacks be performed with no user interaction?
Well, there’s another mechanism that’s done to make the user experience easier – the keyboard can start the connection and pairing process. That’s normally not an issue but it seems that in many cases the authentication process can be bypassed altogether.
To start the Bluetooth HID pairing process, the Host device (computer, etc.) needs to be discoverable and connectable. If it is, then the keyboard can start the connection and pairing process. Now, the key in getting this to work is that the keyboard can specify certain settings that allow it to not require authentication. These are certain fields in the connection packets . The vulnerable devices then themselves ignore any authentication, establish the encryption keys and go about as if everything is fine. The user has no idea what has just happened.
Now, the situation above is slightly different for Windows, macOS and iOS. In this case, aside from being connectable and discoverable, the L2CAP access (and ability to connect) is possible only for known peripherals. That is, only peripherals that were previously paired can reconnect this way. The way this is done is by identifying devices by their Bluetooth address.
Well, it’s trivial to fake a Bluetooth address, because devices advertise it. This means we can create a keyboard that has the address of a legitimate keyboard. Once that’s done, we can connect to the host and then we’re in the same position – we bypass authentication and send Bluetooth HID reports with whatever data we want.
Android Bluetooth HID Vulnerability
Android’s Bluetooth vulnerability is maybe the worst of the bunch because it is so broad. It impacts Android versions 4.2, 5, 6,7 ,8, 9 and 10 (earlier versions of Android weren’t tested since so few devices are available). As long as Bluetooth is enabled, which is pretty much the case with every Android device since no one turns of Bluetooth these days, it’s vulnerable to attack. It also doesn’t require any user interaction (zero-click).
This may be why Google paid Marc the highest bounty. It keeps Androids reputation as a bad Bluetooth implementation (in our opinion well deserved).
Linux and BlueZ Bluetooth HID Vulnerability
Second worst is Linux which uses the BlueZ stack. It’s vulnerable to attack when the device is discoverable and connectable over Bluetooth. Linux usually puts the system into this mode when the user clicks on the Bluetooth settings panel, but in some industrial and commercial devices, this mode can be enabled for long periods of time in other ways (custom applications).
While It’s pretty rare for a user to open the Bluetooth settings panel for long periods of time, it could be possible to force this situation by interfering with streaming for example. Still, this vulnerability is more limited if that’s the only way BlueZ acts.
As before, the vulnerability is pretty straightforward – BlueZ lets unauthenticated Peripheral BLE HID devices establish an encrypted connection and accept HID keyboard reports without the user needing to accept the connection.
Vulnerable Distros
As far as applicability, CVE-2023-45866 impacts a huge number of Linux distributions:
- Ubuntu
- Debian
- Redhat
- Amazon
- Fedora
- Gentoo
- Arch
- OpenEmbedded
- Yocto
- NixOS
The good news is that the patches are in place and one can update.
BlueZ fix Vulnerability
Because it’s open source, we can look at the fix for the Bluetooth HID vulnerability in the BlueZ stack. It is literally one line and can be found here.
What’s interesting is that it implies the stack was not in compliance with the Bluetooth HID specification “which mandates the use[sic] of Security Mode 4”.
The fix changes the classic_bonded_only variable default from false to true. As the comments indicate, the original defaulted to false to help device compatibility. But using “true” is the proper option for security. As is often the case, legacy device support hinders security, and they did so in this case.
Apple macOS and iOS Bluetooth Vulnerability
As we mentioned before, macOS and iOS add a little bit of difficulty by only allowing connections like this with existing paired devices, but this can be bypassed by capturing the existing keyboard’s MAC address and cloning it. it also requires the other keyboard be disconnected or out of range so one can connect instead of it. This reduces the vulnerability’s attack surface but still makes it possible.
Apple has fixed the issue in iOS 17.2 and macOS 14.2, but iOS 16 and prior, as well as macOS 12, 13 and likely prior versions remain vulnerable. The best thing to do (as usual) is to update any iOS and macOS device.
Windows Bluetooth Vulnerability
In Windows, like macOS and iOS, the device needs to have been previously paired. This also limits the attack surface but just a bit – it’s still possible to attack a Windows device.
Microsoft fixed this issue in Windows 10, 11 and Server 2022 with the January 2024 Patch.
Apple Magic Keyboard Key Extraction
In addition to the Bluetooth HID vulnerability that allows attackers to inject keystrokes, Marc also found that the Apple Magic Keyboard was sending the Bluetooth link key over USB inHID reports. It is also possible to extract the Bluetooth keys via USB afterwards.
How did this happen? Well, Apple is usually known for creating seamless experiences. One of the features in the Magic Keyboard is that when the USB cable is disconnected from the Mac, the keyboard automatically connects via Bluetooth so the user can keep on typing, a handoff basically.
For this to happen, the keyboard already needs to be paired with the computer.
The problem is that the Mac sends the Link Key (the key used to protect the data in Bluetooth) over USB with the Bluetooth address of the Mac in the clear, allowing anyone capturing that traffic to get it. Naturally, the keyboard stores this Bluetooth Link key and Address in memory.
So, as long as the Magic Keyboard is on, it’s possible to get the link key by connecting to the Lightning port and reading the HID report. This can essentially bypass all security for the computer since you now have the keys to communicate with it.
The keyboard uses HID report 0x35 to send Out-of-Band pairing data that Bluetooth can use to establish a supposedly secure connection. Connecting to the Keyboard’s Lightning Port, you can read the same HID report 0x35 to get the same information and the link key itself.
But what Apple’s engineers probably didn’t realize, was that this along with Bluetooth HID would allow key retrieval wirelessly.
Unauthenticated Bluetooth HID
Beyond the USB/Lightning connection to the keyboard, it seems that the Apple Magic Keyboard has unauthenticated Bluetooth HID services that allow for reading this same link key and also configuring it. This capability was done to allow the Mac to send it the Bluetooth key for the first time. But it also means anyone able to connect to a keyboard that has paired with a Mac can get the key if they can connect to it.
This “feature” is actually part of the Bluetooth specification which recommends:
Bluetooth HID devices in Discoverable Mode should allow the HID Control channel
and HID Interrupt Channel to be opened without encryption. Many Bluetooth HID
Host stacks compliant to Bluetooth Core Specifications prior to v2.1 + EDR expect
this behavior from Bluetooth HID keyboards as it enables the Bluetooth HID
keyboard to send Security Code Character notifications (see the Generic Device
Controls page in [4]) while the user types the passcode. A Bluetooth HID keyboard
that is implemented to require the use of encryption may be implemented such that
it does not send any keystroke information other than Security Code Character
notifications until pairing is completed.Bluetooth HID Specification 5.4.3.3.3 – Backwards Compatibility
If an attacker can connect to the keyboard quickly enough before the Mac can, the unauthenticated Bluetooth HID services can be used to read the link key via the HID report, which would then compromise the Mac itself since the link key can be read and used by an attacker.
Clearly, Apple’s implementation here is severely flawed. Even though the window to do this attack is limited, it’s still possible and Marc reported he could connect successfully 50% of the time. We assume with some changes that this success rate can be improved. Bluetooth Classic connections can be slow but with some information can be sped up.
Fancy (In)Security
One of the interesting aspects about finding the Apple vulnerabilities is that Marc initially assumed that because the products were Apple, that they were secure. Of course, he ended up finding that it wasn’t the case and Apple had some of the worst issues.
This is an issue we’ve seen before. The reputation and size of a company, especially one with a lot of security experts, can make it seem as if those products are all secure. But in reality, there’s usually only one engineer implementing a feature. Sometimes different engineers implementing things and something falls through the cracks. No matter how big the company is, it’s possible for it to experience.
Bug Bounty Program
Marc Newlin, the researcher that found the vulnerabilities, has been compensated by Microsoft and Google. The story with Apple, however, is different. Apparently Apple is still assessing the vulnerabilities because “they don’t fit neatly into any of their bug bounty categories”.
We hope Marc is compensated by Apple, because these vulnerabilities are pretty big and it’s a small price to pay to help protect Apple customers and their devices.
We’re fans of companies having bug bounty programs. In the real world, vulnerabilities are being bought and sold, so there’s definitively a price. Some of these attacks are significant and can be used for all kinds of nefarious activities. It’s critical product developers keep incentivizing people to do security research.
Summary
There may be more coming from Marc and other researchers about these vulnerabilities. But these attacks show that Bluetooth continues to be an open attack surface that can lead to pretty significant vulnerabilities. Some of these issues can stay hidden for a long time, affect a wide range of systems across different operating systems and Bluetooth stacks. Even worse – some systems will never be patched. Some smartphones with older versions of Android won’t get a fix, making them vulnerable to attack.
We would expect other stacks and devices to be vulnerable to this issue.
We haven’t yet reproduced the issues and test them in our lab, but we’re working on putting a proof of concept together as well. There may be other devices vulnerable to it.
References / More Information
Hi, My Name is Keyboard
Hi, My Name is Keyboard Presentation
Bluetooth Human Interface Device Profile 1.1.1
Bluetooth Assigned Numbers