Vulnerabilidades MQTT Comuns e Como Mitigá-las

As vulnerabilidades do MQTT se enquadram em algumas classes recorrentes: autenticação fraca ou ausente, lacunas de autorização, bugs de parsing em brokers e bibliotecas de cliente, vazamentos de informação e esgotamento de recursos. Este artigo percorre cada classe do ponto de vista de quem defende, explica por que ela acontece e lista as mitigações que funcionam. Ao final, você terá um checklist de gestão de vulnerabilidades para brokers, dispositivos e as aplicações entre eles.

Onde estão as vulnerabilidades do MQTT

O protocolo MQTT em si é pequeno e bem especificado. A maioria dos problemas reais vem de três lugares:

Implementações de broker: o software de servidor que faz o parsing dos pacotes, autentica clientes e roteia mensagens.
Bibliotecas de cliente e firmware: o código em dispositivos e aplicações que fala MQTT.
Implantações: configuração, credenciais, exposição de rede e projeto de topics.

Na prática, erros de implantação causam a maior parte dos incidentes, mas são os bugs de implementação que exigem correções. Ambos merecem um plano.

Classes de vulnerabilidades em resumo

Classe	Causa típica	Mitigação principal
Autenticação ausente	Acesso anônimo deixado habilitado	Exigir credenciais em todo listener
Bypass de autenticação	Bugs em plugins de autenticação ou casos-limite na lógica	Aplicar correções rapidamente, testar a autenticação a cada atualização
Lacunas de autorização	Permissões amplas demais, abuso de curingas	Menor privilégio por identidade, tenants separados
Bugs de parsing de pacotes	Comprimentos, propriedades ou strings UTF-8 malformados	Manter broker e bibliotecas atualizados, fazer fuzzing em staging
Divulgação de informações	Topics `$SYS`, dados retidos, erros verbosos	Limitar metadados, limpar topics retidos
Esgotamento de recursos	Sem limites de conexões, tamanho ou taxa	Cotas, limites de tamanho de pacote, proteção contra inundação
Transporte em texto puro	Porta 1883 em redes não confiáveis	TLS com validação de certificado
Injeção no lado do cliente	Payloads usados de forma insegura em código ou comandos	Validar e checar o esquema de cada payload
Exposição de credenciais	Segredos fixos no código ou compartilhados no firmware	Credenciais exclusivas e revogáveis por dispositivo

Fraquezas de autenticação

A vulnerabilidade mais simples é não ter autenticação alguma. Brokers deixados em um modo permissivo de desenvolvimento aceitam qualquer cliente, o que leva aos problemas descritos em brokers MQTT expostos. Um servidor MQTT público, como o da ConnectMQ, aceita clientes anônimos de propósito e por isso serve apenas para testes e protótipos, nunca para dados de produção.

Problemas mais sutis aparecem quando a autenticação existe, mas tem lacunas. Historicamente, implementações de broker tiveram bugs em que certas combinações de opções, comportamentos de plugins ou pacotes malformados permitiam que um cliente pulasse uma verificação. Padrões a observar:

Plugins de autenticação que falham de forma aberta quando um backend (banco de dados, LDAP) está inacessível.
Listeners com configurações diferentes, em que um listener esquecido permite acesso anônimo.
Confiança baseada em client ID, em que conhecer um client ID basta para assumir uma sessão.
Nenhum limite de tentativas de login, o que torna viável adivinhar senhas.

Mitigações: exija autenticação em todo listener, falhe de forma fechada quando um backend de autenticação estiver fora do ar, vincule client IDs a credenciais e limite ou bloqueie falhas repetidas. Na ConnectMQ, os client IDs ficam vinculados às credenciais emitidas e os IPs são bloqueados após logins com falha repetidos.

Lacunas de autorização

Depois de conectado, um cliente deve conseguir acessar apenas seus próprios topics. Lacunas comuns incluem:

Todos os dispositivos compartilhando uma única conta com acesso total.
Assinaturas com curinga, como #, permitidas para dispositivos comuns.
Topics de comando graváveis por qualquer cliente autenticado.
Regras escritas para o MQTT 3.1.1 que ignoram recursos do MQTT 5, como as shared subscriptions ($share/group/topic).

Mitigações: projete os topics de forma que as permissões possam seguir a hierarquia, dê a cada dispositivo credenciais exclusivas e teste a matriz de permissões em cada release. Brokers auto-hospedados podem usar ACLs, descritas no guia de ACL no MQTT. Quando o broker não oferece regras por topic, tenants ou brokers separados por domínio de confiança garantem um isolamento muito mais forte do que credenciais compartilhadas jamais poderiam.

Bugs de parsing de pacotes e de segurança de memória

Os pacotes MQTT contêm inteiros de comprimento variável, strings prefixadas pelo tamanho, dados binários e, no MQTT 5, um conjunto rico de propriedades. Cada um desses campos precisa ser validado. Bugs de parsing em implementações de broker e de cliente já levaram a travamentos e, nos piores casos, a corrupção de memória.

Causas-raiz típicas:

Valores de remaining length que não correspondem aos dados reais.
Listas de propriedades com propriedades duplicadas ou inesperadas.
UTF-8 inválido ou caracteres proibidos em nomes de topic.
Hierarquias de topic muito profundas ou strings extremamente longas.

Mitigações: mantenha broker e bibliotecas de cliente em versões suportadas e corrigidas; assine os boletins de segurança de cada componente MQTT que você entrega; e execute fuzzing apenas contra brokers de staging isolados que sejam seus. A metodologia de teste de invasão em MQTT explica como definir esse escopo com segurança. Em dispositivos embarcados, prefira bibliotecas mantidas a parsers próprios.

Divulgação de informações

Vazamentos de informação raramente são dramáticos, mas costumam ser úteis para atacantes:

Topics $SYS revelando a versão do broker, o tempo de atividade e a contagem de clientes.
Retained messages deixadas em topics muito depois do fim de um projeto.
Topics de depuração ou diagnóstico publicando configurações, endereços IP ou tokens.
Mensagens de erro que revelam se um nome de usuário existe.
Nomes de topic que descrevem locais, clientes ou equipamentos em detalhe.

Mitigações: restrinja quem pode ler topics de metadados, revise e limpe os topics retidos, mantenha segredos totalmente fora dos payloads e use identificadores opacos quando os nomes de topic revelariam demais. Quando os payloads ou topics envolvem dados pessoais, lembre que a LGPD também se aplica a eles.

Esgotamento de recursos

Sem limites, um único cliente pode consumir conexões, memória ou banda até degradar o broker. As inundações podem ser maliciosas ou simplesmente resultado de bugs de firmware e tempestades de reconexão.

Mitigações: limites de taxa de mensagens por cliente, tamanho máximo de pacote, tetos de assinaturas e conexões e backoff no lado do cliente. A ConnectMQ aplica cotas por plano com o reason code 0x97 do MQTT 5 e proteção contra inundação. Os detalhes estão em limitação de taxa no MQTT e proteção contra DoS.

Vulnerabilidades no lado do cliente

Os clientes costumam ser o elo mais fraco, porque rodam em muitos dispositivos com ciclos de atualização longos.

Payloads não validados: um assinante que passa um payload para um comando de shell, uma consulta SQL ou um eval transformou o broker em um canal de ataque.
Verificação TLS desativada: clientes que ativam o modo "insecure" para contornar erros de certificado podem ser interceptados.
Credenciais fixas no código: imagens de firmware são fáceis de extrair. O guia sobre como proteger credenciais MQTT em dispositivos aborda as opções de armazenamento.
Bibliotecas desatualizadas: dispositivos que não podem ser atualizados mantêm bugs conhecidos para sempre.

Um assinante seguro trata cada payload como entrada não confiável:

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}")  # chame aqui o seu próprio 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()

O padrão é simples: faça parsing estrito, use uma lista de comandos permitidos, verifique as faixas de valores e nunca execute o conteúdo do payload.

Estratégia de atualização: auto-hospedado versus gerenciado

A gestão de vulnerabilidades é um trabalho contínuo. Em um broker auto-hospedado, alguém precisa acompanhar os boletins, testar atualizações, agendar janelas de manutenção e verificar depois se a configuração continua válida. Brokers expostos à internet que ficam para trás nas atualizações são exatamente o que os atacantes procuram.

Um broker MQTT gerenciado transfere a atualização do broker para o provedor. Com a ConnectMQ, o software do broker, os certificados TLS e as proteções da plataforma, como o isolamento de tenants, são operados para você, enquanto você continua responsável pelo firmware dos dispositivos, pelas bibliotecas de cliente, pelas credenciais e pelo tratamento dos payloads. Entender o que um broker MQTT faz ajuda a traçar essa linha com clareza.

Checklist de gestão de vulnerabilidades

Mantenha um inventário de cada broker, biblioteca de cliente e versão de firmware em uso.
Assine os boletins de segurança de cada componente.
Exija autenticação e TLS em todo listener exposto à internet.
Dê a cada dispositivo credenciais exclusivas e revogáveis e acesso com menor privilégio.
Configure limites de tamanho, taxa e conexões; trate os reason codes nos clientes.
Valide todos os payloads nos assinantes; nunca execute o conteúdo do payload.
Remova segredos dos payloads e limpe os topics retidos.
Ofereça um caminho seguro de atualização de firmware para os dispositivos.
Teste novamente autenticação e autorização após cada atualização.
Documente quem atualiza o quê em uma tabela de responsabilidade compartilhada.

Reduza sua superfície de ataque com a ConnectMQ

Comece tirando a atualização do broker da sua lista. Crie um broker privado no plano Serverless (Free) em app.connectmq.com (sem cartão de crédito), conecte seus clientes via TLS com credenciais geradas e concentre seu esforço de segurança em dispositivos e aplicações. O guia de melhores práticas de segurança MQTT é o próximo passo para fortalecer os clientes.

Perguntas frequentes

O protocolo MQTT em si é inseguro?

Não. O MQTT oferece autenticação e roda sobre TLS, mas não obriga nenhuma das duas coisas. A maioria dos problemas vem de implementações e de implantações que deixam esses controles de lado.

Qual vulnerabilidade MQTT é a mais comum na prática?

Autenticação ausente ou fraca em brokers expostos à internet, muitas vezes combinada com a porta 1883 sem criptografia, é o problema mais frequente relatado em pesquisas públicas.

Como manter as bibliotecas de cliente MQTT seguras?

Fixe as versões das bibliotecas, acompanhe os boletins de segurança delas e atualize-as como parte das releases normais. Nos dispositivos, planeje um caminho de atualização over-the-air para que as correções realmente cheguem à frota.

Um broker MQTT gerenciado elimina todas as vulnerabilidades do MQTT?

Ele tira do seu trabalho a atualização do broker e o fortalecimento da plataforma, mas o código dos clientes, o firmware, as credenciais e a validação dos payloads continuam sendo sua responsabilidade.

Vulnerabilidades Comuns do MQTT e Como Mitigá-las