Honda Civics und bösartiges Valet-Parking

 (juniperspring.org)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das Headunit des Honda Civic Modelljahr 2021 kann über den USB-Update-Pfad Updates akzeptieren, die mit öffentlich bekannten AOSP-Testschlüsseln signiert sind, sodass ein Angreifer mit physischem Zugriff beliebigen Code ausführen kann
  • Hondas Updates werden über Android Recovery eingespielt, und selbst wenn das recovery-Binary modifiziert wurde, entspricht die verify_file-Logik zur Signaturprüfung dem Standard von AOSP
  • Wenn man mit dem öffentlichen AOSP-Testschlüssel signiert und das USB-Laufwerk passend formatiert, lässt sich gewünschter Code auch ohne su und setuid installieren; dieser Angriff wird EvilValet genannt
  • Das neue Tool ota-builder erleichtert die Vorbereitung von Update-Dateien, die vom Headunit akzeptiert werden, und apk-rebuilder wandelt Update-Dateien in einen Ausgabebaum um, der für Reverse Engineering benötigt wird
  • Das Projekt hat den Großteil der Untersuchungsarbeit abgeschlossen, aber das Repository ist nicht eingestellt; Beiträge zu Versionsinformationen, Toolchain, Custom Themes und Verbesserungen beim AIDL-Mapping werden benötigt

Hintergrund zum Projekt-Update

  • Vor drei Jahren wurden erste Arbeiten veröffentlicht, um das Headunit des Honda Civic Modelljahr 2021 zu verstehen und per Reverse Engineering zu analysieren; dieses Update fasst die seitherigen Fortschritte zusammen
  • Die anfängliche Reaktion war sehr ermutigend, und der größte Fortschritt ergab sich bei der Analyse des Update-Prozesses

Der Schlüssel zum Königreich

  • Honda unterstützt Headunit-Updates per USB; letztlich werden signierte AOSP-Update-Dateien auf dem USB-Laufwerk über Android Recovery vorbereitet und eingespielt
  • Es gibt mehrere Honda-spezifische Prüfungen, aber in res/keys waren öffentlich bekannte AOSP-Testschlüssel verblieben, und auch die Signaturlogik verify_file im modifizierten recovery-Binary stimmt mit dem Standard von AOSP überein
  • Wenn das USB-Laufwerk passend formatiert und mit dem öffentlichen AOSP-Testschlüssel signiert wird, kann beliebiger Inhalt auf dem Headunit installiert werden, ohne bestehenden Root-Zugriff zu benötigen
    • Ein typischer Root-Zugriff über das Setzen von setuid auf su ist nicht erforderlich
    • Wenn das Headunit mit Strom versorgt ist und der Angreifer physischen Zugriff auf den vordersten USB-Port hat, ist über den Update-Pfad die Ausführung beliebigen Codes auf dem Headunit möglich
  • Dieser Angriff ähnelt einem evil maid attack mit physischem Zugriff auf ein Hotelzimmer, wird hier aber EvilValet genannt, da Zugang zum Fahrzeuginnenraum nötig ist
    • Im Beispielszenario installiert ein Hotel-Valet per USB ein Update; nach Rückgabe des Fahrzeugs bemerkt der Fahrer die Änderungen am Headunit nicht
  • Dieser Beitrag ist keine technische Detaildokumentation; weitere Informationen finden sich im Dokument Display Audio Update Files
  • Das neue Tool ota-builder erleichtert die Vorbereitung von Update-Dateien, die vom Headunit akzeptiert werden
    • Es befindet sich noch in einem frühen Stadium, aber beispielsweise ist es inzwischen trivial, eine Update-Datei zu erzeugen, die ein su-Binary mit gesetztem setuid installiert
  • Es gibt starke Gründe für die Annahme, dass alle Updates mit öffentlichen AOSP-Testschlüsseln signiert wurden, aber es gab keinen Zugriff auf alle möglichen offiziellen Update-Dateien und alle Dateisysteme sämtlicher Headunit-Varianten
    • Bei den überprüften Headunits befanden sich AOSP-Testschlüssel in res/keys, allerdings könnte durch eine frühere Installation von HondaHack auch ein Schlüssel in den Keystore injiziert worden sein
    • Die öffentlich verfügbare EU-Software-Update-Datei MRC_EU_SW_v12_4.zip ist mit dem Testschlüssel signiert und wurde unverändert aus einem öffentlichen Forum heruntergeladen
    • Es ist sehr wahrscheinlich, dass alle Updates mit AOSP-Testschlüsseln signiert sind, aber Beiträge werden benötigt, um diese Hypothese zu stützen oder zu widerlegen

Werkzeuge aufbauen

  • Neben dem Update-Prozess war die Entwicklung von apk-rebuilder die nützlichste Arbeit
  • apk-rebuilder nimmt Honda-Civic-Update-Dateien aus dem Internet als Eingabe und erzeugt einen sauberen Ausgabebaum, der Arbeiten automatisiert, die Reverse Engineers sonst manuell erledigen müssten
    • Führt Ressourcenauflösung durch
    • Führt Rekonstruktion von .smali-Code durch
    • Führt Repackaging von APK-Dateien durch
    • Führt Extraktion der Ramdisk durch
    • Führt weitere Aufgaben aus
  • Da der eigentliche Honda-Quellcode nicht veröffentlicht werden kann, übernimmt apk-rebuilder die Funktion, Update-Dateien als Eingabe zu verarbeiten, die das öffentliche Repository nicht hostet, und daraus unter anderem Honda-.smali-Code und Bild-Assets auszugeben
  • Die erzeugten Ausgaben folgen einer klaren Verzeichnisstruktur und können in der Dokumentation referenziert werden, ohne die sensiblen Dateien selbst hochzuladen

Verbleibende Arbeit und Bitte um Beiträge

  • Bekannte Versionen

    • Der Update-Prozess ist verwundbar und hängt stark von der Versionsnummer ab
    • Die Versionsnummer kann gefälscht werden und beschränkt daher die Möglichkeit, unsignierten Code auszuführen, nicht
    • Um Update-Dateien zu erstellen, muss bekannt sein, welche Version das Headunit erwartet
    • Änderungen an der Headunit-Software, die nicht zum verwendeten Build passen, können zu unerwartetem Verhalten und Recovery-Loops führen
    • Technikaffine Fahrer eines Honda Civic der 10. Generation können zum Abschnitt Known Versions, Display Audio Software im Repository beitragen
    • Besonders mutige Nutzer können den Code von ota-builder lesen und versuchen, ein Update zu flashen, aber wenn das Headunit nicht dem Referenzgerät entspricht, kann es in einen Recovery-Loop geraten und softgebrickt werden

  • Toolchain

    • Auf dem lokalen Rechner existiert eine experimentelle, noch unfertige Toolchain
    • Diese Toolchain nimmt Kandidaten-.c-Code und kompiliert ihn mit derselben Compiler-Version und denselben Build-Flags wie das ursprüngliche Vendor-Binary für ARMv7
    • Für das Verständnis des Update-Prozesses war diese Toolchain unverzichtbar
    • In ihrer aktuellen Form verwendet sie viel Docker, ist aber unordentlich und stark auf einen bestimmten Workflow zugeschnitten; Ziel ist es, eine saubere Implementierung zu veröffentlichen

  • Custom Themes

    • Beim vibe-coding an apk-renderer wurden Custom Themes teilweise untersucht
    • Custom Themes befinden sich im Mitsubishi-Fork des AOSP-Frameworks, und die Headunit-Apps sind offenbar so verkleinert, dass sie hartcodierte Ressourcen-IDs erwarten, was die Verteilung vermutlich erschwert
    • Um Custom Themes zu verteilen, müsste wahrscheinlich das Vendor-Framework chirurgisch modifiziert und ein Tool zur Automatisierung dieses Vorgangs geschrieben werden
    • Diese Arbeit ist nicht einfach und möglicherweise den Aufwand nicht wert, aber Mitwirkende sind willkommen

  • Verbesserungen für aidl-rebuilder

    • Es wurde begonnen, an einem Tool zu arbeiten, das .smali-Dateien parst und sämtliche AIDL-Schnittstellen des Headunits erzeugt und abbildet
    • Das Tool funktioniert, aber die Genauigkeit konnte noch nicht ausreichend geprüft werden
    • Diese Arbeit eröffnet Möglichkeiten für Custom Apps wie virtuelle Tachometer

Gedanken zu Dokumentation und LLMs

  • Der Schwerpunkt liegt stärker auf Tooling als auf Referenzdokumenten
  • Wenn zuverlässige, deterministische Tools den Headunit-Code in besser verständliche Formen überführen, können Nutzer diese Formen mit LLMs abfragen, um konkrete Fragen zu beantworten
  • Da der Headunit-Code die Quelle der Wahrheit ist, lässt sich der Aufwand verringern, Referenzdokumente zu pflegen, die vom tatsächlichen Code abweichen könnten
  • Eine Nutzeranleitung zum Verbinden mit dem Headunit per ADB bleibt weiterhin nützlich
  • Wenn Java-Code selbst für LLMs nutzbar ist, wird es zum Wartungsaufwand, zusätzlich separate Dokumentation über das Verhalten dieses Java-Codes zu pflegen

Abschluss

  • Der Großteil der beabsichtigten Untersuchungsarbeit zum Headunit ist abgeschlossen
  • Es bleibt ein Projekt, an dem man weiterarbeiten könnte, aber künftig ist wahrscheinlich ein Wechsel zu anderen Projekten geplant
  • Das Repository ist nicht eingestellt, und PRs sind jederzeit willkommen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare
  • Das Update für den Honda Civic der 10. Generation wird von Honda über ein USB-Laufwerk mit Spezialformat verteilt und ist im Grunde ein Recovery-Paket aus der Android-4.2.2rc1-Ära, dem Honda nur eine Versionsprüfung hinzugefügt hat
    Diese Versionsprüfung lässt sich täuschen, und das Paket ist mit dem öffentlichen AOSP-Testschlüssel signiert, sodass man bei physischem Zugriff auf den vorderen USB-Port ein beliebiges Paket signieren und flashen und auf der Headunit beliebigen Code ausführen kann
    root/su ist nicht nötig, ich habe das auf einem Civic von 2021 komplett durchgespielt, und ich habe außerdem bestätigt, dass auch die offiziellen EU-Update-Dateien mit dem AOSP-Testschlüssel signiert sind
    • AOSP steht für Android Open Source Project
    • Die Acura-Headunits aus demselben Modelljahr basieren ebenfalls auf Android 4.x, daher wollte ich sie auch analysieren, bin aber schon daran gescheitert, an die Update-Dateien zu kommen; mich würde interessieren, wie diese Dateien beschafft wurden
    • Auch die Infotainment-Systeme anderer Autos sind oft AOSP-basiert. Als ich einmal ein Hyundai-Update heruntergeladen habe, war es meiner Erinnerung nach im Wesentlichen ebenfalls ein Android-Image
  • Bei den meisten Autos auf der Straße ist die Sicherheit von Infotainment und Bordelektronik ziemlich miserabel, und durch Mikrofone, Kameras, GNSS-Empfänger, WLAN und Bluetooth in modernen Fahrzeugen verwandeln sie sich zunehmend in mobile Überwachungsplattformen
    In das Information Security Manual der australischen Regierung vom März 2026 wurde eine Vorgabe aufgenommen, Regierungsgeräte nicht mit dem Fahrzeug-Infotainment zu verbinden und in vernetzten Fahrzeugen oder in deren Nähe keine sensiblen Unterlagen anzusehen oder sensible Gespräche zu führen
    https://www.cyber.gov.au/business-government/asds-cyber-secu...
    • Ist NC im Klassifizierungssystem für Vertraulichkeit nicht die niedrigste Stufe?
    • Das halte ich für okay. Es ist ein Autoradio, kein zentrales System
      Menschen, die für solche Angriffe anfällig sein könnten, haben für ihre Arbeit ohnehin eigene Verfahren und vertrauenswürdige Geräte, und US-Polizeibehörden hatten seit dem Aufkommen von OnStar ähnliche Regeln für Mietwagen
      Die meisten für normale Menschen riskanten Telematikdaten werden ohnehin bereits verkauft
  • Einerseits kämpft man gegen das immer weiter schrumpfende Eigentum an Hardware bei den meisten Geräten in unserem Alltag, andererseits werden offenere Geräte dann sofort wieder angegriffen
    Im Sicherheitsmodell der Technik galt immer die Annahme, dass alles verloren ist, wenn ein Angreifer physischen Zugriff auf das Gerät und genügend Zeit hat
    • Für die Allgemeinheit ist es doch gar nicht offen genug, um es zu modifizieren, oder? Die Hersteller müssen sich entscheiden. Entweder komplett öffnen, damit diejenigen, die es brauchen, selbst härten können und die Kompromisse kennen, oder komplett schließen und sicher machen
      Dieser Mittelzustand wie jetzt — ein die Privatsphäre verletzendes Gerät, das den Nutzer während der gesamten Fahrt überwacht, und zugleich ein unsicheres Gerät, das diese Daten jedem mit nur etwas Interesse preisgibt — ist am schlimmsten
    • Ein ähnliches Bild sieht man auch bei der jüngsten BitLocker-Schwachstelle. Ich frage mich, ob damit nun neue Fälle gelöst oder Menschen inhaftiert werden, weil gespeicherte Hardware jetzt entsperrt werden kann
      Wenn etwas beschlagnahmt werden kann, ist es besser, die Daten nicht lokal zu speichern, und je nach Rechtslage kann man zur Entsperrung gezwungen werden, aber in den USA sollte man geschützt sein, selbst wenn man die Herausgabe des Passworts verweigert
      Technisch haben Google und Apple die physische Sicherheit stark verbessert, und GrapheneOS geht darauf aufbauend noch einen Schritt weiter, indem es die Angriffsfläche reduziert und sinnvolle Funktionen ergänzt. Vor allem durch die breite Einführung von Auto-Reboot muss man bei Smartphones das Fazit „physischer Zugriff bedeutet Game Over“ inzwischen relativieren
      https://grapheneos.org/features#auto-reboot
      https://discuss.grapheneos.org/d/35728-demystifying-phone-un...
    • Das heißt aber nicht, dass man die Sicherheit lokaler Geräte aufgeben kann. Auch physische Geräte haben Login-Schutz und womöglich sogar Vollverschlüsselung der Festplatte
      Nur weil ein ausreichend fortgeschrittener und hartnäckiger Angreifer mit physischem Zugriff letztlich jedes Gerät kompromittieren kann, heißt das nicht, dass man es beliebigen Personen leicht machen sollte
  • Honda wirkt hier deutlich vernünftiger als andere Autohersteller
    Ein böswilliger Parkservice-Mitarbeiter mit physischem Zugriff auf das Auto würde seine Zeit nicht damit verschwenden, die Headunit zu hacken, sondern einfach irgendwo im Fahrzeug eine Wanze verstecken
    Außerdem dürfte ein Civic-Fahrer kaum zum Ziel eines Nachrichtendienstes werden
    • Ich weiß nicht, ob das als Witz gemeint ist, aber es ergibt ziemlich wenig Sinn. Dass Honda das absichtlich so gebaut hat, ist ebenfalls unwahrscheinlich
      Auf einer Headunit liegen oft Verlaufsdaten wie die nach einer Synchronisierung verbliebene Kontakte-SQLite-Datenbank, Standortverläufe oder ältere Daten, die in Telemetrie- oder Log-Dateien zurückgeblieben sind
      Außerdem hat die Headunit oft Zugriff auf die internen Fahrzeugbusse, und selbst wenn es eine Firewall wie ein Gateway-Modul gibt, ist sie meist schwach. Wie der bekannte Honda-Fall zeigte, bei dem Entriegelung und Startfreigabe ohne kryptografisches Material über denselben CAN-Bus wie die Scheinwerfer möglich waren, kann Infotainment weit mächtiger sein als ein bloßes Tracking-Gerät
      Zudem hinterlässt das Einschleusen von Code in die Headunit oder das Auslesen bereits vorhandener Daten deutlich weniger Spuren als das Anbringen eines separaten Trackers
    • Wenn es sarkastisch gemeint war, okay, aber falls nicht, verstehe ich nicht, warum ein Civic-Fahrer kein Ziel eines Nachrichtendienstes sein könnte
      Der Civic ist eines der häufigsten Autos und eignet sich gut, um in der Masse unterzugehen, und auch „gewöhnlich wirkende“ Menschen wie Wissenschaftler, Ingenieure, Journalisten oder Anwälte können sehr gut einen Honda Civic fahren
      Eine im Auto versteckte Wanze kann entdeckt werden, aber etwas, das direkt in der Fahrzeug-Firmware installiert ist, wird mit geringerer Wahrscheinlichkeit gefunden
    • Glaubst du etwa, dass langweilige Wissenschaftler oder Ingenieure mit Zugang zu geheimen Informationen nicht in einem gewöhnlichen Civic zur Arbeit fahren?
  • Ich habe einmal einen Produktmanager stolz erzählen hören, dass die Firmware mit einem firmeninternen Signaturdienst signiert worden sei. Das ist an sich gut
    Die eigentliche Frage war aber, ob die Firmware im Hinblick auf interne Compliance-Anforderungen signiert wurde, nicht, ob das Firmware-Update-Verfahren die Signatur überhaupt prüft, und tatsächlich wurde sie überhaupt nicht geprüft
    • Ich habe schon eine ähnliche „Lösung“ gesehen. Der Signaturalgorithmus wurde direkt aus dem Update-Paket heraus ausgeführt

„Wie sollte man sonst den Signaturalgorithmus aktualisieren?“, lautete die Argumentation, und das Schlimmste daran ist, dass es zeitweise einmal korrekt umgesetzt war.
Als das Sicherheitsteam „postquanten-sichere“ Signaturen verlangte, wurde das Signaturverfahren geändert, und dabei kam es durch einen Regressionsfehler hinein.

  • Bei einem Namen wie BobbyTables2 hätte ich erwartet, dass einem sofort die korrekte Methode zur Verifizierung von E-Mail-PGP-Signaturen einfällt.
  • Ich denke, es gibt eine Grenze zwischen Sicherheit und dem langfristigen Nutzbarhalten von Geräten. Dass bei einem Auto durch einen böswilligen-Maid-Angriff Abhör-Malware installiert wird, scheint eine geringe Bedrohung zu sein.
    Wenn diese Autos aber nach mehr als 10 Jahren in die Hände von Leuten gelangen, die daran herumtüfteln wollen, ist die Möglichkeit, die Software zu öffnen und anzupassen, ein großer Vorteil.
    Es wäre schön, wenn eine Community entstünde, die nützliche Modifikationen entwickelt und die Lebensdauer der Geräte verlängert. Das erscheint deutlich besser, als wenn Endnutzer die originale Headunit herausreißen und eine AliExpress-artige „Android-Tablet“-Einheit einbauen, deren Sicherheit und technische Qualität wahrscheinlich schlechter ist als die des Honda-Geräts.
  • Das könnte auch ein gutes Zeichen sein, dass man nicht einmal versucht hat, das System vor dem Eigentümer abzuschotten.
    • Es ist nicht gut, irgendwem, der kurz ins Auto kommt, Root-Zugriff zu erlauben. Das ist ähnlich, wie im Büro einen Laptop stehen zu lassen, der immer eingeschaltet ist und eine offene Shell hat.
      Wenn man Updates nicht standardmäßig vollständig vertrauen will, hätte es einen Mechanismus geben müssen, mit dem der tatsächliche Eigentümer Updates genehmigen kann.
    • Wahrscheinlich ist das eher das Ergebnis von Inkompetenz als Hackerfreundlichkeit.
      Wäre es wirklich Absicht gewesen, hätte es wohl einen entsperrbaren Bootloader gegeben, der einen speziellen Schlüssel erfordert, oder etwas wie einen schwer zugänglichen Schalter.
  • Vielleicht war es ein Fehler, Autos zu riesigen Computern auf Rädern zu machen. Weitere Forschung ist nötig.
  • Ich frage mich, wie gut der Rest der Sicherheit ist. Die Headunit ist vermutlich an ein CAN-Gateway angeschlossen; vielleicht lässt sich das per Telematik ansprechen, oder es gibt einen neuen Weg, CarPlay/Android Auto auszunutzen, damit es nach Hause kommuniziert.
    • Wenn man physischen Zugang zum Auto hat und nach Hause kommunizieren will, würde ich empfehlen, einen GPS-Tracker unter die Fußmatte zu legen.
      Das funktioniert bei mehr Marken als nur bei einer Honda-Civic-Generation und geht beim Einbau wahrscheinlich auch schneller.
  • Ich sehe immer mehr Projekte, die die Codedokumentation reduzieren, weil man davon ausgeht, dass sich „gut gestalteter Code mit einem LLM abfragen lässt“, und sich stattdessen auf funktionale Betriebsdokumentation konzentrieren.
    Dass zu irgendeinem Zeitpunkt die gesamte Projektdokumentation vollständig mit dem Code abgeglichen und aktuell ist, ist wirklich unwahrscheinlich.
    Grundsätzlich stimme ich dieser Richtung zu, aber die Voraussetzung ist eben, dass der Code gut gestaltet ist.
    • Besser als Dokumentation ist es, Unit-Tests als Dokumentation zu betrachten.
      Tests können die beabsichtigte Nutzung und interessante Randfälle zeigen, und weil sie fortlaufend ausgeführt werden und bestehen, weiß man auch, dass sie aktuell sind.
      Das ist ein stark unterschätzter großer Vorteil, wenn man mehr Tests hinzufügt.
      Wenn Entwickler voraussichtlich nach einem bestimmten Verhalten oder Randfall fragen werden, kann es sinnvoll sein, einen Test zu haben, der die Antwort direkt beweist, statt sie erneut herleiten zu lassen.