Vulnérabilités MQTT courantes et comment les atténuer

Les vulnérabilités MQTT se répartissent en quelques classes récurrentes : authentification faible ou absente, lacunes d'autorisation, bugs d'analyse dans les brokers et les bibliothèques clientes, fuites d'informations et épuisement des ressources. Cet article passe en revue chaque classe du point de vue du défenseur, explique pourquoi elle survient et liste les mesures d'atténuation qui fonctionnent. Vous terminerez avec une checklist de gestion des vulnérabilités pour les brokers, les appareils et les applications entre les deux.

Où se trouvent les vulnérabilités MQTT

Le protocole MQTT lui-même est compact et bien spécifié. La plupart des problèmes concrets proviennent de trois endroits :

Les implémentations de brokers : le logiciel serveur qui analyse les paquets, authentifie les clients et achemine les messages.
Les bibliothèques clientes et le firmware : le code des appareils et des applications qui parle MQTT.
Les déploiements : la configuration, les identifiants, l'exposition réseau et la conception des topics.

En pratique, les erreurs de déploiement causent la plupart des incidents, mais ce sont les bugs d'implémentation qui nécessitent des correctifs. Les deux méritent un plan.

Les classes de vulnérabilités en un coup d'œil

Classe	Cause typique	Atténuation principale
Authentification absente	Accès anonyme laissé activé	Exiger des identifiants sur chaque listener
Contournement de l'authentification	Bugs dans les plugins d'authentification ou cas limites logiques	Appliquer rapidement les correctifs, tester l'authentification à chaque mise à niveau
Lacunes d'autorisation	Permissions trop larges, abus des wildcards	Moindre privilège par identité, tenants séparés
Bugs d'analyse des paquets	Longueurs, propriétés ou chaînes UTF-8 malformées	Maintenir broker et bibliothèques à jour, fuzzing en préproduction
Divulgation d'informations	Topics `$SYS`, données retenues, erreurs trop bavardes	Limiter les métadonnées, nettoyer les topics retenus
Épuisement des ressources	Aucune limite sur les connexions, la taille ou le débit	Quotas, limites de taille de paquet, protection contre le flooding
Transport en clair	Port 1883 à travers des réseaux non fiables	TLS avec validation du certificat
Injection côté client	Payloads utilisés sans précaution dans le code ou des commandes	Valider chaque payload et le contrôler par schéma
Exposition des identifiants	Secrets codés en dur ou partagés dans le firmware	Identifiants uniques et révocables par appareil

Faiblesses d'authentification

La vulnérabilité la plus simple est l'absence totale d'authentification. Les brokers laissés dans un mode de développement permissif acceptent n'importe quel client, ce qui mène aux problèmes décrits dans les brokers MQTT exposés.

Des problèmes plus subtils apparaissent lorsque l'authentification existe mais présente des failles. Historiquement, des implémentations de brokers ont connu des bugs où certaines combinaisons d'options, le comportement d'un plugin ou des paquets malformés permettaient à un client d'échapper à un contrôle. Schémas à surveiller :

Des plugins d'authentification qui laissent passer lorsqu'un backend (base de données, LDAP) est injoignable.
Des listeners aux réglages différents, dont un, oublié, autorise l'accès anonyme.
Une confiance fondée sur le client ID, où connaître un client ID suffit pour s'emparer d'une session.
Aucune limite sur les tentatives de connexion, ce qui rend la devinette de mots de passe praticable.

Atténuations : exigez l'authentification sur chaque listener, refusez l'accès lorsqu'un backend d'authentification est indisponible, liez les client IDs aux identifiants et ralentissez ou bloquez les échecs répétés. Sur ConnectMQ, les client IDs sont liés aux identifiants émis et les IP sont bloquées après des échecs de connexion répétés.

Lacunes d'autorisation

Une fois connecté, un client ne devrait pouvoir toucher qu'à ses propres topics. Les lacunes courantes comprennent :

Tous les appareils partageant un même compte doté d'un accès complet.
Des abonnements avec wildcard comme # autorisés pour des appareils ordinaires.
Des topics de commande accessibles en écriture à n'importe quel client authentifié.
Des règles écrites pour MQTT 3.1.1 qui ignorent des fonctionnalités de MQTT 5 comme les abonnements partagés ($share/group/topic).

Atténuations : concevez les topics de sorte que les permissions puissent suivre la hiérarchie, donnez à chaque appareil des identifiants uniques et testez la matrice de permissions à chaque version. Les brokers auto-hébergés peuvent utiliser des ACL, décrites dans le guide sur les ACL MQTT. Lorsque le broker ne fournit pas de règles par topic, des tenants ou des brokers séparés par domaine de confiance offrent une isolation bien plus forte que ne le pourront jamais des identifiants partagés.

Bugs d'analyse des paquets et de sûreté mémoire

Les paquets MQTT contiennent des entiers de longueur variable, des chaînes préfixées par leur longueur, des données binaires et, en MQTT 5, un riche ensemble de propriétés. Chacun de ces champs doit être validé. Les bugs d'analyse dans les implémentations de brokers et de clients ont historiquement provoqué des plantages et, dans les pires cas, des corruptions de mémoire.

Causes profondes typiques :

Des valeurs de remaining length qui ne correspondent pas aux données réelles.
Des listes de propriétés contenant des propriétés en double ou inattendues.
De l'UTF-8 invalide ou des caractères interdits dans les noms de topics.
Des hiérarchies de topics très profondes ou des chaînes extrêmement longues.

Atténuations : maintenez les brokers et les bibliothèques clientes sur des versions supportées et corrigées ; abonnez-vous aux bulletins de sécurité de chaque composant MQTT que vous livrez ; et n'effectuez de fuzzing que sur des brokers de préproduction isolés qui vous appartiennent. La méthodologie de test d'intrusion MQTT explique comment cadrer cela en toute sécurité. Sur les appareils embarqués, préférez des bibliothèques maintenues à des analyseurs maison.

Divulgation d'informations

Les fuites d'informations sont rarement spectaculaires, mais souvent utiles aux attaquants :

Des topics $SYS qui révèlent la version du broker, sa durée de fonctionnement et le nombre de clients.
Des retained messages laissés sur des topics longtemps après la fin d'un projet.
Des topics de débogage ou de diagnostic qui publient la configuration, des adresses IP ou des jetons.
Des messages d'erreur qui révèlent si un nom d'utilisateur existe.
Des noms de topics qui décrivent en détail des emplacements, des clients ou des équipements.

Atténuations : restreignez qui peut lire les topics de métadonnées, passez en revue et nettoyez les topics retenus, tenez totalement les secrets à l'écart des payloads et utilisez des identifiants opaques lorsque les noms de topics en révéleraient trop.

Épuisement des ressources

Sans limites, un seul client peut consommer connexions, mémoire ou bande passante jusqu'à dégrader le broker. Les floods peuvent être malveillants ou simplement résulter de bugs de firmware et de tempêtes de reconnexions.

Atténuations : limites de débit de messages par client, taille maximale de paquet, plafonds d'abonnements et de connexions, et backoff côté client. ConnectMQ applique des quotas par offre avec le reason code MQTT 5 0x97 et une protection contre le flooding. Les détails figurent dans limitation de débit MQTT et protection contre les DoS.

Vulnérabilités côté client

Les clients sont souvent le maillon faible, car ils fonctionnent sur de nombreux appareils aux cycles de mise à jour longs.

Payloads non validés : un abonné qui transmet un payload à une commande shell, une requête SQL ou un eval a transformé le broker en canal d'attaque.
Vérification TLS désactivée : les clients qui activent un mode « insecure » pour contourner des erreurs de certificat peuvent être interceptés.
Identifiants codés en dur : les images firmware sont faciles à extraire. Le guide pour sécuriser les identifiants MQTT sur les appareils présente les options de stockage.
Bibliothèques obsolètes : les appareils impossibles à mettre à jour conservent indéfiniment des bugs connus.

Un abonné sûr traite chaque payload comme une entrée non fiable :

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}")  # appeler ici votre propre gestionnaire sûr

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()

Le principe est simple : analyser strictement, n'accepter que les commandes d'une liste autorisée, vérifier les plages de valeurs et ne jamais exécuter le contenu d'un payload.

Stratégie de correctifs : auto-hébergé ou managé

La gestion des vulnérabilités est un travail continu. Pour un broker auto-hébergé, quelqu'un doit suivre les bulletins, tester les mises à niveau, planifier les fenêtres de maintenance et vérifier ensuite que la configuration tient toujours. Les brokers exposés à Internet qui prennent du retard sur les mises à jour sont exactement ce que cherchent les attaquants.

Un broker MQTT managé transfère les correctifs du broker au fournisseur. Avec ConnectMQ, le logiciel du broker, les certificats TLS et les protections de la plateforme comme l'isolation des tenants sont exploités pour vous, tandis que vous restez responsable du firmware des appareils, des bibliothèques clientes, des identifiants et du traitement des payloads. Comprendre ce que fait un broker MQTT aide à tracer clairement cette frontière.

Checklist de gestion des vulnérabilités

Tenir un inventaire de chaque broker, bibliothèque cliente et version de firmware en service.
S'abonner aux bulletins de sécurité de chaque composant.
Exiger l'authentification et TLS sur chaque listener exposé à Internet.
Donner à chaque appareil des identifiants uniques et révocables et un accès au moindre privilège.
Configurer des limites de taille, de débit et de connexions ; gérer les reason codes dans les clients.
Valider tous les payloads côté abonnés ; ne jamais exécuter le contenu d'un payload.
Retirer les secrets des payloads et nettoyer les topics retenus.
Fournir un chemin de mise à jour firmware sécurisé pour les appareils.
Retester l'authentification et l'autorisation après chaque mise à niveau.
Documenter qui corrige quoi dans un tableau de responsabilités partagées.

Réduisez votre surface d'attaque avec ConnectMQ

Commencez par rayer les correctifs du broker de votre liste. Créez un broker privé sur l'offre gratuite Serverless sur app.connectmq.com (sans carte bancaire), connectez vos clients via TLS avec des identifiants générés et concentrez vos efforts de sécurité sur les appareils et les applications. Le serveur MQTT public gratuit convient aux tests et aux prototypes, mais il est anonyme et lisible par tous : n'y envoyez jamais de données de production. Le guide des bonnes pratiques de sécurité MQTT est l'étape suivante pour durcir vos clients.

Questions fréquentes

Le protocole MQTT lui-même est-il non sécurisé ?

Non. MQTT prend en charge l'authentification et fonctionne sur TLS, mais n'impose ni l'une ni l'autre. La plupart des problèmes proviennent des implémentations et des déploiements qui font l'impasse sur ces contrôles.

Quelle vulnérabilité MQTT est la plus courante en pratique ?

L'authentification absente ou faible sur des brokers exposés à Internet, souvent combinée au port 1883 non chiffré, est le problème le plus fréquemment signalé dans les recherches publiques.

Comment garder les bibliothèques clientes MQTT sécurisées ?

Figez les versions des bibliothèques, suivez leurs bulletins de sécurité et mettez-les à jour dans le cadre de vos versions habituelles. Sur les appareils, prévoyez un chemin de mise à jour over-the-air pour que les correctifs atteignent réellement le parc.

Un broker MQTT managé élimine-t-il toutes les vulnérabilités MQTT ?

Il retire de votre charge de travail les correctifs du broker et le durcissement de la plateforme, mais le code client, le firmware, les identifiants et la validation des payloads restent sous votre responsabilité.

Les vulnérabilités MQTT courantes et comment les atténuer