BMW 225xe "undicht"

Sicherheitslücken kann man suchen oder sie fallen einfach auf, wie ich auf Intel RootCA Fehler (CVE-2019-11095) schon beschrieben habe. Mein BMW 225xe verliert nun aber kein Wasser und es regnet auch nicht rein, sondern er gibt Daten preis, die der Hersteller so sicher nicht erreichbar machen will. Auf einen USB-Stick mit Musik befanden sich recht ausführliche Protokolldateien des Fahrzeugs.

Allerdings hat sich BMW nicht gerade mit Ruhm bekleckert, was die Kommunikation betrifft, auch wenn abschließend dies nicht als "Sicherheitskritisch" angesehen wurde. Die Timeline zeigt den Ablauf der Kommunikation und danach beschreibe ich die verschiedenen Ausgaben in Auszügen. Haben Sie bitte Verständnis, dass ich hier nicht die kompletten >200MByte Logfiles publiziere.

Einen Erfahrungsbericht über das Fahrzeug selbst finden Sie auf BMW 225xe Erfahrungsbericht

Timeline

Ich habe diese Informationen natürlich erst einmal nicht öffentlich gemacht, sondern habe versucht die Information an BMW zu übermitteln. Das ist gar nicht so einfach und es waren mehrere Anläufe erforderlich, die ich hier nur kurz chronologisch zusammenfassen.

Datum Richtung Beschreibung

24. Sep 18
12:24

Erste Meldung an die Kundenbetreuung unter kundenbetreuung@bmw.de mit ganz wenigen Informationen. Primär um einen seriösen Kontakt zu erhalten, wohin ich mich mit Details wenden kann

25. Sep 18
10:45

Automatische Rückantwort nach etwas mehr als 20 Stunden. Ich habe Hoffnung, dass sich das jemand angeschaut und weiter geroutet hat.

Um Ihr Anliegen schnellstmöglich zu beantworten, stimmen wir uns bereits mit den Kollegen des verantwortlichen Fachbereichs ab. Sobald wir eine Antwort haben, setzen wir uns umgehend wieder mit Ihnen in Verbindung.
Auszug aus der Antwortmail

25. Okt 18
21:03

Anscheinend hat man aber auch nach 30 Tage noch niemand gefunden und eine weitere Rückmeldung gab es auch nicht. Also habe ich noch mal nachgehakt.

30. Okt. 18

Mehrere Anrufe einer Münchner Nummer, die ich leider nicht annehmen konnte, da ich beim Kunden war. Ein späterer Rückruf hat mich zu einem externen Mitarbeiter verbunden, dem ich den Sachverhalt schildern konnte und er war an den Logs interessiert.

30. Okt. 18
14:23

Der externe Mitarbeiter (die Maildomain ist ein @partner.bmw.com) sendet mir seine Kontaktdaten. Leider ohne SMIME/PGP-Schlüssel o.ä..

30. Okt. 18
14:31

Ich habe dann eine kleine Datei mit 382kByte gesendet..

30. Okt. 18
15:40:

Nachfrage von mir per Mail, ob die Datei angekommen ist. Könnte ja sein, dass ein Virenfilter o.ä. so etwas nicht möchte. zudem habe ich angeboten, auch noch ein 21 MB ZIP-File zu senden. Der BMW ist schon recht gesprächig.

31. Okt 18
06:34

Bestätigung des Eingangs und Übermittlung einer "Upload-URL über https://exd-prod1.bmw.com samt Kennwort, um größere Dateien nicht per Mail senden zu müssen.

31. Okt 18
07:42

Datei wurde über das Webportal hochgeladen und der Mitarbeiter per Mail informiert. Mit einer längeren Antwortzeit habe ich nun gerechnet, da ein Hersteller da schon etwas forschen dürfte.

14. Apr 19

Aber nach 5 Monaten habe ich dann doch noch mal nachgefragt.. Die Mail wurde nicht als "Unzustellbar" abgelehnt aber auch hier habe ich keine Antwort bekommen. Vielleicht ist der Partner nur temporär für BMW tätig oder das Deprovisioning funktioniert nicht. Es ist ja auch kein Funktionskonto wie security@, bei dem ein Hersteller ein Ticketsystem nachschaltet.

Allerdings hat in dem ganzen Prozess bis jetzt mich auch niemand auf eine geeignetere Adresse verwiesen.

17. Mai 19

-

Zur Sicherheit habe ich mal geprüft, ob der Incident weiter gültig  ist. Könnte ja sein, dass die Autos ein "Over the Air"-Update bekommen haben. Am 17 Mai aber konnte ich das problematische Verhalten weiterhin nachstellen.

27. Mai 19
01:00

Durch einen Bericht über chinesische "Hacker" habe ich auch gesehen, dass es einen eigenen Alias für Sicherheitsmeldungen gibt. und eine Suche nach der Adresse fördert dann auch folgenden Links zutage:

Die Seite bietet auch einen PGP-Key an, um die Mails zu verschlüsseln. Also habe ich eine ausführliche englisch formulierte Mail gesendet.

 

28. Mai 19 14:34

Zumindest scheint jemand oder etwas diese Mailbox zu lesen. Zurück kam nichtssagend ein:

Man beachte, dass BMW diese Mail unverschlüsselt gesendet hat, obwohl ich mit meiner Mail auch meinen PGP-Key bereitgestellt habe.

18. Jun 19
18:41

Drei Wochen sollten eigentlich genug für eine "Security-Abteilung" sein, um zumindest eine weitere Rückmeldung zu geben oder z.B. die ausführlichen Logs. Nach ca. drei Wochen habe ich mir also erlaubt, nachzufragen:

Eine Antwort darauf habe ich nicht erhalten

8. Jul 19
12:44

Vielleicht bin ich per Mail ja einfach zu "Altmodisch". Also habe ich es auch per Twitter-Meldung versucht. Vielleicht ist das Social-Team etwas flinker.

Aber vermutlich haben Sie es sich schon gedacht. Außer ein paar Reaktionen meiner Follower kam hier auch keine Reaktion

17. Jul 19
10:39

Als nach einem weiteren Monat immer noch eine Rückmeldung gekommen ist, zweifle ich langsam an der Seriosität der Security-Bestrebungen. Vielleicht mache ich mir aber auch umsonst sorgen und die gemeldete Problemstellung ist gar kein Problem und ich kann problemlos darüber bloggen:

24. Jul 19

BMW hat sich doch noch gemeldet.

The files you found are internal debug files stored by the navigation system on the USB drive. This is caused based on our analysis by some files on the USB, which must have enabled the debug output in the head unit. They are not security-related, although we from the security department agree that such debug information should never be exposed, even if harmless.

Das bestätigt meine Einschätzung, dass solche Informationen nicht das Auto verlassen sollten aber noch keine aktive Lücke darstellen dürften. Wobei ich nicht abschätzen kann, wie der USB-Anschluss auf einen USB/Netzwerk-Adapter reagieren wird. Für die weitere Untersuchung möchte BMW gerne den USB-Stick als "DD-Image". Ich denke, dabei kann ich helfen.

27. Jul 19

Bedingt durch die Ferien konnte ich nur etwas verspätet mit Details zum USB-Stick antworten.

6. Aug 19

Bereitstellung der kompletten Log-Dateien auf meinem OneDrive mit Kennwort, damit BMW die >210MB auch komplett analysieren kann.

9. Aug 19

BMW hat die Dateien erfolgreich geladen und an die Fachabteilung weiter gegeben.

26. Aug 19

Noch ein Update, dass die Fachabteilung die Daten erhalten hat

Ich beendet hier die Protokollierung, da alles Daten übertragen und Informationen ausgetauscht wurden. BMW wird die Daten hoffentlich intern weiter analysieren aber ich erwarte erst einmal keine Rückmeldungen oder sogar einen Rückruf. Wie BMW ja selbst schon sagte, wird das Problem als "nicht kritisch" angesehen

Vielleicht bekommt der Entwickler einen Rüffel und vielleicht gibt es irgendwann mal ein Update für die Head-Unit des Navigationssystems. Aber da es nicht als sicherheitsrelevant eingestuft wird, dürften andere Themen, z.B. E-Mobilität oder Absicherung der "Keyless-Go"- Systeme höhere Priorität genießen.

Beschreibung der Lücke

Am 24. Juni 19 hat mir die Sicherheitsabteilung von BMW geschrieben, dass meine Entdeckungen nicht als "sicherheitskritisch" angesehen werden. Vermutlich ist es auch nur ein Verhalten meines Fahrzeugs vielleicht auch nur mit dem besonderen USB-Stick. Ich habe mich daher dazu entschieden, meine Entdeckungen hier zu veröffentlichen.

Ich habe die Daten an verschiedenen Stellen unkenntlich gemacht oder verfremdet, insbesondere IP-Adressen und Hostnamen und Binärwerte, die z.B. Authentifizierungsinformationen wie die Fahrzeug-ID enthalten.

Mein BMW 225xe hat, wie viele andere Autos auch, einen USB-Anschluss um Smartphones zu laden oder auch einfach nur einen USB-Stick mit MP3-Dateien zur Wiedergabe einzustecken. So habe ich einen 16GB Intenso USB-Stick mit meiner Musiksammlung eingesteckt und mir nichts weiter dabei gedacht. Alles hat funktioniert und es ist nur etwas schade, dass die Ordnerstruktur nicht genutzt wird, sondern nur ID-Tags der Dateien. Soweit was das alles erst mal in Ordnung.

Überraschender Zuwachs

Einige Monate später wollte ich weitere Musikstücke, Hörspiele und Vorträge addieren. Den USB-Stick habe abgezogen und in meinen Computer gesteckt. Ich haben nicht schlecht geschaut, als neue Dateien auf dem Stick gelandet waren. Die Neugier war groß. Die Dateien hatten alle die Endung "dlt" und waren fast durchweg 977kByte groß. Der Dateiname scheint einem bekannten Muster zu folgen, bei dem ein Zeitstempel mit genutzt wird.

Ich habe noch keine Idee, wann das Auto auf den USB-Stick solche Traces schreibt. Für den erste Blick in solche Dateien nutze ich einen herkömmlichem Texteditor. Oft erkennt man schon schnell, welcher Dateityp sich dahinter verbirgt. In dem fall war aber gar nicht viel Arbeit erforderlich, den es sind einfache Text-Dateien und die ein oder anderen Information ist direkt sichtbar. Hier eine Auswahl, was direkt auffällt.

Prozessliste

Dieser Text-Auszug zeugt deutlich eine bekannte Prozessliste, wie wir Sie von diversen UNIX-Varianten kennen. Von 150 Prozessen und 3 aktiv und das System hat wohl 2 GB Ram. Interessant ist aber auch die Liste der Prozesse, die ich hier nun nicht komplett abgedruckt habe.

Ich habe diese Liste auch nicht weiter auf Prozesse untersucht, die vielleicht angreifbar wären und ich möchte auch keine Einschätzung abgeben, ob so viele Prozesse alle als "root" laufen müssen. Sicher wird man auf einem Embedded-System vieleicht nicht eine komplexe Benutzerverwaltung mit abgestuften Rechten umsetzen.

Kennzahlen

Dann finde ich wieder Blöcke, die mit einem $ und einem String gefolgt von vielen Zahlen enthalten. Ich könnte mir vorstellen, dass diese Betriebsparameter des Fahrzeugs oder auch nur des Entertainment-Systems sind. Wobei heute die Systeme ja alle irgendwie verbunden sind, da die unterschiedlichen Komponenten über den CAN-Bus miteinander kommunizieren. Ich weiß allerdings nicht, ob diese auch zu BMW übertragen werden oder einfach so im Protokoll landen. Die Zahlen habe ich aus Datenschutzgründen willkürlich verändert.

Internet-Kommunikation

Durch die Funktion "Connected Drive" hat das Fahrzeug auch ein GSM-Modul samt fest eingebauter SIM-Karte, die von BMW sogar aus der Ferne wohl aktiviert und deaktiviert werden kann. Zumindest war die Datenverbindung meines Fahrzeugs Anfangs nicht aktiv und wurde nach einem Telefonat mit dem Kundendienst aktiviert. Es könnte natürlich sei, das die SIM-Karte immer aktiv ist und BMW nur beim Mobilfunk-Provider oder den eigenen Servern die Sperre entfernt hat.

Interessant finde ich, dass der HTTP-Request mit CURL ausgeführt und auch im Textfile protokolliert wird. Wenn die URL aber stimmt, dann nutzt das System

  • Eine IP-Adresse statt DNS
    Zumindest steht i Log eine IP-Adresse drin. Ich habe die Adresse absichtlich durch "xx.xx.xx.xx" unkenntlich gemacht
  • HTTP statt HTTS
    Für IP-Adressen ist es nicht so einfach ein Zertifikat zu erhalten. Aber das kann doch nicht als Rechtfertigung herhalten, die Daten gleich unverschlüsselt zu übertragen.

Auch wenn HTTP nicht verschlüsselt ist, kann es durchaus sein, dass BMW über das Mobilfunknetz ein VPN oder virtuelles eigenes Datennetzwerk aufbauen lässt und die Adresse ist gar nicht so aus dem Internet erreichbar. Die SIM-Karte im Auto ist ja von BMW eingebaut und über das Mobilfunknetz sind ja durchaus einige erweiterte Funktionen möglich. Leider habe ich keine Basisstation, in die sich das Auto einbuchen könnte.

Hier ein exemplarischer Trace.

Interessant finde ich, das hier anscheinend im User-Agent sogar Daten zu den Einstellungen des Systems eingebettet werden und die Fahrgestellnnummer als HTTP-Header "BMW-Vin:" (VIN = Vehicle Identification Number) )mitgeliefert wird. Der "Referer"-Header könnte ein Hinweis darauf sein, dass dieser Request vom Entertainment-System kommt und die Wetter-Anzeige etwas damit zu tun hat.

Weitere Quellen

Ich habe mittlerweile etwas über 200 Megabyte an Textdateien, die ich nicht alle manuell durchforste. Das ist auch überhaupt nicht meine Aufgabe. Ein paar Schnipsel habe ich aber noch herausgefischt.

  • URL mit HTTP
    Das das System anscheinend auch HTTPS kann, zeigt mir diese URL. Der Server ist im Internet auflösbar aber war bei meinen Tests nicht auf Port 443 erreichbar. Ich vermute eine Firewall, die auf "Source-IP" filtert und die Fahrzeuge verstecken sich hinter einer NAT-Adresse des GSM-Providers. Die Location habe ich gefälscht und den Text umgebrochen.
https://b2v.bmwgroup.de/com/cdpid5/vehicle/id5/rest/weather/v1?
  lat=61.818339&lon=9.621024&reason=other&type=app&gen=id6&v=1.38.13&market=DE
  • Sogar Adressen eines vermutlich internen "Subversion"-Servers tauchen im Log auf.
http://subversion/svn/navi-db/3Soft-Navi/tags/ub/8.9/BMW-SOP2/8.9-BMW-SOP2_S16432_17171_114160/Projects@654150
  • Hier mal wieder eine GPS-Koordinate
[GNSSSV]position: 51.818829 8.641965
/org/freedesktop/systemd1/unit/logtraceenabler_2epath
org.freedesktop.DBus.Properties
  • Interessant Details, die das System anscheinend aus den Kartendaten extrahier, z.B. die Höchstgeschwindigkeit
SLProvider: No general speed limit available. Administrative speed limit for road type 0 (urban: 1) will be used: 50
SLProvider: Valid speed limit: 50, source: MAP
  • Auch das Radio-Modul hinterlässt seine Senderlisten im Trace. Hier die DAB-Sender in dem Bereich
CHmiDeviceListBookmark::getCaption] returns 1LIVE DLT
CHmiDeviceListBookmark::getCaption] returns WDR 2 Köln DL
CHmiDeviceListBookmark::getCaption] returns WDR 3 DLT
CHmiDeviceListBookmark::getCaption] returns RADIO BOB! DL
CHmiDeviceListBookmark::getCaption] returns WDR 5 DLT
CHmiDeviceListBookmark::getCaption] returns KLASSIK RADIO DLT
CHmiDeviceListBookmark::getCaption] returns 1LIVE diGGi DLT

Ich habe keine maschinelle Auswertung der +200MB an Textdateien durchgeführt und vielleicht gibt es noch weitere Stellen, die interessant sind. Ich habe auch nicht versucht, die Binär-Informationen z.B.: durch einen Disassembler zu schicken.

ich stimme hier mit der Einschätzung von BMW überein, dass es sich wohl um einen Debug-Dump des Navigation/Radio/Entertainment-Systems handelt und zumindest auf den ersten Blick kein Zugriff auf Sicherheitsfunktionen des Fahrzeugs (ABS, ESP, Spurhalteassistenz etc.) erkennbar ist. Wir wissen aber auch, dass auf dem internen CAN-Bus irgendwie alle Geräte miteinander verbunden sind.

Keenlab und Black Hat 219

Ein Artikel in der ix 9/2019 über die Black Head 2019 hat mich noch mal auf die Sicherheitsanalyse von Keenlab aufmerksam gemacht.

Die Folien zu dem Vortrag sind sogar öffentlich. Hier ein Auszug der Verkabelung. Ich habe den USB-Anschluss rot markiert, über den wohl die "NBT Head Unit" die Logfiles geschrieben hat,


Quelle: https://i.blackhat.com/USA-19/Thursday/us-19-Cai-0-Days-And-Mitigations-Roadways-To-Exploit-And-Secure-Connected-BMW-Cars.pdf

Und ein paar Seiten später wird sogar genau das Szenario beschrieben, über einen USB2Ethernet-Adapter einen Weg zum Fahrzeug zu finden.


Quelle: https://i.blackhat.com/USA-19/Thursday/us-19-Cai-0-Days-And-Mitigations-Roadways-To-Exploit-And-Secure-Connected-BMW-Cars.pdf

Angeblich fand die Analyse vom Feb 2017 bis Feb 2018 statt und die Sicherheitslücken wurden dann am 26. Feb 2018 an BMW gemeldet und das Update wurde angeblich bis August 2018 auf alle Fahrzeuge verteilt. Das behauptet zumindest der Zeitstrahl


Quelle: https://i.blackhat.com/USA-19/Thursday/us-19-Cai-0-Days-And-Mitigations-Roadways-To-Exploit-And-Secure-Connected-BMW-Cars.pdf

Geht es noch weiter?

Wir wissen aber alle, dass ein Update zum Fix eines Problems nicht gleich alle Fehler korrigiert. Gerade solche Updates haben ja den Fokus schnell die erkannten Lücken zu schließen und da bleibt eben keine Zeit für andere Probleme, von denen man noch nichts weiß. Ich habe auf meinem BMW nichts von einem Update gesehen und auch per Mail oder Telefon, über die Werkstatt oder die Connected Drive Meldungen gab es keinen Hinweis über ein Update. Aus anderer Quelle wurde mir gesagt, dass "Over the Air"-Updates eh erst mit Betriebssystem 7 geht, welches man wohl am hexagonalen Design erkennt. Ich werde mal weiter einen USB-Stick im BMW lassen und schauen, welche Logs sich weiter ansammeln.

Meine Neugier ist natürlich schon noch vorhanden. Wenn sich in der Head-Unit auch nur ein "Computer" befindet, der über den USB-Anschluss ein Speichermedium "erkennt" und mit Schreibzugriff einbindet, dann könnte es interessant sein, mal einen USB/Ethernet-Adapter einzustecken. Vielleicht wird der ja genauso eingebunden und sendet einen DHCP-Request und öffnet mit einer IP-Adresse einen Telnet/SSH/HTTP-Port?.Vielleicht funktioniert ein USB auf VGA-Adapter, eine USB-Tastatur, USB-Maus o.ä.

Generell sind solche Lücken aber auch immer wieder ein Weckruf an alle Entwickler: Erwarte das unerwartete und überlege genau, wie "offen" ein System sein. Ich könnte mir durchaus vorstellen, dass ein Linux-System, welches offensichtlich dahinter arbeitet, solche Datenträger auch "ReadOnly" mounten könnte und generell nur "erlaubte Geräte" oder zumindest Geräteklassen einbindet.

Weitere Links