Como uma tentativa de RCE por US$ 20 acabou transformando alguém, por acaso, em administrador do .mobi

 (labs.watchtowr.com)
2 pontos por GN⁺ 2024-09-12 | 1 comentários | Compartilhar no WhatsApp
  • A watchTowr Labs registrou o domínio expirado dotmobiregistry.net por cerca de US$ 20, passou a controlar o hostname do antigo servidor WHOIS de .mobi e confirmou que clientes WHOIS antigos e fluxos de validação de certificados TLS/SSL ainda confiavam nesse endereço
  • O servidor WHOIS oficial de .mobi foi migrado para whois.nic.mobi, mas muitas ferramentas continuavam consultando o endereço antigo, whois.dotmobiregistry.net, com ele hardcoded
  • Depois de implantar um servidor WHOIS temporário em 30 de agosto de 2024, até 4 de setembro chegaram mais de 135.000 sistemas únicos e 2,5 milhões de consultas, revelando como um domínio legado abandonado ainda estava amplamente conectado à infraestrutura real da internet
  • Algumas autoridades certificadoras TLS/SSL usavam validação por e-mail baseada em WHOIS para confirmar a propriedade de domínios .mobi, e num teste com a GlobalSign apareceu whois@watchtowr.com como candidato de e-mail de validação para microsoft.mobi
  • Os pesquisadores não chegaram a emitir certificados maliciosos e, depois disso, o NCSC do Reino Unido e a ShadowServer redirecionaram o domínio para um sinkhole que faz proxy das respostas legítimas de WHOIS de .mobi

Um domínio expirado de US$ 20 voltou à vida como infraestrutura WHOIS

  • O objetivo original da watchTowr Labs era encontrar uma RCE realisticamente explorável no processo em que clientes WHOIS fazem parsing das respostas do servidor
  • Nos testes iniciais, eles se passaram por um servidor WHOIS e retornaram strings longas, confirmando que alguns clientes travavam com facilidade
  • Porém, para um atacante controlar respostas WHOIS, normalmente seria preciso uma destas condições
    • um MITM para interceptar o tráfego WHOIS na camada de rede
    • acesso ao servidor WHOIS real
    • um referral WHOIS apontando para um servidor controlado pelo atacante
  • Esses pré-requisitos são uma barreira alta em ataques reais, mas a situação mudou quando o antigo domínio do servidor WHOIS de .mobi expirou
  • O servidor WHOIS de .mobi havia sido migrado de whois.dotmobiregistry.net para whois.nic.mobi, e o domínio antigo, dotmobiregistry.net, estava expirado desde por volta de dezembro de 2023
  • Depois de registrar esse domínio, a watchTowr colocou um servidor WHOIS atrás de whois.dotmobiregistry.net para verificar se clientes WHOIS com o endereço antigo hardcoded ainda continuavam consultando ali

A superfície de ataque criada pelo endereço WHOIS hardcoded

  • O WHOIS usa servidores separados por TLD, mas há pouco mecanismo padronizado para que o cliente descubra esse servidor em tempo real
  • Na prática, é comum que ferramentas WHOIS consultem uma lista em texto publicada pela IANA e hardcodem o endereço do servidor no momento do desenvolvimento
  • Quando o endereço raramente muda, o problema aparece menos, mas se ele muda e o domínio antigo expira, clientes desatualizados podem continuar consultando o endereço desativado
  • A watchTowr respondeu às requisições WHOIS que chegavam ao servidor lglass e retornou informações WHOIS falsas fazendo parecer que todos os alvos consultados pertenciam à watchTowr
  • As respostas também incluíam ASCII art e um pedido para interromper as consultas

Escala e origem das consultas observadas

  • Após implantar o servidor WHOIS em 30 de agosto de 2024, em poucas horas ele recebeu consultas de mais de 76.000 IPs de origem únicos
  • Em cerca de dois dias, o banco SQLite acumulou 1,3 milhão de consultas e, em 4 de setembro de 2024, já havia 2,5 milhões de consultas e mais de 135.000 sistemas únicos confirmados
  • Entre as origens estavam grandes registradores de domínio e sites que oferecem funcionalidade WHOIS
    • domain.com
    • godaddy.com
    • who.is
    • whois.ru
    • smallseo.tools
    • seocheki.net
    • centralops.net
    • name.com
    • webchart.org
  • Serviços de análise de segurança também usavam o antigo servidor WHOIS de .mobi
    • urlscan.io usava esse resultado WHOIS em páginas de domínios .mobi
    • VirusTotal consultava o servidor WHOIS temporário da watchTowr e exibia o resultado
  • Também foram encontrados muitos servidores de e-mail e filtros antispam
    • Filtros antispam podem fazer consultas WHOIS sobre o domínio do remetente
    • Isso incluía desde cheapsender.email até hosts que pareciam fazer parte da infraestrutura do governo de Bangladesh, como mail.bdcustoms.gov.bd
  • Endereços relacionados a .gov apareceram em vários países
    • Argentina, Paquistão, Índia, Bangladesh, Indonésia, Butão, Filipinas, Israel, Etiópia, Ucrânia, EUA
    • Exemplos ligados ao Brasil incluíam antispam.ap.gov.br e master.aneel.gov.br
  • Entre as origens .mil, apareceu como exemplo a Swedish Armed Forces
  • Também houve origens de .edu e de empresas de segurança, com menções a Group-IB, Detectify e Censys
  • Se órgãos governamentais e servidores de e-mail consultarem o servidor WHOIS sempre que receberem mensagens de domínios .mobi, surge a possibilidade de observar passivamente quem está se comunicando com quem

Vulnerabilidades em clientes WHOIS antigos e possibilidade de RCE

  • A watchTowr procurou casos anteriores de vulnerabilidades em parsing de respostas WHOIS e concluiu que, entre 26 resultados de busca por CVEs relacionadas, apenas 3 envolviam bugs acionados por respostas WHOIS malformadas
  • Essa escassez de casos pode estar ligada à percepção de que a exploração real exige pré-condições difíceis, como controlar o servidor WHOIS de um TLD
  • phpWHOIS CVE-2015-5243 é uma vulnerabilidade que permite RCE ao executar com PHP eval dados recebidos do servidor WHOIS
    • O código vulnerável fazia um escape incompleto apenas de \" na string da resposta WHOIS antes de passá-la para eval
    • A análise da Netitude mostra um payload de exemplo como ”;phpinfo();//
    • Versões vulneráveis do phpWHOIS tinham whois.dotmobiregistry.net hardcoded
  • Fail2Ban CVE-2021-32749 é uma vulnerabilidade de injeção de comando causada porque a saída do WHOIS é passada para a ferramenta mail sem higienização adequada
    • O Fail2Ban pode consultar WHOIS para incluir no e-mail ao administrador informações sobre o dono de um IP bloqueado
    • Porém, essa falha ocorre em consultas WHOIS de endereços IP, então não é alcançada diretamente apenas com o controle do servidor WHOIS de domínio .mobi obtido pela watchTowr
  • Para chegar à execução real de código, ainda seria necessário combinar clientes que consultam o antigo servidor WHOIS de .mobi com implementações vulneráveis desses clientes

Impacto até no fluxo de validação de certificados TLS/SSL

  • Algumas autoridades certificadoras TLS/SSL oferecem validação de propriedade de domínio extraindo do WHOIS o e-mail de contato administrativo e enviando para ele um link de verificação
  • Exemplos listados pela watchTowr de CAs ou revendedores que suportam validação de propriedade baseada em WHOIS incluem
    • Trustico
    • Comodo
    • SSLS
    • GoGetSSL
    • GlobalSign
    • DigiSign
    • Sectigo
  • Num teste com a GoGetSSL, ao enviar um CSR fictício para watchTowr.mobi, o whois@watchtowr.com configurado pela watchTowr não apareceu; só surgiram e-mails placeholder, indicando que o WHOIS aparentemente não havia sido resolvido com sucesso
  • Num teste com a Entrust, o registro WHOIS legítimo de microsoft.mobi foi parseado e apenas e-mails do domínio microsoft.com apareceram como candidatos de validação, enquanto watchTowr.mobi não foi parseado
  • Num teste com a GlobalSign, a princípio parecia que o registro WHOIS de microsoft.mobi não estava sendo parseado, mas isso mudou quando a watchTowr copiou o formato de saída do servidor WHOIS legítimo para microsoft.mobi e passou a servi-lo em seu próprio servidor WHOIS
  • A GlobalSign consultou o servidor WHOIS da watchTowr e extraiu whois@watchtowr.com da resposta, oferecendo esse endereço como e-mail de validação para microsoft.mobi
  • A watchTowr parou nesse ponto e não emitiu de fato nenhum certificado TLS/SSL malicioso
  • Em teoria, o fluxo de ataque seria o seguinte
    • colocar um servidor WHOIS malicioso em um hostname que antes era autoritativo
    • tentar comprar um certificado TLS/SSL para o domínio .mobi alvo
    • a autoridade certificadora consultar o WHOIS e enviar o e-mail de validação para o endereço do atacante, e não para o dono real
    • o atacante clicar no link e obter um certificado TLS/SSL para o domínio alvo
  • Com essa capacidade, seria teoricamente possível realizar ataques como interceptação de tráfego ou personificação do servidor alvo

Medidas tomadas depois e o problema que continua

  • Antes da divulgação, o NCSC do Reino Unido e a ShadowServer Foundation atuaram em conjunto
  • O domínio dotmobiregistry.net e o hostname whois.dotmobiregistry.net passaram a apontar para um sinkhole operado pela ShadowServer
  • Esse sinkhole faz proxy das respostas WHOIS legítimas para domínios .mobi
  • Também foi preparado um processo de notificação às partes afetadas
  • O caso mostra uma falha estrutural que surge quando infraestrutura legada, domínios abandonados, processamento baseado em WHOIS e procedimentos de validação de autoridades certificadoras TLS/SSL operam em conjunto
  • Um agente capaz de fazer MITM também poderia forjar dados WHOIS e tentar o mesmo tipo de ataque, e mesmo com mecanismos como transparência de certificados ainda permanecem barreiras operacionais para ataques em grande escala

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-12
Opiniões do Hacker News

  • Provavelmente houve uma combinação de erros de várias pessoas para chegar a esta situação, mas uma coisa que poderia ter impedido este ataque específico é clara: nunca deixe um domínio expirar
    O servidor WHOIS do domínio de topo .MOBI foi migrado há alguns anos de whois.dotmobiregistry.net para whois.nic.mobi, e o domínio dotmobiregistry.net parece ter sido deixado expirar por volta de dezembro de 2023
    Quando uma empresa começa a usar um novo domínio porque custa 10 dólares por ano, esse domínio se torna, na prática, um ativo pelo qual ela terá de pagar 10 dólares por ano para sempre. Um domínio que já foi associado ao negócio nunca pode ter essa ligação completamente desfeita

    • Isso é a razão mais clara de por que a Verisign é uma operadora monopolista e deveria ser regulada como um bem público, como eletricidade ou água. A ideia de que há escolha e de que não existe dependência é quase uma ilusão; quando você compra e começa a usar um domínio, fica preso a ele na prática para sempre. A Verisign também sabe disso, por isso luta desesperadamente para preservar seu monopólio
    • Até o Google já pisou na bola com isso por um breve período
      https://money.cnn.com/2016/01/29/technology/google-domain-pu...
    • Deve-se sempre usar subdomínios. Para uma empresa, um único domínio de 10 dólares por ano basta por toda a sua existência
    • Gosto desse ponto. Isso me lembra os posts do blog da Backblaze em que eles calculavam a probabilidade de tantos discos falharem a ponto de perderem dados de usuários
      No fim, acho que o valor calculado em si não era tão importante, porque a chance de esquecer o pagamento por ter perdido avisos de renovação devido a um cartão de crédito vencido ou a filtros de spam é maior
      Como as gigantes não esquecem de pagar os custos dos domínios? Será que deixam a renovação por um período quase “infinito” a cargo de registradores caros? Parece um problema de operação de negócios bem difícil

  • Tenho a sensação de que um dia vou acordar de manhã e ver a notícia de que a internet inteira desapareceu porque alguém, em um quarto de hotel num lugar remoto, fez alguma coisa com um Raspberry Pi conectado ao hotspot Wi‑Fi de um café próximo

    • Isso me lembra quando, em alojamentos universitários, alguém conectava qualquer roteador trazido de casa e detonava a internet distribuindo endereços DHCP errados. É como se isso acontecesse em escala global
    • Na prática, muita coisa mesmo está apoiada em esperança e oração [0], mas a internet foi projetada para ser robusta [1]. Neste caso, o alcance ficou limitado a .mobi
      [0] https://xkcd.com/2347/
      [1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
    • É pura coincidência que isso tenha relação com o recente “White House asks agencies to step up internet routing security efforts” [1]
      [1] https://news.ycombinator.com/item?id=41482087

  • Por que as ferramentas usam uma lista de servidores WHOIS hardcoded?
    Parece haver uma forma padronizada de registrar isso no DNS, mas, fazendo um teste simples, muitos domínios de topo não têm o registro. Um exemplo que funciona é dig _nicname._tcp.fr SRV +noall +answer, que retorna _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.
    Além disso, existe também um rascunho de internet expirado sobre isso: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

    • Só mobi.whois.arpa. CNAME whois.nic.mobi já teria resolvido o problema. Mas é difícil fazer todo mundo concordar com esse método e adotá-lo
      Como fanf2 disse abaixo, talvez bastasse consultar primeiro o servidor WHOIS da IANA. Ao consultar mobi em https://www.iana.org/whois, parte da resposta retorna whois: whois.nic.mobi
    • Na prática, existem muito mais strings hardcoded do que se imagina, e muito mais do que deveria haver
    • O WHOIS provavelmente é muito mais antigo até do que o conceito de registro SRV
    • Essas ferramentas geralmente são criadas para uma necessidade pontual e publicadas para que outras pessoas as usem ou para que o próprio autor as consulte depois. Outros “engenheiros” copiam e colam sem hesitar, e quando isso vai para o ambiente de produção vira um CVE como este
      A falta de competência dos desenvolvedores já é um problema, mas as alucinações de IA vão piorar ainda mais essa situação

  • Já vi equipes demais que não percebem que, quando começam a usar um domínio de forma significativa, precisam renová-lo praticamente até a morte térmica do universo — ou pelo menos até a morte térmica da equipe
    Seja num caso como este, seja por causa de uma URL antiga, mas importante, que ainda existe em algum lugar, seja porque um integrante da equipe se cadastrou em um serviço usando o e-mail de um domínio antigo, é muito difícil saber quando realmente se pode largar um domínio antigo

  • A superfície de ataque criada simplesmente por comprar um único domínio expirado de um servidor WHOIS antigo é realmente enorme

  • A verdadeira solução para o WHOIS é o RDAP
    Infelizmente, ele não é obrigatório para domínios de topo com código de país, e mesmo entre os domínios de topo que não são códigos de país há muitos em que ele não funciona corretamente
    https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
    https://resolve.rs/domains/rdap-missing.html

    • Como isso mitigaria os problemas descritos no artigo?

  • Um trabalho muito interessante
    O domínio dotmobiregistry.net e o nome de host whois.dotmobiregisry.net agora apontam para um sistema de sinkhole fornecido pela ShadowServer, que, segundo consta, faz proxy das respostas WHOIS legítimas do domínio .mobi
    Se esses domínios estavam destinados a ser desativados, teria sido melhor retornar algo como um 404. Deixá-los continuar funcionando como se tudo estivesse normal reduz o incentivo para migrar para o domínio oficial

    • Whois não oferece suporte a códigos de status HTTP, mas o sinkhole da ShadowServer responde assim:
      Domain not found.
      >>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<
    • Pelo texto, parece que isso já estava quebrado havia anos, e muitos clientes não perceberam

  • Acho que a própria abordagem geral da computação está fadada ao fracasso. Ela se apoia na ideia de segurança perfeita, e presume que essa segurança é alcançada por meio de verificações de SBOM e atualizações frequentes
    Mas isso simplesmente nunca vai acontecer. Só no caso do log4j, 40% de todos os downloads ainda são de versões vulneráveis. Nem é preciso falar quando uma empresa na cadeia de suprimentos fecha as portas ou deixa de manter um componente
    Assim como nosso corpo está sempre em guerra contra microrganismos, tudo inevitavelmente estará sempre cheio de bugs e brechas

    • Não, dá para escrever código bom e confiável de forma lenta, mas consistente, usar isso para criar ferramentas melhores e depois usar essas ferramentas para construir o próximo passo
      Provavelmente vai levar décadas, mas o caminho parece bastante claro. Basta investir o esforço, aplicar o conhecimento obtido em todas as “lições aprendidas” e não parar

  • No geral, gostei do clima de “a gente não queria fazer isso, mas a situação foi crescendo, e a cada etapa acabamos encontrando algo maior do que esperávamos”
    Se as pessoas que resistiram tivessem escutado e corrigido o parsing, talvez os autores do texto não precisassem ter passado por todo esse trabalho

  • Vendo pelo outro lado, será que precisamos confiar que todos os servidores WHOIS do mundo são sempre legítimos e seguros?
    Especialmente do ponto de vista de uma autoridade certificadora que faz validação TLS, ela provavelmente não gostaria de saber que, ao executar whois somethingarbitrary.ru, fica exposta a execução remota de código por causa de um servidor russo