Hackeando milhões de modems e investigando quem hackeou o meu modem

• Há 2 anos, enquanto fazia testes de vulnerabilidade em casa, vivi algo estranho
• Subi um servidor HTTP em uma instância da AWS para buscar um arquivo de um servidor vulnerável
• Tudo parecia configurado corretamente, mas no momento em que eu ia voltar ao teste de vulnerabilidade, apareceu um log inesperado
• Alguém interceptou a mesma requisição HTTP entre minha rede doméstica e a instância da AWS e a reenviou 10 segundos depois
• Esse tráfego deveria ser inacessível e não deveria haver nenhum intermediário
• Meu pensamento imediato foi que meu computador tinha sido hackeado e que um invasor estava monitorando ativamente o tráfego
• Verifiquei se o mesmo fenômeno acontecia no iPhone, e um endereço IP desconhecido interceptava e reenviava tanto as requisições HTTP do computador quanto as do iPhone
• Parecia mais provável que ISP, modem ou AWS tivessem sido comprometidos
• Para descartar a ideia absurda de que a AWS havia sido hackeada, subi uma instância no GCP e o mesmo fenômeno ocorreu
• A única possibilidade restante era que o modem tivesse sido hackeado, mas quem seria o atacante? Ao consultar o proprietário do endereço IP, vi que ele pertencia à DigitalOcean
• Esse IP havia sido usado nos últimos anos para vários sites de phishing e servidores de e-mail
• Como o dispositivo comprometido continuava funcionando, desliguei-o da tomada e o guardei em uma caixa
• Fui a uma loja da Cox, devolvi o modem comprometido e recebi um novo
• Depois de instalar o novo modem, o comportamento estranho parou, mas eu ainda não sabia exatamente como o modem havia sido comprometido
• Três anos depois, durante férias com amigos especialistas em segurança, acabei contando esse caso, e eles se interessaram e começaram a investigar
• Ao examinar os domínios registrados por aquele endereço IP, encontraram uma grande quantidade de domínios gerados algoritmicamente, sugerindo um servidor de C&C
• O atacante realizava várias atividades maliciosas a partir do mesmo IP, mas não havia sido derrubado em 3 anos. Era difícil entender sua intenção
• Como o novo modem era do mesmo modelo, também considerei a possibilidade de o atacante tê-lo comprometido novamente
• Chamou atenção o fato de que, por meio do protocolo TR-069, o ISP pode gerenciar os dispositivos. Se a infraestrutura das ferramentas de suporte fosse atacada, seria possível assumir o controle dos modems
• Ao analisar o JavaScript do portal empresarial da Cox, foram descobertos mais de 700 caminhos de API. Entre eles, as APIs com mais funções de acesso a equipamentos e contas de clientes eram accountequipment, datainternetgateway e account
• Foi encontrada uma vulnerabilidade que permitia contornar a autenticação. Reenviando repetidamente requisições HTTP, era possível executar comandos sem autorização
• Confirmou-se que era possível se comunicar diretamente com o equipamento de qualquer pessoa usando o endereço MAC. A Cox atende milhões de clientes
• Foi demonstrado que era possível sobrescrever configurações do equipamento, acessar o roteador e executar comandos no dispositivo, obtendo privilégios semelhantes aos da equipe de suporte técnico do ISP
• Trata-se de uma vulnerabilidade que, sem pré-requisitos, permitiria alterar as configurações de milhões de modems, acessar PII de clientes e obter privilégios no nível da equipe de suporte do ISP
• O cenário de incidente seria o seguinte
  1. Buscar clientes empresariais da Cox via API
  2. Obter PII do cliente, como endereço MAC do equipamento, e-mail, telefone e endereço, usando o UUID
  3. Consultar a senha do Wi‑Fi e os dispositivos conectados pelo endereço MAC
  4. Executar comandos arbitrários, alterar propriedades do equipamento e sequestrar a conta
• A vulnerabilidade foi reportada à Cox, que bloqueou a API em 6 horas e começou a corrigir o problema de autenticação
• Entre as mais de 700 APIs expostas, muitas forneciam funções administrativas, e todas tinham o mesmo problema de permissões
• Este caso mostra a fragilidade da camada de confiança entre o ISP e os equipamentos dos clientes
• Ainda continuo curioso sobre como exatamente meu modem foi hackeado. Também não consigo entender por que o atacante retransmitia o tráfego
• Teorias ou opiniões relacionadas são bem-vindas

Opinião do GN⁺

• Vulnerabilidade de segurança: este artigo mostra quão grave pode ser o impacto de falhas de segurança em um ISP. Em especial, recursos que permitem alterar remotamente as configurações dos dispositivos podem ser explorados de forma maliciosa.
• Segurança de API: reforça a importância da segurança de APIs. Vulnerabilidades como bypass de autenticação podem causar problemas de segurança sérios.
• Proteção de dados do usuário: alerta para o risco de informações pessoais dos clientes e configurações dos dispositivos serem expostas com facilidade. ISPs devem adotar medidas de segurança mais fortes para proteger esses dados.
• Compreensão técnica: ao explicar os detalhes técnicos de forma que até engenheiros de software iniciantes possam entender, o texto ajuda a aprender como detectar e corrigir vulnerabilidades de segurança.
• Apresentação de alternativas: para resolver problemas como esse, é importante usar equipamentos de rede e protocolos de segurança mais seguros. Vale considerar outros ISPs ou soluções de segurança.

[GN⁺]

Comentários do Hacker News

• É impressionante que a Cox tenha respondido com responsabilidade, sem negar o problema nem atacar o mensageiro. Gostaria de ler uma matéria de acompanhamento explicando qual foi o bug.
• É incômodo quando o ISP força o uso do seu próprio modem ou roteador. Meu roteador da AT&T pode até ser hackeado, mas felizmente existe HTTPS.
• Foi uma excelente matéria e investigação. Parece que a interface local de administrador do roteador da Nokia não faz autenticação corretamente. Não era possível alterar certas configurações, mas dava para modificar a página e alterá-las.
• Muitos roteadores exigem atualização manual de firmware. Os roteadores da GL.iNet tiveram recentemente uma vulnerabilidade de RCE. É recomendável atualizar o firmware e tomar medidas como desativar o acesso por SSH.
• Ainda me pergunto como o atacante interceptou o tráfego HTTP. A Cox provavelmente consegue verificar a versão do firmware e corrigir o problema por meio de atualização automática.
• A Cox afirma que essa vulnerabilidade nunca foi explorada no passado, mas é difícil confiar nisso. A rede parece muito frágil.
• É chocante que uma vulnerabilidade tão grande tenha sido descoberta em uma grande empresa de tecnologia. A matéria é excelente, mas essa vulnerabilidade é imperdoável.
• Fico curioso para saber se houve alguma recompensa para quem relatou a vulnerabilidade. Ele fez uma grande contribuição, mas parece não ter recebido nada. Isso é muito insultante.
• A Cox provavelmente afirma que isso nunca foi explorado no passado porque faltam logs ou dados de auditoria.
• O conteúdo da matéria é excelente, mas um atacante determinado poderia se passar por um técnico da Cox para obter acesso. O ISP deveria implementar uma configuração que desative o acesso remoto por padrão.