Une faute de frappe DNS chez MasterCard est restée inaperçue pendant près de cinq ans

• MasterCard avait mal configuré un nom de serveur DNS Akamai qui oriente une partie du trafic de mastercard.com, en mettant akam.ne au lieu de akam.net, et cette faute de frappe est restée en place pendant près de 5 ans, du 30 juin 2020 au 14 janvier 2025
• Le chercheur en sécurité Philippe Caturegli a constaté que akam.ne, sous le domaine national de premier niveau du Niger, n’était pas enregistré, et a sécurisé le domaine pour empêcher tout abus, au prix de 300 dollars et d’environ 3 mois d’attente
• Une fois le serveur DNS activé sur akam.ne, il a reçu des centaines de milliers de requêtes DNS par jour depuis le monde entier, MasterCard étant l’organisation la plus importante parmi celles ayant commis la même erreur
• Si ce domaine avait été exploité de manière malveillante, cela aurait pu permettre de recevoir des e-mails mal acheminés, d’obtenir des certificats SSL/TLS pour les sites affectés, et de capter manuellement certaines informations d’authentification Windows
• MasterCard a affirmé qu’« il n’y avait aucun risque pour les systèmes » et a corrigé la faute, mais la controverse sur les modalités de divulgation s’est poursuivie après une demande de suppression du post LinkedIn via Bugcrowd

---

Une faute de frappe DNS laissée en place pendant près de cinq ans

• MasterCard utilisait cinq serveurs DNS partagés d’Akamai pour orienter une partie du trafic du réseau mastercard.com
• Du 30 juin 2020 au 14 janvier 2025, l’un d’eux a été configuré avec un nom erroné
  • Le nom de serveur correct devait se terminer par akam.net
  • La configuration fautive pointait vers akam.ne
• akam.ne est un domaine relevant de l’administration du domaine national de premier niveau du Niger, en Afrique de l’Ouest

Le chercheur a enregistré le domaine avant tout le monde

• Philippe Caturegli, fondateur de la société de conseil en sécurité Seralys, a découvert cette faute de frappe
• Caturegli a supposé que akam.ne n’avait pas encore été enregistré et a obtenu le domaine via le registre nigérien
  • Coût : 300 dollars
  • Délai d’enregistrement : près de 3 mois
• Une fois le serveur DNS activé, il a reçu chaque jour des centaines de milliers de requêtes DNS venues du monde entier
• MasterCard n’était pas la seule organisation à avoir fait cette erreur, mais c’était la plus importante en volume de requêtes reçues

Les risques qu’un domaine mal orthographié aurait pu créer

• Si Caturegli avait activé un serveur de messagerie sur akam.ne, il aurait pu recevoir des e-mails mal acheminés destinés à mastercard.com ou à d’autres domaines affectés
• En abusant de cet accès, il aurait aussi pu potentiellement obtenir des certificats SSL/TLS permettant de recevoir et de relayer le trafic des sites web concernés
• Il subsistait également une possibilité de capter manuellement des informations d’authentification Microsoft Windows depuis les postes des employés
• Caturegli n’a pas tenté ce type d’actions et a indiqué à MasterCard qu’il pouvait lui transférer le domaine
  • Le message de notification incluait aussi en référence l’auteur de Krebs on Security

La réaction de MasterCard et de Bugcrowd

• Quelques heures plus tard, MasterCard a reconnu l’erreur, tout en affirmant qu’il n’y avait eu aucun risque réel pour la sécurité opérationnelle
  • « Il n’y avait aucun risque pour les systèmes »
  • « Cette faute de frappe a été corrigée »
• Par la suite, Caturegli a reçu un message via Bugcrowd
  • Le message soutenait que le fait d’avoir rendu l’affaire publique sur LinkedIn après avoir obtenu akam.ne n’était pas conforme aux pratiques éthiques de sécurité
  • Il indiquait aussi que MasterCard demandait la suppression de cette publication
• Caturegli a répondu qu’il n’avait jamais soumis le signalement via le programme Bugcrowd et qu’il avait rapporté le problème directement à MasterCard
• Il a précisé qu’avant toute divulgation, il avait enregistré les domaines concernés pour empêcher leur exploitation, et qu’il en avait lui-même supporté le coût

L’impact potentiel amplifié par le cache DNS

• En général, les organisations utilisent au moins deux serveurs DNS faisant autorité, mais celles qui reçoivent beaucoup de requêtes emploient davantage de domaines de serveurs DNS pour répartir la charge
• Comme MasterCard utilisait cinq serveurs DNS, on pourrait penser qu’un attaquant n’en contrôlant qu’un seul ne verrait qu’environ un cinquième des requêtes DNS totales
• En pratique, les internautes dépendent souvent de résolveurs DNS publics comme Cloudflare ou Google, ce qui peut élargir l’impact
  • Il suffit qu’un résolveur interroge le mauvais serveur de noms puis mette le résultat en cache
  • Avec un TTL long dans les enregistrements DNS, de mauvaises instructions pourraient se propager via de grands fournisseurs cloud
• Selon Caturegli, avec un TTL long, l’ampleur d’un reroutage du trafic pourrait être bien supérieure à un simple cinquième

Le sous-domaine concerné et les traces d’enregistrements passés

• Les captures d’écran publiées par Caturegli montrent que le serveur DNS mal configuré était lié au sous-domaine az.mastercard.com de MasterCard
• Son usage exact reste incertain
• D’après la convention de nommage, il semble s’agir d’un domaine lié à des serveurs de production dans le cloud Microsoft Azure, et Caturegli indique que ces domaines se résolvent vers des adresses Internet de Microsoft
• akam.ne avait déjà été enregistré par le passé
  • En décembre 2016, il a été enregistré par un utilisateur utilisant l’e-mail [e-mail]
  • Yandex indique que ce compte appartient à un certain « Ivan I. » à Moscou
  • Selon l’historique DNS passif de DomainTools.com, le domaine a été relié de 2016 à 2018 à un serveur Internet en Allemagne, avant d’expirer en 2018
• Un ancien employé de Cloudflare a partagé dans les commentaires du post LinkedIn de Caturegli un lien vers un rapport sur un cas similaire
  • Il s’agissait d’un domaine typo-squatté potentiellement dû à des organisations ayant saisi awsdns-06.ne au lieu du serveur DNS AWS awsdns-06.net
  • Selon DomainTools, ce domaine comportant la même faute a lui aussi été enregistré par un utilisateur Yandex et hébergé chez le même FAI allemand, Team Internet

[GN⁺]

Avis sur Hacker News

• Les serveurs de noms enregistrables publiquement, comme dans ce cas, ne constituent qu’un sous-type relativement rare du problème des dangling DNS ; le cas plus courant est celui où un domaine pointe directement vers une adresse IP d’un fournisseur cloud qu’un attaquant peut récupérer
  Les services cloud ont une surface très large et manquent souvent de visibilité globale, donc les entreprises qui utilisent le cloud ont de fortes chances d’avoir quelque part un sous-domaine avec ce type de vulnérabilité
  Les programmes de bug bounty excluent souvent en bloc les « prises de contrôle de sous-domaines », mais une fois découvertes, elles sont faciles à exploiter, et des erreurs de configuration de ce type ont déjà exposé des données internes et publiques sensibles
  L’environnement actuel de divulgation des vulnérabilités permet trop facilement aux entreprises d’éviter de reconnaître une vraie vulnérabilité, tandis que les chercheurs de bonne foi ont du mal à fournir le niveau de preuve exigé par le fournisseur à cause de contraintes éthiques et juridiques
  Le risque que ce type de vulnérabilité permette en pratique une émission de certificat TLS est aussi sous-estimé
  [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

  • Au-delà des IP, il existe toute une immense catégorie de « registres DNS pointant vers des ressources cloud partagées que l’organisation ne contrôle plus », et plus l’entreprise est grande, plus c’est répandu
    On peut citer par exemple des CNAME pointant vers des buckets S3 libérés, des instances Azure Website/WebApp, des enregistrements A pointant vers des IP non élastiques, des serveurs de noms Route53 qui n’appartiennent plus à un compte AWS de l’organisation, des comptes Heroku/Shopify/GitHub Pages supprimés ou désactivés, ou encore des enregistrements MX pointant vers le domaine d’un fournisseur d’e-mails transactionnels qui a fait faillite
    Les causes sont la décentralisation de l’IT, avec des gens qui créent de l’infrastructure sans bien la connaître puis oublient le DNS lors du démantèlement, la multiplicité des filiales, marques et organisations régionales qui rendent la découverte et l’application des politiques difficiles, le grand nombre de sites web et d’apps par pays, et l’accumulation d’usages de prestataires externes jamais signalés à l’équipe sécurité
    Je travaille comme Field CTO dans une entreprise israélienne de cybersécurité de ce secteur, et encore hier je parlais d’une douzaine de sites de jeu indonésiens « exploités » à partir du domaine, du PageRank et des liens d’un grand fabricant de composants informatiques ; ce genre de conversation revient chaque semaine
  • Considérer comme invalide toute « prise de contrôle de sous-domaine » dans les bug bounty est une réponse beaucoup trop générale ; il faudrait distinguer selon la facilité avec laquelle le domaine peut être récupéré
    Dire que « si quelqu’un arrivait d’une manière ou d’une autre à détourner google.com, il pourrait compromettre des utilisateurs de Google » n’est pas une vulnérabilité de sécurité valable, mais si, comme ici, la prise de contrôle d’un domaine non enregistré ou expiré conduit à une compromission, alors cela doit être considéré comme une vulnérabilité valable
  • Il pourrait être plus efficace que la divulgation via bug bounty soit automatiquement signalée aussi à des organismes publics comme la FCC, avec l’adresse e-mail de l’entreprise concernée en copie
    Si l’entreprise veut rejeter le signalement, elle devrait produire des preuves claires, et si une exploitation issue de ce signalement est démontrée ou si l’entreprise a modifié quelque chose au point que les étapes de reproduction ne fonctionnent plus, cela pourrait entraîner le versement d’une récompense ou une amende
  • Sur une certaine plateforme d’échange de cryptomonnaies, une liste blanche autorisait des adresses IP pouvant accéder à un load balancer plus rapide, sans contrôle au niveau de l’application
    J’ai alloué énormément d’IP cloud et cherché par itérations d’anciennes IP, ce qui m’a permis d’obtenir bien plus de capacité qu’à l’origine et d’envoyer des requêtes avec des limites de débit plus élevées
    Ça ne marcherait probablement plus aujourd’hui, et c’est désormais une technique connue de tous

• La partie Bugcrowd dans cette histoire est inattendue
  La capture d’écran de l’e-mail semble provenir de la « Platform Behavior Standards Team » ; si c’est bien le cas, soit Bugcrowd a interprété de façon excessivement large ses règles de plateforme en essayant de réguler aussi des comportements hors plateforme, soit Mastercard s’est fait passer pour un employé officiel de Bugcrowd
  Aucune des deux possibilités n’est vraiment acceptable
  [1] https://www.bugcrowd.com/resources/hacker-resources/platform...

  • Selon une certaine interprétation, les plateformes de bug bounty existent non pas pour encourager une divulgation responsable, mais pour la capter et l’empêcher
    Quelqu’un qui défend souvent cette thèse saurait probablement mieux l’expliquer
  • La formulation est aussi extrêmement mauvaise
    Le message est rédigé comme si la faute avait déjà été établie, et les seules options sont d’obéir ou de demander des explications supplémentaires sur ce qui ne va pas
    Il n’y a aucune possibilité d’expliquer qu’on n’est pas en tort
  • D’après mon expérience, BugCrowd fait tout pour retarder l’arrivée d’un rapport jusqu’à l’entreprise réelle et pour l’enliser
    Du point de vue de l’entreprise, cela réduit les paiements de bounty, les coûts d’examen interne, et offre aussi un déni plausible sur le plan juridique
  • Il y a sûrement aussi des employés de Bugcrowd ici, donc quelqu’un pourra peut-être expliquer cet e-mail

• Une réponse du type « il n’y avait pas de menace réelle » risque, la prochaine fois, de pousser les chercheurs en sécurité à pénétrer plus profondément chez cette entreprise ou chez d’autres pour rassembler davantage de preuves d’impact
  Si l’entreprise veut pouvoir laisser son porte-parole dire qu’« il n’y a pas de problème », elle doit au moins payer suffisamment pour que le chercheur l’accepte, même si l’impact est minimisé
  Le chercheur semble déjà avoir agi correctement, et pourtant on a fait pression sur lui pour étouffer l’affaire dans la presse ; on peut se demander si une société de cartes de crédit avait réellement une raison de faire cela, si cela relève simplement d’une mauvaise compréhension du travail côté communication, ou si le responsable final d’une erreur de sécurité informatique a utilisé les ressources de l’entreprise pour éviter une humiliation pendant son mandat

  • Il y a bien une raison
    Ils veulent que les chercheurs en sécurité aient peur de rendre publics leurs résultats

• Il y a quelques années, en Ukraine, la totalité ou la plupart des transactions en ligne devaient être validées via un service appelé masterpass, qui ressemblait à une sorte de 3DS façon Mastercard.
  Mais, comme souvent sur les sites d’entreprise, le certificat SSL a expiré, et à cet instant la totalité ou la plupart des transactions en ligne avec certains types de cartes MasterCard ont été complètement bloquées.
  Mastercard n’a pas renouvelé le certificat pendant plus d’un an, et ni moi, client, ni le service IT de la banque n’avons réussi à faire bouger les choses malgré tous nos contacts ; plus tard, ils ont discrètement abandonné le service.
  En regardant de plus près, le service semblait développé sur une pile Microsoft (IIS), la chaîne de certificats était anormalement longue avec des certificats intermédiaires dont je n’avais jamais entendu parler, et l’hébergement se trouvait dans un pays du tiers monde assez éloigné de l’Ukraine.

  • masterpass est la version 3DS de Mastercard, utilisée dans le monde entier quand une transaction est jugée suspecte.
    Du point de vue de Mastercard, on dirait qu’ils considéraient par défaut comme suspectes les transactions de ce pays, même lorsqu’elles étaient entièrement domestiques.
    Aux États-Unis, je ne l’ai jamais vu expirer, et je ne sais pas comment ils gèrent le trafic selon les pays, mais on dirait que le trafic était routé ailleurs que chez Mastercard.

• Le fait que akam.ne ait été enregistré en 2016 au nom d’un certain « Ivan I. » à Moscou, utilisant une adresse e-mail Yandex, puis ait pointé vers un serveur allemand entre 2016 et 2018 avant d’expirer, est troublant.
  Il est particulièrement suspect qu’un autre domaine typo, apparemment destiné à viser une organisation ayant mal saisi le serveur DNS AWS awsdns-06.net en awsdns-06.ne, ait lui aussi été enregistré avec un compte Yandex et hébergé chez le même ISP allemand, Team Internet (AS61969).

  • « Ivan I » désigne très probablement Ivan Ivanov, un faux nom russe banal, l’équivalent de « John Smith » dans le monde anglophone.

• Entre « s’il avait exploité cet accès, il aurait pu obtenir des certificats SSL/TLS capables de recevoir et relayer le trafic des sites web affectés » et « il n’y avait aucun risque pour nos systèmes », l’une des deux affirmations doit être fausse.
  Les deux camps ont des raisons de mentir ou d’exagérer.

  • L’un a un intérêt à mentir ou exagérer à hauteur de plusieurs dizaines de milliards de dollars, l’autre passe ses journées à imaginer les pires scénarios face à des attaquants sophistiqués.
    S’il s’agissait d’un serveur CS:GO, le pire scénario d’un attaquant sophistiqué pourrait être exagéré ; mais quand on parle de l’un des plus grands processeurs de paiement au monde, ce n’est pas de l’exagération.
  • Quiconque comprend un minimum comment les certificats sont délivrés voit que le chercheur a raison et que MasterCard raconte n’importe quoi.
    Dix minutes de recherche suffisent pour arriver à la même conclusion.
  • S’il n’y avait aucun impact, il suffirait de l’autoriser à publier la liste complète des requêtes DNS qu’il a capturées.
    S’ils ne le font pas, c’est parce que cette liste donnerait à des acteurs malveillants des indices sur l’infrastructure.
    Soit MasterCard ment, soit l’entreprise est ignorante et incompétente.
  • Tout dépend en grande partie de ce qu’est réellement az.mastercard.com et de sa fonction.
    L’idée qu’il reçoive des e-mails destinés à [e-mail] ne semble pas tenir, et il s’agit simplement d’un sous-domaine dont l’usage est inconnu.
    TLS serait probablement possible, mais le risque dépend de ce qu’est ce domaine, et il n’aurait sans doute pas d’impact direct sur les utilisateurs qui visitent mastercard.com.
  • En matière de certificat SSL/TLS, la première chose qui vient à l’esprit est un fournisseur de certificats basé sur ACME.
    Le simple contrôle du DNS du domaine suffit, qu’il s’agisse d’utiliser un enregistrement TXT ou de faire pointer la requête vers un serveur HTTP sous son contrôle.

• C’est clairement une grosse erreur de Mastercard, mais laisser exister des domaines ne différant du TLD d’origine que d’une seule lettre semble aussi être une erreur.
  Par exemple .com et .co, ou .net et .ne : c’est une structure qui attire les problèmes.
  Si ces domaines n’existaient pas, personne n’aurait pu les enregistrer et les requêtes DNS erronées ne seraient simplement allées nulle part.

  • Pas forcément.
    Les fautes de frappe peuvent se produire n’importe où dans le nom, pas seulement dans le domaine de premier niveau ; et même sans faute de frappe, on peut capter du trafic issu de diverses erreurs informatiques via le bitsquatting, qui consiste à enregistrer un domaine à 1 bit d’écart d’un site populaire.
    Il existe même un article avec des exemples.
    [1] https://en.wikipedia.org/wiki/Bitsquatting
    [2] https://www.securitee.org/files/bitsquatting_www2013.pdf
  • Pour une grande entreprise, je m’attendais à ce que ce problème soit géré par Markmonitor.
    En gros, il s’agit d’enregistrer autant que possible les domaines typo à distance d’édition 1.
    D’après Wikipedia, Akamai fait partie des clients de Markmonitor, donc il est surprenant que ce domaine n’ait pas déjà été enregistré.
  • La question est aussi de savoir quoi faire des codes ISO 3166-2 du Niger et de la Colombie.
  • Je ne vois pas en quoi c’est différent de l’existence d’un numéro de téléphone sensible dont il existe un autre numéro à un seul chiffre d’écart.
  • Les TLD ISO 3166-1 alpha-2 sont clairement utiles, mais la structure de l’espace d’adressage génère beaucoup de fautes de frappe à une lettre près.
    Les domaines non nationaux peuvent eux aussi recouper des TLD nationaux lorsqu’il manque une lettre, donc la différence n’est pas énorme.
    En revanche, un bon outil de vérification DNS devrait détecter ce type d’erreur de configuration.
    Cela se verrait par exemple si l’un des serveurs de noms enregistrés ne se résout pas, ou si les serveurs ne renvoient pas le même numéro de série de zone, voire pas de réponse cohérente.
    En .is, il fallait fournir deux serveurs de noms fonctionnels pour enregistrer un domaine, mais .com est désormais moins strict sur ce point.

• Ce nom de domaine aurait dû être transféré à akamai.
  D’autres requêtes arrivent aussi à cette même adresse, et akamai devrait les traiter de manière responsable.

• La réponse typique du genre « nous nous sommes nous-mêmes examinés et avons conclu que nous n’avions rien fait de mal ».
  Mastercard est une société cotée pesant plusieurs milliards de dollars, avec au moins 3,4 milliards de cartes de marque en circulation dans le monde et 44,3 milliards de transactions mondiales de crédit, débit et cash traitées au troisième trimestre 2024.
  Reconnaître une faute peut coûter cher à court terme sur le marché, mais une culture du déni finit par pourrir la culture d’entreprise.
  Ce n’est pas différent de ClownStrike, et il est temps que les réseaux de crédit et de débit prédateurs et parasitaires subissent un peu de chaos.

• « La faute de frappe a été corrigée et il n’y avait aucun risque pour le système » : c’est toujours la même rengaine, et ce genre de déclaration est vraiment exaspérant

  • Leur calcul doit être le suivant
    reconnaître le problème peut faire perdre des millions de dollars en Bourse, tandis que le nier ne fera que pousser quelques originaux à râler un peu plus
    sans preuve d’une compromission, il est difficile de les contraindre, et s’il existe une preuve de compromission, ils finissent en prison
  • En réalité, cela veut plutôt dire : « Nous avons parlé à un employé du service informatique qui ne comprenait rien au sujet, qui avait un intérêt personnel à ne pas chercher d’exposition, et qui n’a pas réussi à imaginer une méthode d’exploitation en 15 secondes »
    quiconque s’y connaît évite presque toujours de se sentir assez certain pour affirmer catégoriquement que quelque chose ne peut pas être exploité.