xg3nesis/rustyinjectorRust-Implementierung des Proof-of-Concept für Keystroke-Injection von Marc Newlin (CVE-2023-45866).
⚠️ Haftungsausschluss: Nur für Forschungs- und Bildungszwecke
Dieses Projekt ist ein Proof of Concept (PoC), der Bluetooth-Tastatureingabe-Injection demonstriert und in Rust neu implementiert wurde. Es ist ausschließlich für Bildungs- und Sicherheitsforschungszwecke gedacht.
Durch das Herunterladen, Klonen oder Verwenden dieses Codes erklären Sie sich damit einverstanden, ihn verantwortungsbewusst und in Übereinstimmung mit allen geltenden Gesetzen und Vorschriften zu verwenden.
Willkommen bei Rusty Injector – einer Rust-Implementierung, die von Marc Newlins Bluetooth-Tastatureingabe-Injection-PoC inspiriert ist und mit CVE-2023-45866, CVE-2024-21306 und CVE-2024-0230 verknüpft ist.
Derzeit implementiert dieses Repository nur CVE-2023-45866, das Tastatureingabe-Injection-Schwachstellen in BlueZ auf dem Betriebssystem Linux ausnutzt.
Im Folgenden sehen Sie einen Screenshot der NIST-Beschreibung, einschließlich der CVSS-Bewertung:
Screenshot 1 : NIST-Beschreibung von CVE-2023-45866.
Die Implementierung der anderen CVEs, CVE-2024-21306 und CVE-2024-0230, ist von mir nicht geplant, aber Beiträge sind herzlich willkommen.
Bevor wir ins Detail gehen, empfehle ich Ihnen, sich die Präsentation von Marc Newlin auf der NullCon 2024 Conference anzusehen, da sie eine klare und gründliche Erklärung dieser Schwachstellen bietet: Hi, My Name Is keyboard von Marc Newlin..
Außerdem habe ich ein Video bereitgestellt, das diese Schwachstelle allgemeinverständlich erklärt. Sie finden es direkt hier: How a Simple Bluetooth Hack Can Hijack Your Device - Hi, my name is keyboard.
📌 Wenn Ihnen fehlende Punkte auffallen, Bereiche, die besser vereinfacht werden könnten, oder mögliche Fehler in der folgenden Erklärung, können Sie diese gerne ändern und einen Merge-Request einreichen. Ich würde mich freuen, Ihre Beiträge zu überprüfen und in das Repository aufzunehmen.
Da wir uns nur mit der Schwachstelle CVE-2023-45866 befasst haben, die für Linux-Betriebssysteme gilt, erklären wir nur den Prozess, der zu dieser spezifischen, gegen die BlueZ-Bibliothek gerichteten Ausnutzung führt.
Zunächst müssen Sie verstehen, dass diese Schwachstelle nur über Bluetooth BR/EDR ausnutzbar ist, da sie auf das HID-Profil abzielt, das auf dieser Technologie basiert. Sie wissen vielleicht, dass die Bluetooth-Architektur in mehrere Schichten unterteilt ist, ähnlich wie das OSI-Modell für das Ethernet-Protokoll, und wie Sie in unserem folgenden Schema sehen können.
Diagramm 1 : Vereinfachter Bluetooth-BR/EDR-Stack (Basic Rate - Enhanced Data Rate). Die unterste Schicht des Stacks repräsentiert die physische Schicht mit einer dedizierten Antenne, und die oberste Ebene steht für die Anwendungsebene, die wir manchmal auch als Betriebssystem bezeichnen. Wenn zwei Geräte miteinander kommunizieren möchten, durchlaufen sie diese verschiedenen Schichten: von oben nach unten für ausgehende Pakete und von unten nach oben für eingehende Bluetooth-Pakete.
Nach dem Inquiry-Prozess, sobald die Geräte feststellen, dass sie eine Verbindung aufbauen möchten, fahren sie mit dem Pairing-Prozess fort. Dieser Prozess ermöglicht die gegenseitige Authentifizierung zwischen den Geräten und die Einrichtung eines Verschlüsselungsschlüssels, der anschließend zur Sicherung der Kommunikation verwendet wird.
Die Bluetooth-Spezifikation bietet verschiedene Stufen der Authentifizierung und Sicherheit. Je nach verwendetem Authentifizierungsmechanismus kann das Sicherheitsniveau der Kommunikation variieren. Geräte können sich auf der Grundlage der Eingabe- und Ausgabe-Peripheriegeräte authentifizieren, die sie besitzen – ein Konzept, das als Assoziationsmodelle bezeichnet wird. Sie sind diesem wahrscheinlich schon beim Pairing zweier Geräte begegnet – etwa wenn Sie aufgefordert wurden, eine PIN einzugeben, die auf dem anderen Gerät angezeigt wird.
Es gibt vier Pairing-Assoziationsmodelle, die durch die I/O-Fähigkeiten (Input/Output) der Geräte bestimmt werden:
Unten finden Sie eine Tabelle, die zeigt, welches Assoziationsmodell basierend auf den Fähigkeiten unserer IoT-Geräte verwendet wird.
Diagramm 2 : Tabelle, die die Bluetooth-BR/EDR-Assoziationsmodelle veranschaulicht, inspiriert von der Bluetooth Core Specification v5.3 – 2.3.5.1 Selecting key generation method, Tabelle 2.8: Mapping von IO-Fähigkeiten zur Schlüsselerzeugungsmethode (Seite 1573). Weitere Informationen zu Sicherheitsmodi und Assoziationsmodellen finden Sie in diesem interessanten Blogbeitrag von Thyrasec: Bluetooth Security : Classic & BLE!
Ich bin überzeugt, dass Sie die 'Just Works'-Methode interessant finden, und genau hier liegt unsere Schwachstelle. Das Problem: Diese Methode stellt das Pairing her, ohne dass eine Bestätigung oder Interaktion des Benutzers erforderlich ist, sodass es keine Möglichkeit gibt, die Authentizität des koppelnden Geräts zu überprüfen. Auf Linux-Systemen akzeptierte der BlueZ-Stack standardmäßig eingehende Pairing-Anfragen von Geräten, die als NoInputNoOutput eingestuft wurden (um Abwärtskompatibilität zu ermöglichen). Eine wirklich "wunderbare" Designentscheidung, finden Sie nicht auch?
Screenshot 2 : Update der Standardkonfiguration von blueZ, um die Bluetooth-Sicherheit zu aktivieren und CVE-2023-45866 zu patchen.
