Al explotar un descuido de seguridad en el que un purificador de aire Coway Airmega IconS descarga su certificado raíz a través de HTTP sin cifrar, un usuario pudo interceptar la comunicación del dispositivo y redirigirla a un servidor privado. Esta maniobra 'desvinculó' efectivamente el dispositivo de la nube, permitiendo que se integrara en un sistema de automatización del hogar local sin depender de la infraestructura oficial en la nube de Coway.

El problema de los dispositivos IoT dependientes de la nube

Muchos dispositivos modernos para el hogar inteligente, como el Coway Airmega IconS, dependen de servicios en la nube alojados por el fabricante para el control remoto y la integración con aplicaciones. Aunque es conveniente, esta dependencia crea un punto único de falla: si los servidores del fabricante se desconectan, cambian su API o descontinúan el servicio, la funcionalidad del dispositivo puede perderse.

El autor del proyecto señaló varios casos en los que el servicio en la nube de Coway falló debido al mantenimiento del servidor, baneos de cuentas por usar integraciones de terceros o cambios en el diseño HTML de la aplicación móvil. Para garantizar la fiabilidad a largo plazo, el objetivo era trasladar la lógica de control de la nube a un servidor local.

Interceptando la solicitud de arranque

El principal obstáculo técnico para omitir un servicio en la nube es el uso de certificados SSL, que evitan que un dispositivo se conecte a un servidor falso. Sin embargo, se descubrió que el dispositivo Coway descargaba su certificado raíz desde un bucket de Amazon S3 a través de HTTP sin cifrar durante su configuración inicial.

Al configurar un entorno Man-in-the-Middle (MitM) utilizando una Raspberry Pi y mitmproxy, el usuario interceptó esta solicitud específica. Utilizaron un plugin personalizado para intercambiar el certificado oficial por uno generado en su propio laboratorio, obligando al dispositivo a confiar en la infraestructura local del usuario en lugar de la del fabricante.

Una interfaz mitmweb que muestra una solicitud GET en HTTP sin cifrar para AmazonRootCA1.pem
El usuario interceptó la solicitud inicial del dispositivo para descargar su certificado raíz a través de HTTP sin cifrar.scottjg.com

Esta imagen ilustra la vulnerabilidad específica donde el dispositivo obtiene su certificado raíz a través de HTTP sin cifrar, permitiendo la interceptación MitM.

Mapeo de comandos MQTT con asistencia de IA

Una vez que el dispositivo confió en el certificado local, el usuario pudo ver el tráfico sin procesar. Si bien las solicitudes HTTP iniciales proporcionaban metadatos como direcciones MAC y tokens de certificado, los comandos operativos reales se enviaban a través del protocolo MQTT por el puerto 8883.

El usuario empleó un LLM para ayudar a navegar por el tedioso proceso de configurar las reglas del firewall de la red. Al observar el flujo MQTT cifrado mientras interactuaba con la aplicación oficial, el usuario pudo mapear pulsaciones de botones específicas con los mensajes correspondientes en el bus de mensajes, permitiendo finalmente la replicación local completa de las funciones del dispositivo.

Una interfaz mitmweb que muestra el flujo MQTT sin procesar entre el ventilador y AWS IoT
Tráfico MQTT sin procesar capturado después de que se obligó al dispositivo a confiar en un certificado local.scottjg.com

Esta visualización demuestra el flujo MQTT sin procesar utilizado para identificar comandos específicos de velocidad del ventilador y otros controles.

Una interfaz de chat que muestra una lista de pulsaciones de botones de la aplicación mapeadas a comandos MQTT
Uso de un LLM para mapear interacciones específicas de la aplicación con los mensajes MQTT correspondientes.scottjg.com

El usuario utilizó un LLM para navegar por el complejo proceso de mapear las pulsaciones de botones al bus de mensajes subyacente.

Limitaciones e implicaciones de seguridad

Aunque el proyecto tuvo éxito, resalta una falla de seguridad significativa: los dispositivos que obtienen certificados raíz a través de HTTP son inherentemente susceptibles a la interceptación. Esta vulnerabilidad de 'arranque' permite que un atacante —o un aficionado— redirija el tráfico del dispositivo a cualquier destino.

El autor señala que, si bien este método proporciona independencia de la nube, requiere una configuración sofisticada que involucra enrutamiento de red, proxy y análisis de protocolos. Además, las llamadas específicas a la API para la velocidad del ventilador no eran visibles en las solicitudes HTTP iniciales, lo que obligó al usuario a analizar más a fondo el flujo MQTT para lograr el control total.

Qué dicen los lectores de Hacker News

  • Nota técnica: Un comentarista señaló que el manejo inseguro de los certificados raíz del dispositivo a través de HTTP sin cifrar lo hacía vulnerable a ataques de hombre en el medio, sugiriendo que las herramientas de IA están facilitando que las personas realicen el tedioso trabajo de ingeniería inversa de tales fallas. comentario ↗
  • Nota técnica: Otro usuario compartió su experiencia integrando varios componentes de hardware y sensores en una configuración de automatización del hogar personalizada para crear un entorno sensible que omite las limitaciones estándar del fabricante. comentario ↗
  • Nota técnica: Un comentarista advirtió que intentar modificar el hardware omitiendo los controladores podría terminar costando más en piezas y mano de obra que simplemente comprar un dispositivo con funciones inteligentes nativas. comentario ↗

Resumen de opiniones del hilo de Hacker News; no son hechos verificados. Leer el debate completo ↗