TP-Link Tapo C200: chave hardcoded, buffer overflow e privacidade na era da engenharia reversa com IA

 (evilsocket.net)
1 pontos por GN⁺ 2025-12-21 | 1 comentários | Compartilhar no WhatsApp
  • A análise do firmware da câmera IP TP-Link Tapo C200 de baixo custo com engenharia reversa assistida por IA revelou várias vulnerabilidades de segurança
  • O firmware inclui uma chave privada SSL hardcoded, permitindo a descriptografia do tráfego HTTPS na mesma rede
  • Durante a análise, foram usadas ferramentas de IA (Grok, GhidraMCP, Cline etc.) para automatizar a compreensão da estrutura do firmware e a análise semântica das funções
  • As principais vulnerabilidades encontradas incluem buffer overflow (CVE-2025-8065), integer overflow (CVE-2025-14299) e sequestro de WiFi (CVE-2025-14300), algumas delas exploráveis remotamente sem autenticação
  • O caso é visto como um exemplo de como a IA aumenta a eficiência da pesquisa em segurança ao mesmo tempo em que expõe vulnerabilidades estruturais em dispositivos IoT

Obtenção e descriptografia do firmware

  • Ao fazer engenharia reversa do app Android do Tapo, foi encontrado um bucket S3 público da TP-Link, permitindo baixar o firmware de todos os dispositivos sem autenticação
    • Comando de exemplo: aws s3 ls s3://download.tplinkcloud.com/ --no-sign-request --recursive
  • A descriptografia do firmware foi realizada com a ferramenta tp-link-decrypt
    • A chave RSA pode ser extraída do material de código GPL divulgado pela TP-Link
  • O firmware descriptografado é composto pela estrutura de bootloader, kernel e sistema de arquivos raiz SquashFS

Engenharia reversa com IA

  • A análise do firmware foi automatizada com Ghidra, GhidraMCP, Cline e Anthropic Opus/Sonnet 4
  • A IA explicou a função de cada rotina e renomeou variáveis de forma significativa, melhorando a legibilidade do código
  • Com isso, foi possível mapear handlers HTTP, protocolo de descoberta e rotinas de criptografia
  • Também foi confirmado que a chave privada SSL no firmware não é gerada no boot, mas embutida
    • Um atacante na mesma rede pode descriptografar o tráfego HTTPS

Principais vulnerabilidades

  • CVE-2025-8065 (overflow de memória no parser SOAP XML do ONVIF)

    • O servidor /bin/main na porta 2020 não faz verificação de limites para a quantidade de elementos XML
    • O envio de um grande volume de requisições XML causa overflow de memória e crash da câmera
    • Pontuação CVSS v4.0: 7.1 (High)

  • CVE-2025-14299 (integer overflow no Content-Length do HTTPS)

    • O servidor HTTPS na porta 443 processa o cabeçalho Content-Length com atoi() sem validação
    • Em sistemas 32-bit, isso causa crash por overflow
    • Pontuação CVSS v4.0: 7.1 (High)

  • CVE-2025-14300 (sequestro de WiFi)

    • A API connectAp pode ser acessada sem autenticação e permanece ativa mesmo após a configuração inicial
    • Um atacante pode conectar a câmera a uma rede controlada pelo invasor e interceptar o tráfego de vídeo
    • Pontuação CVSS v4.0: 8.7 (High)

  • API de varredura de WiFi sem autenticação (scanApList)

    • Retorna SSID, BSSID, intensidade do sinal e configurações de segurança das redes próximas
    • Com ferramentas como Apple BSSID Locator, é possível rastrear a localização GPS exata
    • Um atacante remoto pode identificar a localização real da câmera

Processo de divulgação e resposta

  • O primeiro reporte à equipe de segurança da TP-Link foi feito em 22 de julho de 2025, incluindo PoC e vídeo
  • A divulgação ocorreu após 150 dias (19 de dezembro), e depois disso a TP-Link publicou um aviso de segurança
  • A TP-Link possui autoridade própria para emissão de CVE (CNA), controlando diretamente o processo de reporte e divulgação de vulnerabilidades em seus produtos
  • Foi apontado um conflito de interesse, já que a empresa usa em seu site um número menor de CVEs que concorrentes como métrica de marketing

Conclusão

  • Ferramentas de IA maximizam a eficiência da engenharia reversa e ampliam a acessibilidade da pesquisa em segurança
  • Porém, chaves hardcoded, APIs sem autenticação e parsers frágeis revelam a ausência de segurança fundamental em dispositivos IoT
  • O caso da TP-Link simboliza o problema do equilíbrio entre pesquisa em segurança na era da IA e a responsabilidade dos fabricantes

Leituras relacionadas

1 comentários

 
GN⁺ 2025-12-21
Comentários do Hacker News

  • É uma pena quando textos assim misturam casos reais de fracasso com problemas que até a FAANG tem dificuldade para resolver, e fazem a crítica desse jeito
    Em especial, tratar de forma crítica a parte de que “o repositório de firmware da TP-Link estava em um bucket S3 público sem autenticação” é uma abordagem equivocada
    Na verdade, considero isso um bom exemplo de evitar segurança por obscuridade (security through obscurity)
    Um texto assim pode até acabar levando a diretoria a dar ordens erradas de “trancar mais” as coisas

    • O texto em si era fácil de ler, mas tinha um tom que parecia escrito por LLM
      Textos escritos por IA tendem a carecer de nuances sutis e a tratar tudo de forma exageradamente nova, boa ou ruim
      Não é um texto ruim, mas é preciso ler com cuidado. Hoje em dia, a maioria dos posts que aparecem no HN parece ter recebido ajuda de IA
    • Alguém fez a piada de que, se o firmware estar público é um problema, então “melhor nem falar de Linux”
    • Esses blogs de engenharia reversa são, acima de tudo, uma forma divertida e didática de contar uma história
      Eu mesmo já escrevi vários textos assim, e este foi realmente interessante
      Na prática, “como o firmware foi obtido” é a parte menos importante dessa história
    • Não senti nenhum tom negativo na parte sobre o firmware estar público. Fiquei curioso se mais alguém interpretou assim
    • Acho que o firmware deveria ser sempre público. Esse é o caminho certo

  • É bem provável que a maioria dos outros modelos de câmera também compartilhe vulnerabilidades de segurança parecidas
    Segundo a página da comunidade da TP-Link, o firmware mais recente da C200 aparece como 1.4.4, mas no artigo é citado o 1.4.2
    Ou seja, houve algumas atualizações, mas aparentemente correções de segurança não foram incluídas

    • Quando analisei produtos da Zyxel no passado, cheguei à mesma conclusão
      Muitos fabricantes trabalham no modelo de vender hardware comum com outra marca
      Textos relacionados: Part 1, Part 2
    • Essas câmeras servem para conexões locais, mas para usuários comuns ainda há muitos problemas de usabilidade

  • É por isso que a segmentação da rede IoT é essencial
    Todas as câmeras inteligentes e dispositivos IoT devem ficar em uma VLAN separada, com o acesso à internet restrito por firewall
    Configurações recomendadas para usuários de câmeras TP-Link:

    1. Desativar o UPnP no roteador
    2. Separar os dispositivos IoT com VLAN
    3. Permitir tráfego de saída apenas para os endpoints necessários
    4. Trocar pelo firmware aberto quando possível
    5. Verificar atualizações regularmente
      O problema das chaves hardcoded é especialmente grave e afeta toda a linha de produtos
    • Uma vez testei a rede da casa de um amigo e consegui acessar toda a rede interna por meio de um sistema de interfone PoE
      Ele não tinha separado os dispositivos IoT por VLAN e também não havia nenhum sistema de alerta
      No fim, ele aprendeu naquele dia, na prática, a importância da separação por VLAN e das restrições de acesso
      Acho que muita gente deve estar expondo a rede interna de forma parecida
    • Também houve quem perguntasse se existe algum guia explicando a configuração de VLAN passo a passo. É tecnicamente possível, mas é preciso ter um procedimento concreto

  • O Thingino supostamente oferece suporte à C200

    • Mas, na prática, ele só oferece suporte a algumas das 5 versões da C200
      Para confirmar o chipset exato, é preciso consultar o OpenIPC
    • O firmware criado pela comunidade do Thingino é realmente impressionante
      Se você tiver uma câmera compatível, vale muito a pena testar

  • Eu uso todas as câmeras em uma VLAN sem acesso à internet
    O acesso local funciona via HomeKit, então tudo roda bem mesmo sem aplicativo separado

  • Esse nível de descuido com segurança parece quase intencional
    É difícil entender como se vende milhões de unidades sem sequer fazer verificações básicas de vulnerabilidade
    Acho que a maioria das câmeras Wi‑Fi abaixo de $150 deve ter problemas parecidos
    Se quiser usar algo realmente seguro, a única saída é montar por conta própria um adaptador Wi‑Fi ↔ Ethernet não proprietário

    • Essa câmera está sendo vendida no site oficial por $17.99
      Descontando hardware, embalagem, logística, testes, devoluções etc., sobra menos de $5 de lucro por unidade
      Gastar mais $100.000 em desenvolvimento extra equivale a queimar 20.000 unidades
      Em uma empresa com uma linha de produtos tão grande quanto a TP-Link, esse custo pode virar dezenas de milhões de dólares por ano
      No fim, o modelo acaba sendo embarcar o produto com o mínimo de desenvolvimento possível
    • Algumas câmeras alimentadas por USB oferecem suporte a adaptadores de rede USB
      Quem tem mais familiaridade técnica pode montar um ambiente somente local com o firmware do Thingino
    • Essas câmeras nunca deveriam ser colocadas em uma rede não confiável. É um princípio óbvio demais
    • Concordo totalmente com a afirmação de que “todas as câmeras Wi‑Fi têm problemas parecidos”

  • Não sei até quando o repositório S3 de firmware da TP-Link vai continuar aberto
    São cerca de 990GiB de dados, então seria bom se alguém fizesse backup em arquivo ou torrent

  • Eu uso essa câmera com Unifi + ONVIF apenas para funções não críticas
    Ela está em uma VLAN separada e sem acesso à internet, e felizmente continua funcionando normalmente

  • Ao investigar a câmera, consultei o site drmnsamoliu.github.io

  • Já tentei fazer engenharia reversa do feed de vídeo de um drone de brinquedo usando Ghidra e AWS Amazon Q
    Acho que teria sido bem mais rápido se eu tivesse usado o GhidraMCP