Hi, My Name Is Keyboard

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 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.

Full vulnerability details and proof-of-concept scripts will be released at an upcoming conference, and I will update this document with conference details when available.

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!

Vulnerability Details

What is the vulnerability?

Multiple Bluetooth stacks have authentication-bypass vulnerabilities that permit an attacker to connect to a discoverable host without user-confirmation and inject keystrokes.

What is the impact?

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.

What hardware is required exploit the vulnerability?

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 at an upcoming conference.

Android

• 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

Linux/BlueZ

• 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: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/profiles/input?id=25a471a83e02e1effb15d5a488b3f0085eaeb675
• 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

macOS

• 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
• 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 Statements