Tempestade no Horizonte: Por Dentro do Ecossistema de IoT da AJCloud

Introdução

Câmeras Wi-Fi são alguns dos dispositivos de IoT mais comuns encontrados em residências, empresas e outros espaços públicos. Eles tendem a ser bastante acessíveis e oferecem aos usuários acesso fácil a uma transmissão de vídeo ao vivo em seus dispositivos móveis de qualquer lugar do planeta. Como geralmente acontece com dispositivos de IoT, a segurança tende a ser negligenciada nessas câmeras, deixando-as expostas a vulnerabilidades críticas. Se exploradas, essas vulnerabilidades podem levar a efeitos devastadores nas câmeras e nas redes nas quais elas são implantadas. Eles podem levar ao comprometimento de informações pessoais sensíveis de seus usuários.

Uma recente Elastic ON Week nos deu a oportunidade de explorar a superfície de ataque desses tipos de dispositivos para obter uma compreensão mais profunda de como eles estão sendo comprometidos. Nós nos concentramos principalmente em realizar pesquisas de vulnerabilidade na Wansview Q5 (junto com a quase idêntica Q6), uma das câmeras mais populares e acessíveis vendidas na Amazon. A Wansview é uma fornecedora de produtos de segurança sediada em Shenzhen, China, e uma das distribuidoras mais importantes de câmeras Wi-Fi da Amazon.

A Q5 oferece o mesmo conjunto de recursos básicos visto na maioria das câmeras:

Panorâmica / inclinação / zoom
Visão noturna
Áudio bidirecional
Gravação de vídeo em cartão SD
Integração com assistentes de IA de casa inteligente (por exemplo (Alexa)
ONVIF para interoperabilidade com outros produtos de segurança
RTSP para acesso direto ao feed de vídeo dentro da LAN
Atualizações automatizadas de firmware da nuvem
Suporte técnico remoto
Acesso compartilhado ao dispositivo com outras contas
Assinatura mensal opcional para armazenamento em nuvem e detecção de movimento

Como a maioria das outras câmeras Wi-Fi, esses modelos exigem uma conexão ativa com a infraestrutura de nuvem do fornecedor para operação básica; sem acesso à Internet, eles simplesmente não funcionarão. Antes que uma câmera possa entrar no ar, ela deve ser pareada a uma conta de usuário registrada por meio do aplicativo móvel oficial da Wansview e de um processo de configuração padrão baseado em código QR. Quando esse processo estiver concluído, a câmera estará totalmente online e operacional.

AJCloud: Uma breve introdução

Embora a Wansview esteja em operação desde 2009, no momento eles parecem ser principalmente revendedores de produtos de câmera fabricados por uma empresa separada sediada em Nanquim, China: AJCloud.

A AJCloud fornece aos fornecedores acesso a dispositivos de segurança fabricados, ao firmware necessário, aplicativos de usuário móveis e de desktop, à plataforma de gerenciamento de nuvem e serviços que conectam tudo. Desde que a AJCloud foi fundada em 2018, eles fizeram parcerias com vários fornecedores, grandes e pequenos, incluindo, mas não se limitando aos seguintes:

Uma análise superficial dos aplicativos móveis e de desktop desenvolvidos e publicados pela AJCloud no Google Play, na App Store da Apple e na Microsoft Store revela seus vínculos com cada um desses fornecedores. Além da marca superficial da empresa, esses aplicativos são idênticos em forma e função, e todos exigem conectividade com a plataforma de gerenciamento AJCloud.

Quanto às câmeras, é evidente que esses fornecedores estão vendendo modelos semelhantes com apenas pequenas modificações no corpo da câmera e no hardware subjacente.

A semelhança entre o Faleemi 886 e o Wansview Q6 (1080p) é óbvia

Reutilizar recursos de fabricação de hardware e desenvolvimento de software provavelmente ajuda a controlar custos e simplificar a logística para a AJCloud e seus revendedores. No entanto, essa simplificação de ativos também significa que vulnerabilidades de segurança descobertas em um modelo de câmera provavelmente afetariam todos os produtos associados ao AJCloud.

Apesar de seu papel fundamental em levar esses dispositivos aos consumidores, a AJCloud tem um perfil público relativamente baixo. No entanto, pesquisadores do IPVM publicaram recentemente uma pesquisa sobre uma vulnerabilidade significativa (que já foi resolvida) no repositório GitLab da AJCloud. Essa vulnerabilidade permitiria que qualquer usuário acessasse código-fonte, credenciais, certificados e outros dados confidenciais sem exigir autenticação.

Embora seja difícil obter números totais de vendas da Wansview e de outros fornecedores no setor de câmeras Wi-Fi, a IPVM estimou que pelo menos um milhão de dispositivos estavam conectados à plataforma AJCloud no momento da publicação do relatório. À medida que as vendas de câmeras continuam a atingir centenas de milhões, é seguro assumir que mais dispositivos da AJCloud serão conectados em lares ao redor do mundo nos próximos anos.

Esforços iniciais de pesquisa sobre vulnerabilidade

Para obter uma compreensão mais profunda da postura de segurança do Wansview Q5, nós o atacamos de vários ângulos:

No início, nossos esforços se concentraram principalmente no reconhecimento de rede ativo e passivo da câmera e da versão Android do Wansview Cloud, o aplicativo móvel oficial da Wansview. Verificamos portas abertas, espionamos comunicações de rede por meio de ataques do tipo man-in-the-middle (MitM), tentamos coagir comportamento imprevisível das câmeras por meio de configuração incorreta intencional no aplicativo e interrompemos a operação das câmeras abusando do formato do código QR e interagindo fisicamente com a câmera. Os dispositivos e sua infraestrutura foram surpreendentemente resistentes a esses tipos de ataques superficiais, e nossos esforços iniciais produziram poucos sucessos dignos de nota.

Ficamos particularmente surpresos com nossa falta de sucesso em interceptar comunicações de rede tanto na câmera quanto no aplicativo. Encontramos repetidamente recursos de segurança robustos (por exemplo, fixação de certificado, restrições de versão de aplicativo e sistema operacional e conexões TLS devidamente protegidas) que interromperam nossas tentativas.

Ferramentas de engenharia reversa nos permitiram analisar o APK muito mais de perto, embora a complexidade da ofuscação de código observada no código-fonte Java descompilado exigisse um tempo maior para ser totalmente reunido.

Nosso sucesso inicial limitado exigiria que explorássemos mais opções que nos forneceriam uma visão mais detalhada do Q5 e de como ele opera.

Hacking de hardware inicial

Para entender melhor como a câmera funcionava, decidimos analisar mais detalhadamente o firmware da câmera. Embora alguns pacotes de firmware estejam disponíveis on-line, queríamos dar uma olhada no código diretamente e poder monitorá-lo e os registros resultantes enquanto a câmera estava em execução. Para fazer isso, primeiro demos uma olhada no diagrama de hardware do sistema em um chip (SoC) para ver se havia alguma possibilidade de hardware que pudéssemos aproveitar. O Wansview Q5 usa um Ingenic Xburst T31 SoC, seu diagrama de blocos do sistema é mostrado abaixo.

Um caminho que se destacou para nós foi o bloco de E/S SPI I2Cx3/UARTx2/SPIx2. Se acessíveis, esses blocos de E/S geralmente fornecem interfaces de saída de log e/ou interfaces de shell, que podem ser usadas para depuração e interação com o SoC. Parecendo promissor, realizamos uma desmontagem do hardware da câmera e encontramos o que parecia ser uma interface serial UART para o SoC, mostrada abaixo.

Em seguida, conectamos um analisador lógico para ver qual protocolo estava sendo usado nesses pinos e, quando decodificado, o sinal era de fato UART.

Agora que podemos acessar uma interface UART exposta, procuramos estabelecer uma conexão shell com o SoC via UART. Há vários mecanismos de software diferentes para fazer isso, mas para nossos propósitos usamos o utilitário Unix screen com a taxa de transmissão detectada pelo analisador lógico.

Ao abrir e monitorar a sequência de inicialização, descobrimos que a inicialização segura não estava habilitada, apesar de ser suportada pelo SoC. Em seguida, modificamos a configuração para inicializar no modo de usuário único, fornecendo um shell root para usarmos para examinar o firmware antes que os processos de inicialização fossem executados, conforme mostrado abaixo.

Uma vez no modo de usuário único, conseguimos extrair os arquivos de firmware para análise estática usando o utilitário binwalk , conforme mostrado abaixo.

Nesse estágio, o sistema de arquivos geralmente é somente leitura; no entanto, queríamos poder fazer edições e instanciar apenas partes específicas da inicialização do firmware, conforme necessário, então fizemos algumas configurações rápidas para persistência adicional além do acesso no modo de usuário único. Isso pode ser feito de várias maneiras, mas há dois métodos principais que você pode querer usar. De modo geral, em ambas as abordagens, será necessário fazer o mínimo possível de modificações na configuração existente. Geralmente, isso é preferível ao executar análises dinâmicas, se possível, pois tivemos o menor impacto no ambiente de tempo de execução. Um método que usamos para essa abordagem é criar uma partição tmpfs para acesso de leitura/gravação na memória e montá-la via fstab. No nosso caso, fstab já foi considerado de tal forma que suportou isso e, como tal, tornou-se uma mudança mínima. Veja os comandos e resultados para esta abordagem abaixo.

Outro método é obter credenciais de usuário existentes e tentar usá-las para efetuar login. Essa abordagem também foi bem-sucedida. O hash da senha do usuário root pode ser encontrado no arquivo etc/passwd e descriptografado usando uma ferramenta como John the Ripper. Em nossos exemplos acima, estávamos transferindo dados e arquivos inteiramente pela conexão serial. A câmera também possui um slot para cartão SD disponível que pode ser montado e usado para transferir arquivos. No futuro, usaremos o cartão SD ou a rede local para mover arquivos, pois a largura de banda permite uma transferência mais rápida e fácil; no entanto, a conexão serial ainda pode ser usada para todas as comunicações para configuração e depuração de hardware, se preferir.

Agora, temos acesso root à câmera, fornecendo acesso ao firmware e aos logs do dmesg enquanto o software está em execução. Usando o firmware e os logs como referência, examinamos mais detalhadamente as interfaces de usuário da câmera para ver se havia um bom ponto de entrada que poderíamos usar para obter mais informações.

Wansview Cloud para Windows

Depois que os aplicativos móveis provaram ser mais seguros do que esperávamos inicialmente, mudamos nosso foco para uma versão mais antiga do aplicativo Wansview Cloud, criado para o Windows 7. Este aplicativo, que ainda está disponível para download, nos fornecerá uma visão direta das comunicações de rede envolvidas com câmeras conectadas à plataforma AJCloud.

Graças em grande parte ao registro de depuração excessivamente indulgente por parte dos desenvolvedores, o aplicativo do Windows revela seus segredos com uma imprudência raramente vista em software comercial. O primeiro sinal de que algo está errado é que as credenciais de login do usuário são registradas em texto simples.

A engenharia reversa do executável principal e das DLLs (que não são compactadas, ao contrário do Wansview Cloud APK) foi acelerada graças ao uso frequente de mensagens de log detalhadas contendo strings exclusivas. Identificar referências a arquivos e linhas específicas dentro de sua base de código subjacente nos ajudou a mapear rapidamente os principais componentes do aplicativo e estabelecer o fluxo de controle de alto nível.

As comunicações de rede, que eram difíceis de interceptar no Android, ainda são transmitidas por TLS, embora sejam convenientemente registradas no disco em texto simples. Com acesso total a todos os dados de solicitação e resposta HTTP POST (que são compactados em objetos JSON), não houve mais necessidade de realizar ataques MitM no lado do aplicativo.

Nas respostas do POST, encontramos metadados confidenciais, incluindo links para capturas de tela acessíveis publicamente, juntamente com informações sobre a localização da câmera, configuração de rede e sua versão de firmware.

Depois de documentar todas as solicitações e respostas POST encontradas nos dados de log, começamos a experimentar manipular campos diferentes em cada solicitação, na tentativa de acessar dados não associados à nossa câmera ou conta. Eventualmente, utilizaríamos um depurador para alterar o deviceId para o de uma câmera de destino não pareada com a conta conectada no momento. O deviceId da câmera também funciona como seu número de série e pode ser encontrado impresso em uma etiqueta adesiva localizada na parte traseira ou inferior da câmera.

Encontramos o alvo mais apropriado para nosso ataque em uma seção de código onde o deviceId é primeiro transmitido em uma solicitação POST para https://sdc-us.ajcloud.net/api/v1/dev-config:

Nosso plano era definir um ponto de interrupção na instrução destacada na captura de tela acima, trocar o deviceId na memória e então permitir que o aplicativo retomasse a execução.

Surpreendentemente, essa abordagem ingênua não só funcionou para recuperar dados confidenciais armazenados na plataforma AJCloud associados à câmera alvo e à conta à qual ela está vinculada, mas também nos conectou à própria câmera. Isso nos permitiu acessar seus fluxos de vídeo e áudio e controlá-la remotamente por meio do aplicativo, como se fosse nossa própria câmera.

Explorando essa vulnerabilidade e testando vários modelos de vários fornecedores, determinamos que todos os dispositivos conectados à plataforma AJCloud poderiam ser acessados e controlados remotamente dessa maneira. Escrevemos um script de exploração PoC para automatizar esse processo e demonstrar efetivamente a facilidade com que essa vulnerabilidade de controle de acesso na infraestrutura da AJCloud pode ser explorada de forma trivial.

Explorando as comunicações de rede

Embora tenhamos conseguido criar e acionar de forma confiável uma exploração contra uma vulnerabilidade crítica na plataforma AJCloud, precisaríamos nos aprofundar mais para entender melhor o funcionamento interno dos aplicativos, o firmware da câmera e a infraestrutura da nuvem.

À medida que exploramos além das solicitações e respostas POST observadas durante o processo de login, notamos uma infinidade de solicitações e respostas UDP de uma grande variedade de IPs. Poucos dados de texto simples discerníveis puderam ser encontrados nessas comunicações, e os números de porta UDP de destino para as solicitações de saída pareciam variar. Investigações posteriores revelariam que essa atividade UDP era indicativa de PPPP, um protocolo ponto a ponto (P2P) de IoT que foi analisado e demonstrado extensivamente por Paul Marrapesse durante sua apresentação na DEF CON 28. Mais tarde, concluímos que a maneira como exploramos a vulnerabilidade que descobrimos foi facilitada por meio de solicitações P2P modificadas, o que nos levou a explorar ainda mais o papel crítico que o P2P desempenha na plataforma AJCloud.

O principal objetivo do P2P é facilitar a comunicação entre aplicativos e dispositivos IoT, independentemente das configurações de rede envolvidas. O P2P utiliza principalmente uma abordagem baseada em perfuração UDP para criar caminhos de comunicação temporários que permitem que as solicitações cheguem ao seu destino diretamente ou por meio de um servidor de retransmissão localizado em um ambiente de rede mais acessível. O conjunto principal de comandos P2P integrados aos aplicativos da AJCloud fornece acesso a fluxos de vídeo e áudio, bem como ao microfone e panorâmica/inclinação/zoom.

Hacking avançado de hardware

Com nosso entendimento adicional das comunicações P2P, agora era hora de examinar a câmera mais de perto durante essas conversas P2P, incluindo a execução do software da câmera em um depurador. Para começar, configuramos a câmera com uma saída de registro ao vivo por meio da conexão serial UART que estabelecemos anteriormente, mostrada abaixo.

Isso forneceu uma visão ao vivo das mensagens de log dos aplicativos, bem como de quaisquer fontes de log adicionais de que precisávamos. A partir dessas informações, identificamos o binário primário usado para estabelecer a comunicação entre a câmera e a nuvem, além de fornecer as interfaces para acessar a câmera via P2P.

Este binário é chamado localmente de initApp e é executado assim que a câmera é totalmente inicializada e a sequência de inicialização é concluída. Diante disso, decidimos executar esse binário com um depurador para avaliar melhor as funções locais. Ao tentar fazer isso, encontramos um watchdog do kernel que detectava quando o initApp não estava em execução e reiniciava a câmera à força se detectasse um problema. Este watchdog verifica se há gravações em /dev/watchdog e, se essas gravações cessarem, acionará um temporizador que reinicializará a câmera se as gravações não forem retomadas. Isso torna a depuração mais difícil, pois quando se pausa a execução do initApp, as gravações no watchdog também são pausadas. Um exemplo desse comportamento de parada é mostrado abaixo:

Para evitar isso, pode-se simplesmente tentar escrever no watchdog sempre que o initApp parar para impedir a reinicialização. Entretanto, outra opção mais limpa é usar o recurso de fechamento mágico da API do Linux Kernel Watchdog Driver. Resumindo, se alguém escrever um caractere mágico específico 'V' /dev/watchdog o watchdog será desabilitado. Existem outros métodos para derrotar o watchdog, mas este foi o que escolhemos para nossa pesquisa, pois facilita habilitar e desabilitar o watchdog à vontade.

Com o watchdog desabilitado, a configuração para depurar o initApp é bastante simples. Queríamos executar o código diretamente na câmera, se possível, em vez de usar um emulador. A arquitetura da câmera é Little Endian MIPS (MIPSEL). Tivemos a sorte de que os binários pré-construídos do GDB e do GDBServer pudessem funcionar sem modificações; no entanto, não sabíamos disso inicialmente, então também configuramos uma cadeia de ferramentas para compilar o GDBServer especificamente para a câmera. Uma técnica que pode ser útil se você se encontrar em uma situação semelhante é usar uma ferramenta de compilação como o gcc para compilar algum código-fonte para sua arquitetura de destino suspeita e ver se ele roda; veja o exemplo abaixo.

No nosso caso, como conhecíamos nosso SoC, tínhamos bastante certeza da arquitetura de destino; no entanto, em certas situações, isso pode não ser tão simples de descobrir, e trabalhar com binários hello world pode ser útil para estabelecer um entendimento inicial. Depois que conseguimos compilar os binários, compilamos o GDBServer para nossa câmera e o usamos para anexar e iniciar o initApp. Depois, nos conectamos a ela a partir de outro computador na mesma rede local da câmera. Um exemplo disso é mostrado abaixo:

Como observação para o exemplo acima, estamos usando o parâmetro -x para passar alguns comandos por conveniência, mas eles não são necessários para depuração. Para mais informações sobre qualquer um dos arquivos ou comandos, consulte nosso repositório Elastic/Camera-hacks no GitHub. Para que o initApp carregasse corretamente, também precisávamos garantir que as bibliotecas usadas pelo binário fossem acessíveis por meio das variáveis de ambiente PATH e LD_LIBARY_PATH . Com essa configuração, conseguimos depurar o binário conforme necessário. Como também usamos o método do personagem mágico para derrotar o watchdog anteriormente, também precisaremos ter certeza de controlar as instâncias em que o watchdog pode ser reativado. Na maioria dos casos, não queremos que isso aconteça. Dessa forma, substituímos as chamadas do watchdog em initApp para que o watchdog não fosse reativado enquanto estávamos depurando, conforme mostrado abaixo.

O vídeo a seguir mostra o processo completo de configuração, desde a inicialização até a execução do GDBServer. No vídeo, também iniciamos um novo processo initApp e, como tal, precisamos encerrar o processo original e o script de shell daemon.sh que gerará um novo processo initApp se for encerrado.

Construindo um cliente P2P

Para explorar ainda mais a extensão total dos recursos que o P2P fornece aos dispositivos IoT da AJCloud e como eles podem ser usados indevidamente por invasores, decidimos criar nosso próprio cliente autônomo. Essa abordagem eliminaria a sobrecarga de manipulação do aplicativo Wansview Cloud para Windows, ao mesmo tempo em que nos permitiria conectar mais rapidamente às câmeras e testar os comandos que derivamos da engenharia reversa do firmware.

A partir dos dados de configuração que obtivemos anteriormente dos logs de aplicativos do Windows, sabíamos que um cliente emite solicitações para até três servidores diferentes como parte do processo de conexão. Esses servidores fornecem instruções aos clientes sobre onde o tráfego deve ser roteado para acessar uma determinada câmera. Se você quiser descobrir mais desses servidores abertamente, você pode escanear a Internet usando a seguinte carga útil UDP de quatro bytes na porta 60722. Paul Marrapese usou essa técnica com grande efeito como parte de sua pesquisa.

Para estabelecer corretamente uma conexão P2P, um cliente deve primeiro enviar uma mensagem de saudação simples (MSG_HELLO), que precisa ser confirmada (MSG_HELLO_ACK) por um servidor ponto a ponto. O cliente então consulta o servidor (MSG_P2P_REQ) para obter um deviceId específico. Se o servidor estiver ciente desse dispositivo, ele responderá (MSG_PUNCH_TO) ao cliente com um par de endereço IP de destino e número de porta UDP. O cliente tentará então se conectar (MSG_PUNCH_PKT) ao par de IP e porta junto com outras portas dentro de um intervalo predeterminado como parte de uma rotina de perfuração UDP . Se for bem-sucedido, o alvo enviará uma mensagem (MSG_PUNCH_PKT) de volta ao cliente junto com uma mensagem final (MSG_P2P_RDY) para confirmar que a conexão foi estabelecida.

Depois de conectar a uma câmera, estamos principalmente interessados em enviar diferentes pacotes MSG_DRW e observar seu comportamento. Esses pacotes contêm comandos que nos permitirão manipular fisicamente a câmera, visualizar e ouvir seus fluxos de vídeo e áudio, acessar dados armazenados nela ou alterar sua configuração. O comando mais direto com o qual começamos envolvia girar a câmera no sentido anti-horário, o que poderíamos facilmente identificar como uma única transmissão de mensagem.

As mensagens de log de depuração na câmera nos permitiram localizar facilmente onde esse comando foi processado no firmware.

Localizar a origem dessa mensagem específica nos colocou na rotina principal que lida com o processamento de mensagens MSG_DRW, o que nos forneceu uma visão crítica sobre como esse comando é invocado e quais outros comandos são suportados pelo firmware.

Engenharia reversa e testes extensivos nos permitiram construir um cliente PoC P2P que permite aos usuários se conectar a qualquer câmera na plataforma AJCloud, desde que tenham acesso ao seu deviceId. Os comandos básicos suportados pelo cliente incluem panorâmica e inclinação da câmera, reinicialização, redefinição, reprodução de clipes de áudio e até mesmo travamento do firmware.

O recurso mais perigoso que conseguimos implementar foi por meio de um comando que modifica um arquivo de configuração do dispositivo principal: /var/syscfg/config_default/app_ajy_sn.ini. Em nossa câmera de teste, o conteúdo do arquivo era originalmente o seguinte:

[common]
product_name=Q5
model=NAV
vendor=WVC
serialnum=WVCD7HUJWJNXEKXF
macaddress=
wifimacaddress=

Embora pareça conter metadados básicos do dispositivo, esse arquivo é o único meio pelo qual a câmera sabe como se identificar. Na inicialização, a câmera lê o conteúdo deste arquivo e tenta se conectar à plataforma AJCloud por meio de uma série de solicitações curl para vários pontos de extremidade da API. Essas solicitações curl passam o nome do produto, o modelo da câmera, o código do fornecedor e os valores do número de série extraídos do arquivo INI como argumentos de string de consulta. Usamos nosso cliente para entregar uma mensagem que substitui o conteúdo assim:

[common]
product_name=
model=OPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
vendor=YZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
serialnum=defghijklmnopqrstuvwxyz{|}~HH01
macaddress=
wifimacaddress=

Após a reinicialização da câmera, todas as solicitações curl emitidas para os pontos de extremidade da API da plataforma AJCloud como parte da rotina de inicialização falharão devido aos dados malformados contidos no arquivo INI. Essas solicitações continuarão sendo enviadas periodicamente, mas nunca serão bem-sucedidas e a câmera permanecerá inativa e inacessível por meio de qualquer aplicativo. Infelizmente, não há uma maneira simples de restaurar o conteúdo anterior do arquivo por meio da redefinição da câmera, atualização do firmware ou restauração das configurações de fábrica. Modificações de arquivo realizadas por meio deste comando efetivamente bloquearão a câmera e a tornarão inútil.

Observando mais de perto a função descompilada (syscfg_setAjySnParams) que substitui os valores armazenados em app_ajy_sn.ini, podemos ver que os parâmetros de entrada, extraídos do comando MSG_DRW são usados para passar dados de string que serão usados para substituir os campos de modelo, fornecedor e número de série no arquivo. memset é usado para sobrescrever três variáveis globais, destinadas a armazenar essas strings de entrada, com bytes nulos. strcpy é então usado para transferir os parâmetros de entrada para esses globais. Em cada instância, isso resultará em bytes sendo copiados diretamente do buffer de comando MSG_DRW até encontrar um caractere nulo.

Como nenhuma validação é aplicada ao comprimento desses parâmetros de entrada extraídos do comando, é trivial criar uma mensagem de comprimento suficiente que irá disparar um estouro de buffer. Embora não tenhamos aproveitado essa vulnerabilidade como parte do nosso ataque para bloquear a câmera, esta parece ser uma instância em que uma exploração poderia ser desenvolvida, o que permitiria que um invasor conseguisse executar código remotamente na câmera.

Impacto

Confirmamos que uma ampla gama de dispositivos de vários fornecedores afiliados à AJCloud e diversas versões diferentes de firmware são afetados por essas vulnerabilidades e falhas. No geral, demonstramos com sucesso nossos ataques contra quinze produtos de câmera diferentes da Wansview, Galayou, Cinnado e Faleemi. Com base em nossas descobertas, é seguro assumir que todos os dispositivos que operam o firmware AJCloud e se conectam à plataforma AJCloud são afetados.

Todas as tentativas de contato com a AJCloud e a Wansview para divulgar essas vulnerabilidades e falhas não tiveram sucesso.

O que os fornecedores fizeram certo?

Apesar das vulnerabilidades que descobrimos e discutimos anteriormente, há uma série de controles de segurança que a AJCloud e os fornecedores de câmeras implementaram bem. Para um dispositivo de baixo custo, muitas práticas recomendadas foram implementadas. Primeiro, as comunicações de rede são bem protegidas usando autenticação WebSocket baseada em certificado. Além de adicionar criptografia, colocar muitos dos endpoints da API por trás da autenticação do certificado torna os ataques do tipo man-in-the-middle significativamente mais desafiadores. Além disso, os APKs para os aplicativos móveis eram assinados e ofuscados, tornando a manipulação desses aplicativos muito demorada.

Além disso, os fornecedores também tomaram algumas decisões acertadas com o hardware e o firmware da câmera. O sistema operacional local da câmera é efetivamente limitado, concentrando-se apenas na funcionalidade necessária para o produto. O sistema de arquivos é configurado para ser somente leitura, fora do registro, e o watchdog do kernel é um método eficaz de garantir o tempo de atividade e reduzir o risco de ficar preso em um estado de falha. O SoC Ingenic Xburst T31 fornece uma plataforma capaz com uma ampla gama de suporte, incluindo inicialização segura, um watchdog Power-On Reset (POR) e um processador RISC-V separado capaz de executar algum aprendizado de máquina rudimentar na entrada da câmera.

O que os vendedores fizeram de errado?

Infelizmente, houve uma série de oportunidades perdidas com esses recursos disponíveis. O mais grave é, potencialmente, o acesso não autenticado à nuvem. Considerando os controles de acesso à API estabelecidos para muitos dos endpoints, ter os endpoints de acesso do usuário da câmera disponíveis por meio de número de série sem autenticação é um erro enorme e evitável. O protocolo P2P também é vulnerável, como mostramos, mas, comparado ao acesso à API, que deve ser imediatamente corrigível, isso pode levar mais tempo para consertar o protocolo. É uma vulnerabilidade muito perigosa, mas é um pouco mais compreensível, pois exige um investimento de tempo consideravelmente maior para ser descoberta e corrigida.

Do lado do aplicativo, o problema principal está no aplicativo do Windows, que tem um extenso registro de depuração que deveria ter sido removido antes do lançamento público. Quanto ao hardware, ele pode ser facilmente manipulado com acesso físico (botão de reset exposto, etc.). Isso não é um problema tão grande, dado o público-alvo do consumidor. Espera-se que ele peque mais na usabilidade do que na segurança, especialmente devido ao acesso físico ao dispositivo. Em uma nota semelhante, a inicialização segura deve ser habilitada, especialmente considerando que o SoC T31 a suporta. Embora não seja estritamente necessário, isso tornaria muito mais difícil depurar o código-fonte e o firmware do dispositivo diretamente, dificultando a descoberta de vulnerabilidades que possam estar presentes. O ideal seria que ele fosse implementado de tal forma que o bootloader ainda pudesse carregar um sistema operacional não assinado para permitir ajustes e desenvolvimento mais fáceis, mas impediria que o sistema operacional assinado fosse carregado até que a configuração do bootloader fosse restaurada. Entretanto, uma falha significativa no firmware atual é a dependência do número de série original, que não é armazenado em um ponto de montagem somente leitura enquanto o sistema está em execução. Manipular o número de série não deve bloquear o dispositivo permanentemente. Ele deve ter um mecanismo para solicitar um novo número de série (ou restaurar seu número de série original) caso seu número de série seja substituído, ou o número de série deve ser imutável.

Mitigações

Certas medidas podem ser tomadas para reduzir a superfície de ataque e limitar potenciais efeitos adversos no caso de um ataque, embora variem em sua eficácia.

Segmentar câmeras Wi-Fi e outros dispositivos IoT do restante da sua rede é uma contramedida altamente recomendada que evitará que invasores migrem lateralmente para sistemas mais críticos. No entanto, essa abordagem não impede que um invasor obtenha dados confidenciais do usuário explorando a vulnerabilidade de controle de acesso que descobrimos na plataforma AJCloud. Além disso, considerando a facilidade com que conseguimos demonstrar como as câmeras podem ser acessadas e manipuladas remotamente via P2P, qualquer dispositivo conectado à plataforma AJCloud ainda corre risco significativo de comprometimento, independentemente de sua configuração de rede local.

Restringir todas as comunicações de rede de e para essas câmeras não seria viável devido à importância da conectividade com a plataforma AJCloud para sua operação. Como mencionado anteriormente, os dispositivos simplesmente não funcionarão se não conseguirem se conectar a vários pontos de extremidade da API na inicialização.

Uma abordagem viável poderia ser restringir as comunicações além da rotina inicial de inicialização. No entanto, isso impediria o acesso e o controle remoto por meio de aplicativos móveis e de desktop, o que anularia todo o propósito dessas câmeras. Para mais pesquisas nesta área, consulte “Bloqueio sem interrupção: identificação e mitigação de tráfego de IoT não essencial”, que explorou essa abordagem mais profundamente em uma infinidade de dispositivos e fornecedores de IoT.

A melhor abordagem para proteger qualquer câmera Wi-Fi, independentemente do fornecedor, mantendo a funcionalidade principal, seria atualizá-la com firmware alternativo de código aberto, como OpenIPC ou thingino. A mudança para firmware de código aberto evita as dores de cabeça associadas à conectividade forçada com plataformas de nuvem de fornecedores, fornecendo aos usuários controle detalhado da configuração do dispositivo e acessibilidade remota à rede. O acesso aberto à fonte do firmware ajuda a garantir que falhas e vulnerabilidades críticas sejam rapidamente identificadas e corrigidas por colaboradores diligentes do projeto.

Principais conclusões

Nossa pesquisa revelou diversas vulnerabilidades críticas que abrangem todos os aspectos das câmeras que operam o firmware AJCloud e que estão conectadas à sua plataforma. Falhas significativas no gerenciamento de controle de acesso em sua plataforma e o protocolo PPPP peer fornece uma superfície de ataque expansiva que afeta milhões de dispositivos ativos em todo o mundo. Explorar essas falhas e vulnerabilidades leva à exposição de dados confidenciais do usuário e fornece aos invasores controle remoto total de qualquer câmera conectada à plataforma AJCloud. Além disso, um comando P2P integrado, que fornece intencionalmente acesso de gravação arbitrário a um arquivo de configuração de chave, pode ser aproveitado para desabilitar câmeras permanentemente ou facilitar a execução remota de código por meio do acionamento de um estouro de buffer.

Visite nosso repositório no GitHub para obter ferramentas e scripts personalizados que criamos, juntamente com dados e notas que capturamos e que acreditamos que trariam mais benefícios à comunidade de pesquisa de segurança.

Tempestade no Horizonte: Por Dentro do Ecossistema IoT da AJCloud