tezeb/accflyDivulgação de vulnerabilidades da câmera Accfly: CVE-2020-25782, CVE-2020-25783, CVE-2020-25784, CVE-2020-25785.
No início de 2020, no meu antigo local de trabalho, tive a oportunidade de participar de um evento interno no estilo pwn2own. Havia vários alvos disponíveis, mas o que mais me interessou foi a câmera de segurança sem fio Accfly. Infelizmente, não consegui terminar minha pesquisa a tempo para o evento, mas como ninguém mais tentou atacar este dispositivo, continuei com ela.
O foco principal da pesquisa foram vulnerabilidades que pudessem levar à execução remota de código (RCE). Esse tipo de vulnerabilidade permite que um invasor assuma o controle total do dispositivo e, no caso de uma câmera de vídeo, pode resultar em um comprometimento completo da privacidade do proprietário. Infelizmente, descobriu-se que o firmware do dispositivo está repleto de tais problemas.
Primeiramente, o dispositivo não fornece nenhuma autenticação. Como resultado, um invasor capaz de se conectar a ele pode acessá-lo e reconfigurá-lo livremente. Na forma mais simples, é possível reiniciar continuamente o dispositivo, tornando-o completamente inutilizável para o usuário legítimo. O escopo desse ataque é um pouco limitado, pois o dispositivo foi projetado para ser usado dentro de uma rede WiFi, geralmente atrás de NAT, portanto, não diretamente acessível pela Internet. No entanto, a falta de criptografia entre o dispositivo e o aplicativo do smartphone do proprietário, juntamente com o uso do servidor do fabricante como proxy para a comunicação, cria uma oportunidade para ataques MitM ou de manipulação de DNS, que podem romper a restrição WiFi/NAT.
Além disso, o aplicativo usa um protocolo binário proprietário para comunicação. Ele foi implementado em uma mistura de C e C++ e descobriu-se que está cheio de funções inseguras de manipulação de strings. O executável principal contém uma enorme quantidade de código não utilizado, o que sugere que ele é reutilizado em outros dispositivos. Isso dificulta a manutenção e aumenta a superfície de ataque. O aplicativo não habilita nenhum mecanismo de segurança moderno, que o protegeria contra muitas técnicas comuns de exploração. Além disso, ele nem sequer limita as permissões do usuário, sendo executado como root — com os privilégios mais altos disponíveis.
Como resultado desta pesquisa, as quatro vulnerabilidades a seguir foram documentadas.
CNetClientManage::ServerIP_Proto_Set no tratamento de mensagens recebidasCNetClientTalk::OprMsg no tratamento de mensagens recebidasCNetClientGuard::SubOprMsg no tratamento de mensagens recebidasCFtpProtocol::FtpLogin durante o procedimento de atualizaçãoPara três delas, foram desenvolvidos exploits de RCE, que permitem que um invasor obtenha controle total sobre o dispositivo. No entanto, devido à falta de resposta do fabricante às tentativas de relato de vulnerabilidade, este repositório contém apenas PoCs limitados, que apenas travam o aplicativo.
Os problemas foram encontrados na versão de software V3.10.73 e verificados na versão V4.15.77, a mais recente disponível no momento desta publicação (26 de janeiro de 2021).
Em caso de dúvidas, não hesite em me contatar por e-mail (veja o commit do git) ou através de issues do Github. Se você tem um dispositivo IoT que acha que pode ser interessante para hackear, está procurando um Pesquisador de Segurança ou apenas quer dar um oi, ficarei feliz em ouvir de você. Você também pode me pagar um café!
O dispositivo alvo é uma câmera de vídeo controlada pelo aplicativo móvel acompanhante. Minha análise começou com o tráfego de rede da câmera e continuou pelo firmware da câmera. Um protocolo binário personalizado é usado para toda a comunicação. Os comandos são enviados diretamente ao dispositivo móvel quando na mesma rede ou passam pelo servidor do fabricante do dispositivo. O software da câmera escuta em várias portas TCP (23456,34567) e UDP (34568, 34569). Não há criptografia nem autenticação para o tráfego de rede, o que permite ataques MitM ou acesso direto quando a câmera está exposta na rede. Parece provável que o acesso ao fluxo de vídeo também seja possível sem autenticação, mas não fiz engenharia reversa suficiente do protocolo proprietário para testar isso.
Após uma breve visão geral da comunicação, o próximo passo foi tentar obter acesso ao firmware do dispositivo. Minha primeira tentativa foi baixá-lo diretamente sequestrando o processo de atualização do dispositivo, mas nada disso apareceu no tráfego de rede. Eu teria ficado preso nessa etapa, não fosse a ajuda muito necessária de um colega que extraiu o firmware da memória flash, o que me permitiu continuar com esta pesquisa.
Descobriu-se que o firmware estava rodando Linux em CPU MIPS little-endian. Há exatamente um processo interessante, chamado Alloca, que é responsável pela captura de vídeo e também lida com todas as comunicações de rede. O aplicativo é criado em C++ e contém muito código que não é utilizado neste dispositivo. Isso indica que o mesmo software é usado em diferentes dispositivos também.
Embora esse problema tenha sido encontrado por último, ele é crucial para a exploração real da maioria dos outros, porque eles decorrem do uso de funções inseguras de string da linguagem C. Embora existam várias técnicas que podem ser usadas para execução bem-sucedida de código em cenários semelhantes, o aplicativo é criado de tal forma que elas são praticamente inúteis. O principal problema é que o código e os dados de Alloca são alocados estaticamente em endereços baixos ( < 0x01000000). Assim, tentativas de reutilizar código existente (isto é, ROP e similares) não são úteis, pois exigem a capacidade de escrever endereços na memória do programa. Como as strings da linguagem C usam \x00 como caractere de terminação, e as funções de string encerram o processamento no primeiro byte desse tipo, não é possível usar mais de um único byte NULL. Além disso, a localização da pilha é aleatória e o aplicativo é fortemente multithread, o que torna outras técnicas muito menos confiáveis.
Essa vulnerabilidade é resultado do compartilhamento de dados entre várias threads e do uso inseguro de strcpy. Embora eu tenha analisado esse problema específico por muito tempo, não percebi a chance de usá-lo como vetor de vazamento de dados até apenas algumas semanas antes desta publicação. Curiosamente, graças ao vazamento do endereço de heap de um objeto C++, essa vulnerabilidade também permite a execução remota de código. No entanto, esse ataque não está incluído neste relatório.
O aplicativo Alloca pode se atualizar via FTP. Essa operação pode ser solicitada por um servidor, que também fornece o nome de usuário, senha e nome do arquivo necessários. A função que inicia a atualização é mostrada aqui:
