Bluetooth-Tastatureingabe-Injektionslücke in Android, Linux, macOS und iOS
(github.com/skysafe)- CVE-2023-45866 ist eine Authentifizierungs-Bypass-Schwachstelle in den Bluetooth-Stacks mehrerer Betriebssysteme, durch die sich ohne Bestätigung des Nutzers eine gefälschte Tastatur verbinden und Tastatureingaben einschleusen lassen
- Angreifer in räumlicher Nähe können ohne spezielle Hardware allein mit einem Linux-Computer und einem gewöhnlichen Bluetooth-Adapter Aktionen wie die Installation von Apps, das Ausführen beliebiger Befehle oder das Versenden von Nachrichten versuchen
- Die Voraussetzungen für die Schwachstelle unterscheiden sich je nach Plattform: Bei Android ist vor allem entscheidend, ob Bluetooth aktiviert ist; bei Linux/BlueZ der discoverable/connectable-Status; bei iOS und macOS, ob ein Magic Keyboard gekoppelt ist
- Android 11-14 wird mit dem Sicherheits-Patch-Level 2023-12-05 entschärft, für Android 4.2.2-10 gibt es jedoch keinen Fix, und bei BlueZ war ein Fix aus dem Jahr 2020 standardmäßig deaktiviert
- Aktionen, die ein Passwort oder biometrische Authentifizierung erfordern, lassen sich nicht allein per Tastatureingabe-Injektion ausführen, doch ungepatchte Geräte können Nahbereichs-Bluetooth-Angriffen ausgesetzt sein
Bluetooth-Tastatureingabe-Injektion ohne Authentifizierung
- CVE-2023-45866 ist eine Schwachstelle, die Bluetooth-Keystroke-Injection ohne Authentifizierung auf Android, Linux, macOS und iOS ermöglicht
- In mehreren Bluetooth-Stacks ist ein Authentifizierungs-Bypass möglich, bei dem sich Angreifer ohne Bestätigung durch den Nutzer mit einem discoverable Host verbinden und Tastatureingaben injizieren können
- Angreifer in räumlicher Nähe können eine nicht authentifizierte Bluetooth-Verbindung zu einem verwundbaren Gerät aufbauen und per Tastatureingabe folgende Aktionen ausführen
- Apps installieren
- beliebige Befehle ausführen
- Nachrichten versenden
- Für den Angriff ist keine spezielle Hardware nötig; er lässt sich mit einem Linux-Computer und einem gewöhnlichen Bluetooth-Adapter durchführen
- Vollständige Exploit-Details und ein PoC-Skript sollen in der Woche der ShmooCon vom 12. bis 14. Januar veröffentlicht werden
Angriffsbedingungen je Plattform
- Die Schwachstelle funktioniert, indem sie die Zustandsmaschine des Bluetooth-Hosts täuscht, sodass ohne Bestätigung des Nutzers ein gefälschtes Keyboard gekoppelt wird
- Der zugrunde liegende Pairing-Mechanismus ohne Authentifizierung ist Teil der Bluetooth-Spezifikation; Implementierungsfehler machen ihn jedoch zur Angriffsfläche
- Die erforderlichen Bedingungen auf ungepatchten Geräten unterscheiden sich je nach Betriebssystem
- Android: verwundbar, wenn Bluetooth aktiviert ist
- Linux/BlueZ: Bluetooth muss im discoverable/connectable-Zustand sein
- iOS und macOS: verwundbar, wenn Bluetooth aktiviert ist und ein Magic Keyboard mit dem Telefon oder Computer gekoppelt ist
- Nachdem ein Angreifer das Zieltelefon oder den Zielcomputer gekoppelt hat, kann er Tastatureingaben mit den Rechten des Opfers injizieren
- Aktionen, die ein Passwort oder biometrische Authentifizierung erfordern, lassen sich nicht allein durch Tastatureingabe-Injektion ausführen
Eine alte Schwachstelle, die nach MouseJack sichtbar wurde
- Die 2016 veröffentlichte MouseJack-Forschung betraf nicht Bluetooth, sondern proprietäre Funkprotokolle von Peripheriegeräten
- Die vorliegende Forschung begann bei der Untersuchung von Bluetooth und des Apple-Ökosystems anhand des Apple Magic Keyboard
- Unter macOS und iOS wurde Bluetooth-Keystroke-Injection ohne Authentifizierung gefunden; auf beiden Plattformen war der Missbrauch sogar im Lockdown Mode möglich
- Als anschließend ähnliche Schwachstellen auch unter Linux und Android bestätigt wurden, wirkte das eher wie ein Protokollfehler als nur wie ein einfacher Implementierungsbug; ein Abgleich mit der Bluetooth-HID-Spezifikation zeigte, dass beides zutraf
- Einige der Schwachstellen sind älter als MouseJack, und die Keystroke-Injection ließ sich bis zurück zu Android 4.2.2 reproduzieren
Android-Auswirkungen und Patch-Status
- In Tests wurden folgende Android-Geräte und -Versionen als verwundbar bestätigt
- Pixel 7, Android 14
- Pixel 6, Android 13
- Pixel 4a (5G), Android 13
- Pixel 2, Android 11
- Pixel 2, Android 10
- Nexus 5, Android 6.0.1
- BLU DASH 3.5, Android 4.2.2
- Das Sicherheits-Patch-Level 2023-12-05 entschärft die Schwachstelle in Android 11-14
- Für Android 4.2.2-10 gibt es keinen verfügbaren Fix
- Der Zeitplan der Offenlegung war wie folgt
- 2023-08-05: Schwachstelle an Google gemeldet
- 2023-12-06: veröffentlicht
- Google erklärte, dass ein Fix für das Problem, das Android 11-14 betrifft, an die betroffenen OEMs ausgeliefert wurde und alle derzeit unterstützten Pixel-Geräte mit dem Dezember-OTA-Update abgesichert werden
Linux/BlueZ-Auswirkungen und Patches
- In Tests wurden die Ubuntu-Versionen 18.04, 20.04, 22.04, 23.10 als verwundbar bestätigt
- Laut Google ist ChromeOS nicht verwundbar; obwohl es nicht direkt getestet wurde, scheint die BlueZ-Konfiguration die Schwachstelle zu entschärfen
- Die Linux-Schwachstelle wurde 2020 unter CVE-2020-0556 behoben, doch dieser Fix war standardmäßig deaktiviert
- ChromeOS ist das einzige Linux-basierte Betriebssystem, von dem bekannt ist, dass es diesen Fix aktiviert hat
- Der BlueZ-Patch für CVE-2023-45866 aktiviert den Fix von 2020 standardmäßig
- Relevante BlueZ-Patches:
- Informationen zu Ubuntu:
- Informationen zu Debian:
- Informationen zu Fedora:
- Der Zeitplan der Offenlegung war wie folgt
- 2023-08-10: Schwachstelle an Canonical gemeldet
- 2023-09-25: Schwachstelle an die Bluetooth SIG gemeldet
- 2023-10-02: Fall bei CERT/CC eröffnet
- 2023-12-06: veröffentlicht
Auswirkungen auf macOS und iOS
- Unter macOS wurden folgende Geräte als verwundbar getestet und bestätigt
- 2022 MacBook Pro, macOS 13.3.3, M2
- 2017 MacBook Air, macOS 12.6.7, Intel
- Der Lockdown Mode von macOS kann den Angriff nicht verhindern
- macOS Sonoma 14.2 behebt die Schwachstelle
- Der Zeitplan der Offenlegung für macOS war wie folgt
- 2023-08-01: Schwachstelle an Apple gemeldet
- 2023-12-06: veröffentlicht
- Unter iOS wurde ein iPhone SE mit iOS 16.6 als verwundbar getestet und bestätigt
- Auch der Lockdown Mode von iOS kann den Angriff nicht verhindern
- Der Zeitplan der Offenlegung für iOS war wie folgt
- 2023-08-04: Schwachstelle an Apple gemeldet
- 2023-12-06: veröffentlicht
1 Kommentare
Hacker-News-Kommentare
Ich musste ein wenig nachforschen, um das zu überprüfen, aber um auf Nummer sicher zu gehen, sollte man auf Android Bluetooth ausschalten, wenn man es nicht benutzt. Während der Nutzung bleibt man allerdings verwundbar.
Mein Pixel hat das Sicherheitsupdate vom 2023-12-05 erhalten und dieses Problem wurde behoben, aber bei Geräten, die keine Pixels sind, weiß ich es nicht genau.
Unter Linux kann man
/etc/bluetooth/input.conföffnen undClassicBondedOnly=truesetzen. Bei mir musste ich nichts neu hinzufügen, sondern nur die Auskommentierung entfernen. In der nächstenbluetoothd-Version soll der Standardwerttruesein, aber man kann es schon jetzt selbst setzen; danach muss der Bluetooth-Dienst neu gestartet werden.Zu macOS oder iOS kann ich nichts sagen, weil ich die entsprechenden Geräte nicht habe.
Auch Wi‑Fi ist so löchrig wie Schweizer Käse, weil man es im Kontrollzentrum nicht vollständig ausschalten kann.
truezu sein.$ rpm -q --changelog bluez | grep CVE-2023-45866 -C1* Thu Dec 07 2023 Peter Robinson - 5.70-4- Add mitigation for CVE-2023-45866Nach dem Umstieg von Android habe ich es eine Zeit lang versucht, es dann aber aufgegeben.
Wenn man das Telefon aktiv sperrt, sobald man es nicht benutzt, und gesendete Tastenanschläge während der Nutzung ohnehin auf dem Bildschirm sichtbar wären, wirkt es nicht ganz so schrecklich, Bluetooth eingeschaltet zu lassen.
Falls GrapheneOS es behoben hat, wäre das endlich ein Anlass zum Wechseln, aber mein aktuelles Telefon funktioniert noch einwandfrei, daher ist ein Neukauf schwer zu rechtfertigen.
Ich finde es bemerkenswert, dass Windows überhaupt nicht erwähnt wird. Oberflächlich klingt das wie eine gute Nachricht, aber um das Risiko einschätzen zu können, müsste man wissen, warum Windows tatsächlich nicht betroffen ist.
Wenn es im Windows-Bluetooth-Stack zum Beispiel etwas gibt, das BlueZs
ClassicBondedOnly=falseentspricht, könnte man daraus ableiten, dass man in Umgebungen, die man härten möchte, prüfen sollte, ob dieser Wert auftruesteht.Oder der Stack funktioniert völlig anders, sodass die zu berücksichtigenden Punkte ebenfalls ganz andere sind.
Ich rechne mit Videos voller PoCs und Demos, aber Windows hat einen hohen Marktanteil und viele Admins würden vermutlich in Panik geraten, daher wären Informationen dazu hilfreich. Selbst „Wir haben Windows noch nicht angegriffen“ wäre nützliche Information.
Wenn man aber mit einem Flipper Zero ein Bluetooth-Gerät erstellt, erkennt ein Windows-Client es beim Verbindungsaufbau als Tastatur und lässt beliebige PowerShell-Befehle ausführen. Ich selbst habe das nur genutzt, um per YouTube einen Rickroll zu starten, und nichts Illegales ausprobiert.
Inzwischen habe ich Bluetooth überall deaktiviert, aber ich weiß nicht, wie man unter Linux
bluezentfernt, ohne Linux kaputtzumachen.ClassicBondedOnly=false; wolltest du vielleichtClassicBondedOnly=truesagen?Jetzt, wo die Branche physische Audioanschlüsse aus Smartphones entfernt und alles in Richtung Funk drängt, ist es wirklich schön, so etwas zu hören. Gut gemacht.
[1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...
Diese Schwachstelle funktioniert, indem sie die Zustandsmaschine des Bluetooth-Hosts täuscht, sodass sich ohne Bestätigung durch den Benutzer eine gefälschte Tastatur koppeln kann. Der zugrunde liegende unauthentifizierte Pairing-Mechanismus ist in der Bluetooth-Spezifikation definiert, und Implementierungsfehler setzen ihn für Angreifer offen.
Warum wollte man aber stilles Pairing überhaupt ermöglichen? Ich würde gern mehr über den vorgesehenen Zweck des problematischen Mechanismus erfahren.
Warum das auf den tatsächlich betroffenen Geräten so belassen wurde, weiß ich allerdings nicht.
Dieses Problem wurde in macOS 14.2 und iOS 17.2 behoben.
https://support.apple.com/en-us/HT214036
https://support.apple.com/en-us/HT214035
Unter Arch Linux wurde es ab bluez 5.70-2 behoben [1].
[1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...
Die Passage „Bluetooth wirkte damals einschüchternd, also ging man einfach davon aus, dass es sicher sei“ ist hängen geblieben. Dieser Mythos scheint aus genau dieser Ehrfurcht zu entstehen: dass irgendwo weiter oben in einem komplexen Technologie-Stack schon Leute sitzen werden, die wirklich verstehen, was sie tun, und nicht bloß mit einem Stock eine auf Sand gebaute Burg abstützen.
Ob das gegen Handys oder Computer praktisch ausnutzbar ist, bezweifle ich, aber wenn man in der Position ist, Kiosksysteme so zu verwalten, dass niemand sie anfassen kann, ist das Leben jetzt etwas interessanter geworden.
Wenn man nur ein einziges Backdoor erfolgreich platziert, kann man danach weiterarbeiten.
Bei einem gezielten Angriff könnte es schon reichen, jede Minute einen Shift-Tastendruck zu senden, damit die Bildschirmsperre nicht aktiviert wird, und später selbst vor die Maschine zu gehen und etwas zu tun.
sudoodersuirgendwo unterzubringen und$PATHentsprechend zu erweitern.USB ist ähnlich. Wenn man an einen „Nur-Laden“-Port eine Tastatur anschließt, funktioniert sie. Ich habe das direkt unter Android ausprobiert und wurde hier dafür gerügt, dass das praktisch nicht ausnutzbar sei.
Trotzdem würde ich das nicht als Schwachstelle ansehen. Es ist einfach eine nützliche Funktion. Das Problem hier ist, dass jemand das tun kann, ohne dass der Nutzer es bemerkt, sogar während sensibler Vorgänge.
Auch das gestern veröffentlichte coole Projekt https://mitxela.com/projects/smsc ließ sich auf diese Weise mit einem Handy verwenden.
Die Linux-Schwachstelle wurde 2020 behoben (CVE-2020-0556), aber diese Korrektur blieb standardmäßig deaktiviert. Soweit bekannt, hat nur ChromeOS diese Korrektur aktiviert, obwohl Ubuntu, Debian, Fedora, Gentoo, Arch und Alpine entsprechende Hinweise veröffentlicht hatten.
Wenn in den Distributionshinweisen aber einfach steht, dass das Problem durch ein Upgrade behoben wird[2], verstehe ich nicht, was mit „die Korrektur war standardmäßig deaktiviert“ gemeint ist. Bedeutet das, dass nach dem Upgrade weiterhin eine manuelle Konfigurationsänderung nötig ist? Die NixOS-Änderung sieht eher danach aus, als würde der Standardwert umgedreht.
Wenn gemeint ist, dass Nutzer, die explizit
ClassicBondedOnly=falsegesetzt haben, das ändern müssen, hätte man das deutlich klarer formulieren können.[1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
[2] https://ubuntu.com/security/notices/USN-4311-1