Smartphones podem hackear carros japoneses — vídeo

Resumo do experimento

Um professor associado da Graduate School of Information Sciences da Hiroshima City University testou a possibilidade de controlar remotamente um carro japonês usando um dispositivo Wi‑Fi montado em um conector do veículo e um app de smartphone. O alvo foi um Toyota Corolla Fielder Hybrid 2013. Com cerca de ¥10.000 (≈US$83) em peças comerciais e software próprio ele:

• Conectou um módulo Wi‑Fi a um terminal do carro normalmente usado para monitoramento e manutenção.
• Lançou comandos que permitiram ler dados não encriptados da ECU (unidade de controle do motor) e enviar tráfego que paralisou funções.
• Mostrou no velocímetro uma leitura de 180 km/h enquanto o carro estava parado.
• Bloqueou a resposta ao acelerador criando um efeito semelhante a um ataque de negação de serviço distribuída (DDoS) sobre os sistemas internos.

Importante: o pesquisador ressalta que carros de fábrica cujos computadores não têm acesso à internet direto não foram diretamente atacados — o vetor explorado foram dispositivos instalados e conectados ao exterior.

Como o ataque funcionou (mini‑metodologia)

1. Identificação do ponto de entrada: o pesquisador localizou um terminal de cerca de 5 centímetros usado por oficinas para conectar equipamentos de diagnóstico.
2. Instalação física: conectou um dispositivo Wi‑Fi construído com componentes comerciais a esse conector.
3. Comunicação e extração: o módulo expôs dados não encriptados da rede interna do veículo, incluindo sinais para motor, travão e velocímetro.
4. Comando remoto: um app de smartphone enviou tráfego e comandos simulados, alterando leituras do painel e sobrecarregando a ECU.

Este fluxo é um exemplo prático de ataque por acesso físico a um ponto de diagnóstico que depois passa a ser controlado remotamente.

Limitações e cenários em que o ataque não funciona

• Veículos sem dispositivos de terceiros: carros cujo sistema eletrônico não tem pontos conectáveis à internet e que isolam a ECU permanecem fora do alcance.
• Sistemas encriptados/assinados: se os dados de bordo estiverem encriptados ou autenticados, leitura e injeção de comandos ficam muito mais difíceis.
• Acesso físico necessário: o atacante precisa conectar o módulo ao terminal — em muitos casos isso exige tempo e proximidade.

Contraexemplo: um carro novo com portas de diagnóstico seladas e sem adaptadores expostos dificilmente será comprometido do mesmo modo.

Impacto operacional e riscos

• Segurança do condutor: perda de controle parcial — como aceleração inativa — aumenta risco de acidentes.
• Confiança do utilizador: leituras de instrumentos falsificadas podem levar a decisões erradas do motorista.
• Vetor de ataque ampliado: se dispositivos aftermarket com acesso à rede veicular forem comuns, uma única falha pode afetar várias unidades.

Nota: o experimento não demonstrou como partir a direção ou ligar o motor remotamente; o pesquisador afirmou que essas ações não foram possíveis com o método usado.

Medidas de segurança recomendadas (hardening)

• Criptografia e autenticação: encriptar tráfego interno e exigir assinaturas digitais para comandos críticos.
• Segmentação de rede: isolar a ECU e os sistemas de segurança de interfaces de entretenimento e de diagnóstico com firewalls internos.
• Proteção física: selagem e controle de acessos aos pontos de diagnóstico; detecção de dispositivos não autorizados.
• Monitorização e rate limiting: limitar a taxa de mensagens aceitas por controles críticos para reduzir possibilidade de DDoS interno.
• Processos de atualização seguros: garantir atualizações assinadas e verificadas para evitar injeção de firmware malicioso.

Essas ações formam uma camada de defesa em profundidade: nenhuma única medida elimina o risco, mas combinadas reduzem muito a superfície de ataque.

Checklist por função

Proprietário do veículo

• Verifique se foram instalados dispositivos aftermarket no conector de diagnóstico.
• Evite conectar dispositivos não certificados ao carro.
• Mantenha atualizações do fabricante em dia.

Oficina / Técnico

• Use apenas ferramentas e módulos oficiais e autenticados.
• Documente e selecione permissões de acesso para interfaces de diagnóstico.
• Selar ou proteger fisicamente portas OBD quando não estiverem em uso.

Fabricante / OEM

• Implementar encriptação end‑to‑end entre ECUs críticas.
• Validar assinaturas de mensagens e firmware.
• Projetar segmentação de rede e deteção de intrusões embarcadas.

Regulador / Governo

• Estabelecer normas mínimas de segurança para interfaces de diagnóstico e comunicação veicular.
• Promover certificação de dispositivos aftermarket.

Critérios de aceitação para testes de segurança veicular

• O sistema rejeita comandos não assinados para funções de propulsão e travagem.
• Leituras do painel são validadas por múltiplas fontes antes de serem exibidas ao condutor.
• O veículo mantém respostas funcionais ao acelerador e travagem sob tráfego malicioso simulado.
• Alerts e logs gerados quando um dispositivo desconhecido é conectado ao conector de diagnóstico.

Privacidade e conformidade (observações GDPR e similares)

Dados de telemetria podem incluir informações pessoais (localização, hábitos de condução). Mesmo que o experimento seja técnico, fabricantes e oficinas devem aplicar princípios de minimização de dados, retenção limitada e consentimento informado quando transmitir ou armazenar telemetria ligada a indivíduos.

Fato: números e pontos-chave

• Veículo testado: Toyota Corolla Fielder Hybrid, 2013.
• Custo aproximado do equipamento usado: ¥10.000 (≈US$83) em componentes comerciais.
• Terminal explorado: ~5 cm, usado para monitoramento/diagnóstico.
• Efeitos demonstrados: alteração do velocímetro, bloqueio de aceleração, negação de serviço interno.

Testes de aceitação sugeridos (casos)

• Conectar módulo não autorizado e verificar se mensagens críticas são rejeitadas.
• Injetar tráfego de alto volume e validar que o limite de taxa protege a ECU.
• Simular leituras inconsistentes e confirmar que o sistema exibe aviso ao condutor.

Alternativas e estratégias de mitigação

• Solução de hardware: módulos de diagnóstico com autenticação física (chave/elemento seguro).
• Solução de software: protocolos de comunicação autenticados e verificações de integridade em tempo real.
• Abordagem organizacional: certificação de aftermarkets e políticas de garantia que proíbem alterações não autorizadas.

Resumo e próximos passos

O experimento evidencia que dispositivos conectados instalados em veículos podem abrir vetores de ataque significativos. A solução passa por encriptação, segmentação, proteção física e normas regulatórias. Fabricantes, oficinas e proprietários têm papéis complementares na mitigação do risco.

Importante: profissionais de segurança automotiva devem reproduzir testes controlados, validar políticas de hardening e colaborar com reguladores para definições de certificação.

Resumo final:

• Ataque explorou dispositivo conectado ao conector de diagnóstico para acessar dados não encriptados.
• Carros sem acesso à internet nativo não foram afetados; o risco está nos dispositivos instalados e mal protegidos.
• Medidas técnicas e organizacionais podem reduzir substancialmente o risco.