Recentemente, um pesquisador de segurança adquiriu um smart doorbell de baixo custo em uma plataforma de comércio eletrônico chinesa, com o objetivo de investigar a segurança de dispositivos conectados de baixo preço. O dispositivo, comercializado como "Smart Doorbell X3" e controlado por um aplicativo chamado "X Smart Home", é equipado com câmera, microfone, áudio bidirecional e um receptor sub-GHz. Tais dispositivos se tornaram comuns em muitas residências.
Após um fim de semana de testes, o pesquisador conseguiu realizar três ações alarmantes:
- Roubo silencioso de acesso: Remover o doorbell da conta do proprietário sem que ele percebesse, redirecionando todas as chamadas reais para o telefone do invasor.
- Imitação de chamada: Simular um toque no dispositivo, exibindo um vídeo escolhido pelo invasor no telefone do proprietário.
- Roubo de senha Wi-Fi: Capturar a senha da rede Wi-Fi doméstica através de uma porta de depuração acessível.
Essas vulnerabilidades, que custam cerca de 12 dólares por dispositivo, permitem a compromissão de toda a rede doméstica em um único fim de semana. A primeira exploração requer apenas uma conta gratuita na plataforma, enquanto a segunda não exige nenhuma credencial adicional. O doorbell original permanece online, alheio à invasão. Essencialmente, o usuário paga para que qualquer pessoa na internet possa "tocar a campainha" de sua casa.
As falhas não residem em um componente específico, mas sim na plataforma como um todo. O doorbell se comunica com um backend sob a marca Naxclow, pertencente à Guangzhou Qiangui IoT Technology Co., Ltd. O mesmo hardware é vendido sob diversas marcas, e o mesmo fornecedor gerencia uma família de aplicativos de consumo sob a marca Naxclow. Um desses aplicativos, o V720, já foi alvo de engenharia reversa, revelando semelhanças de código com o X Smart Home. A reutilização de código-fonte e a intersecção de protocolos sugerem que o mesmo backend opera sob diferentes marcas, indicando um problema sistêmico na plataforma.
O pesquisador tentou contatar a Naxclow para reportar as vulnerabilidades, mas a empresa não possui uma página de contatos clara. Após encontrar um endereço de e-mail e testar variações, ele enviou um relatório detalhado em 29 de abril de 2026, mas não obteve resposta até o momento da publicação. O artigo é divulgado como parte de uma política de divulgação responsável, com informações confidenciais e código de exploração omitidos.
Análise Técnica Detalhada:
O sistema é composto por três partes: o doorbell (câmera, botão, microfone, alto-falante, Wi-Fi, transmissor sub-GHz), um receptor interno que emite um som e o aplicativo móvel. O hardware do doorbell é fabricado pela Shenzhen Ruilang Technology Co., Ltd, com FCC ID 2A5LK-X3PRO, aprovado em março de 2024. O chip principal é o Beken BK7252N, um módulo Wi-Fi e áudio de baixo custo, com portas JTAG e UART expostas na placa.
A comunicação sub-GHz utiliza um sinal OOK de 24 bits codificado em Princeton a 433,91 MHz, replicável por qualquer dispositivo emissor OOK. O Wi-Fi opera com RT-Thread 3.1.0 e Beken SDK.
Ao pressionar o botão, ocorrem três eventos simultâneos: um pulso sub-GHz para o receptor interno, uma requisição HTTP para o backend Naxclow que envia uma notificação ao telefone do proprietário, e, se o proprietário atender, uma chamada P2P (peer-to-peer) para áudio e vídeo.
Fase 1: Interceptação de Tráfego (MITM)
O tráfego de controle entre o doorbell e o backend Naxclow não utiliza TLS, permitindo a interceptação e análise. A requisição de notificação inclui o ID do dispositivo, um nonce e um token semelhante a uma assinatura, além de um arquivo JPG para a notificação. A resposta do servidor contém uma chave de configuração com credenciais estáticas para a chamada P2P, vinculadas ao ID do dispositivo.
O token, que muda a cada requisição, sugere uma assinatura criptográfica local. A substituição do arquivo JPG na requisição de notificação é bem-sucedida, exibindo uma imagem personalizada no telefone do proprietário, indicando que a imagem não faz parte da assinatura.
Após o envio da notificação, o dispositivo estabelece uma conexão TCP com o backend. O protocolo é binário, com um cabeçalho fixo de 20 bytes e um corpo JSON contendo comandos e parâmetros. A autenticação inicial envolve o ID do dispositivo, senha do relay e domínio. O aplicativo móvel realiza um processo similar, registrando-se no relay com seu ID de conta e token.
O relay conecta as duas partes para uma chamada P2P. A troca de parâmetros de configuração permite a conexão direta via UDP. O canal P2P, que não é criptografado, transmite quadros JPEG e amostras de áudio em tempo real, juntamente com tokens de dispositivo e conta. Qualquer pessoa interceptando este tráfego pode obter vídeo e áudio em tempo real, além das credenciais de acesso.
Fase 2: Exploração da Porta UART
A porta UART, acessível após abrir o dispositivo, permite a observação do bootloader, que exibe informações como a versão do firmware, erros de inicialização do OTA e detalhes do sistema RT-Thread. Durante a conexão Wi-Fi, o SSID, PSK e chaves de sessão WPA são expostos. Qualquer pessoa com acesso físico à porta UART pode obter as credenciais da rede Wi-Fi doméstica.
O dispositivo também expõe no UART as credenciais de configuração do backend, incluindo o IP do host relay e a senha estática do relay do dispositivo. O protocolo STUN é espelhado no UART, revelando o processo de autenticação do dispositivo e os detalhes da chamada P2P, incluindo o ID da conta, token, IPs públicos e privados do chamador e do dispositivo.
Fase 3: Acesso ao Shell RT-Thread
A porta UART também fornece acesso a um shell interativo do RT-Thread, com comandos como help, device_code, printenv, setenv, saveenv, ls, cat e fal. O comando device_code revela o UID do dispositivo, um endereço MAC separado e uma string secreta com um erro de digitação ("sercret"). A comando write_device_code permite a reescrita do ID do dispositivo sem autenticação.
O comando fal (Flash Abstraction Layer) permite a manipulação direta da memória flash. A tabela de partições revela cinco seções: bootloader, app, filesystem, param1 e netinfo, totalizando 2MB. O comando fal read permite a leitura de dados de qualquer partição. O pesquisador desenvolveu um script Python para extrair o firmware completo do dispositivo através da porta UART, contornando o modo de suspensão do dispositivo com reinicializações manuais.
O bootloader contém lógica de verificação de imagem, indicando a possibilidade de restauração de firmware de fábrica em caso de falha na verificação. A falta de um slot de atualização OTA e a exposição de informações sensíveis através de portas de depuração e protocolos não criptografados tornam esses dispositivos um risco significativo para a segurança doméstica.
