Hackeando um dispositivo de casa inteligente (2024)

• Fez engenharia reversa de um dispositivo de casa inteligente baseado em ESP32 e o integrou ao Home Assistant
• Analisou o app móvel e confirmou a conexão com o servidor em nuvem
• Interceptou o tráfego de rede para tentar controlar o dispositivo
• Fez dump e análise da flash do ESP32 para tentar modificar o firmware
• Analisou a estrutura dos pacotes para entender criptografia e checksum

---

Introdução

• Recentemente, vem tentando conectar todos os dispositivos ao Home Assistant
• Como um determinado purificador de ar só se conecta pelo próprio app, tentou hackeá-lo para integrá-lo
• Aponta os problemas de produtos que dependem de conexão com a internet e de uma conta na nuvem

Plano

• Confirmou que o app móvel se conecta ao servidor em nuvem e permite controle remoto
• Buscou uma forma de interceptar o tráfego de rede para controlar o dispositivo

Análise do app móvel

• Analisou o app Android e confirmou que ele foi desenvolvido com React Native
• Descobriu que ele se conecta ao servidor em nuvem via WebSocket

Inspeção da rede

• Usou Pi-hole para verificar consultas DNS e analisou o tráfego com Wireshark
• Confirmou a comunicação entre o dispositivo e o servidor por meio de pacotes UDP

Análise de pacotes

• Usou um proxy UDP para encaminhar o tráfego entre o dispositivo e o servidor em nuvem
• Analisou a estrutura dos pacotes com Wireshark e verificou a possibilidade de criptografia

Desmontagem física

• Desmontou o dispositivo baseado em ESP32 e fez dump do firmware a partir do chip de flash
• Usou esptool para ler os dados por meio de uma conexão serial

Análise da flash

• Usou esp32knife para analisar os dados da flash e verificar a tabela de partições
• Encontrou arquivos importantes no sistema de arquivos FAT

Análise estática inicial

• Usou Ghidra para analisar as strings do firmware e confirmou o uso de uma biblioteca de criptografia
• Implementa os algoritmos ECDH e HKDF usando a biblioteca mbedtls

Modificação do firmware

• Desativou a funcionalidade CapSense com Ghidra e inicializou o dispositivo com o firmware modificado
• Resolveu o problema de checksum e gravou com sucesso o firmware modificado na flash

Cabeçalho de pacote

• Analisou a estrutura do cabeçalho de pacote e identificou o número de série e o identificador de mensagem
• Entendeu o padrão de requisições do cliente e respostas do servidor

Checksum de pacote

• Verificou o checksum CRC para validar a integridade dos dados dos pacotes

[GN⁺]

Comentários do Hacker News

• A solução de longo prazo é não comprar produtos domésticos que ignoram o controle local

  • Se a senha do Wi‑Fi for obrigatória, eu devolveria o produto
  • Se você quer abrir mão de segurança e privacidade, é uma escolha pessoal, mas deveria haver uma opção para recusar isso sem perder funcionalidades
  • Eu não compraria uma câmera de campainha que não suporte RTSP

• Um purificador de ar aumentar a operação quando a qualidade do ar interno piora não precisa de dispositivo IoT, app, comunicação sem fio nem hub

  • Basta acoplar um sensor de qualidade do ar e um pequeno LCD ao purificador de ar e ajustar as configurações
  • A luz do corredor acender automaticamente funciona sem nuvem, HomeAssist, Wi‑Fi, Zigbee, app nem troca de bateria
  • Nos últimos 10 anos, funcionou sem problemas mesmo quando a rede caiu

• Para vendedores de dispositivos IoT baseados em ESP32:

  • Atualizar dispositivos inteligentes para integrar com sistemas de casa inteligente não afeta outras instâncias nem serviços em nuvem
  • Dados sensíveis do produto são ofuscados ou removidos

• Para proprietários de dispositivos IoT baseados em ESP32:

  • Ao criar um projeto open source para remover a nuvem e depurar produtos de casa inteligente, aprende-se muito sobre os aspectos técnicos
  • Houve muito esforço na redação desta postagem, e seria bom receber feedback sobre o formato

• Fiquei curioso para saber se seria possível descobrir quais pinos estão conectados na placa do dispositivo, fazer flash completo com ESPHome e escrever uma configuração yaml personalizada

• Sempre que estive em uma equipe de projeto de dispositivos IoT, o engenheiro com foco em segurança cuidava da proteção de boot

  • Surpreende que não houvesse resistência a fazer dump do firmware e regravar
  • Fico curioso por que não usam criptografia do flash

• Feedback sobre o artigo:

  • A nota sobre uso de chaves do dispositivo ficaria mais clara dizendo que há chaves por dispositivo
  • Quero compartilhar feedback sobre a complexidade e os riscos do gerenciamento de chaves por dispositivo
  • A criptografia no dispositivo pode causar muitos problemas na fábrica, e se o produto puder bancar isso, talvez seja melhor ignorar

• Fiquei curioso por que não foi usada uma solução padronizada

  • Parece que seria mais custo-efetivo do que criar uma solução própria

• Era raro ver uso de criptografia de firmware em dispositivos IoT com ESP32

  • Se não fosse possível ler o firmware, teria sido difícil criar certificados
  • Mas, ao mesmo tempo, é impressionante

• Opinião sobre a decisão dos engenheiros de serviço de não implementar protocolos padrão como DTLS

  • Não está claro se cada dispositivo tem sua própria chave privada única
  • Se todos os dispositivos compartilhassem a mesma chave privada do firmware, seria possível fazer engenharia reversa de um único dispositivo e realizar ataques MITM contra os demais

• Pessoas que usam dispositivos inteligentes deveriam usar DD-WRT, OpenWrt, Tomato e Asuswrt-Merlin para isolar esses dispositivos em uma VLAN separada da rede privada

• Não deveria ser necessário hackear um produto comprado para poder usá-lo

  • A economia de "rent-seeking" deveria ser regulada ou proibida