Hackeando un dispositivo de hogar inteligente (2024)

• Se hizo ingeniería inversa de un dispositivo de hogar inteligente basado en ESP32 para integrarlo con Home Assistant
• Se analizó la app móvil para confirmar la conexión con el servidor en la nube
• Se interceptó el tráfico de red para intentar el control del dispositivo
• Se volcó y analizó la flash del ESP32 para intentar una modificación del firmware
• Se analizó la estructura de los paquetes para entender el cifrado y el checksum

---

Introducción

• Recientemente ha estado intentando conectar todos sus dispositivos a Home Assistant
• Como cierto purificador de aire no se conecta más que con su propia app, intenta hackearlo para integrarlo
• Señala los problemas de los productos que dependen de una conexión a Internet y de una cuenta en la nube

Plan

• Confirmó que la app móvil se conecta al servidor en la nube y permite control remoto
• Buscó una forma de interceptar el tráfico de red para poder controlar el dispositivo

Análisis de la app móvil

• Analizó la app de Android y confirmó que fue desarrollada con React Native
• Descubrió que se conecta al servidor en la nube mediante WebSocket

Inspección de red

• Usó Pi-hole para revisar las consultas DNS y analizó el tráfico con Wireshark
• Confirmó la comunicación entre el dispositivo y el servidor mediante paquetes UDP

Análisis de paquetes

• Usó un proxy UDP para retransmitir el tráfico entre el dispositivo y el servidor en la nube
• Analizó la estructura de los paquetes con Wireshark y confirmó la posibilidad de cifrado

Desmontaje físico

• Desarmó un dispositivo basado en ESP32 y volcó el firmware desde el chip flash
• Usó esptool para leer los datos mediante una conexión serial

Análisis de la flash

• Usó esp32knife para analizar los datos de la flash y revisar la tabla de particiones
• Encontró archivos importantes en el sistema de archivos FAT

Análisis estático inicial

• Usó Ghidra para analizar las cadenas del firmware y confirmar el uso de una biblioteca de cifrado
• Implementa los algoritmos ECDH y HKDF mediante la biblioteca mbedtls

Modificación del firmware

• Mediante Ghidra, desactivó la función CapSense y modificó el firmware para arrancar el dispositivo
• Resolviendo el problema del checksum, logró flashear correctamente el firmware modificado

Encabezado de paquetes

• Analizó la estructura del encabezado de paquetes para identificar el número de serie y el identificador de mensaje
• Identificó los patrones de las solicitudes del cliente y las respuestas del servidor

Checksum de paquetes

• Verificó el checksum CRC para validar la integridad de los datos de los paquetes

[GN⁺]

Comentarios de Hacker News

• La solución a largo plazo es no comprar productos para el hogar que ignoren el control local

  • Si requiere obligatoriamente una contraseña de WiFi, lo devolvería
  • Si quieres sacrificar seguridad y privacidad, es una elección personal, pero deberían ofrecer una opción para rechazarlo sin perder funcionalidad
  • No compraría una cámara de timbre que no soporte RTSP

• Que un purificador de aire aumente su funcionamiento cuando la calidad del aire interior empeora no requiere un dispositivo IoT, app, comunicación inalámbrica ni hub

  • Basta con añadir al purificador un sensor de calidad del aire y una pequeña pantalla LCD para ajustar la configuración
  • Que la luz del pasillo se encienda automáticamente funciona sin nube, HomeAssist, WiFi, Zigbee, app ni cambio de baterías
  • Durante los últimos 10 años ha funcionado sin problemas incluso cuando la red se cae

• Para los vendedores de dispositivos IoT basados en ESP32:

  • Actualizar dispositivos inteligentes para integrarlos con un sistema de hogar inteligente no afecta otras instancias ni servicios en la nube
  • Los datos sensibles del producto se ofuscan o eliminan

• Para los propietarios de dispositivos IoT basados en ESP32:

  • Al crear un proyecto open source para quitar la nube y depurar productos de hogar inteligente, se aprende mucho del aspecto técnico
  • Se puso mucho esfuerzo en escribir esta publicación y sería bueno recibir comentarios sobre el formato

• Me pregunto si será posible averiguar qué pines están conectados en la placa del dispositivo, flashearlo por completo con ESPHome y escribir una configuración yaml personalizada

• Cada vez que estuve en un equipo de diseño de dispositivos IoT, el ingeniero enfocado en seguridad se encargaba de la protección de arranque

  • Sorprende que no hubiera resistencia a volcar el firmware y volver a flashearlo
  • Me pregunto por qué no usan cifrado de flash

• Comentarios sobre el artículo:

  • En la nota sobre el uso de claves de dispositivo, lo más claro sería que hubiera claves por dispositivo
  • Quisiera compartir comentarios sobre la complejidad y el riesgo de administrar claves por dispositivo
  • El cifrado por dispositivo puede causar muchos problemas en fábrica, y si el producto puede prescindir de ello, es mejor omitirlo

• Me pregunto por qué no usaron una solución estandarizada

  • Parece que sería más rentable que crear una solución propia

• Rara vez he visto que se use cifrado de firmware en dispositivos IoT con ESP32

  • Si no se pudiera leer el firmware, habría sido difícil crear certificados
  • Pero al mismo tiempo es impresionante

• Opinión sobre que los ingenieros de servicio decidieran no implementar protocolos estándar como DTLS

  • No está claro si cada dispositivo tiene una clave privada única
  • Si todos los dispositivos comparten la misma clave privada del firmware, se puede hacer ingeniería inversa a un solo dispositivo y lanzar ataques MITM contra los demás

• Quienes usan dispositivos inteligentes deberían usar DD-WRT, OpenWrt, Tomato o Asuswrt-Merlin para aislarlos en una VLAN separada de la red privada

• No debería ser necesario hackear un producto para poder usar lo que compraste

  • La economía del "rent-seeking" debería regularse o prohibirse