Undokumentierte Backdoor in Bluetooth-Chip entdeckt, der in Milliarden Geräten genutzt wird

 (bleepingcomputer.com)
3 Punkte von GN⁺ 2025-03-09 | 1 Kommentare | Auf WhatsApp teilen
  • Im in IoT-Geräten weit verbreiteten ESP32 wurden Bluetooth-Befehle entdeckt, die nicht öffentlich dokumentiert sind. Da der Chip Stand 2023 in mehr als einer Milliarde Geräten steckt, ist die potenzielle Reichweite groß.
  • Tarlogic Security veröffentlichte auf der RootedCON 29 herstellerspezifische Befehle in der Bluetooth-Firmware des ESP32 und wies darauf hin, dass damit Lesen/Schreiben von RAM und Flash, MAC-Adress-Spoofing sowie das Einschleusen von LMP/LLCP-Paketen möglich sein könnten.
  • Diese Befehle könnten zur Imitation vertrauenswürdiger Geräte, zu unbefugtem Datenzugriff, lateraler Bewegung im Netzwerk und zur Erlangung langfristiger Persistenz führen; sie werden als CVE-2025-27840 verfolgt.
  • Ob eine tatsächliche Remote-Ausnutzung möglich ist, hängt davon ab, wie der Bluetooth-Stack eines Geräts HCI-Befehle verarbeitet; relevanter wird dies bei bösartiger Firmware, bösartigen Updates oder bereits erlangtem Root-Zugriff.
  • Espressif erklärte, es handle sich um Debug-Befehle für interne Tests, die für sich genommen kein Sicherheitsrisiko für den ESP32 schaffen könnten. Das Unternehmen will die undokumentierten Befehle jedoch in künftigen Software-Updates entfernen.

Undokumentierte Bluetooth-Befehle im ESP32

  • Der ESP32-Mikrochip des chinesischen Herstellers Espressif enthält Bluetooth-Befehle, die nicht in der öffentlichen Dokumentation stehen.
  • Der ESP32 ist ein Mikrocontroller, der IoT-Geräten Wi-Fi- und Bluetooth-Konnektivität bereitstellt und Stand 2023 in mehr als einer Milliarde Geräten verwendet wird.
  • Die entdeckten Befehle können für folgende Aktionen genutzt werden:
    • Spoofing, um wie ein vertrauenswürdiges Gerät zu erscheinen
    • unbefugter Datenzugriff
    • Bewegung zu anderen Geräten im Netzwerk
    • potenzielle Erlangung langfristiger Persistenz

Tarlogics Entdeckung und Forschungstool

  • Miguel Tarascó Acuña und Antonio Vázquez Blanco von der spanischen Tarlogic Security präsentierten ihre Forschungsergebnisse auf der RootedCON in Madrid.
  • Die Forscher sind der Ansicht, dass das Interesse an Bluetooth-Sicherheitsforschung zurückgegangen ist, aber nicht, weil das Protokoll oder seine Implementierungen sicherer geworden wären.
  • Viele der zuletzt vorgestellten Angriffe hatten keine funktionierenden Tools, liefen nicht auf allgemein verfügbarer Hardware oder stützten sich auf alte, nicht mehr gepflegte Tools, die zu aktuellen Systemen schlecht passten.
  • Tarlogic entwickelte einen neuen, in C geschriebenen USB-Bluetooth-Treiber.
    • Er ist hardwareunabhängig und plattformübergreifend.
    • Er kann direkt auf die Hardware zugreifen, ohne von OS-spezifischen APIs abhängig zu sein.
    • Er ermöglicht Rohzugriff auf Bluetooth-Traffic.

Low-Level-Kontrolle durch die Befehle

  • In der Bluetooth-Firmware des ESP32 wurden versteckte herstellerspezifische Befehle identifiziert.
    • Der Opcode ist 0x3F.
    • Sie erlauben eine Low-Level-Steuerung von Bluetooth-Funktionen.
  • Insgesamt wurden 29 undokumentierte Befehle entdeckt.
  • Die wichtigsten Funktionen stehen im Zusammenhang mit:
    • Speichermanipulation von RAM und Flash
    • Geräte-Imitation durch MAC-Adress-Spoofing
    • Einschleusen von LMP/LLCP-Paketen
  • Da Espressif diese Befehle nicht öffentlich dokumentiert hat, waren sie möglicherweise nicht für den Zugriff vorgesehen oder wurden versehentlich belassen.
  • Das Problem wird als CVE-2025-27840 verfolgt.

Angriffsmöglichkeiten und realistische Einschränkungen

  • Die Forscher sehen in diesen Befehlen ein mögliches Risiko für bösartige Implementierungen auf OEM-Ebene oder Supply-Chain-Angriffe.
  • Die Möglichkeit einer Remote-Ausnutzung hängt davon ab, wie der Bluetooth-Stack des Geräts HCI-Befehle verarbeitet.
  • Unter folgenden Bedingungen könnte eine Remote-Ausnutzung wahrscheinlicher werden:
    • wenn ein Angreifer bereits Root-Zugriff erlangt hat
    • wenn Schadcode eingeschleust wurde
    • wenn ein bösartiges Update verteilt wurde, das Low-Level-Zugriff öffnet
    • wenn bösartige Firmware oder eine rogue Bluetooth-Verbindung beteiligt ist
  • Im Allgemeinen ist physischer Zugriff auf die USB- oder UART-Schnittstelle eines Geräts das realistischere Angriffsszenario.
  • Tarlogic geht davon aus, dass bei der Kompromittierung eines IoT-Geräts mit ESP32 ein APT im ESP-Speicher versteckt werden könnte, während das Gerät über Wi-Fi/Bluetooth gesteuert wird und Bluetooth- oder Wi-Fi-Angriffe auf andere Geräte ausführt.
  • Befehle, die RAM und Flash verändern können, könnten zur vollständigen Kontrolle des ESP32-Chips und zu Persistenz auf Chip-Ebene führen.

Espressifs Erklärung und geplanter Fix

  • BleepingComputer bat Espressif zunächst um eine Stellungnahme, erhielt aber nicht sofort eine Antwort.
  • Später gab Espressif eine offizielle Stellungnahme zu Tarlogics Entdeckung ab.
  • Das Unternehmen erklärte, die entdeckten Funktionen seien Debug-Befehle für interne Testzwecke.
    • Diese Befehle sind Teil der Implementierung des HCI-Protokolls (Host Controller Interface), das in der Bluetooth-Technologie verwendet wird.
    • HCI wird innerhalb des Produkts für die Kommunikation zwischen Bluetooth-Schichten genutzt.
  • Espressif ist der Ansicht, dass die bloße Existenz der Debug-Befehle für sich genommen kein Sicherheitsrisiko für den ESP32-Chip schaffen kann.
  • Allerdings will das Unternehmen einen Software-Fix bereitstellen, der die undokumentierten Befehle entfernt.

Begriffskorrektur und Artikel-Updates

  • In einem Update vom 9. März 2025 wurden Titel und Text überarbeitet, um Bedenken hinsichtlich der Bezeichnung der undokumentierten Befehle als „Backdoor“ zu berücksichtigen.
  • Am 8. März 2025 wurde Tarlogics Stellungnahme ergänzt.
  • Am 9. März 2025 wurde die CVE-ID ergänzt.
  • Am 10. März 2025 wurde Espressifs offizielle Stellungnahme ergänzt.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-09
Meinungen auf Hacker News

  • Ich finde, der Titel ist etwas irreführend. Wenn ich das richtig gelesen habe, ist die hier gemeinte Backdoor etwas, das einem Computer erlaubt, den Speicher und Low-Level-Funktionen seines eigenen USB-Bluetooth-Adapters zu lesen und zu schreiben.
    Es sieht nicht so aus, als ließe sich das drahtlos ausnutzen. Solche undokumentierten Debugging-Befehle sind verbreitet; ähnliche Funktionen habe ich auch bei WiFi-Adaptern und GPS-Empfängern gesehen. Man hat sie nur durch Reverse Engineering der Chip-Firmware oder der Vendor-Treiber gefunden, dokumentiert waren sie nicht, und für sich genommen ist das kein Problem mit großer Tragweite. Wenn sie unsignierte Firmware erlauben, ist das genauso anfällig.
    Wenn es von etwas anderem als dem Host aus nutzbar wäre, wäre das eine völlig andere Geschichte.

    • Aus Sicht von Open Hardware sind solche reißerischen Überschriften wirklich schädlich. Wenn man Debugging-Interfaces und Firmware-Updates als „Backdoors“ und „Sicherheitslücken“ bezeichnet, ist die natürliche Reaktion, alles dichtzumachen.
      Espressif war in diesem Bereich fast außergewöhnlich offen. Das Unternehmen hat zu einer Open-Source-Rust-Toolchain für seine Chips beigetragen und sogar öffentlich zum Reverse Engineering des Modem-Stacks ermutigt, den es wegen lizenziertem Code nicht veröffentlichen kann. Ich mag es nicht, wenn der Preis für auch nur ein bisschen Offenheit schlechte und schädliche PR ist.
    • HCI-Befehle sind ohne zusätzliche Fehler nicht aus der Ferne zugänglich. Der zentrale Satz im Artikel ist dieser:
      „Je nachdem, wie der Bluetooth-Stack auf dem Gerät HCI-Befehle verarbeitet, könnte eine Remote-Ausnutzung der Backdoor über bösartige Firmware oder eine bösartige Bluetooth-Verbindung möglich sein.“
      Kurz gesagt: Wenn man einen sicheren Driver-Stack hat und lokalem Code vollständig vertraut, sind HCI-Vendor-Extensions kein Problem.
      Allerdings können HCI-Erweiterungen leicht zu Sicherheitslücken werden. Das Problem ist, dass HCI vom Angreifer kontrollierte Eingaben mit komplexen Interfaces und heiklem Parsing vermischt. Wie die BleedingTooth-Schwachstelle vor einigen Jahren gezeigt hat, sind Fehler dabei leicht zu machen.
      Solche Funktionen machen es auch einfacher, von anderen Schwachstellen aus zu pivotieren, aber in den meisten Systemen ist das eher niedrig hängende Frucht.
      [0] https://google.github.io/security-research/pocs/linux/bleedi...
    • Was wäre, wenn ein Computer, der den Speicher seines eigenen Bluetooth-Adapters liest und schreibt, das über Software tun kann, die auf der Web Bluetooth API läuft? Ich hoffe, es ist nicht so schlimm, aber falls doch, passt das unheimlich gut zu der vorherigen Beschreibung.
      Selbst wenn man den schlimmsten Fall einer Web-API ausklammert: Nehmen wir an, man lässt halb vertrauenswürdige Software zur Risikovermeidung in einer dreifach verschachtelten VM laufen. Diese Software bringt einen plausiblen Grund vor, warum sie Bluetooth-Zugriff braucht, und man erlaubt die Ausnahme. Das Ergebnis gefällt einem nicht, man löscht die Software und setzt alle drei VM-Schichten zurück. Es wirkt erledigt, aber was die Malware während der Zugriffszeit auf dem ESP installiert hat, könnte weiterhin vorhanden sein.
      Undokumentierter Zugriff auf ein untergeordnetes Gerät kann besonders dann wirklich übel werden, wenn Persistenz ins Spiel kommt.
    • Für einen Angreifer, der über einen anderen Exploit bereits Zugriff erlangt hat, scheint das ziemlich nützlich sein zu können.
      Man kann sich Situationen vorstellen, in denen ein ESP32 nicht als eigenständiger SoC, sondern als WiFi/Bluetooth-„Modem“ über eine serielle Verbindung an ein Host-System angebunden ist.
      Theoretisch könnte ein Angreifer mit undokumentierten Befehlen Bluetooth-Geräte in der Umgebung scannen, spoofing betreiben oder sie angreifen. Vielleicht sogar, ohne root-Rechte auf dem Gerät zu erlangen, das den ESP32 hostet.
    • Beim Lesen wirkt das wirklich wie eine stark aufgeblasene Kleinigkeit.
      Ihr wärt wohl überrascht, wenn ihr erfahrt, dass man mit root-Rechten innerhalb des OS die Firmware eines Laufwerks neu schreiben kann.

  • Was die Forscher gefunden haben, ist eine undokumentierte Hardware-Funktion, die jemandem, der bereits Codeausführungsrechte hat, tieferen Low-Level-Zugriff auf den ESP32-WiFi-Stack erlaubt als erwartet.
    Das als „Backdoor“ zu bezeichnen, ist reiner Clickbait.

  • Ich bin verwirrt. Heißt das, dass es im Bluetooth-Stack ein paar undokumentierte Befehle gibt? Wenn nur Code darauf zugreifen kann, der bereits auf dem Gerät läuft, wirkt es schwierig, das als Backdoor zu bezeichnen.

    • „Je nachdem, wie der Bluetooth-Stack auf dem Gerät HCI-Befehle verarbeitet, könnte eine Remote-Ausnutzung der Backdoor über bösartige Firmware oder eine bösartige Bluetooth-Verbindung möglich sein.“
      Das klingt nicht nach Remote Code Execution.
    • Zustimmung. Das ist ziemlich üblich und auch nicht schlimmer als Firmware-Updates. Die potenzielle Falle ist allerdings, dass In-Band-Debugging möglicherweise nicht dieselben Host-Rechte verlangt, wie man sie bei Firmware-Updates erwarten würde.
      Deshalb besteht die Möglichkeit, dass ein User-Space-Programm, oder schlimmer noch ein WebBLE-Programm, dem Adapter eine persistente bösartige Payload hinzufügt. Ein Tracking-Beacon, der selbst nach einem Laufwerkstausch bleibt, ist beängstigend, aber keine Remote Code Execution.

  • Theoretisch sollte man Low-Level-Zugriff auf den verbundenen Bluetooth-Funkchip selbst haben können, daher wirkt das bis zu einem gewissen Grad erwartbar.
    Geräte mit solchen Low-Level-Interfaces sind besser. Das Problem ist möglicherweise nicht ihre Existenz, sondern die fehlende Dokumentation.
    Früher konnte man bei Qualcomm-Funkchips mit Speicher-Lese-/Schreibbefehlen über USB gesperrte Geräte entsperren und die Kontrolle darüber übernehmen. Das war vollständiges Out-of-Band-Lesen/-Schreiben und daher vielleicht nicht besonders gut, aber wenn der Zugriff hier nur über geflashten Code möglich ist, ist das eher besser.

  • Spanische Folien: https://www.documentcloud.org/documents/25554812-2025-rooted...

  • Kurz gesagt: Durch Reverse Engineering der Firmware wurden HCI-Befehle gefunden, die Dinge wie Speicher lesen/schreiben, Pakete senden und die MAC-Adresse setzen können.
    Eine Backdoor ist das nicht wirklich. Ob die Forscher es so genannt haben, weiß ich nicht, weil die Präsentation auf Spanisch ist; oder ob Journalisten es Backdoor nennen, um mehr Klicks zu bekommen, weiß ich ebenfalls nicht.
    Um diese Befehle zu nutzen, braucht man beliebigen Zugriff, um HCI-Befehle an das Gerät zu senden. Das heißt, man kontrolliert das Gerät und seine Funktionsweise bereits. Das wird nicht remote über die Funkverbindung ausgenutzt. Für jeden Exploit müsste man schon die vollständige Kontrolle über das Gerät haben, und an diesem Punkt ist es nicht überraschend, die MAC-Adresse ändern oder Pakete senden zu können.
    Interessante Forschung, aber dass es als „Backdoor“ verpackt wird, ist wirklich ernüchternd. Ich weiß nicht, wer für diese Wortwahl verantwortlich ist, aber ich vermute die Journalisten.
    Als vertrautere Analogie: Man stelle sich vor, man entdeckt, dass der Ethernet-Controller eines verbreiteten IoT-Chips auf Anweisung der Firmware seine MAC-Adresse ändern oder beliebige Pakete senden kann. Nur dass es hier Bluetooth ist; ansonsten ist es dieselbe Geschichte.

    • Die Forscher selbst nennen es Backdoor. Das ist die englische Mitteilung auf der Website.
      https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-...
    • Interessante Tatsache zum Setzen von MAC-Adressen: Viele der sehr billigen USB-Bluetooth-Adapter, die online verkauft werden, haben dieselbe MAC-Adresse. Vermutlich hat man sich nicht die Mühe gemacht, sie auf einen eindeutigen Wert zu ändern.
      Deshalb gibt es Windows-Tools wie https://macaddresschanger.com/ und bdaddr unter Linux. Die meisten scheinen Klone des CSR-Designs zu sein, und der Befehl zum Setzen der Adresse ist ebenfalls gut bekannt. https://sources.debian.org/src/bluez/5.55-3.1%2Bdeb11u1/tool...
    • Siehst du nicht, dass ein beliebiges Gerät mit eingestecktem Ethernet-Kabel, das seine MAC-Adresse ändern und beliebige Pakete senden kann, für sich genommen zu einem wurmähnlich verbreitungsfähigen Threat Actor werden kann?
      Hier wurde die Anforderung eines Ethernet-Kabels sogar noch gestrichen.
      Man könnte mit einem weißen Van herumfahren, auf dem „Free Candy / BLE Persistent Threats“ steht, und auf dem Weg nach China Geräte ausräumen, während sie durch Metalldetektoren gehen.
      Es ist drahtlos, kann sich wurmähnlich verbreiten, beliebige Pakete senden und beliebige Geräte spoofen — und du siehst darin kein Problem?

  • Ich hasse solche reißerischen Artikel. Jetzt wird Espressif sich vermutlich unter Druck gesetzt fühlen, noch stärker auf Geschlossenheit zu setzen.

    • Wäre das dokumentiert gewesen, wäre es von Anfang an kein Problem gewesen.

  • Auf Desktops und Laptops installieren wir ganz selbstverständlich undurchsichtige Binary-Blob-Treiber, die im Kernel-Space laufen, und auf unseren von der Cloud kontrollierten eigenen Smartphones haben wir nicht einmal Root-Zugriff; aber ein paar undokumentierte Low-Level-Befehle des ESP32, für die das Gerät bereits kompromittiert sein muss, werden zu einem nachrichtenwürdigen Bedrohungsvektor.
    Ich frage mich wirklich, ob bei der Übersetzung etwas verloren gegangen ist. Früher hätte man das einfach cool gefunden und nach einer Möglichkeit gesucht, es in ein softwaredefiniertes Radio umzubauen.

    • Da lebt wieder jemand von übertriebenem Hype. Er macht der ahnungslosen Öffentlichkeit Angst und schadet der Reverse-Engineering-Community.

  • Die Forschung selbst ist gut, aber der Titel ist schlecht. Als Angriffsvektor betrachtet erfordert das physischen Zugriff und ist in fast allen Fällen etwas, das man auch auf anderem Wege bereits tun könnte.
    „Undokumentierte Befehle in verbreitetem Bluetooth-Chip entdeckt“ wäre ein besserer Titel.

    • Aus Sicht des Hardware-Hackings kann es interessant sein. Es wirkt wie ein legitimer Weg, zusätzliche Funktionen aus vorhandener Hardware herauszuholen.

  • Dieser Titel ist eine Lüge. Eine Backdoor in einem Bluetooth-Chip müsste einem drahtlosen Angreifer ermöglichen, Codeausführung auf dem Chip zu erlangen.
    Dieser Artikel behandelt, dass der Gerätetreiber des angeschlossenen Geräts Codeausführung auf dem Chip erlangen kann, was keine Sicherheitsgrenze verletzt.
    In einem funktionierenden Medienökosystem wäre eine Korrektur nötig, und der Ruf des Mediums, das den Artikel geschrieben hat, müsste erheblich Schaden nehmen. Leider wird das nicht passieren.