CVE-2023-45866: Unauthenticated Bluetooth keystroke-injection in Android, Linux, macOS and iOS
In 2016, I published keystroke-injection vulnerabilities in wireless mice and keyboards from 17 vendors. Branded as MouseJack, my research focused on the custom wireless protocols used by non-Bluetooth peripherals.
I was intimidated by Bluetooth at the time, and just sort of assumed it was secure. I didn't try to hack any Bluetooth devices, and I recommended Bluetooth as a secure alternative to the plethora of custom protocols. It never occurred to me that Bluetooth would have trivial keystroke-injection vulnerabilities like the MouseJack protocols, so I never looked.
Fast-forward to 2023, and I decided that I needed more hacker conferences in my life after having a blast at Hardwear.io. For me, conferences are synonymous with presenting research, so I set out to do some stunt-hacking.
I started with an investigation of wireless gaming keyboards, but they proved to be the wrong kind of dumpster fire, so I looked to Apple's Magic Keyboard for a challenge. It had two things notably absent from my earlier peripheral research: Bluetooth and Apple.
Research got off to a humbling start when I realized that I knew next to nothing about Bluetooth, macOS or iOS. I had a lot to learn, but one question led to another, and I was soon reporting unauthenticated Bluetooth keystroke-injection vulnerabilities in macOS and iOS, both exploitable in Lockdown Mode. At this point, I still thought Bluetooth was probably okay-ish, but the mirage of Apple security was starting to fade.
When I found similar keystroke-injection vulnerabilities in Linux and Android, it started to look less like an implementation bug, and more like a protocol flaw. After reading some of the Bluetooth HID specification, I discovered that it was a bit of both.
The vulnerabilities work by tricking the Bluetooth host state-machine into pairing with a fake keyboard without user-confirmation. The underlying unauthenticated pairing mechanism is defined in the Bluetooth specification, and implementation-specific bugs expose it to the attacker. Unpatched devices are vulnerable under the following conditions:
- Android devices are vulnerable whenever Bluetooth is enabled
- Linux/BlueZ requires that Bluetooth is discoverable/connectable
- iOS and macOS are vulnerable when Bluetooth is enabled and a Magic Keyboard has been paired with the phone or computer
The vulnerabilities can be exploited from a Linux computer using a standard Bluetooth adapter. Once the attacker has paired with the target phone or computer, they can inject keystrokes to perform arbitrary actions as the victim, provided those actions don't require a password or biometric authentication.
Some of the vulnerabilities predate MouseJack, and I was able to reproduce keystroke-injection on Android back to version 4.2.2, which was released in 2012. The Linux vulnerability was fixed in 2020 (CVE-2020-0556), but the fix was left disabled by default. ChromeOS is the only Linux-based OS known to have enabled the fix, even though it was announced by Ubuntu, Debian, Fedora, Gentoo, Arch and Alpine. The BlueZ patch for CVE-2023-45866 enables the 2020 fix by default.
I only tested recent versions of macOS and iOS, and am not privy to the full scope or history of the Apple vulnerabilities.
Proof-of-concept scripts and full vulnerability details will be released the week of ShmooCon (January 12-14).
I'm really not sure what sort of wireless keyboard to recommend at this point. If you are reading this and you make a secure wireless keyboard, please send me one so I can hack it for you. (I'm serious. I want a challenge.)
Anyway, this rabbit-hole kept going, so stay tuned for Part 2: More Vulnerabilities.
Happy Hacking!
Multiple Bluetooth stacks have authentication-bypass vulnerabilities that permit an attacker to connect to a discoverable host without user-confirmation and inject keystrokes.
A nearby attacker can connect to a vulnerable device over unauthenticated Bluetooth and inject keystrokes to eg. install apps, run arbitrary commands, forward messages, etc.
The attack does not require specialized hardware, and can be performed from a Linux computer using a normal Bluetooth adapter. Full exploit details and proof-of-concept scripts will be released the week of ShmooCon (January 12-14).
- The following devices were tested and found vulnerable:
- Pixel 7 running Android 14
- Pixel 6 running Android 13
- Pixel 4a (5G) running Android 13
- Pixel 2 running Android 11
- Pixel 2 running Android 10
- Nexus 5 running Android 6.0.1
- BLU DASH 3.5 running Android 4.2.2
- Security patch level 2023-12-05 mitigates the vulnerability in Android 11-14, and there is no fix available for Android 4.2.2-10.
- Disclosure Timeline
- 2023-08-05 - vulnerability reported to Google
- 2023-12-06 - public disclosure
- The following Ubuntu versions were tested and found vulnerable.
- Ubuntu 18.04, 20.04, 22.04, 23.10
- Per Google, ChromeOS is not vulnerable. I did not test ChromeOS, but their BlueZ configuration does appear to mitigate the vulnerability
- The following patch mitigates the vulnerability in BlueZ
- Details regarding the vulnerability and fix from Ubuntu:
- Details regarding the vulnerability and fix from Debian:
- Details regarding the vulnerability and fix from Fedora:
- Disclosure Timeline
- 2023-08-10 - vulnerability reported to Canonical
- 2023-09-25 - vulnerability reported to Bluetooth SIG
- 2023-10-02 - case opened with CERT/CC
- 2023-12-06 - public disclosure
- The following devices were tested and found vulnerable:
- 2022 MacBook Pro with MacOS 13.3.3 (M2)
- 2017 MacBook Air with macOS 12.6.7 (Intel)
- Lockdown Mode does not prevent the attack
- macOS Sonoma 14.2 fixes the vulnerability.
- Disclosure Timeline
- 2023-08-01 - vulnerability reported to Apple
- 2023-12-06 - public disclosure
- The following devices were tested and found vulnerable:
- iPhone SE running iOS 16.6
- Lockdown Mode does not prevent the attack
- Disclosure Timeline
- 2023-08-04 - vulnerability reported to Apple
- 2023-12-06 - public disclosure
| Vendor | Statement |
|---|---|
| Fixes for these issues that affect Android 11 through 14 are available to impacted OEMs. All currently-supported Pixel devices will receive this fix via December OTA updates. |