Por mais de 4 anos, a infraestrutura da MasterCard permaneceu vulnerável devido a um bug que permitiu que seu servidor DNS fosse falsificado. Esta falha foi detectada por um especialista em segurança da Seralys, que menciona que o problema teve origem de um erro de digitação na configuração da infraestrutura de pagamento da MasterCard, já que o DNSSEC não está implementado.
Desde junho de 2020, na lista de servidores DNS responsáveis pelo gerenciamento da zona, em vez de incluir corretamente “a22-65.akam.net” da Akamai, "a22-65.akam.ne" foi registrado incorretamente. Este pequeno erro acabou sendo significativo, pois “.ne” corresponde ao domínio de nível superior da República do Níger e “akam.ne” estava disponível para compra.
Isso significa que, Por mais de quatro anos, qualquer pessoa poderia ter adquirido “akam.ne”, Configurado um servidor DNS e manipulado a zona DNS da Mastercard e redirecionar tráfego legítimo de qualquer subdomínio do site para servidores maliciosos. Além disso, como a Mastercard não implementou o DNSSEC, uma medida de segurança que protege a integridade dos registros DNS, um invasor teria conseguido manipular pelo menos um quinto do tráfego do domínio, já que a falha afetou um dos cinco servidores DNS registrados. .
Para verificar o impacto da vulnerabilidade, O pesquisador comprou o domínio por US$ 300 e implantou no um sniffer de DNS com o objetivo de analisar o volume de tráfego direcionado para aquele endereço. Os resultados revelaram que a MasterCard não foi a única afetada, pois outras zonas de domínio também tinham o mesmo erro de digitação, redirecionando o tráfego para “akam.ne” em vez de “akam.net”. Além disso, foi descoberto que entre 2015 e 2018, esse domínio foi registrado e possivelmente usado para fins maliciosos.. A suspeita de que ele foi usado em ataques é reforçada pelo fato de seu antigo dono também ter registrado “awsdns-06.ne”, cuja estrutura imita “awsdns-06.net”, um servidor DNS legítimo da Amazon Web Services.
Esses tipos de falhas podem passar despercebidos por longos períodos, já que a configuração de vários servidores DNS garante tolerância a falhas. Nesse caso, A MasterCard inicialmente ignorou a notificação do pesquisador sobre o problema. No entanto, Após a intervenção do jornalista Brian Krebs, a empresa reconheceu a vulnerabilidade e a corrigiu., embora tenha minimizado sua gravidade ao afirmar que não representava um risco à infraestrutura. Posteriormente, a MasterCard solicitou a remoção do relatório público sobre o incidente por meio do Bugcrowd, uma plataforma que gerencia recompensas pela identificação de vulnerabilidades.
Para confirmar que o erro não representava um perigo significativo, apresentou estatísticas de consultas DNS recebidas, onde foram identificadas solicitações direcionadas a domínios do tipo *.az.mastercard.com. Esses domínios estavam vinculados a componentes hospedados na nuvem Microsoft Azure, indicando que seu comprometimento poderia ter tido consequências sérias para a segurança da infraestrutura da MasterCard.
El O impacto potencial deste erro é significativo, como permitiu que qualquer pessoa controlasse um dos cinco servidores DNS, um invasor poderia ter desviado pelo menos 20% do tráfego destinado à Mastercard. Além disso, ao definir um TTL (Time to Live) alto na zona DNS falsificada, os registros maliciosos podem permanecer armazenados em cache por mais tempo em resolvedores públicos, como os da Cloudflare ou do Google, expandindo o alcance do ataque. Isso não apenas permitiria a interceptação de tráfego, mas também a criação de subdomínios fraudulentos para campanhas de phishing.
Além disso, O controle sobre um dos servidores DNS teria facilitado a obtenção de certificados TLS válidos por meio de serviços como o Let's Encrypt, que verifica a propriedade do domínio usando DNS. Isso abriria a porta para ataques mais sofisticados, como a criação de servidores de e-mail falsos. para interceptar comunicações enviadas para endereços @mastercard.com ou capturar credenciais de autenticação de funcionários usando Windows.
FinalizaçãoE, vale ressaltar que o pesquisador Ele esclareceu que embora tivesse uma conta no Bugcrowd, nunca pediu nenhuma recompensa por sua descoberta e que sua intenção ao publicar o relatório era simplesmente alertar sobre o problema depois que ele já havia sido mitigado e o domínio estava sob seu controle. Apesar de tomar medidas para proteger a empresa de um possível ataque, Ele não recebeu indenização pelos US$ 300 que gastou. ao comprar o domínio, nem mesmo reconhecimento pelo seu trabalho.