Vulnerabilidades MQTT comunes y cómo mitigarlas

Las vulnerabilidades MQTT se agrupan en unas pocas clases recurrentes: autenticación débil o inexistente, huecos de autorización, errores de parsing en brokers y librerías cliente, fugas de información y agotamiento de recursos. Este artículo recorre cada clase desde la perspectiva del defensor, explica por qué ocurre y enumera las mitigaciones que funcionan. Al final tendrás una checklist de gestión de vulnerabilidades para brokers, dispositivos y las aplicaciones que hay entre ellos.

Dónde se esconden las vulnerabilidades MQTT

El protocolo MQTT en sí es pequeño y está bien especificado. La mayoría de los problemas reales proceden de tres lugares:

Implementaciones de broker: el software de servidor que analiza los paquetes, autentica a los clientes y enruta los mensajes.
Librerías cliente y firmware: el código de los dispositivos y las aplicaciones que habla MQTT.
Despliegues: configuración, credenciales, exposición de red y diseño de topics.

En la práctica, los errores de despliegue causan la mayoría de los incidentes, pero los bugs de implementación son los que requieren parches. Ambos merecen un plan.

Clases de vulnerabilidades de un vistazo

Clase	Causa típica	Mitigación principal
Autenticación ausente	Acceso anónimo habilitado	Exigir credenciales en cada listener
Bypass de autenticación	Bugs en plugins de autenticación o casos límite de la lógica	Parchear pronto, probar la autenticación en cada actualización
Huecos de autorización	Permisos demasiado amplios, abuso de comodines	Mínimo privilegio por identidad, tenants separados
Bugs de parsing de paquetes	Longitudes, propiedades o cadenas UTF-8 malformadas	Mantener broker y librerías actualizados, fuzzing en staging
Divulgación de información	Topics `$SYS`, datos retenidos, errores verbosos	Limitar metadatos, limpiar topics retenidos
Agotamiento de recursos	Sin límites de conexiones, tamaño o tasa	Cuotas, límites de tamaño de paquete, protección contra floods
Transporte en claro	Puerto 1883 a través de redes no confiables	TLS con validación de certificados
Inyección en el cliente	Payloads usados de forma insegura en código o comandos	Validar y comprobar el esquema de cada payload
Exposición de credenciales	Secretos fijos en el código o compartidos en el firmware	Credenciales únicas y revocables por dispositivo

Debilidades de autenticación

La vulnerabilidad más simple es no tener autenticación. Los brokers que se dejan en un modo de desarrollo permisivo aceptan cualquier cliente, lo que lleva a los problemas descritos en brokers MQTT expuestos.

Surgen problemas más sutiles cuando la autenticación existe pero tiene huecos. Históricamente, algunas implementaciones de broker han tenido bugs en los que ciertas combinaciones de opciones, el comportamiento de un plugin o paquetes malformados permitían a un cliente saltarse una comprobación. Patrones a vigilar:

Plugins de autenticación que fallan en abierto cuando un backend (base de datos, LDAP) no está disponible.
Listeners con configuraciones distintas, donde uno olvidado permite el acceso anónimo.
Confianza basada en el client ID, donde conocer un client ID basta para apoderarse de una sesión.
Sin límite de intentos de login, lo que hace viable adivinar contraseñas.

Mitigaciones: exige autenticación en cada listener, falla en cerrado cuando un backend de autenticación está caído, vincula los client ID a credenciales y limita o bloquea los fallos repetidos. En ConnectMQ, los client ID están vinculados a las credenciales emitidas y las IP se bloquean tras varios inicios de sesión fallidos.

Huecos de autorización

Una vez conectado, un cliente solo debería poder tocar sus propios topics. Los huecos habituales incluyen:

Todos los dispositivos compartiendo una cuenta con acceso total.
Suscripciones con comodín como # permitidas para dispositivos normales.
Topics de comandos en los que puede escribir cualquier cliente autenticado.
Reglas escritas para MQTT 3.1.1 que no contemplan funciones de MQTT 5 como las suscripciones compartidas ($share/group/topic).

Mitigaciones: diseña los topics para que los permisos puedan seguir la jerarquía, da a cada dispositivo credenciales únicas y prueba la matriz de permisos en cada release. Los brokers autoalojados pueden usar ACL, descritas en la guía de ACL en MQTT. Cuando el broker no ofrece reglas por topic, separar tenants o brokers por dominio de confianza logra un aislamiento más fuerte del que jamás conseguirán unas credenciales compartidas.

Bugs de parsing de paquetes y de seguridad de memoria

Los paquetes MQTT contienen enteros de longitud variable, cadenas con prefijo de longitud, datos binarios y, en MQTT 5, un amplio conjunto de propiedades. Cada uno de esos campos debe validarse. Los bugs de parsing en implementaciones de broker y cliente han provocado históricamente caídas y, en los peores casos, corrupción de memoria.

Causas raíz típicas:

Valores de remaining length que no coinciden con los datos reales.
Listas de propiedades con propiedades duplicadas o inesperadas.
UTF-8 inválido o caracteres prohibidos en los nombres de topic.
Jerarquías de topics muy profundas o cadenas extremadamente largas.

Mitigaciones: mantén el broker y las librerías cliente en versiones soportadas y parcheadas; suscríbete a los avisos de seguridad de cada componente MQTT que distribuyas; y ejecuta fuzzing solo contra brokers de staging aislados que sean tuyos. La metodología de pruebas de penetración MQTT explica cómo acotarlo de forma segura. En dispositivos embebidos, prefiere librerías mantenidas antes que parsers propios.

Divulgación de información

Las fugas de información rara vez son espectaculares, pero a menudo resultan útiles para los atacantes:

Topics $SYS que revelan la versión del broker, el uptime y el número de clientes.
Mensajes retenidos que siguen en los topics mucho después de que terminara un proyecto.
Topics de depuración o diagnóstico que publican configuración, direcciones IP o tokens.
Mensajes de error que revelan si un nombre de usuario existe.
Nombres de topic que describen con detalle ubicaciones, clientes o equipos.

Mitigaciones: restringe quién puede leer los topics de metadatos, revisa y limpia los topics retenidos, mantén los secretos completamente fuera de los payloads y usa identificadores opacos cuando los nombres de topic revelarían demasiado.

Agotamiento de recursos

Sin límites, un solo cliente puede consumir conexiones, memoria o ancho de banda hasta degradar el broker. Los floods pueden ser maliciosos o simplemente consecuencia de bugs de firmware y tormentas de reconexión.

Mitigaciones: límites de tasa de mensajes por cliente, tamaño máximo de paquete, topes de suscripciones y conexiones, y backoff en el cliente. ConnectMQ aplica cuotas por plan con el reason code 0x97 de MQTT 5 y protección contra floods. Los detalles están en limitación de tasa y protección DoS en MQTT.

Vulnerabilidades del lado del cliente

Los clientes suelen ser el eslabón más débil, porque se ejecutan en muchos dispositivos con ciclos de actualización largos.

Payloads sin validar: un suscriptor que pasa un payload a un comando de shell, una consulta SQL o un eval ha convertido el broker en un canal de ataque.
Verificación TLS desactivada: los clientes que activan el modo "inseguro" para esquivar errores de certificado pueden ser interceptados.
Credenciales fijas en el código: las imágenes de firmware son fáciles de extraer. La guía para proteger credenciales MQTT en dispositivos cubre las opciones de almacenamiento.
Librerías obsoletas: los dispositivos que no pueden actualizarse conservan bugs conocidos para siempre.

Un suscriptor seguro trata cada payload como entrada no confiable:

import json
import paho.mqtt.client as mqtt

ALLOWED_COMMANDS = {"set_interval": (5, 3600), "set_threshold": (0, 100)}

def on_message(client, userdata, msg):
    try:
        data = json.loads(msg.payload.decode("utf-8"))
        cmd, value = data["cmd"], float(data["value"])
    except (ValueError, KeyError, UnicodeDecodeError):
        print("rejected malformed payload on", msg.topic)
        return
    if cmd not in ALLOWED_COMMANDS:
        print("rejected unknown command", cmd)
        return
    low, high = ALLOWED_COMMANDS[cmd]
    if not low <= value <= high:
        print("rejected out-of-range value", value)
        return
    print(f"applying {cmd}={value}")  # llama aquí a tu propio handler seguro

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_message = on_message
client.on_connect = lambda c, u, f, rc, p: c.subscribe("connectmq/site1/device42/cmd", qos=1)
client.connect("YOUR_BROKER_HOST", 8883)
client.loop_forever()

El patrón es sencillo: analiza de forma estricta, usa una lista de comandos permitidos, comprueba los rangos de los valores y nunca ejecutes el contenido del payload.

Estrategia de parches: autoalojado frente a gestionado

La gestión de vulnerabilidades es un trabajo continuo. En un broker autoalojado, alguien tiene que vigilar los avisos, probar las actualizaciones, programar ventanas de mantenimiento y verificar después que la configuración sigue siendo válida. Los brokers expuestos a internet que se quedan atrás en las actualizaciones son justo lo que buscan los atacantes.

Un broker MQTT gestionado traslada los parches del broker al proveedor. Con ConnectMQ, el software del broker, los certificados TLS y las protecciones de la plataforma, como el aislamiento de tenants, se operan por ti, mientras que tú sigues siendo responsable del firmware de los dispositivos, las librerías cliente, las credenciales y el manejo de los payloads. Entender qué hace un broker MQTT ayuda a trazar esa línea con claridad.

Checklist de gestión de vulnerabilidades

Mantén un inventario de cada broker, librería cliente y versión de firmware en uso.
Suscríbete a los avisos de seguridad de cada componente.
Exige autenticación y TLS en cada listener expuesto a internet.
Da a cada dispositivo credenciales únicas y revocables y acceso de mínimo privilegio.
Configura límites de tamaño, tasa y conexiones; gestiona los reason codes en los clientes.
Valida todos los payloads en los suscriptores; nunca ejecutes el contenido de un payload.
Elimina los secretos de los payloads y limpia los topics retenidos.
Ofrece una vía segura de actualización de firmware para los dispositivos.
Vuelve a probar la autenticación y la autorización tras cada actualización.
Documenta quién parchea qué en una tabla de responsabilidad compartida.

Reduce tu superficie de ataque con ConnectMQ

Empieza por quitar los parches del broker de tu lista. Crea un broker privado en el plan gratuito Serverless en app.connectmq.com (sin tarjeta de crédito), conecta tus clientes por TLS con credenciales generadas y centra tu esfuerzo de seguridad en los dispositivos y las aplicaciones. Para pruebas rápidas puedes usar el servidor MQTT público gratuito, pero cualquiera puede leer lo que se publica allí, así que nunca lo uses para datos de producción. La guía de buenas prácticas de seguridad MQTT es el siguiente paso para reforzar los clientes.

Preguntas frecuentes

¿Es inseguro el protocolo MQTT en sí?

No. MQTT admite autenticación y funciona sobre TLS, pero no obliga a usar ninguna de las dos. La mayoría de los problemas vienen de las implementaciones y de los despliegues que se saltan estos controles.

¿Qué vulnerabilidad MQTT es la más común en la práctica?

La autenticación ausente o débil en brokers expuestos a internet, a menudo combinada con el puerto 1883 sin cifrar, es el problema más frecuente en la investigación pública.

¿Cómo mantengo seguras las librerías cliente MQTT?

Fija las versiones de las librerías, sigue sus avisos de seguridad y actualízalas como parte de las releases normales. En los dispositivos, planifica una vía de actualización OTA para que las correcciones lleguen realmente a la flota.

¿Un broker MQTT gestionado elimina todas las vulnerabilidades MQTT?

Elimina de tu carga de trabajo los parches del broker y el refuerzo de la plataforma, pero el código cliente, el firmware, las credenciales y la validación de payloads siguen siendo responsabilidad tuya.

Vulnerabilidades comunes de MQTT y cómo mitigarlas