Erro de digitação no DNS da Mastercard passou quase 5 anos sem ser detectado

• A MasterCard configurou incorretamente um dos nomes de servidor DNS da Akamai que direcionam parte do tráfego de mastercard.com, usando akam.ne em vez de akam.net, e esse erro de digitação permaneceu por quase 5 anos, de 30 de junho de 2020 a 14 de janeiro de 2025
• O pesquisador de segurança Philippe Caturegli observou que akam.ne, sob o domínio de topo de código do país Níger, não estava registrado, e adquiriu o domínio por 300 dólares e cerca de 3 meses para bloquear um possível abuso
• Quando ele ativou um servidor DNS em akam.ne, passaram a chegar centenas de milhares de consultas DNS por dia de todo o mundo, e a MasterCard era o maior caso entre as organizações com o mesmo erro
• Se esse domínio tivesse sido explorado, isso poderia ter levado ao recebimento de e-mails entregues por engano, à obtenção de certificados SSL/TLS para os sites afetados e ao recebimento manual de algumas credenciais do Windows
• A MasterCard afirmou que “não houve risco para os sistemas” e corrigiu o erro, mas depois o caso evoluiu para um pedido de remoção de uma publicação no LinkedIn via Bugcrowd, deixando controvérsia sobre a forma de divulgação

---

Erro de digitação no DNS ficou quase 5 anos sem correção

• A MasterCard usa 5 servidores DNS compartilhados da Akamai para direcionar parte do tráfego da rede de mastercard.com
• De 30 de junho de 2020 a 14 de janeiro de 2025, um deles esteve configurado com um nome incorreto
  • O nome correto do servidor deveria terminar em akam.net
  • A configuração problemática apontava para akam.ne
• akam.ne é um domínio sob a gestão do domínio de topo de código do país Níger, na África Ocidental

Pesquisador registrou o domínio antes

• Philippe Caturegli, fundador da empresa de consultoria em segurança Seralys, descobriu o erro
• Caturegli presumiu que akam.ne ainda não estivesse registrado e obteve o domínio por meio do registro do Níger
  • O custo foi de 300 dólares
  • O registro levou quase 3 meses
• Ao ativar o servidor DNS, ele começou a receber diariamente centenas de milhares de consultas DNS vindas de todo o mundo
• A MasterCard não era a única organização com o mesmo erro, mas era a maior em volume de consultas recebidas

Riscos que o domínio com erro poderia causar

• Se Caturegli tivesse ativado um servidor de e-mail em akam.ne, ele poderia ter recebido e-mails entregues por engano que estavam indo para mastercard.com ou outros domínios afetados
• Se abusasse do acesso, também poderia ter conseguido certificados SSL/TLS capazes de receber e encaminhar tráfego dos sites afetados
• Também permanecia a possibilidade de receber manualmente credenciais de autenticação do Microsoft Windows a partir de computadores de funcionários
• Caturegli não tentou nenhuma dessas ações e informou à MasterCard que poderia transferir o domínio para a empresa
  • A notificação também incluiu como referência o autor do Krebs on Security

Resposta da MasterCard e da Bugcrowd

• A MasterCard reconheceu o erro algumas horas depois, mas afirmou que não houve risco real para a segurança operacional
  • “Não houve risco para os sistemas”
  • “Esse erro de digitação foi corrigido”
• Depois, Caturegli recebeu uma mensagem via Bugcrowd
  • A mensagem dizia que a divulgação feita por Caturegli no LinkedIn, após registrar akam.ne, não estava alinhada com práticas éticas de segurança
  • Também incluía que a MasterCard havia solicitado a remoção da publicação
• Caturegli respondeu que nunca havia feito o reporte por meio do programa da Bugcrowd e que informou o problema diretamente à MasterCard
• Ele afirmou que, antes de divulgar o caso, registrou os domínios afetados para impedir abuso e arcou pessoalmente com esse custo

Como o cache DNS pode ampliar o impacto

• Em geral, as organizações mantêm pelo menos 2 servidores DNS autoritativos, mas organizações com muitas consultas usam mais domínios de servidores DNS para distribuir carga
• Como a MasterCard usa 5 servidores DNS, pode parecer que um atacante controlando apenas um deles veria apenas cerca de um quinto de todas as consultas DNS
• Na prática, usuários da internet dependem de resolvedores DNS públicos como Cloudflare ou Google, o que pode ampliar o impacto
  • Basta que um resolvedor consulte o nameserver incorreto e armazene o resultado em cache
  • Se registros DNS forem configurados com TTL longo, instruções incorretas podem se espalhar por grandes provedores de nuvem
• Caturegli avalia que, com TTLs longos, o alcance do redirecionamento de tráfego pode ficar muito maior do que simplesmente um quinto

Subdomínio afetado e vestígios de registros antigos

• Em uma captura de tela divulgada por Caturegli, o servidor DNS configurado incorretamente está relacionado ao subdomínio az.mastercard.com da MasterCard
• Não está claro exatamente como esse subdomínio é usado
• Pelo padrão do nome, ele parece estar ligado a servidores de produção na nuvem Azure da Microsoft, e Caturegli afirmou que esses domínios são resolvidos para endereços de internet da Microsoft
• akam.ne já havia sido registrado anteriormente
  • Em dezembro de 2016, foi registrado por um usuário que usava o e-mail [e-mail]
  • A Yandex mostra que essa conta pertence a “Ivan I.”, de Moscou
  • Segundo o histórico manual de DNS do DomainTools.com, de 2016 a 2018 o domínio esteve conectado a um servidor de internet na Alemanha, e expirou em 2018
• Um ex-funcionário da Cloudflare vinculou, nos comentários da publicação de Caturegli no LinkedIn, um relatório sobre um caso semelhante
  • Trata-se de um caso de domínio com erro de digitação em que algumas organizações podem ter digitado o servidor DNS da AWS awsdns-06.net como awsdns-06.ne
  • Segundo o DomainTools, esse domínio com erro também foi registrado por um usuário da Yandex e hospedado no mesmo ISP alemão, Team Internet

[GN⁺]

Opiniões no Hacker News

• Nameservers publicamente registráveis, como neste caso, são apenas um subtipo relativamente raro do problema de dangling DNS; o mais comum é quando um domínio é mapeado diretamente para um endereço IP de um provedor de nuvem que o atacante pode obter
  Serviços de nuvem têm um escopo amplo e muitas vezes carecem de visibilidade global, então empresas que usam nuvem provavelmente têm esse tipo de vulnerabilidade em algum subdomínio
  Programas de bug bounty muitas vezes excluem “sequestro de subdomínio” em bloco, mas, quando encontrado, ele pode ser explorado com facilidade, e há dados internos e públicos em que informações sensíveis vazaram por causa desse tipo de erro de configuração
  O cenário atual de divulgação de vulnerabilidades torna fácil demais para empresas evitarem reconhecer vulnerabilidades reais, enquanto pesquisadores bem-intencionados, por restrições éticas e legais, têm dificuldade para apresentar o nível de prova exigido pelos provedores
  O risco de que essas vulnerabilidades permitam emitir certificados TLS com facilidade também é subestimado
  [1] https://dl.acm.org/doi/pdf/10.1145/2976749.2978387
  [2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf
  [3] https://pauley.me/post/2022/cloud-squatting/
  [4] https://arxiv.org/pdf/2204.05122

  • Além de IPs, existe uma categoria enorme de problemas envolvendo “registros DNS que apontam para recursos de nuvem compartilhados que a organização já não controla”, e quanto maior a empresa, mais disseminado isso tende a ser
    Exemplos incluem CNAMEs apontando para buckets S3 liberados, instâncias Azure Website/WebApp, registros A apontando para IPs não elásticos, nameservers Route53 que já não pertencem à conta AWS da organização, contas Heroku/Shopify/GitHub Pages apagadas ou desativadas, e registros MX apontando para domínios de provedores falidos de e-mail transacional
    As causas são a descentralização de TI, em que pessoas pouco familiarizadas criam infraestrutura e esquecem o DNS ao desmontá-la; a existência de muitas subsidiárias, marcas e organizações regionais, dificultando descobrir e aplicar políticas; a grande quantidade de sites e apps por país; e o acúmulo de fornecedores externos usados sem avisar a equipe de segurança
    Trabalho como Field CTO em uma empresa israelense de cibersegurança nessa área e, ainda ontem, conversei com uma grande fabricante de componentes de computador sobre cerca de 12 sites de apostas da Indonésia que “operam” usando seus domínios, PageRank e links; conversas assim se repetem toda semana
  • Tratar todos os casos de “sequestro de subdomínio” como inválidos em bug bounties é uma resposta genérica demais; deveria haver distinção conforme a facilidade de obter o domínio
    “Se de algum modo você sequestrar google.com, poderá comprometer usuários do Google” não é uma vulnerabilidade de segurança válida, mas, se o sequestro de um domínio não registrado ou expirado, como aqui, leva a comprometimento, isso deve ser considerado uma vulnerabilidade válida
  • A divulgação de bug bounty poderia ser mais eficaz se também fosse reportada automaticamente a órgãos governamentais como a FCC, com o e-mail da empresa em cópia
    Para rejeitar o relatório, a empresa teria de apresentar provas claras, e, se uma exploração derivada daquele relatório fosse comprovada, ou se a empresa fizesse uma alteração que impedisse que os passos de reprodução do relatório continuassem funcionando, isso poderia resultar em pagamento de recompensa ou multa
  • Em uma certa corretora de criptomoedas, endereços IP que tinham acesso a load balancers mais rápidos eram mantidos em uma allowlist, sem controles no nível da aplicação
    A pessoa alocava uma quantidade enorme de IPs na nuvem e repetia o processo até encontrar IPs antigos, obtendo muito mais capacidade do que originalmente e enviando requisições com limites de taxa mais altos
    Acho que isso já não funciona mais, e hoje é uma técnica conhecida por todos

• A parte da Bugcrowd nessa história é inesperada
  A captura de tela do e-mail parece ter vindo da “Platform Behavior Standards Team”; se for o caso, ou a Bugcrowd interpretou seus padrões de plataforma de forma ampla demais, tentando regular condutas fora da plataforma, ou a Mastercard se passou por funcionários oficiais da Bugcrowd
  Nenhuma das opções é muito aceitável
  [1] https://www.bugcrowd.com/resources/hacker-resources/platform...

  • Há uma interpretação de que plataformas de bug bounty existem não para incentivar a divulgação responsável, mas para capturá-la e bloqueá-la
    Alguém que costuma defender esse argumento provavelmente conseguiria explicá-lo melhor
  • A redação também é seriamente ruim
    Ela escreve como se já tivesse sido determinado que a pessoa cometeu uma infração, e as únicas opções são obedecer ou pedir mais explicações sobre por que aquilo é errado
    Não há oportunidade de explicar que a pessoa não fez nada errado
  • Pela minha experiência, a BugCrowd faz de tudo para atrasar e atolá-lo, impedindo que o relatório chegue de fato à empresa
    Para a empresa, isso reduz pagamentos de recompensa e custos de análise interna, além de oferecer uma negação plausível juridicamente convincente
  • Deve haver algum funcionário da Bugcrowd por aqui, então talvez possa explicar esse e-mail

• Uma resposta do tipo “não houve ameaça real” provavelmente fará com que, da próxima vez, pesquisadores de segurança invadam mais fundo esta ou outras empresas para reunir mais evidências de impacto
  Se querem permitir que o porta-voz da empresa diga “não houve problema”, precisam recompensar o suficiente para que o pesquisador aceite, mesmo com o impacto minimizado
  Mesmo parecendo que o pesquisador já agiu corretamente, pressioná-lo para abafar a notícia levanta a dúvida: havia algum motivo para uma empresa de cartão de crédito fazer isso, foi uma compreensão equivocada do trabalho por parte do pessoal de relações públicas, ou a pessoa no fim responsável pela falha de segurança da informação usou recursos da empresa para evitar constrangimento durante seu mandato?

  • Há um motivo
    Querem fazer com que pesquisadores de segurança tenham medo de divulgar seus resultados

• Alguns anos atrás, na Ucrânia, todas — ou quase todas — as transações online tinham de ser verificadas por um serviço chamado masterpass, que parecia algo como o 3DS da Mastercard.
  Mas, como costuma acontecer em sites corporativos, o certificado SSL expirou, e todas — ou quase todas — as transações online feitas com certos tipos de cartões MasterCard simplesmente pararam naquele momento.
  A Mastercard não renovou o certificado por mais de um ano; não adiantou nada eu, como cliente, nem o departamento de TI do banco entrarmos em contato, e depois eles simplesmente encerraram o serviço discretamente.
  Ao investigar, o serviço parecia ter sido escrito com tecnologias da Microsoft (IIS), a cadeia de certificados era anormalmente longa, com intermediários dos quais eu nunca tinha ouvido falar, e estava hospedado em um país de terceiro mundo bem distante da Ucrânia.

  • masterpass é a versão da Mastercard para 3DS e é usada globalmente quando uma transação parece suspeita.
    Do ponto de vista da Mastercard, parece que as transações daquele país eram consideradas suspeitas por padrão, mesmo quando todas as partes eram locais.
    Nos EUA, nunca vi isso expirar, e não sei como eles tratam o tráfego por país, mas soa como se o tráfego tivesse sido roteado para algum lugar que não era a Mastercard.

• É incômodo o fato de que akam.ne foi registrado em 2016 para um “Ivan I.”, de Moscou, usando e-mail do Yandex, ter apontado para servidores na Alemanha entre 2016 e 2018 e depois expirado.
  O trecho especialmente suspeito é que um domínio com erro de digitação, aparentemente mirando organizações que digitavam errado o servidor DNS da AWS awsdns-06.net como awsdns-06.ne, também foi registrado com uma conta Yandex e hospedado no mesmo ISP alemão, Team Internet (AS61969).

  • “Ivan I” muito provavelmente significa Ivan Ivanov, um nome comum fictício em russo, equivalente a “John Smith” em inglês.

• As afirmações “se o acesso tivesse sido explorado, teria sido possível obter certificados SSL/TLS capazes de receber e retransmitir o tráfego dos sites afetados” e “nossos sistemas não estavam em risco” não podem estar ambas corretas.
  Os dois lados têm incentivo para mentir ou exagerar.

  • Um lado tem incentivos de bilhões de dólares para mentir ou exagerar; o outro passa o dia inteiro pensando nos piores cenários com atacantes sofisticados.
    Se fosse um servidor de CS:GO, o pior ataque de um atacante sofisticado talvez fosse exagero; quando se fala de uma das maiores empresas de processamento de pagamentos do mundo, não é exagero.
  • Se você souber um mínimo sobre como certificados são emitidos, dá para perceber que o pesquisador está certo e que a MasterCard está falando bobagem.
    Dez minutos de pesquisa levam à mesma conclusão.
  • Se não houve impacto, basta autorizarem a publicação da lista completa de consultas DNS que ele capturou.
    O único motivo para não fazer isso é que essa lista daria pistas de infraestrutura a agentes mal-intencionados.
    A MasterCard está mentindo ou é ignorante e incompetente.
  • O ponto central depende muito do que az.mastercard.com realmente é e faz.
    A ideia de receber e-mails enviados para [e-mail] não parece correta; isso é apenas um subdomínio de finalidade desconhecida.
    TLS provavelmente seria possível, mas o risco depende do que esse domínio é e aparentemente não afetaria diretamente usuários que visitam mastercard.com.
  • Quando se fala em certificado SSL/TLS, a primeira coisa que vem à cabeça são provedores de certificados baseados em ACME.
    Ter controle do DNS do domínio basta, e é possível fazer isso por meio de um registro TXT ou enviando a solicitação para um servidor HTTP que você controla.

• É claramente um grande erro da Mastercard, mas permitir que exista um domínio que difere do TLD original por apenas uma letra também parece um erro em si.
  Por exemplo, casos como .com e .co, .net e .ne; é uma estrutura que cria o próprio problema.
  Se esses domínios não existissem, ninguém conseguiria registrá-los, e as requisições DNS digitadas errado simplesmente não iriam para lugar nenhum.

  • Não necessariamente.
    Erros de digitação podem acontecer não só no TLD, mas em qualquer parte do nome; e, mesmo sem erro de digitação, é possível obter tráfego de vários erros de computador por meio de bitsquatting, registrando domínios que diferem por 1 bit do nome de sites populares.
    Há artigos com exemplos.
    [1] https://en.wikipedia.org/wiki/Bitsquatting
    [2] https://www.securitee.org/files/bitsquatting_www2013.pdf
  • Eu esperaria que uma grande empresa lidasse com isso via Markmonitor.
    Basicamente, é a prática de registrar junto, sempre que possível, domínios com erros de digitação a uma distância de edição 1.
    Segundo a Wikipedia, a Akamai é uma das clientes da Markmonitor, então é surpreendente que esse domínio ainda não estivesse registrado.
  • A questão é o que pretendem fazer com os códigos ISO 3166-2 do Níger e da Colômbia.
  • Não vejo como isso é diferente de existir um número de telefone que difere por apenas um dígito de um número sensível.
  • TLDs ISO 3166-1 alpha-2 são obviamente úteis, mas, pela natureza do espaço de endereços, muitos erros de digitação de uma letra acontecem.
    Domínios que não são códigos de país também podem coincidir com formas de TLDs de código de país com uma letra faltando, então não há uma diferença enorme.
    Ainda assim, esse tipo de erro de configuração poderia ser detectado por uma boa ferramenta de verificação de DNS.
    Isso apareceria, por exemplo, quando um dos nameservers registrados não resolve, ou quando os nameservers não retornam o mesmo número de série da zona ou as mesmas respostas reais.
    Em .is, para registrar um domínio era preciso fornecer dois nameservers funcionando corretamente, mas .com já não é tão exigente assim.

• Esse nome de domínio deveria ter sido entregue à akamai.
  Outras requisições também chegam ao mesmo endereço, e a akamai deveria lidar com isso de forma responsável.

• “Nós nos investigamos e concluímos que não fizemos nada errado” é a resposta clássica.
  A Mastercard é uma empresa aberta de bilhões de dólares, com pelo menos 3,4 bilhões de cartões com sua marca no mundo, e processou 44,3 bilhões de transações globais de crédito, débito e dinheiro no 3º trimestre de 2024.
  Admitir um erro pode prejudicar a empresa no curto prazo no mercado, mas uma cultura de negação destrói a cultura corporativa.
  Não é diferente da ClownStrike, e já está na hora de chegar alguma turbulência para essas redes predatórias e parasitárias de crédito e débito.

• Frases do tipo “o erro de digitação foi corrigido e não houve risco para os sistemas” são sempre a mesma coisa, e esse tipo de declaração dá muita raiva

  • O cálculo deles deve ser este:
    admitir o problema pode fazer a ação perder milhões de dólares, mas negar só faz alguns nerds reclamarem um pouco mais
    sem evidências de comprometimento, é difícil obrigá-los a agir; com evidências de comprometimento, eles acabam indo para a cadeia
  • O significado real está mais para “conversamos com um funcionário do departamento de TI que não sabia de nada, que tinha um incentivo pessoal para não procurar a exposição e não conseguiu imaginar uma forma de exploração em 15 segundos”
    quem entende do assunto raramente se sente seguro o bastante para afirmar categoricamente que algo não pode ser explorado