Hackeando milhões de modems e investigando a invasão do meu modem

• Sam Curry descobriu que requisições HTTP enviadas da rede de casa eram reproduzidas 10 segundos depois a partir de um IP da DigitalOcean, e passou a suspeitar de comprometimento do modem antigo depois que o problema sumiu ao trocar o gateway Cox Panoramic Wifi
• O IP do tráfego reproduzido, 159.65.76.209, estava ligado a domínios relacionados à Adidas, domínios de phishing da ISG Latam e domínios de C&C com aparência de geração algorítmica, mas o vetor real de comprometimento não foi confirmado
• Durante a análise do portal Cox Business em 2024, foi encontrada uma API baseada em Spring atrás de /api/cbma/ com documentação Swagger, e parte de cerca de 700 APIs apresentava um problema de bypass de autorização, alternando entre erro de autenticação e 200 OK
• Esse bypass permitia pesquisar clientes, consultar PII de contas, buscar endereços MAC de equipamentos, consultar IPs de modems, ler e escrever em contas Cox Business e fazer alterações na configuração dos equipamentos, como mudar o SSID do WiFi; na PoC, o próprio SSID foi alterado para Curry
• Após o relato, a Cox tirou as APIs expostas do ar em 6 horas e, no dia seguinte, a falha já não podia mais ser reproduzida; a empresa disse que esse serviço de API começou em 2023, era separado da invasão do modem em 2021 e não havia histórico de exploração anterior

---

Tráfego estranho começando no modem de casa

• Para testar uma vulnerabilidade de blind XXE na rede doméstica, ele subiu um servidor HTTP simples em Python numa instância AWS e verificou se requisições externas estavam chegando
• Logo depois de uma requisição enviada com curl a partir do computador de casa ser registrada normalmente, um IP desconhecido, 159.65.76.209, requisitou o mesmo caminho novamente 10 segundos depois
• Quando ele acessou outro caminho pelo Safari no iPhone, o mesmo IP repetiu a mesma requisição, o que fazia parecer que não era um computador específico, mas todo o tráfego da rede doméstica que estava sendo observado
• O mesmo comportamento se repetiu em uma nova instância AWS com Nginx e depois em uma instância GCP, descartando a possibilidade de comprometimento da AWS
• Depois de devolver o gateway Cox Panoramic Wifi antigo na loja e trocar por um equipamento novo, o tráfego reproduzido desapareceu, e os logs deixaram de mostrar “outro IP”

Investigando 159.65.76.209

• Foi confirmado que o IP pertencia à DigitalOcean e não era um endereço do ISP Cox
• Nos registros do VirusTotal, 3 dos 5 domínios conectados recentemente pareciam sites de phishing, e 2 pareciam servidores de e-mail
  • regional.adidas.com.py
  • isglatam.online
  • isglatam.tk
  • mx12.limit742921.tokyo
  • mx12.jingoism44769.xyz
• isglatam.online e isglatam.tk já foram sites de phishing voltados contra a empresa sul-americana de cibersegurança isglatam.com
• Pelos registros do URLscan, os dois domínios ligados à ISG Latam hospedavam sites de phishing BeEF comuns, e os registros relacionados podem ser vistos no resultado do urlscan.io
• O mesmo IP estava associado à Adidas, à ISG Latam e à reprodução de tráfego do modem, mas não dá para descartar totalmente a possibilidade de o IP ter sido realocado entre diferentes proprietários

A análise continuou 3 anos depois

• No começo de 2024, amigos da área de segurança chamaram atenção para o formato de limit742921.tokyo e jingoism44769.xyz
• Ao fazer uma busca reversa por IP usando o IP do subdomínio mx1 de limit742921.tokyo, ele encontrou mais de 1.000 domínios com o mesmo padrão
• Todos os nomes de domínio tinham o formato [palavra][6 números].[TLD]
  • Ex.: acquire543225.biz
  • Ex.: battery935904.biz
  • Ex.: grocery634272.biz
• Pelo volume de registros e pela estrutura algorítmica, isso parecia um algoritmo de geração de domínios usado por operadores de malware para esconder endereços de servidores de C&C
• O último domínio observado foi registrado em 17 de março de 2023; naquela época ele já não resolvia mais para um host, e não foram encontrados domínios parecidos registrados no mesmo IP

Hipótese baseada em funções de gestão do ISP e TR-069

• Atendentes de suporte da Cox conseguiam atualizar o modem remotamente, trocar a senha do WiFi e ver os dispositivos conectados
• Essa gestão remota está ligada ao protocolo TR-069, implementado em 2004, por meio do qual ISPs gerenciam equipamentos da rede pela porta 7547
• O próprio TR-069 não estava exposto externamente e já havia sido abordado em apresentações da DEF CON, então o foco passou para as ferramentas de suporte e APIs internas usadas pelos atendentes
• A avaliação foi que, se um atacante quisesse comprometer modems, poderia mirar a infraestrutura por trás dessas ferramentas, especialmente APIs capazes de alterar configurações de equipamentos de clientes ou executar comandos arbitrários
• Em vez de tentar confirmar o vetor exato do comprometimento real de 2021, a investigação evoluiu para verificar a camada de confiança entre o ISP e os equipamentos dos clientes

A estrutura de APIs do portal Cox Business

• No arquivo JavaScript de frontend main.36624ed36fb0ff5b.js do portal Cox Business, foram encontradas mais de 100 chamadas de API baseadas em /api/cbma/
• O caminho /api/cbma/ respondia de forma diferente de outros caminhos /api/, parecendo uma API encaminhada por proxy para um backend separado do frontend
  • /api/anything_else/example retornava um redirecionamento
  • /api/cbma/example retornava 500 Internal Server Error
• As requisições de registro incluíam cabeçalhos como clientid, Apikey, Cb_session e Authorization, e o formato das respostas parecia vir de um backend baseado em Spring
• Ao trocar o método HTTP, surgiram respostas de erro típicas do Spring, confirmando que o backend da API era baseado em Spring
• Ele não encontrou caminhos de actuator, mas encontrou um caminho para a Swagger UI

Carregando a documentação Swagger com bypass e 700 APIs

• A Swagger UI carregava, mas os recursos estáticos entravam em loop de redirecionamento, fazendo a documentação parecer vazia
• As requisições de recursos estáticos como .js, .css e .png pareciam ser roteadas para o host padrão, e não pelo proxy da API
• Ao adicionar %2f, uma / codificada, ao fim da URL, foi possível carregar os recursos JavaScript estáticos via proxy da API
• Ao usar match-and-replace no Burp para acrescentar %2f às requisições de recursos estáticos, a documentação Swagger passou a aparecer normalmente
• No total, foram identificadas cerca de 700 chamadas de API; entre elas, as áreas mais relevantes para funções de conta e equipamento eram accountequipment, datainternetgateway e account

Bypass de autenticação e acesso a dados de clientes

• Ao repetir requisições para todos os endpoints GET, alguns retornavam erro de autenticação e outros retornavam 200 OK; em alguns casos, a mesma requisição alternava de resultado conforme era repetida
• O endpoint profilesearch inicialmente retornava resultado de busca vazio e depois passou a alternar entre erro de autenticação e resposta bem-sucedida para a mesma requisição
• Ao repetir a busca pelo termo cox, ele recebeu resultados que pareciam perfis de clientes Cox Business junto com profileGuid
• Ao buscar por fbi, a resposta trouxe resultados com endereços físicos de vários escritórios de campo do FBI que eram clientes da Cox Business
• O mesmo problema de autorização afetava outras APIs, e reproduzir requisições várias vezes permitia acessar funções administrativas mesmo sem autenticação

Consulta de endereços MAC e informações de conta

• Ao pegar o endereço MAC do próprio modem na conta Cox e colocá-lo em uma API com o parâmetro macAddress, a resposta retornou o endereço IPv4 daquele equipamento
• Isso confirmou que a API do site Cox Business conseguia realmente se comunicar com equipamentos reais
• Uma API de listagem de equipamentos por ID de conta retornava informações dos dispositivos vinculados à conta
  • categoria do equipamento
  • nome do modelo
  • endereço MAC
  • informações de portas
  • número de série
• Uma API de busca de usuário por e-mail retornava informações da conta empresarial, como nome, telefone, status, tipo de usuário, se era proprietário do perfil e e-mail alternativo
• Uma requisição POST semelhante para atualização de conta também funcionou, confirmando capacidade de leitura e escrita em contas empresariais

encryptedValue e alteração de configuração do equipamento

• Requisições para mudar configurações do equipamento exigiam o parâmetro encryptedValue
• As funções encryptWithSaltandPadding e decryptWithSaltandPadding, no JavaScript, eram usadas para criptografar e descriptografar valores com base em AES
• O PIN de 4 dígitos definido no cadastro da conta também era criptografado com a mesma função, o que permitiu capturar o contexto de execução da função no depurador do navegador
• Ao descriptografar o encryptedValue incluído na resposta de equipamento de uma conta de um conhecido que usava Cox Business, apareceram os seguintes elementos
  • número da conta Cox
  • nome do equipamento
  • ID do equipamento
  • valor desconhecido
  • endereço MAC
  • rótulo
• Mesmo ao recolocar número da conta e ID do equipamento com valores arbitrários e manter apenas o endereço MAC válido, a requisição era aceita, mostrando que o servidor não validava a correspondência entre MAC e conta

Possibilidade de alterar configurações de qualquer modem

• Ele enviou uma requisição POST para alterar o SSID do WiFi usando o endereço MAC do próprio equipamento
• A resposta foi 200 OK com Success, e em seguida a rede ficou temporariamente offline
• Cerca de 5 minutos depois, a rede reiniciou e o SSID foi alterado para Curry
• Essa PoC mostrou que a API de atualização de configuração de equipamento realmente funcionava e que um atacante poderia sobrescrever configurações de equipamentos pela API
• O nível de permissão era parecido com o do suporte técnico do ISP e poderia afetar centenas de milhares de equipamentos Cox acessíveis pela API

Escopo do impacto e fluxo de ataque possível

• A combinação de falhas criava um caminho para que um atacante externo, sem pré-requisitos, conseguisse alterar configurações de milhões de modems, acessar PII de clientes empresariais e obter permissões equivalentes às da equipe de suporte do ISP
• A Cox é a maior provedora privada de banda larga dos EUA, a terceira maior provedora de TV a cabo e a sétima maior operadora de telefonia, com milhões de clientes e sendo o ISP mais popular em 10 estados
• Um possível fluxo de ataque seria o seguinte
  • buscar alvos da Cox Business por nome, telefone, e-mail e número de conta
  • usar o UUID retornado para consultar PII da conta, endereços MAC dos equipamentos, e-mail, telefone e endereço
  • usar o endereço MAC do equipamento para consultar senha do WiFi e dispositivos conectados
  • executar comandos arbitrários, atualizar propriedades do equipamento e assumir a conta da vítima
• Havia mais de 700 APIs expostas, e muitas ofereciam funções administrativas, como listar dispositivos conectados ao modem
• Cada API sofria do mesmo problema de autorização, permitindo executar comandos não autorizados com requisições repetidas

Relato, correção e perguntas em aberto

• A vulnerabilidade foi reportada pelo programa de responsible disclosure da Cox
• Em 6 horas, a Cox tirou do ar as chamadas expostas de API e, no dia seguinte, já não era mais possível reproduzir a falha
• Segundo a investigação da Cox, não havia histórico de exploração anterior desse vetor, e o serviço vulnerável de API começou em 2023, então não poderia ter sido usado na invasão do modem em 2021
• A Cox informou que não tinha qualquer relação com o IP da DigitalOcean e, portanto, o modem antigo teria sido comprometido por outro método, e não pelo que foi divulgado neste texto
• Como o modem original foi devolvido, não foi possível fazer dump de firmware nem análise forense, e também não se descobriu por que o tráfego era reproduzido de propósito

Linha do tempo da divulgação

• 2024-03-04: vulnerabilidade reportada ao programa de divulgação responsável da Cox
• 2024-03-05: hotfix aplicado; endpoints empresariais não essenciais passaram a retornar 403 e pararam de funcionar
• 2024-03-06: e-mail enviado à Cox informando que a falha já não podia mais ser reproduzida
• 2024-03-07: a Cox respondeu que iniciaria uma revisão abrangente de segurança
• 2024-04-10: foi informado à Cox que a intenção era divulgar publicamente após 90 dias da denúncia
• 2024-04-29: link do rascunho do blog foi compartilhado com a Cox

[GN⁺]

Comentários do Hacker News

• albinowax_ postou isto primeiro, e eu me senti mal por ele não receber o karma, então movi os comentários para https://news.ycombinator.com/item?id=40560010
  Espero que xrayarx leve isso numa boa. Tenho a intenção de implementar de verdade um compartilhamento de karma para casos assim, mas, até lá, às vezes dependemos deste método manual meio tosco
  • Pelo registro do sistema, eu postei há 13 horas e ele postou há 10 horas. Então não entendo muito bem a afirmação de que ele postou primeiro.