Tentei monitorar meu cachorro, mas acabei monitorando a TP-Link

• Comprei uma câmera Tapo para observar meu cachorro em casa, mas acabei fazendo uma engenharia reversa de como os dispositivos e o app da TP-Link funcionam
• Para analisar o processo de onboarding e a estrutura de comunicação da API criptografada, usei várias técnicas, como MITM, descompilação de APK e criação de scripts de descriptografia
• Ao descobrir a senha inicial de administrador e o processo de derivação de chave de sessão, consegui decifrar mensagens criptografadas e identificar um problema de sincronização pouco confiável entre o dispositivo e a conta na nuvem
• Analisei todo o fluxo de onboarding e automatizei com scripts Bash as principais chamadas de API, criação de conta, troca de senha e conexão ao Wi‑Fi
• Aponto características típicas de dispositivos IoT de baixo custo, como falhas no design de segurança do firmware da Tapo, implementação de criptografia menos sofisticada e sincronização irregular de contas

---

Visão geral do projeto

• O autor comprou e usou uma câmera Tapo de baixo custo para observar seu cachorro dentro de casa
• Durante o uso, a configuração incômoda e a falta de informações online o levaram a investigar a fundo como o produto funciona
• Problemas inesperados com integração ao frigate e ativação de 2way audio despertaram interesse em um método de onboarding direto sem integração com a nuvem

Análise da estrutura de onboarding e autenticação

• Para analisar o procedimento de conexão da câmera Tapo, foram usados MITM proxy e a ferramenta de hook dinâmico frida para interceptar o tráfego entre o app e a câmera
  • Como apps mais recentes contam com mecanismos de resistência a bypass, como ignorar proxy e certificate pinning, a abordagem com ferramentas dinâmicas se mostrou eficaz
• Depois de configurar essa estrutura de bypass, foi possível confirmar com precisão o processo de login da conta administrativa padrão no fluxo de onboarding da câmera
• Foi descoberto que a API de login padrão funciona com uma senha padrão própria do dispositivo, separada da senha da conta na nuvem

Estrutura de criptografia e busca da senha padrão

• Por meio de descompilação de APK (com JADX) e análise de código, foi obtida a senha padrão da conta admin (TPL075526460603)
• Também foi confirmado que, mesmo após alterar a senha da nuvem, câmeras já vinculadas não percebem a mudança, mostrando que a sincronização de senhas entre app e câmera é imprecisa
• Como a senha padrão foi descoberta, foi possível implementar a lógica de derivação das chaves de sessão (lsk, ivb) e descriptografar mensagens da API criptografada em tempo real

Scripts com mitmproxy e análise da API

• Com referência ao projeto open source PyTapo, foi feita uma análise detalhada do fluxo de API do procedimento real de onboarding da Tapo
• Por meio do script tapo_decrypt_pretty.py, foi possível:
  • detectar o handshake de login
  • extrair chaves de sessão
  • descriptografar a API criptografada, gerar uma saída mais legível e salvar JSON
• Entre todo o histórico de chamadas de API do onboarding, foram selecionados apenas os processos principais mais relevantes para criar um fluxo de automação
  • consulta da lista de Wi‑Fi (scanApList)
  • ativação de conta RTSP/ONVIF
  • alteração da senha de administrador
  • conexão ao Wi‑Fi

Automação e resultados

• Um script Bash (tapo_onboard.sh) foi montado para executar automaticamente todo o processo de onboarding acima
  • login inicial como admin
  • seleção e conexão ao Wi‑Fi
  • remoção do logo do feed da câmera
  • permissão de uso de RTSP/ONVIF
  • redefinição da senha de administrador
• Na estrutura do firmware da câmera, foram identificadas as seguintes características e falhas
  • algumas APIs usam hash SHA-256, mas outras ainda mantêm métodos antigos como MD5
  • existem 2 chaves públicas, mas não está claro em que situação cada uma deve ser usada
  • a sincronização de senha entre app e dispositivo é muito instável

Conclusão e impressões

• A estrutura de segurança do firmware e da API da câmera Tapo passa a impressão de ser uma solução improvisada e pouco refinada
• O projeto proporcionou uma experiência indireta com as falhas de segurança de dispositivos IoT baratos e a realidade de sistemas de onboarding incompletos
• O objetivo final do projeto, que era acompanhar o cachorro, foi alcançado, e o autor constatou que ele normalmente dorme no sofá ou na cama

[helio]

CVE-2022-37255 tem nota 7,5.

[GN⁺]

Comentários no Hacker News

• Achei curioso ver meu script do Frida sendo usado; ele pode ser encontrado aqui. Fico feliz que pareça funcionar bem em ambiente real, e gostaria de saber se houve algo adicionado ou modificado.

  • Acho o HTTP Toolkit uma ferramenta realmente excelente; é um ótimo trabalho do Tim.
  • Das ferramentas que já usei, o HTTP Toolkit é a melhor. Já testei mitmproxy, proxyman e charles proxy, mas o httptoolkit foi o melhor, além de ser open source.

• Só como referência: para usar áudio bidirecional no frigate, é preciso aplicar a configuração tapo:// do go2rtc no stream principal em vez do rtsp:// comum. A TP-Link só oferece áudio bidirecional pela própria API. O problema é que, com essa configuração, o ONVIF (controle de pan/tilt da câmera via ferramenta open source) deixa de funcionar, o que é bem incômodo. Para usar os dois recursos, é preciso um fluxo de trabalho agressivo: interromper a leitura do stream tapo:// → executar o cliente ONVIF/ajustar pan e tilt → encerrar o ONVIF → reiniciar o tapo://.

• Acho que a segurança de IoT é uma bagunça no geral, e me preocupa especialmente que roteadores de consumo sejam caixas-pretas não auditáveis por onde passa todo o tráfego da rede. Muita gente nem sabe que o firmware do roteador não é atualizado há anos e já tem vulnerabilidades conhecidas. Acho que o modelo de confiança da cadeia de suprimentos de hardware de rede está completamente quebrado.

  • Concordo que a segurança de IoT é ruim. No meu caso, eu só queria que os dispositivos IoT simplesmente conectassem direito e, às vezes, até gostaria de usar exploits para burlar restrições de uso exclusivamente online. Mas também existem casos de uso legítimos para IoT com integração em nuvem, então acho que, na configuração inicial, o dispositivo deveria perguntar ao usuário qual abordagem ele quer e funcionar apenas no modo escolhido. Se precisar de MFA na nuvem, a pessoa escolhe isso; se quiser apenas controlar por programação, deveria poder deixá-lo offline.
  • Existem incontáveis roteadores entre o usuário e o destino, e não dá para monitorar todos. Como os dispositivos finais já assumem que o roteador pode estar comprometido e transmitem tudo de forma validada e criptografada, a segurança do roteador em si não parece tão importante, a menos que ele esteja sendo usado para algo indevido como DDoS ou mineração de criptomoeda.
  • A maioria das pessoas usa o roteador fornecido e configurado pelo ISP, então na prática é como conectar uma caixa-preta em outra caixa-preta. Às vezes vejo casos em que, ao conectar o Wi‑Fi, a pessoa recebe o SSID e a senha definidos pelo ISP, e isso me surpreende pelo tanto de poder que está sendo entregue ao provedor.
  • Isso vale para produtos de consumo em geral, mas com hardware prosumer como Ubiquiti ou Mikrotik dá para ter atualizações de segurança rápidas e suporte de firmware mais estável.

• Achei este post de blog excepcionalmente bem escrito. Hoje em dia, muitos textos nesse estilo parecem gerados por LLM e ficam desconfortáveis de ler, mas este me impressionou por equilibrar bem o lado técnico com uma leitura leve. (Sei que a imagem de capa foi gerada por IA, mas acho isso irrelevante para a essência do texto.)

  • Eu uso o uBlock Origin para bloquear arquivos de mídia grandes por padrão e economizar recursos. Imagens de capa muitas vezes já acabam bloqueadas e quase não têm utilidade. Acho uma pena que hoje em dia as pessoas gastem recursos para gerar isso à toa.

• Fico curioso para saber se ainda será possível continuar usando ferramentas como Frida e mitmproxy em apps Android, e o que vai acontecer quando os requisitos de assinatura entrarem em vigor no ano que vem.

  • No geral, ainda deve ser possível, mas apps que exigem attestation vão ficar bem mais difíceis. Mesmo hoje, dispositivos como os Pixel, em que OEM unlock e root são permitidos, ainda podem continuar sendo usados para desenvolvimento. Só que, nesse caso, o aparelho fica marcado como desbloqueado e falha na attestation do Google. Também imagino que ainda será possível descompactar o app, injetar o Frida e fazer sideload com uma conta de desenvolvedor, como no iOS. Mas isso também continuará sujeito a falhas de attestation e a ataques anti-tampering/anti-debugging.
  • Na verdade, não espero que essa mudança tenha impacto direto nisso, porque engenharia reversa normalmente é feita em dispositivos com root e emuladores. Em casos mais raros, quando se injeta o Frida por gadget em APKs em dispositivos sem root, deve ficar mais difícil, mas ainda deve restar o caminho de compilar e instalar APKs em modo de desenvolvedor. Se bloquearem isso completamente, o desenvolvimento de apps Android se tornaria inviável, então imagino que devam bloquear o sideload em aparelhos de usuários comuns, mas manter algo como certificados de desenvolvedor. No fim, o mais difícil deve ser a distribuição real do app; para desenvolvimento/engenharia reversa, ainda deve continuar possível. A ameaça maior é a expansão da attestation de dispositivo: mais apps podem passar a insistir agressivamente em verificar se o aparelho está sem modificações, especialmente em dispositivos com root ou não oficiais. Hoje isso aparece mais em grandes apps financeiros. Ainda é algo que afeta pouca gente (como usuários do GrapheneOS) e envolve custos extras, como manter infraestrutura de servidor, então não deve se popularizar tão fácil, mas isso pode mudar no futuro.
  • Na prática, usar Frida já não é tão simples. Para usar Frida é preciso root, e o próprio root está ficando impossível em um número cada vez maior de modelos, além de já existirem SDKs de detecção de root muito fortes e contramedidas ao Play Integrity.

• Como referência, há também The Tapo C200 Research Project e PyTapo: biblioteca Python para câmeras Tapo.

• Outro material relacionado: a análise de descriptografia de firmware da TP-Link e do bootloader da câmera em nuvem C210 V2 está aqui.

• Alguém especula se o motivo de o cachorro do autor ter saído da cama para o chão não seria o aquecedor (radiador) ligado. Parece que seriam necessários mais dados de sensores.

  • Ou talvez ele só estivesse com frio.

• Acho que chegamos a um ponto em que encontrar uma senha de administrador hardcoded já não impressiona mais ninguém.

  • Pelo que entendi, é só uma senha padrão hardcoded, não um backdoor permanente. Como o texto diz, o usuário muda a senha durante o processo de onboarding. A maioria dos apps funciona assim.
  • Acho que não há problema, porque a senha é trocada no processo normal após a instalação. O que percebi ao montar o máximo possível de dispositivos IoT/smarthome em casa nos últimos cinco anos é que quase todas as empresas vendem produtos com funcionalidades questionáveis, e que montar uma casa inteligente completa fica muito difícil se você não padronizar tudo com um único fabricante. E, mesmo assim, nenhum fabricante bom atende todas as necessidades individuais. No meu celular tenho apps da Ecobee, Lutron, Hue, vários fornecedores de câmeras, Meross, Smart Life e outros. Desses, só Lutron e Hue podem ser controlados diretamente por hub/HomeKit, então nem preciso abrir o app. Matter e Thread já existem há bastante tempo como padronização, mas ainda há um excesso de produtos Wi‑Fi baratos em vez de dispositivos compatíveis, e a maioria é ruim, só pode ser administrada por app e foi feita para empurrar o usuário para serviços em nuvem. A culpa de eu ter comprado quatro câmeras também é minha, mas na prática cada fornecedor tem seus pontos fortes, então é inevitável que o consumidor acabe dividindo as compras.
  • Não acho que uma senha de administrador hardcoded que obrigatoriamente precisa ser alterada para permitir o uso seja um grande problema.
  • Na verdade, acho que eu só estava irritado com essa tecnologia sem motivo. Aqui isso não chega a ser um problema.
  • Também existe a visão de que o smartphone é o dispositivo hostil original. Dispositivos de rede, pelo menos, ainda permitem algum nível de inspeção ou descoberta.

• Queria encontrar alguma referência organizada sobre quais modelos de câmera Tapo suportam RTSP. A C210 funciona razoavelmente bem (embora captura em nuvem não funcione) e eu a uso integrada ao frigate. Hoje comprei uma C402 (modelo externo), mas ela não tem camera account nas configurações avançadas, o que foi decepcionante. O preço baixo é atraente, mas sinto falta de consistência entre os recursos. Se alguém tiver recomendação de uma boa câmera externa barata, com suporte a stream RTSP e painel solar, aceito sugestões.

  • Mesmo que a câmera não suporte rtsp://, talvez ainda seja possível usar uma fonte de stream tapo:// no go2rtc. Deixei minha configuração do frigate aqui como referência.