RustyInjector

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

• Verwenden Sie diesen Code nicht, um Systeme ohne ausdrückliche Genehmigung zu kompromittieren.
• Jede unbefugte, illegale oder unethische Nutzung dieses Projekts ist strengstens untersagt.
• Der Autor übernimmt keine Verantwortung für Missbrauch oder Schäden, die durch diesen Code verursacht werden.

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.

🦀 Rusty Injector !

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.

1. Wie funktioniert es?

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:

• Just Works (Nicht authentifiziert)
• Numeric Comparison (Authentifiziert)
• Passkey Entry (Authentifiziert)
• Out of Band (Authentifiziert) – Verlässt sich auf eine andere Technologie, um den Pairing-Prozess zu erleichtern.

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.

Nach dem Pairing mit dem Zielgerät stellt unser System eine Verbindung zum Service Discovery Protocol (SDP) über Port 1 der L2CAP-Schicht her. Wie in Diagramm 1 gezeigt, dient die L2CAP-Schicht als Vermittler zwischen den unteren und oberen Dienstschichten und übernimmt Segmentierung, Multiplexing und Wiederzusammensetzung von Datenpaketen. Über die SDP-Verbindung identifizieren wir alle verfügbaren Dienste auf dem Zielgerät und verbinden uns mit dem Human Interface Profile (HID)-Dienst. Das HID-Profil, das von Betriebssystemen zur Verarbeitung von Eingaben über Bluetooth-Tastaturen und -Mäuse verwendet wird, arbeitet über die Ports 17 (HID Control) und 19 (HID Interrupt) der L2CAP-Schicht. Für den Zugriff auf das HID-Profil ist keine Authentifizierung erforderlich, und jedes Gerät, das mit Port 17 und 19 der L2CAP-Schicht verbunden ist, wird als HID-Gerät erkannt.

Ein Angreifer kann die Dienste und die Geräteklasse einer kabellosen Bluetooth-Tastatur nachahmen, das Assoziationsmodell 'Just Works' ausnutzen, indem er eine 'NoInputNoOutput'-Fähigkeit angibt, und nicht autorisierte Tastatureingaben in das Zielgerät einschleusen.

2. Wie wurde es umgesetzt?

Um ganz ehrlich zu sein, bestand das einzige Ziel darin, den Proof of Concept in Rust neu zu implementieren, um ein tieferes Verständnis der Hintergründe dieses Exploits zu gewinnen. Deshalb wurde die Gesamtarchitektur in dieser ersten Iteration vom Python-PoC von Marc Newlin inspiriert: Github "hi_my_name_is_keyboard". In einer zukünftigen Überarbeitung könnte es auf eine rustigere Art und Weise implementiert werden.

Crates (= Rust-Bibliotheken), die bei dieser Implementierung verwendet wurden:

[dependencies]
bluer = { version = "0.17.3", features = ["l2cap", "bluetoothd", "id", "rfcomm"] }
tokio = "1.42.0"
regex = "1.11.1"
clap = { version = "4.5.23", features = ["derive"] }

Die wichtigste Abhängigkeit in meinem Projekt war 'BlueR', eine Rust-API, die auf der ursprünglichen BlueZ-C-Bibliothek aufbaut. Sie können sich ihre Arbeit hier ansehen: GitHub BlueR. Ich habe außerdem Tokio integriert, um die von der BlueR-Bibliothek bereitgestellten async-Funktionen nutzen zu können. Darüber hinaus habe ich Clap, einen Kommandozeilen-Argumentparser, und Regex, eine Crate zur Implementierung regulärer Ausdrücke in Rust, verwendet, um Benutzereingaben für 'bt_addr' (Bluetooth-Adresse) zu validieren.

Nach Beobachtung der Implementierung von Marc Newlin habe ich die Architektur in mehrere Schritte zerlegt, um dieselbe Funktionalität nachzubilden:

1. Benutzerargumente parsen, um Folgendes zu erhalten:
   • --iface oder -i, die für die zu verwendende Bluetooth-Schnittstelle / den Adapter stehen. Dieses Argument ist optional; wenn nichts angegeben wird, wird versucht, eine Standard-Schnittstelle zu verwenden.
   • --target oder -t, das obligatorisch ist und die Bluetooth-Adresse des Ziels angibt.
2. Einen Bluetooth-Agent mit NoInputNoOutput-Fähigkeiten bereitstellen, um während der Verbindung mit dem Zielgerät auf die Pairing-Methode 'Just Works' zugreifen zu können.
3. Ein Profil mit HID-Tastaturdiensten registrieren und die Klasse 0x002540 registrieren, um eine Tastatur vorzutäuschen.
4. Alle Enums und Funktionen erstellen, um unsere Eingaben in die richtigen HID-Bytes umzuwandeln, die in HID-Paketen gesendet werden sollen.
5. Verbindungen zu den richtigen Ports auf der L2CAP-Schicht herstellen (Port 1 - SDP, Port 17 - HID Control & Port 19 - HID Interrupt) und unberechtigte Tastatureingaben injizieren.

Ich habe versucht, meinen Code so gut wie möglich zu kommentieren. Wenn Sie ihn durchgehen, werden Sie alle diese Schritte leicht wiedererkennen. Um es eleganter zu gestalten, wäre der nächste Schritt, es rustiger zu machen, eine saubere Beendigung zu haben und einige weitere Funktionen hinzuzufügen, wie die Möglichkeit, Tastatur-Skripte (vorbereitete Payloads) zu parsen oder eine grafische Benutzeroberfläche zu haben. Noch einmal: Dies diente nur Bildungszwecken, und ich bin nicht sicher, ob ich an einer weiteren Iteration dieses Programms arbeiten werde. Aber auch hier sind Beiträge herzlich willkommen. Wenn Sie Fragen haben, zögern Sie nicht, sie zu stellen.

3. Wie verwendet man es?

Zunächst ist anzumerken: Dieses Tool wurde unter Ubuntu 24.04 entwickelt und getestet.

Um dieses Tool zu verwenden, müssen Sie den standardmäßig von BlueZ registrierten HID-Dienst deaktivieren, damit er beim Start des Exploits neu registriert werden kann. Führen Sie die folgenden Schritte aus:

• Bearbeiten Sie die Konfigurationsdatei /etc/systemd/system/bluetooth.target.wants/bluetooth.service
• Ändern Sie die Zeile: ExecStart=/usr/libexec/bluetooth/bluetoothd in die folgende: ExecStart=/usr/libexec/bluetooth/bluetoothd --noplugin=input
• Nach dem Ändern der Datei müssen Sie die systemd-Konfiguration neu laden und den Bluetooth-Dienst neu starten, um die Änderungen zu übernehmen. sudo systemctl daemon-reload sudo systemctl restart bluetooth

Jetzt müssen Sie nur noch das Projekt holen und es ausführen, indem Sie es mit cargo build bauen oder es direkt ausführen, indem Sie die Argumente wie folgt angeben: cargo run -- -i [BT_INTERFACE] -t [BT_TARGET].

Screenshot 3 : Kommandozeilenschnittstelle von Rusty Injector.

Hier ist ein Beispiel: cargo run -- -i hci0 -t AA:BB:CC:DD:EE:FF

Ein weiterer Punkt ist, dass Sie, wenn Sie den Code ändern und die Funktion "set_address" über das Configuration-Trait verwenden möchten, das Tool bdaddr installieren müssen, um es nutzen zu können:

# build bdaddr from the bluez source
cd ~/
git clone --depth=1 https://github.com/bluez/bluez.git
gcc -o bdaddr ~/bluez/tools/bdaddr.c ~/bluez/src/oui.c -I ~/bluez -lbluetooth
sudo cp bdaddr /usr/local/bin/

Bitte beachten Sie: Wenn Sie keine Bluetooth-Schnittstelle angeben, wird versucht, eine Standard-Schnittstelle zu verwenden. Und NATÜRLICH sollten Sie nicht vergessen, eine Bluetooth-Schnittstelle an Ihr Ubuntu-Betriebssystem anzuschließen.🙃

Ich glaube, ich habe alles abgedeckt – Sie sind jetzt bereit, das Beste aus Rusty Injector herauszuholen! Wenn Sie auf Probleme stoßen oder Kommentare oder Feedback haben, können Sie gerne ein Issue eröffnen. Viel Spaß und Happy Hacking! 🚀