xg3nesis/rustyinjectorRust implementation of Marc Newlin's keystroke injection proof of concept (CVE-2023-45866).
⚠️ Disclaimer: For Research and Educational Purposes Only
This project is a Proof of Concept (PoC) demonstrating Bluetooth keystroke injection, re-implemented in Rust. It is intended strictly for educational and security research purposes.
By downloading, cloning, or using this code, you agree to use it responsibly and in compliance with all applicable laws and regulations.
Welcome to Rusty Injector — a Rust implementation inspired by Marc Newlin's Bluetooth keystroke injection PoC, linked to CVE-2023-45866, CVE-2024-21306, and CVE-2024-0230.
Currently, this repository only implements CVE-2023-45866, which exploits keystroke injection vulnerabilities in BlueZ on the Linux operating system.
Below is a screenshot of the NIST description, including the CVSS scoring :
Capture 1 : NIST description of CVE-2023-45866.
The other CVEs, CVE-2024-21306 and CVE-2024-0230, are not planned for implementation by myself, but contributions are warmly welcomed.
Before getting into any details, I encourage you to watch Marc Newlin's presentation at the NullCon 2024 Conference, as it offers a clear and thorough explanation of these vulnerabilities : Hi, My Name Is keyboard by Marc Newlin..
*I've also made available a video that popularizes this vulnerability. You'll find it right here : How a Simple Bluetooth Hack Can Hijack Your Device - Hi, my name is keyboard.
📌 If you notice any missing points, areas that could be better simplified, or potential mistakes in the explanation below, please feel free to modify it and submit a merge request. I would be delighted to review your contributions and incorporate them into the repository.
As we have only covered CVE-2023-45866 vulnerability standing for Linux operating systems, we would only explain the process to reach this specific exploitation targeting the BlueZ library.
First of all, you must understand that this vulnerability is only exploitable on Bluetooth BR/EDR because it is targeting the HID profile standing upon this technology. You may know that the bluetooth architectural implementation is divided into multiple layers such as the OSI model for the ethernet protocol, and as you can observe it on our schematic below.
Diagram 1 : Simplified Bluetooth BR/EDR (Basic Rate - Enhanced Data Rate) stack. The lowest layer of the stack represents the physical layer with a dedicated antenna, and the higher level stands for the application level or that we can sometimes designate as the operating system. When two devices want to communicate with eachother, they go through these different layers : from up to bottom for outgoing packets and bottom to up for incoming bluetooth packets.
After the inquiry process, once the devices determine that they want to establish a connection, they proceed to the pairing process. This process enables mutual authentication between the devices and the establishment of an encryption key, which is then used to secure the communication.
The Bluetooth specification offers different levels of authentication and security. Depending on the mechanism used for authentication, the level of security for the communication may vary. Devices can authenticate based on the input and output peripherals they possess, a concept referred to as association models. You have likely encountered this when pairing two devices—such as being asked to enter a PIN code displayed on the other device.
There are four pairing association models, determined by the devices' I/O (Input/Output) capabilities:
Below is a table showing which association model is used based on the capabilities of our IoT devices.
Diagram 2 : Table illustrating Bluetooth BR/EDR association models inspired by the Bluetooth Core Specification v5.3 - 2.3.5.1 Selecting key generation method Table 2.8 : Mapping of IO cacpabilities to key generation method (page 1573). For more information on security modes and association models, please check this interresting blog post published by Thyrasec : Bluetooth Security : Classic & BLE !
I’m confident you’re intrigued by the 'Just Works' method, which is precisely where our vulnerability lies. Here’s the issue: this method establishes pairing without requiring user confirmation or interaction, leaving no way to verify the authenticity of the pairing device. On Linux systems, the BlueZ stack, by default, accepted incoming pairing requests from devices classified as NoInputNoOutput (to enable backward compatibility). A truly "wonderful" design choice, wouldn’t you agree?
Capture 2 : Update of the default configuration of blueZ to enable bluetooth security and patch CVE-2023-45866.
After pairing with the target device, our system establishes a connection to the Service Discovery Protocol (SDP) through port 1 of the L2CAP layer. As shown in Diagram 1, the L2CAP layer serves as an intermediary between the lower and upper service layers, providing segmentation, multiplexing, and reassembly of data packets. Through the SDP connection, we identify all available services on the target device and connect to the Human Interface Profile (HID) service. The HID profile, used by operating systems to process input from Bluetooth keyboards and mice, operates via ports 17 (HID Control) and 19 (HID Interrupt) of the L2CAP layer. To access the HID profile, no authentification is required and any device connected to port 17 and 19 of the L2CAP is recognized as an HID device.
An attacker can impersonate the services and device class of a Bluetooth wireless keyboard, exploit the 'Just Works' association model by specifying a 'NoInputNoOutput' capability, and inject unauthorized keystrokes into the target device.
