Degradación del protocolo de comunicación en IoT mediante un ataque de hombre en el medio (MitM)

Introducción A lo largo de este post se utiliza Eclipse Mosquitto para simular el broker, cliente y suscriptor MQTT; se establece un entorno controlado para demostrar como realizar un ataque de hombre en el medio (Man-in-the-Middle MitM) utilizando Kali Linux y se muestra como causar una degradación del protocolo de comunicación utilizado por un dispositivo IoT inseguro (simulado). Un poco de teoría La degradación de protocolo se aprovecha de una mala práctica en ciertos sistemas IoT, en los cuales se permite que el cliente MQTT haga un cambio automático a una conexión insegura (sin TLS), si falla la conexión segura (TLS). El atacante, ubicado entre el cliente y el broker, interrumpe únicamente las conexiones seguras, obligando al cliente a comunicarse sin cifrado. Este tipo de ataque se ejecuta de la siguiente manera: El cliente MQTT intenta conectarse al broker por el puerto seguro (TLS). Un atacante lanza un ataque MitM a partir de envenenamiento ARP, reenvío de IP y reglas iptables para bloquear tráfico seguro. La conexión segura falla debido al bloqueo silencioso. El cliente MQTT activa el cambio automático a una conexión sin cifrado. El atacante intercepta el mensaje MQTT en texto claro. En este punto, es conveniente preguntar: ¿Qué impacto tiene en la seguridad?. Respecto a la confidencialidad, el atacante puede ver en texto claro el contenido del mensaje publicado y el nombre del tópico MQTT, en cuanto a integridad el atacante puede inyectar mensajes falsos al broker si logra autenticarse sin TLS, y sobre la disponibilidad el dispositivo IoT, este puede actuar basado en mensajes falsificados, poniendo en riesgo el proceso que este ejecutando. Práctica Configuración inicial Para la práctica se utilizaron 3 máquinas virtualizadas sobre VirtualBox, configuradas en una red interna con el modo promiscuo activado. A estas máquinas se les asigno el direccionamiento de red mostrado en la figura: Se procede a instalar mosquitto y openssl en Alpine, en el cliente solo es necesario instalar mosquitto-clients: Para habilitar la conexión TLS, se requiere un certificado, el cual se genera utilizando openssl y posteriormente se envía utilizando ssh a la máquina cliente: Para establecer la conexión MQTT, se debe configurar en el archivo mosquitto.conf, en el cual se habilita el puerto 1883 sin TLS y el puerto 8883 con TLS: Del lado del cliente, se simula un dispositivo IoT que tiene habilitada la conexión insegura en caso de fallar la conexión segura, utilizando un script en bash, estableciendo un tiempo de espera de 3 segundos antes de intentar otra opción: Ejecución del escenario Se inicia la ejecución del broker MQTT, observando que se encuentran habilitados ambos puertos y que está aceptando conexiones: Del lado del cliente, se observa el envío de mensajes vía TLS Y el suscriptor (que se encuentra en la misma máquina cliente, en una segunda terminal) recibe el mensaje de la manera esperada: En wireshark, se observa que los datos van por el protocolo TLSv1.3: Igualmente se puede observar que los datos de la aplicación van encriptados: Ejecución del ataque MitM Desde kali linux, se procede a habilitar el reenvío de paquetes y las reglas en iptables: El primer comando permite que Kali actúe como un router, reenviando paquetes entre el cliente MQTT y el broker, el segundo asegura que no haya reglas previas que interfieran con el ataque o con el reenvío de tráfico, el tercero agrega una regla NAT que modifica la dirección IP de origen de los paquetes salientes por la interfaz eth0, permitiendo que las respuestas del broker MQTT regresen a través de Kali, esto se requiere para mantener la ilusión de una conexión directa, ocultando la presencia del atacante. Los últimos 2 comandos permiten que Kali reenvíe paquetes desde el cliente MQTT hacia el broker, y del broker hacia el cliente. Finalmente, se debe realizar un envenenamiento de ARP, que consiste en suplantar el dispositivo en cuestión falsificando las respuestas ARP, haciendole creer al objetivo que se está comunicando con el dispositivo suplantado. En 2 terminales, se ejecuta el ataque utilizando la herramienta arpspoof tanto para el broker como para el cliente, habilitando de esa manera un ataque MitM: Hasta este punto se ha ejecutado el ataque MitM y todo el tráfico pasa por KaliLinux, al ejecutar el script debe seguir viendo en la consola del cliente: "Mensaje enviado con TLS". Ejecución del ataque de degradación de protocolo Para ejecutar el ataque se debe incluir una regla que agrega un bloqueo específico a 8883 (TLS) antes de las reglas de ACCEPT (-I FORWARD 1 inserta la regla en la primera posición), obligando de esta manera a que el dispositivo cambie automáticamente hacia la conexión insegura. Esto hace que, al ejecutar el script, y pasados los 3 segundos definidos sin poder realizar la conexión por TLS, se ejecute sin TLS: E

Apr 5, 2025 - 16:25

Degradación del protocolo de comunicación en IoT mediante un ataque de hombre en el medio (MitM)

Introducción

A lo largo de este post se utiliza Eclipse Mosquitto para simular el broker, cliente y suscriptor MQTT; se establece un entorno controlado para demostrar como realizar un ataque de hombre en el medio (Man-in-the-Middle MitM) utilizando Kali Linux y se muestra como causar una degradación del protocolo de comunicación utilizado por un dispositivo IoT inseguro (simulado).

Un poco de teoría

La degradación de protocolo se aprovecha de una mala práctica en ciertos sistemas IoT, en los cuales se permite que el cliente MQTT haga un cambio automático a una conexión insegura (sin TLS), si falla la conexión segura (TLS). El atacante, ubicado entre el cliente y el broker, interrumpe únicamente las conexiones seguras, obligando al cliente a comunicarse sin cifrado.

Este tipo de ataque se ejecuta de la siguiente manera:

El cliente MQTT intenta conectarse al broker por el puerto seguro (TLS).
Un atacante lanza un ataque MitM a partir de envenenamiento ARP, reenvío de IP y reglas iptables para bloquear tráfico seguro.
La conexión segura falla debido al bloqueo silencioso.
El cliente MQTT activa el cambio automático a una conexión sin cifrado.
El atacante intercepta el mensaje MQTT en texto claro.

En este punto, es conveniente preguntar: ¿Qué impacto tiene en la seguridad?. Respecto a la confidencialidad, el atacante puede ver en texto claro el contenido del mensaje publicado y el nombre del tópico MQTT, en cuanto a integridad el atacante puede inyectar mensajes falsos al broker si logra autenticarse sin TLS, y sobre la disponibilidad el dispositivo IoT, este puede actuar basado en mensajes falsificados, poniendo en riesgo el proceso que este ejecutando.

Práctica

Configuración inicial

Para la práctica se utilizaron 3 máquinas virtualizadas sobre VirtualBox, configuradas en una red interna con el modo promiscuo activado. A estas máquinas se les asigno el direccionamiento de red mostrado en la figura:

Se procede a instalar mosquitto y openssl en Alpine, en el cliente solo es necesario instalar mosquitto-clients:

Para habilitar la conexión TLS, se requiere un certificado, el cual se genera utilizando openssl y posteriormente se envía utilizando ssh a la máquina cliente:

Para establecer la conexión MQTT, se debe configurar en el archivo mosquitto.conf, en el cual se habilita el puerto 1883 sin TLS y el puerto 8883 con TLS:

Del lado del cliente, se simula un dispositivo IoT que tiene habilitada la conexión insegura en caso de fallar la conexión segura, utilizando un script en bash, estableciendo un tiempo de espera de 3 segundos antes de intentar otra opción:

Ejecución del escenario

Se inicia la ejecución del broker MQTT, observando que se encuentran habilitados ambos puertos y que está aceptando conexiones:

Del lado del cliente, se observa el envío de mensajes vía TLS

Y el suscriptor (que se encuentra en la misma máquina cliente, en una segunda terminal) recibe el mensaje de la manera esperada:

En wireshark, se observa que los datos van por el protocolo TLSv1.3:

Igualmente se puede observar que los datos de la aplicación van encriptados:

Ejecución del ataque MitM

Desde kali linux, se procede a habilitar el reenvío de paquetes y las reglas en iptables:

El primer comando permite que Kali actúe como un router, reenviando paquetes entre el cliente MQTT y el broker, el segundo asegura que no haya reglas previas que interfieran con el ataque o con el reenvío de tráfico, el tercero agrega una regla NAT que modifica la dirección IP de origen de los paquetes salientes por la interfaz eth0, permitiendo que las respuestas del broker MQTT regresen a través de Kali, esto se requiere para mantener la ilusión de una conexión directa, ocultando la presencia del atacante. Los últimos 2 comandos permiten que Kali reenvíe paquetes desde el cliente MQTT hacia el broker, y del broker hacia el cliente.

Finalmente, se debe realizar un envenenamiento de ARP, que consiste en suplantar el dispositivo en cuestión falsificando las respuestas ARP, haciendole creer al objetivo que se está comunicando con el dispositivo suplantado. En 2 terminales, se ejecuta el ataque utilizando la herramienta arpspoof tanto para el broker como para el cliente, habilitando de esa manera un ataque MitM:

Hasta este punto se ha ejecutado el ataque MitM y todo el tráfico pasa por KaliLinux, al ejecutar el script debe seguir viendo en la consola del cliente: "Mensaje enviado con TLS".

Ejecución del ataque de degradación de protocolo

Para ejecutar el ataque se debe incluir una regla que agrega un bloqueo específico a 8883 (TLS) antes de las reglas de ACCEPT (-I FORWARD 1 inserta la regla en la primera posición), obligando de esta manera a que el dispositivo cambie automáticamente hacia la conexión insegura.

Esto hace que, al ejecutar el script, y pasados los 3 segundos definidos sin poder realizar la conexión por TLS, se ejecute sin TLS:

En wireshark se puede observar que el protocolo utilizado ahora es MQTT, y en texto claro se observa tanto el tópico como el mensaje:

Mostrando que se ejecutó un ataque de degradación de protocolo, a través de un ataque MitM.

Conclusiones

El ataque de degradación de protocolo de comunicación demuestra que permitir el cambio automático a protocolos IoT sin cifrado debilita toda la arquitectura de seguridad, lo cual es usualmente permitido para facilitar la usabilidad de un producto, sin embargo, se recomienda forzar el uso exclusivo de TLS, validar el certificado del broker correctamente, utilizar autenticación mutua con certificados y monitorizar redes IoT para detectar actividades ARP sospechosas.