- Requisições HTTP da rede doméstica estavam sendo reproduzidas cerca de 10 segundos depois a partir de um IP da DigitalOcean, revelando indícios de que o tráfego de vários dispositivos atrás de um gateway Cox Panoramic Wifi estava exposto externamente
- O rastreamento via VirusTotal e URLscan mostrou que esse IP já havia sido ligado a domínios de phishing e a grandes volumes de domínios no formato
palavra+6 dígitos+TLD, levantando a possibilidade de um algoritmo de geração de domínios para C&C - Durante a análise do portal Cox Business em 2024, foram expostos uma API baseada em Spring e documentação Swagger atrás de
/api/cbma/, e apenas com requisições repetidas era possível contornar a validação de autorização - A API exposta permitia busca de clientes, consulta de PII de contas, consulta de endereços MAC de equipamentos e até alteração de configurações de Wi‑Fi, e a lógica de geração de
encryptedValuetambém podia ser chamada a partir do JavaScript do frontend - Após a notificação, a Cox retirou a API exposta do ar em 6 horas, mas o serviço havia começado em 2023, então a causa da invasão inicial do modem em 2021 continua sendo um caso separado
Repetição de requisições HTTP encontrada na rede doméstica
- Ao testar uma vulnerabilidade blind XXE, foi iniciado um servidor HTTP em Python em uma instância AWS, e do computador de casa foi enviada uma requisição para
/test123- A requisição original chegou a partir do IP residencial
98.161.24.100 - Cerca de 10 segundos depois, um IP desconhecido
159.65.76.209reenviou a requisição para o mesmo caminho
- A requisição original chegou a partir do IP residencial
- Ao acessar a mesma URL no Safari do iPhone, o mesmo IP voltou a reproduzir a requisição
- O mesmo comportamento se repetiu não só no computador de casa, mas também em outros dispositivos da rede doméstica
- O mesmo IP reproduziu as requisições também em uma nova instância AWS com Nginx e em uma instância GCP, reduzindo a chance de ser um problema específico da AWS
- As possibilidades restantes eram comprometimento do ISP, do modem ou do caminho de rede
- Pela consulta de propriedade do IP,
159.65.76.209era um endereço da DigitalOcean, não do ISP
Infraestrutura maliciosa anterior ligada ao IP da DigitalOcean
- Uma consulta no VirusTotal mostrou domínios anteriormente resolvidos para esse IP
- Dos 5 domínios mais recentes, 3 eram sites de phishing e 2 pareciam servidores de e‑mail
- Exemplos de domínios:
regional.adidas.com.pyisglatam.onlineisglatam.tkmx12.limit742921.tokyomx12.jingoism44769.xyz
isglatam.onlineeisglatam.tkeram sites de phishing mirando a empresa sul‑americana de cibersegurançaisglatam.com- No site real da ISG Latam, a empresa aparece como sediada no Paraguai e parceira de Crowdstrike, AppGate, Acunetix, DarkTrace e ForcePoint
- No URLscan havia rastros de que os dois domínios hospedaram um site de phishing BeEF típico
- Registro relacionado: resultado do URLscan
- O mesmo IP estava ligado a um domínio relacionado à Adidas, ao phishing da ISG Latam e à atividade que parecia reproduzir tráfego do modem
- Havia a possibilidade de o IP ter passado por vários donos, mas como o intervalo entre as atividades era grande, parecia improvável que tivesse sido imediatamente reatribuído a outro operador malicioso
Troca do modem e reinvestigação 3 anos depois
- O equipamento em uso era um gateway Cox Panoramic Wifi, e ele foi trocado por um novo modem em uma loja da Cox
- O equipamento antigo era alugado do ISP e precisava ser devolvido
- Não foi possível fazer dump do firmware nem engenharia reversa
- Depois da instalação do novo modem, o fenômeno de repetição das requisições HTTP parou completamente
- Nenhum outro IP voltou a aparecer nos logs
- Na época, era difícil ir além da conclusão de que o modem antigo havia sido comprometido
- No início de 2024, cerca de 3 anos depois, a investigação foi retomada com contatos do setor de segurança, e o formato de domínios como
limit742921.tokyoejingoism44769.xyzchamou atenção- Ao fazer reverse IP search no IP relacionado, foram encontrados mais de 1.000 domínios com o mesmo padrão
- Todos os domínios seguiam a estrutura
palavra+6 números+TLD- Pelo registro em massa e pela estrutura algorítmica, isso parecia um algoritmo de geração de domínios usado por operadores maliciosos para ocultar endereços de servidores de C&C
- O último domínio observado foi registrado em 17 de março de 2023, e depois disso não houve mais hosts resolvendo para ele
- O modem novo trocado era do mesmo modelo, mas, com base em buscas no Google, não foram encontradas vulnerabilidades públicas conhecidas para esse modelo
Hipótese a partir de ferramentas de suporte do ISP e TR-069
- Ao mover o modem da Cox para outro local, foi confirmado que atendentes de suporte do ISP podiam alterar remotamente as configurações do equipamento
- O atendente conseguia atualizar configurações do equipamento, trocar a senha do Wi‑Fi e ver dispositivos conectados
- Essa administração remota é feita pelo protocolo TR-069, implementado em 2004
- É a forma como o ISP gerencia equipamentos de sua própria rede pela porta
7547 - O protocolo já foi abordado em palestras da DEF CON, mas não era uma superfície exposta externamente
- É a forma como o ISP gerencia equipamentos de sua própria rede pela porta
- O foco da investigação saiu do protocolo em si e foi para o site interno de gerenciamento de equipamentos usado pelos atendentes e para a API por trás dele
- Se essa API pudesse consultar ou alterar configurações de equipamentos de clientes, ou executar comandos, ela poderia ser o caminho de comprometimento do modem
Estrutura da API do portal Cox Business
- O portal Cox Business oferece recursos de gerenciamento remoto de equipamentos, configuração de regras de firewall e monitoramento de tráfego de rede
- As rotas foram extraídas do arquivo JavaScript de frontend da página de login,
main.36624ed36fb0ff5b.js- Foram identificadas mais de 100 chamadas de API baseadas em
/api/cbma/ - Exemplos:
/api/cbma/voicemail/services/voicemail/inbox/transcribeMessage//api/cbma/profile/services/profile/userroles//api/cbma/accountequipment/services/accountequipment/equipments/eligibleRebootDevice
- Foram identificadas mais de 100 chamadas de API baseadas em
/api/cbma/mostrava respostas diferentes do frontend comum, parecendo um proxy reverso apontando para um backend separado- Uma requisição para
/api/anything_else/exampleretornava redirecionamento 301 - Uma requisição para
/api/cbma/exampleretornava 500 Internal Server Error
- Uma requisição para
- As requisições registradas incluíam vários cabeçalhos relacionados a autenticação
Clientid: cbmauserApikey: 5d228662-aaa1-4a18-be1c-fb84db78cf13Cb_session: unauthenticateduserAuthorization: Bearer undefined
- Ao trocar o método HTTP, retornavam respostas de erro no estilo Spring, confirmando que o backend era baseado em Spring
Documentação Swagger e bypass de recursos estáticos
- Os caminhos do Spring actuator não foram encontrados, mas parte do caminho do Swagger UI era acessível
- O caminho
/api/cbma/userauthorization/swagger-ui/index.htmlrespondia
- O caminho
- A página Swagger carregada inicialmente estava vazia
- Recursos estáticos como
.png,.jse.csseram roteados para o caminho do host original, e não para o proxy da API, causando redirecionamento infinito
- Recursos estáticos como
- Ao testar com Burp Intruder adicionando de
%00até%FFao final da URL, foi descoberto que acrescentar%2f, que é/codificado em URL, depois de.jsfazia o servidor retornar 200 OK- Exemplo:
/swagger-initializer.js%2f
- Exemplo:
- Ao usar o match-and-replace do Burp para adicionar
%2fa todos os recursos estáticos, a documentação Swagger carregou normalmente - No total, foram identificadas cerca de 700 chamadas de API
account: 115voiceutilities: 73user: 70datainternetgateway: 57accountequipment: 55billing: 53ticket: 52- além de
profile,voicecallmanagement,voicemail,userauthorization,csre outros
- As APIs mais importantes para equipamentos e contas de clientes pareciam ser
accountequipment,datainternetgatewayeaccount
Bypass de autorização com requisições repetidas
- Ao verificar se todos os endpoints GET podiam ser acessados sem autenticação, alguns retornavam erro de autenticação e outros retornavam 200 OK
- O endpoint
profilesearchinicialmente retornava uma resposta de sucesso com resultado de busca vazio- A mesma requisição às vezes retornava
Authorization Error-Invalid User Token, e ao ser enviada de novo voltava a ter sucesso
- A mesma requisição às vezes retornava
- Ao reenviar a mesma requisição várias vezes, o erro de autorização desaparecia e os resultados de busca de clientes eram retornados
- A busca por
coxretornava10000+ hits - A busca por
fbiretornava resultados com endereços físicos de escritórios de campo do FBI, clientes do Cox Business
- A busca por
- Apenas repetindo requisições à API, era possível burlar a autorização, e o mesmo problema parecia afetar mais de 700 APIs
Acesso a equipamentos de clientes e consulta de contas
- Para verificar se a API do Cox Business também conseguia acessar equipamentos de redes residenciais, foi testada uma API simples que recebe um endereço MAC
- Endpoint:
/api/cbma/accountequipment/services/accountequipment/ipAddress?macAddress=:mac
- Endpoint:
- Após verificar o endereço MAC na própria conta Cox e repetir a requisição, foi retornado o endereço IPv4 do próprio modem
- Isso confirmou que a API conseguia de fato se comunicar com equipamentos reais da Cox
- A API de lista de equipamentos por ID de conta também funcionava
- Endpoint:
/api/cbma/accountequipment/services/accountequipment/v1/equipments/{accountId} - A resposta incluía informações de equipamentos de internet, voz e TV
- Eram retornados modelo do equipamento, tipo, endereço MAC, lista de portas e número de série
- Endpoint:
- Uma API de consulta de usuário por e‑mail também retornava informações de contas business
- Exemplo de requisição:
/api/cbma/user/services/user/admin@cox.net - Incluía e‑mail, nome, telefone, status, permissões, indicador de dono do perfil e e‑mail alternativo
- Exemplo de requisição:
- Requisições POST semelhantes para atualização de conta também funcionavam, confirmando que era possível ler e escrever em contas business
encryptedValue e alteração de configuração de equipamento
- Requisições para alterar configurações de hardware exigiam um parâmetro chamado
encryptedValue- Ex.: troca de senha do equipamento, alteração de configurações de Wi‑Fi
- A lógica de geração e descriptografia de
encryptedValuefoi rastreada no JavaScript do frontendencryptWithSaltandPaddingdecryptWithSaltandPadding
- Como o PIN de 4 dígitos definido no cadastro da conta também era criptografado com a mesma função, foi possível colocar breakpoints no navegador onde essa função era chamada e invocá-la diretamente pelo console
- Ao descriptografar um
encryptedValueobtido de uma resposta real da conta, apareceu um valor no seguinte formato- número da conta Cox
- nome do equipamento
- ID do equipamento
- valor desconhecido
- endereço MAC
- rótulo
- Mesmo preenchendo a maior parte desses campos com valores arbitrários e deixando válido apenas o endereço MAC, era possível gerar um novo
encryptedValuee fazer a requisição com sucesso- O servidor não validava se o ID da conta e o endereço MAC correspondiam entre si
Possibilidade de alterar configurações de qualquer modem
- Foi enviada uma requisição POST para alterar o SSID do Wi‑Fi do próprio equipamento para
Curry- Endpoint:
/api/cbma/accountequipment/services/accountequipment/gatewaydevice/wifisettings - O corpo da requisição incluía
wifiSettings,additionalPropertieseencryptedValue
- Endpoint:
- A resposta foi
{"message": "Success"}, e depois a rede caiu brevemente e reiniciou cerca de 5 minutos depois- O SSID foi realmente alterado para
Curry
- O SSID foi realmente alterado para
- Isso demonstrou que mudanças de configuração enviadas pela API eram aplicadas de fato ao equipamento
- Um invasor poderia obter o UUID da conta por busca de clientes
- Consultar os endereços MAC dos equipamentos conectados
- E ler ou alterar configurações do equipamento com base no endereço MAC
- Esse nível de permissão era semelhante ao da equipe de suporte do ISP, criando um caminho com potencial de afetar milhões de equipamentos da Cox
Impacto e cenário de ataque
- A combinação das vulnerabilidades mostrou que um invasor externo, sem pré-requisitos, poderia fazer o seguinte
- executar comandos e alterar configurações de milhões de modems
- acessar PII de clientes do Cox Business
- obter privilégios semelhantes aos 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, a sétima maior operadora telefônica e o ISP mais popular em 10 estados
- Exemplo de fluxo de ataque:
- buscar alvos do Cox Business por nome, telefone, e‑mail e número da conta Cox
- usar o UUID retornado para consultar toda a PII da conta, além de endereço MAC do equipamento, e‑mail, telefone e endereço
- usar o MAC do hardware para consultar a senha do Wi‑Fi e os dispositivos conectados
- executar comandos arbitrários, alterar propriedades do equipamento e sequestrar a conta da vítima
- Entre as mais de 700 APIs expostas, muitas ofereciam funções administrativas, e o mesmo problema de autorização aparecia com requisições repetidas
Notificação à Cox e correção
- A vulnerabilidade foi reportada pelo programa de responsible disclosure da Cox
- A Cox retirou as chamadas de API expostas do ar em 6 horas após o reporte e iniciou o trabalho de correção da falha de autorização
- No dia seguinte, já não era mais possível reproduzir a vulnerabilidade
- Linha do tempo pública:
- 2024-03-04: vulnerabilidade reportada à Cox
- 2024-03-05: hotpatch aplicado; endpoints business não essenciais passaram a retornar 403 e deixaram de funcionar
- 2024-03-06: e‑mail enviado à Cox informando que a vulnerabilidade já não podia ser reproduzida
- 2024-03-07: a Cox respondeu que iniciaria uma revisão abrangente de segurança
- 2024-04-10: a Cox foi informada da intenção de divulgar após 90 dias do reporte
- 2024-04-29: link do rascunho do blog foi compartilhado com a Cox
Dúvidas que permaneceram
- A Cox investigou se esse caminho específico de vulnerabilidade havia sido explorado no passado e confirmou que não havia histórico de exploração
- Esse serviço começou a operar em 2023
- Como a invasão inicial do modem ocorreu em 2021, a vulnerabilidade exposta da API do Cox Business não foi a causa daquela invasão
- A Cox informou que não tinha qualquer relação com o IP da DigitalOcean
- O equipamento de fato havia sido hackeado, mas por um método diferente da vulnerabilidade de API divulgada
- O modem não havia sido configurado para acesso externo, e nunca havia sido feito login no equipamento a partir da rede doméstica
- Entre os outros caminhos possíveis, foi levantada a hipótese de algo como um 0day que ligasse CSRF local a RCE
- A maior dúvida é por que o invasor reproduzia requisições HTTP
- Se ele já estava dentro da rede, poderia ter acessado tudo sem ser notado, então o motivo de reproduzir todas as requisições HTTP continua sem explicação
1 comentários
Opiniões no Hacker News
Bom texto e fácil de acompanhar. Gostei especialmente do fato de a Cox não ter atacado quem fez a denúncia nem negado o problema, e ter agido como um exemplo de resposta de segurança responsável que se esperaria numa situação dessas.
Gostaria de ver um post de acompanhamento explicando qual era o bug que permitia acesso não autorizado à API de forma intermitente. Esse tipo de erro pode passar facilmente em testes superficiais ou, dependendo da causa, talvez nem seja reproduzível no ambiente de testes.
Já descobri por acaso uma vulnerabilidade grave em uma operadora tradicional, e, usando apenas o atendimento comum ao cliente, levei quase uma semana para chegar à pessoa responsável; a organização de suporte não conseguia escalar o caso de jeito nenhum. Na Cox também, um especialista em segurança da informação apareceu pessoalmente com um equipamento infectado, mas a organização de suporte não soube lidar com isso direito.
O irritante nesse tipo de situação é quando o ISP obriga você a usar o modem ou roteador deles. Por exemplo, a AT&T fiber usa autenticação 802.1X baseada em certificado para acesso à rede; sem isso, seria possível conectar qualquer equipamento ao ONT.
Existem, ou existiram, formas de contornar isso, mas eu não quero passar por esse processo só para usar a internet, então desativei todas as funções do roteador da AT&T e coloquei atrás dele o meu próprio roteador, que mantenho atualizado. Se o roteador da AT&T for hackeado, talvez eu nem perceba até que o serviço seja afetado negativamente. Ainda bem que hoje em dia quase tudo usa HTTPS.
Se o ONT reiniciar, é bem provável que seja preciso refazer o processo, mas no meu caso a AT&T forneceu um UPS para o ONT, então a frequência de reinicializações deve ser baixa. Pessoalmente, montei uma configuração complexa baseada em uma NIC de bypass: quando o firewall está desligado ou reiniciando, o tráfego passa pelo modem da AT&T; quando está ligado, meu firewall recebe o tráfego e o encaminha seletivamente pelo modem. Mas, na prática, usar só um switch não gerenciável já basta.
Mas meus elogios à Cox param por aí. Há 2 anos venho sofrendo com perda intermitente de pacotes e, mesmo reunindo dados indicando que um nó específico provavelmente está sobrecarregado por excesso de assinantes, não parece existir um caminho de escalonamento no suporte que leve isso a alguém capaz de entender o problema.
Na prática, o estado do 802.1X não é verificado do lado do servidor. O padrão diz que, se 802.1X for exigido e não executado, o modem não deve repassar tráfego, mas a maioria simplesmente repassa, ou pode ser alterada para fazer isso. Do lado da AT&T, eles não verificam e sempre deixam o tráfego passar; internamente, é isso que está acontecendo.
Texto muito legível e investigação excelente. Também é bom ver um caso em que uma grande empresa não joga uma bomba nuclear em cima do pesquisador de segurança.
Não tenho certeza, mas desconfio que as solicitações à interface local de administrador desse roteador Nokia não sejam autenticadas corretamente. Recebi recentemente o mesmo equipamento e havia configurações que não podiam ser alteradas com permissões comuns de administrador, e o ISP não forneceu a conta de superadministrador. Porém, ao reativar campos desabilitados pelo inspetor da página e alterar os valores, a API aceitava normalmente. Se, nesse cenário, uma aplicação puder ser executada dentro da rede interna, não parece difícil tomar controle do roteador dessa forma, embora pareça depender de condições bem específicas.
A Cox é claramente um alvo atraente, e, como no exemplo do artigo, uma única vulnerabilidade poderia colocar até um escritório de campo do FBI em risco. Acho que teria sido mais correto escrever “a Cox afirmou ter investigado” em vez de “a Cox investigou explorações anteriores e não encontrou registros”.
Dá para acreditar na afirmação de que “não houve histórico de exploração no passado”? A rede inteira parece cheia de buracos, como um queijo suíço.
Muitos roteadores exigem atualização manual do firmware. Roteadores GL.iNet tiveram várias vulnerabilidades de execução remota de código nos últimos 6 meses, então é melhor verificar rapidamente se o seu roteador não foi hackeado e, se possível, atualizar o firmware.
Do ponto de vista de um usuário comum, os sintomas visíveis eram queda na velocidade da internet, interrupções no sinal Wi‑Fi e falhas na conexão de dispositivos, além de o próprio roteador estar conectado à internet, mas a página interna de administração (192.168.8.1) não responder. No meu caso, o invasor instalou o app Pawns, da IPRoyal, transformou o roteador em um servidor proxy e ganhou dinheiro com isso; também roubou logs do sistema com tempo de uso e informações sobre conexão ao NAS, e ainda tinha um shell reverso. A melhor ordem para resolver é atualizar o firmware, redefinir o roteador para remover o malware, desativar SSH e desligar acessos remotos como DNS dinâmico. Se acesso remoto for necessário, dá para considerar Cloudflare Tunnel, Zero Trust, GoodCloud, ZeroTier, Tailscale e similares, mas não sei bem qual seria o mais adequado. A GL.iNet não segue o princípio do menor privilégio e, por padrão, executa processos como root; o SSH também vem ativado por padrão com acesso root, então parece melhor evitar
Dizer que “não havia histórico de exploração” pode significar que, desde o início, não havia logs ou materiais de auditoria suficientes, ou que os logs não ficaram preservados após o hack
Que tipo de sistema de autenticação deixa chamadas passarem aleatoriamente de vez em quando? Parece realmente incompetente
Pagaram alguma coisa? Essa pessoa basicamente salvou a Cox e avisou sobre uma tomada completa da infraestrutura de segurança que não era nada fácil de descobrir.
Parece que ela não recebeu nada por ter feito “a coisa certa”, o que é bem insultante. A forma como a empresa deve ter visto alguém aparecendo no escritório com informações importantes provavelmente era muito diferente da autoimagem dessa pessoa. Casos assim mostram bem por que nunca se deve reportar um 0day
Uma pergunta ainda em aberto é como os invasores capturaram o tráfego HTTP dele.
Alguns CPEs têm uma função parecida com um Wireshark na nuvem para depuração. Não sei se as imagens de firmware de produção da Cox incluem algo assim. Normalmente há firmwares separados para produção e teste, o que torna mais difícil testar problemas do ambiente de produção. A Cox deve conseguir verificar quais versões de firmware estão em campo; um ISP pode fazer upgrade automático de firmware que não corresponda a uma versão específica e, como é um modem da Cox, é bem provável que também tenham o firmware. Se era firmware de depuração, fico curioso para saber como foi instalado e como continuou lá
Seria fácil interceptar todos os dados da porta 80, analisar os cabeçalhos HTTP e fazer o que fosse necessário. Mas não sei bem por que alguém reproduziria as requisições
Este é um dos motivos para não comemorar modems a cabo fornecidos pelo ISP com Wi‑Fi embutido, e para cuidar bem da segurança de endpoints e serviços dentro da LAN. No mínimo, é preciso TLS e DNS over TLS no trecho modem/ISP.
Eu simplesmente deixo em modo bridge, desligo o Wi‑Fi e deixo todo o restante das funções de rede por conta do meu equipamento. O último modem alugado do ISP que usei ficou quase 10 anos sem atualização de firmware pelo ISP; por outro lado, era extremamente estável
A Free, onde trabalho, é um ISP francês e também fornece gateways domésticos na Itália por meio da Iliad; ainda atualizamos equipamentos lançados em 2011. Eles rodam o Linux 6.4 mais recente e oferecem recursos modernos como airtime QoS, atualizações de app móvel e vários recursos de software
Comprei um roteador relativamente bom, instalei OpenWrt e o conectei em bridge à rede por meio do equipamento do ISP; funciona bem. Agora uso HTTPS até dentro da LAN