Em 2016, uma botnet chamada Mirai derrubou parte da internet nos Estados Unidos, incluindo serviços como Twitter, Netflix e Reddit, usando uma coisa surpreendentemente boba: câmeras de segurança IP e roteadores domésticos com senha padrão de fábrica, nunca trocada, escaneados em massa e infectados automaticamente. Não teve exploit sofisticado. Teve uma lista de vinte e poucas combinações usuário/senha padrão e milhões de dispositivos que nunca tiveram essa senha alterada.
Quase dez anos depois, esse tipo de falha continua sendo a regra, não a exceção, em produtos IoT. E o motivo não é falta de conhecimento técnico — é que o mercado de IoT tem uma pressão de custo e de time-to-market que constantemente perde pra segurança na hora de decidir prioridade.
Por que IoT é um alvo tão atraente
Um dispositivo IoT combina três características que, juntas, formam uma tempestade perfeita:
- Volume enorme e homogêneo. Uma vulnerabilidade numa câmera IP não afeta uma unidade — afeta todas as unidades do mesmo modelo vendidas no mundo inteiro, geralmente rodando o mesmo firmware.
- Ciclo de vida longo sem atualização correspondente. Diferente de um smartphone, ninguém troca uma câmera de segurança ou um sensor industrial a cada dois anos. O dispositivo fica em campo por cinco, dez anos, muitas vezes sem nenhum mecanismo de atualização, ou com um mecanismo que existe mas nunca é usado na prática.
- Conectividade constante, com hardening mínimo. É um computador completo, com sistema operacional, pilha de rede e frequentemente um servidor web embutido pra configuração — só que projetado com orçamento e prioridade de um eletrodoméstico, não de um servidor.
As falhas que eu vejo repetidas com mais frequência
Credenciais padrão nunca forçadas a trocar. Não é só “ter senha padrão” que é o problema — é não forçar a troca no primeiro acesso. Se o dispositivo permite continuar usando “admin/admin” indefinidamente, uma fração relevante dos usuários vai fazer exatamente isso.
Comunicação sem criptografia entre dispositivo e servidor/app. Protocolos como MQTT, usados amplamente em IoT, não trazem criptografia por padrão — é uma decisão de configuração (MQTT sobre TLS) que muita implementação simplesmente pula pra economizar processamento ou simplificar debug, e nunca corrige antes de ir pra produção.
APIs de configuração expostas sem autenticação adequada. Já vi produto onde a interface web de configuração do dispositivo aceitava comandos administrativos sem sessão autenticada, confiando que “só quem está na rede local vai acessar isso” — o que ignora completamente cenários de rede doméstica comprometida ou dispositivo exposto diretamente à internet por erro de configuração do roteador (algo extremamente comum, ironicamente, via UPnP).
Ausência de mecanismo de atualização, ou mecanismo presente mas nunca usado. Ter capacidade de OTA no código não significa nada se a empresa nunca publica atualização depois do lançamento — o que é comum em produtos de ciclo de vida curto no mercado, onde o fabricante já está vendendo a próxima geração quando uma vulnerabilidade é descoberta na anterior.
Um cenário pra deixar concreto
Pense numa lâmpada inteligente controlada por Wi-Fi, vendida em varejo, com app de smartphone pra configuração. Ela conecta na rede Wi-Fi doméstica do usuário (que ela precisa conhecer a senha), se comunica com um servidor na nuvem do fabricante via MQTT sem TLS (pra economizar processamento no microcontrolador barato usado no produto), e tem uma interface de debug via HTTP na porta 80 que ninguém desabilitou antes de sair de fábrica.
Um invasor na mesma rede (ou que comprometeu outro dispositivo IoT na mesma rede doméstica) pode capturar o tráfego MQTT em texto plano, ver credenciais ou tokens de sessão trafegando, ou simplesmente acessar a interface HTTP de debug diretamente e reconfigurar o dispositivo — inclusive potencialmente usá-lo como ponto de pivô pra atacar outros dispositivos na mesma rede, que é exatamente o padrão que botnets como Mirai exploraram em escala.
O dano de uma lâmpada comprometida sozinha é baixo. O dano de um roteador doméstico ou de milhares de lâmpadas formando uma botnet coordenada é outra categoria de problema completamente.
O que realmente reduz o risco
Não existe bala de prata, mas existe uma lista de práticas que resolve a maior parte do problema real, sem exigir orçamento de empresa de defesa:
- Forçar troca de senha padrão no primeiro uso, não deixar como opcional.
- TLS em qualquer comunicação que carregue credencial, token ou dado sensível — inclusive MQTT. O custo de processamento em microcontroladores modernos com aceleração de criptografia em hardware é muito menor do que era há uma década; a desculpa de “não temos processamento pra isso” hoje raramente se sustenta.
- Desabilitar qualquer interface de debug/configuração não documentada antes de sair de fábrica — se existe uma porta HTTP de debug, ela precisa estar atrás de autenticação real ou simplesmente não existir no build de produção.
- Mecanismo de atualização funcional e testado, com verificação de assinatura (sem isso, você abre a porta que discuti no artigo sobre secure boot: um “update” malicioso é indistinguível de um legítimo).
- Seguir um checklist reconhecido, como o OWASP IoT Top 10 — não porque é lei, mas porque é uma lista compilada a partir de vulnerabilidades reais repetidamente encontradas em produtos reais, o que economiza você reinventar a roda.
O ponto que fica
Segurança em IoT não é sobre criptografia exótica ou proteção contra atacante nível estado-nação. É sobre não deixar as portas óbvias abertas — que é exatamente o que a maioria dos incidentes reais explora. Se o seu produto tem Wi-Fi, um app de smartphone e um microcontrolador processando dados de rede, ele já é, por definição, um sistema embarcado com superfície de ataque de rede — trate como tal desde o design, não como um acessório de conveniência que “não é bem um computador”.
Esse assunto se conecta direto com o que eu escrevi sobre segurança em Embedded Linux e sobre secure boot — se você trabalha com produto conectado, os três artigos juntos cobrem a base do que costuma faltar.
