Mastercard-DNS-Tippfehler blieb fast 5 Jahre unentdeckt
(krebsonsecurity.com)- MasterCard hatte einen Akamai-DNS-Servernamen, der einen Teil des Traffics für mastercard.com steuert, fälschlich auf
akam.nestattakam.netgesetzt; dieser Tippfehler blieb vom 30. Juni 2020 bis zum 14. Januar 2025 fast fünf Jahre lang bestehen - Der Sicherheitsforscher Philippe Caturegli stellte fest, dass akam.ne unter der Länder-Top-Level-Domain von Niger nicht registriert war, und sicherte sich die Domain für 300 Dollar und nach rund drei Monaten, um eine mögliche Ausnutzung zu verhindern
- Als er auf akam.ne einen DNS-Server aktivierte, gingen aus aller Welt täglich Hunderttausende DNS-Anfragen ein; unter den Organisationen mit demselben Tippfehler war MasterCard der größte Fall
- Wäre die Domain missbraucht worden, hätte dies zum Empfang fehlgeleiteter E-Mails, zur Beschaffung von SSL/TLS-Zertifikaten für betroffene Websites und zum passiven Empfang einiger Windows-Anmeldedaten führen können
- MasterCard erklärte, es habe „kein Risiko für die Systeme“ bestanden, und korrigierte den Tippfehler; später kam es über Bugcrowd sogar zu einer Aufforderung, einen LinkedIn-Beitrag zu löschen, was eine Kontroverse über die Art der Offenlegung auslöste
Fast fünf Jahre lang übersehener DNS-Tippfehler
- MasterCard nutzt fünf gemeinsam genutzte DNS-Server von Akamai, um einen Teil des Netzwerk-Traffics für mastercard.com zu steuern
- Vom 30. Juni 2020 bis zum 14. Januar 2025 war einer davon mit einem falschen Namen konfiguriert
- Der korrekte Servername hätte auf
akam.netenden müssen - Die fehlerhafte Konfiguration verwies auf
akam.ne
- Der korrekte Servername hätte auf
akam.neist eine Domain im Zuständigkeitsbereich der Länder-Top-Level-Domain des westafrikanischen Staates Niger
Forscher sicherte sich die Domain zuerst
- Philippe Caturegli, Gründer der Sicherheitsberatung Seralys, entdeckte den Tippfehler
- Caturegli vermutete, dass akam.ne noch nicht registriert war, und sicherte sich die Domain über die Registry von Niger
- Die Kosten betrugen 300 Dollar
- Bis zur Registrierung dauerte es fast drei Monate
- Nach Aktivierung eines DNS-Servers gingen täglich Hunderttausende DNS-Anfragen aus aller Welt ein
- MasterCard war nicht die einzige Organisation mit demselben Tippfehler, gemessen an den eingehenden Anfragen aber die größte
Risiken, die die Tippfehler-Domain hätte verursachen können
- Hätte Caturegli auf akam.ne einen E-Mail-Server betrieben, hätte er fehlgeleitete E-Mails empfangen können, die für mastercard.com oder andere betroffene Domains bestimmt waren
- Bei Missbrauch des Zugriffs wäre es möglicherweise auch möglich gewesen, SSL/TLS-Zertifikate zu erhalten, mit denen sich Traffic für betroffene Websites annehmen und weiterleiten ließe
- Auch die Möglichkeit blieb bestehen, passiv Microsoft-Windows-Anmeldedaten von Mitarbeiterrechnern zu empfangen
- Caturegli unternahm keine solchen Versuche und informierte MasterCard, dass er die Domain übergeben könne
- In der Benachrichtigung war auch der Autor von Krebs on Security in Kopie gesetzt
Reaktion von MasterCard und Bugcrowd
- MasterCard räumte den Fehler einige Stunden später ein, erklärte jedoch, es habe kein tatsächliches Risiko für die operative Sicherheit gegeben
- „Es bestand kein Risiko für die Systeme“
- „Dieser Tippfehler wurde behoben“
- Später erhielt Caturegli eine Nachricht über Bugcrowd
- Darin hieß es sinngemäß, Catureglis öffentliche Mitteilung auf LinkedIn nach der Sicherung von akam.ne entspreche nicht ethischen Sicherheitspraktiken
- Außerdem stand darin, MasterCard habe die Löschung des Beitrags verlangt
- Caturegli antwortete, er habe den Hinweis nicht über ein Bugcrowd-Programm eingereicht, sondern das Problem direkt an MasterCard gemeldet
- Er erklärte, er habe die betroffene Domain vor der Veröffentlichung registriert, um Missbrauch zu verhindern, und die Kosten selbst getragen
Wie DNS-Caching die Auswirkungen vergrößern kann
- Üblicherweise betreiben Organisationen mindestens zwei autoritative DNS-Server; Organisationen mit hohem Anfrageaufkommen nutzen zur Lastverteilung jedoch mehr DNS-Server-Domains
- Da MasterCard fünf DNS-Server nutzt, könnte es so wirken, als könne ein Angreifer durch die Kontrolle nur eines davon lediglich etwa ein Fünftel aller DNS-Anfragen sehen
- Tatsächlich können die Auswirkungen größer sein, weil Internetnutzer auf öffentliche DNS-Resolver wie Cloudflare oder Google angewiesen sind
- Es genügt, wenn ein Resolver den falschen Nameserver abfragt und das Ergebnis cached
- Wird für DNS-Records eine lange TTL gesetzt, können sich falsche Anweisungen über große Cloud-Anbieter verbreiten
- Caturegli ist der Ansicht, dass eine lange TTL den Umfang der Traffic-Umleitung deutlich über ein einfaches Fünftel hinaus vergrößern könnte
Betroffene Subdomain und Spuren früherer Registrierung
- In den von Caturegli veröffentlichten Screenshots steht der falsch konfigurierte DNS-Server im Zusammenhang mit der Subdomain az.mastercard.com von MasterCard
- Wie genau diese Subdomain genutzt wird, ist unklar
- Nach der Namenskonvention scheint es sich um eine Domain im Zusammenhang mit Produktionsservern in der Microsoft-Azure-Cloud zu handeln; Caturegli erklärte, diese Domains würden auf Microsoft-Internetadressen aufgelöst
- akam.ne war auch früher schon einmal registriert
- Im Dezember 2016 wurde sie von einem Nutzer mit der E-Mail-Adresse
um-i-delo@yandex.ruregistriert - Yandex weist dieses Konto einem „Ivan I.“ aus Moskau zu
- Laut passiven DNS-Einträgen von DomainTools.com war sie von 2016 bis 2018 mit Internetservern in Deutschland verbunden und lief 2018 ab
- Im Dezember 2016 wurde sie von einem Nutzer mit der E-Mail-Adresse
- Ein ehemaliger Cloudflare-Mitarbeiter verlinkte in den Kommentaren zu Catureglis LinkedIn-Beitrag einen Bericht über einen ähnlichen Fall
- Dabei ging es um eine Tippfehler-Domain, bei der einige Organisationen möglicherweise den AWS-DNS-Server
awsdns-06.netfälschlich alsawsdns-06.neeingetragen hatten - Laut DomainTools war auch diese Tippfehler-Domain auf einen Yandex-Nutzer registriert und beim selben deutschen ISP, Team Internet, gehostet
- Dabei ging es um eine Tippfehler-Domain, bei der einige Organisationen möglicherweise den AWS-DNS-Server
1 Kommentare
Meinungen auf Hacker News
Öffentlich registrierbare Nameserver wie in diesem Fall sind nur ein relativ seltener Untertyp des Problems Dangling DNS; häufiger ist, dass eine Domain direkt auf eine IP-Adresse eines Cloud-Anbieters gemappt ist, die sich ein Angreifer sichern kann.
Cloud-Dienste haben oft einen großen Umfang und es fehlt an globaler Sichtbarkeit, daher ist es bei Unternehmen, die Cloud nutzen, wahrscheinlich, dass irgendwo unter ihren Subdomains eine solche Schwachstelle existiert.
Bug-Bounty-Programme schließen „Subdomain Takeover“ oft pauschal aus, doch wenn er gefunden wird, lässt er sich leicht ausnutzen, und es gibt interne wie öffentliche Daten, bei denen durch solche Fehlkonfigurationen sensible Informationen offengelegt wurden.
Das heutige Umfeld für Vulnerability Disclosure macht es Unternehmen zu leicht, die Anerkennung echter Schwachstellen zu umgehen, während gutwillige Forschende wegen ethischer und rechtlicher Grenzen nur schwer Beweise in dem Umfang liefern können, den Anbieter verlangen.
Auch das Risiko wird unterschätzt, dass über solche Schwachstellen sehr einfach TLS-Zertifikate ausgestellt werden können.
[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
Beispiele sind CNAMEs, die auf freigegebene S3-Buckets zeigen, Azure-Website-/WebApp-Instanzen, A-Records auf nicht-elastische IPs, Route53-Nameserver, die nicht mehr zu einem AWS-Konto der Organisation gehören, gelöschte oder deaktivierte Heroku-/Shopify-/GitHub-Pages-Konten sowie MX-Records, die auf Domains gescheiterter Anbieter für Transaktions-E-Mails zeigen.
Die Ursachen liegen darin, dass durch dezentrale IT Menschen Infrastruktur aufbauen, die sich nicht gut auskennen, beim Rückbau DNS vergessen wird, viele Tochterfirmen, Marken und regionale Organisationen das Finden und Durchsetzen von Richtlinien erschweren, es viele länderspezifische Websites und Apps gibt und sich die Nutzung externer Anbieter anhäuft, ohne dass das Security-Team informiert wird.
Ich arbeite als Field CTO bei einer israelischen Cybersecurity-Firma in diesem Bereich; erst gestern habe ich mit einem großen Computerteilehersteller über rund ein Dutzend indonesische Glücksspielseiten gesprochen, die mithilfe ihrer Domains, ihres PageRanks und ihrer Links „betrieben“ werden, und solche Gespräche wiederholen sich jede Woche.
„Wenn man irgendwie google.com übernimmt, kann man Google-Nutzer kompromittieren“ ist keine gültige Sicherheitslücke, aber wenn wie hier die Übernahme einer nicht registrierten oder abgelaufenen Domain zu einer Kompromittierung führt, sollte das als gültige Schwachstelle gelten.
Wenn ein Unternehmen einen Bericht ablehnen will, müsste es klare Belege vorlegen; wenn eine aus dem Bericht hervorgehende Ausnutzung nachgewiesen wird oder das Unternehmen Änderungen vornimmt, sodass die Reproduktionsschritte des Berichts nicht mehr funktionieren, könnte dies eine Auszahlung der Prämie oder eine Geldstrafe auslösen.
Man wies massenhaft Cloud-IPs zu, suchte wiederholt nach alten IPs, erhielt dadurch viel mehr Kapazität als ursprünglich vorgesehen und sendete Requests mit höheren Rate Limits.
Ich glaube, heute funktioniert das nicht mehr, und inzwischen kennt jeder diese Methode.
Der Bugcrowd-Teil an dieser Geschichte ist unerwartet.
Der Mail-Screenshot sieht so aus, als käme er vom „Platform Behavior Standards Team“. Wenn das stimmt, hat Bugcrowd entweder die Plattformregeln sehr weit ausgelegt und versucht, auch Verhalten außerhalb der Plattform zu regulieren, oder Mastercard hat sich als offizieller Bugcrowd-Mitarbeiter ausgegeben.
Beides ist schwer zu akzeptieren.
[1] https://www.bugcrowd.com/resources/hacker-resources/platform...
Jemand, der dieses Argument oft vorgebracht hat, könnte es vermutlich besser ausführen.
Sie ist so geschrieben, als sei bereits festgestellt worden, dass man etwas falsch gemacht hat, und die Optionen bestehen nur darin, sich zu fügen oder zusätzliche Erklärungen dazu zu verlangen, warum es falsch sei.
Es gibt keine Möglichkeit zu erklären, dass man selbst nichts falsch gemacht hat.
Aus Sicht des Unternehmens sinken dadurch die Kosten für Bounty-Zahlungen und interne Prüfung, und rechtlich erhält man eine plausible Abstreitbarkeit.
Eine Reaktion nach dem Muster „es gab keine tatsächliche Bedrohung“ wird beim nächsten Mal vermutlich dazu führen, dass Sicherheitsforschende bei diesem oder anderen Unternehmen tiefer eindringen, um mehr Belege für die Auswirkungen zu sammeln.
Wenn man möchte, dass ein Unternehmenssprecher sagen kann „kein Problem“, muss man ausreichend zahlen, damit Forschende es akzeptieren, auch wenn die Auswirkungen heruntergespielt werden.
Obwohl der Forscher bereits korrekt gehandelt zu haben scheint, wurde er unter Druck gesetzt, um die Nachricht zu unterdrücken; da fragt man sich, ob ein Kreditkartenunternehmen dafür einen Grund hatte, ob es ein falsches Aufgabenverständnis der PR-Abteilung war oder ob die letztverantwortliche Person für den Informationssicherheitsfehler Firmenressourcen nutzte, um eine Blamage während der eigenen Amtszeit zu vermeiden.
Man will erreichen, dass Sicherheitsforschende Angst bekommen, ihre Ergebnisse zu veröffentlichen.
Vor einigen Jahren mussten in der Ukraine alle oder die meisten Online-Transaktionen über einen Dienst namens masterpass verifiziert werden; es sah nach etwas wie Mastercards 3DS aus.
Dann lief, wie es im Unternehmens-Web häufig vorkommt, das SSL-Zertifikat ab, und alle oder die meisten Online-Transaktionen mit bestimmten Arten von MasterCard-Karten waren in diesem Moment komplett blockiert.
Mastercard erneuerte das Zertifikat über ein Jahr lang nicht; weder meine Kontaktversuche als Kunde noch die der IT-Abteilung der Bank halfen, und später wurde der Dienst stillschweigend eingestellt.
Bei näherem Hinsehen war der Dienst auf Microsoft-Technologie (IIS) geschrieben, die Zertifikatskette war mit unbekannten Zwischenzertifikaten ungewöhnlich lang, und gehostet wurde er in einem Dritte-Welt-Land, ziemlich weit von der Ukraine entfernt.
Aus Sicht von Mastercard galten die Transaktionen dieses Landes offenbar grundsätzlich als verdächtig, selbst wenn sie alle zwischen lokalen Akteuren stattfanden.
In den USA habe ich nie gesehen, dass es abgelaufen war, und ich weiß nicht, wie der Traffic pro Land verarbeitet wird, aber es klingt, als sei der Traffic nicht zu Mastercard, sondern an eine andere Stelle geroutet worden.
Es ist beunruhigend, dass akam.ne 2016 auf einen „Ivan I.“ in Moskau mit Yandex-E-Mail registriert war, von 2016 bis 2018 mit deutschen Servern verbunden war und dann ablief.
Besonders verdächtig ist, dass eine ähnliche Tippfehler-Domain, die offenbar auf Organisationen zielte, die den AWS-DNS-Server
awsdns-06.netfälschlich alsawsdns-06.neeingaben, ebenfalls mit einem Yandex-Konto registriert und beim selben deutschen ISP, Team Internet (AS61969), gehostet wurde.„Hätte jemand den Zugriff missbraucht, hätte er SSL/TLS-Zertifikate erhalten können, mit denen sich der Traffic der betroffenen Websites empfangen und weiterleiten ließe“ und „Unsere Systeme waren nicht gefährdet“ – eine dieser beiden Aussagen muss falsch sein.
Beide Seiten haben Anreize zu lügen oder zu übertreiben.
Bei einem CS:GO-Server wäre der schlimmste Angriff eines ausgefeilten Angreifers vielleicht übertrieben; wenn es um einen der größten Zahlungsabwickler der Welt geht, ist es das nicht.
Zehn Minuten Recherche reichen, um zum selben Schluss zu kommen.
Der einzige Grund, das nicht zu tun, ist, dass diese Liste böswilligen Akteuren Hinweise auf die Infrastruktur liefern würde.
MasterCard lügt entweder oder ist ignorant und inkompetent.
az.mastercard.comtatsächlich ist und tut.Die Behauptung, man erhalte E-Mails an
x@mastercard.com, scheint nicht zu stimmen; es ist lediglich eine Subdomain mit unbekanntem Zweck.TLS wäre vermutlich möglich, aber das Risiko hängt davon ab, was diese Domain ist, und dürfte Nutzer, die
mastercard.combesuchen, nicht unmittelbar betreffen.Kontrolle über das DNS der Domain reicht aus; möglich ist das über TXT-Records oder indem Anfragen an einen HTTP-Server geschickt werden, den man selbst kontrolliert.
Es ist eindeutig ein großer Fehler von Mastercard, aber schon die Tatsache, Domains existieren zu lassen, die sich nur um einen Buchstaben von ursprünglichen Top-Level-Domains unterscheiden, wirkt ebenfalls wie ein Fehler.
Beispiele sind
.comund.cooder.netund.ne; diese Struktur provoziert Probleme.Gäbe es solche Domains nicht, könnte man sie nicht registrieren, und falsch adressierte DNS-Anfragen würden einfach nirgendwo hingehen.
Tippfehler können nicht nur bei der Top-Level-Domain auftreten, sondern an jeder Stelle des Namens, und selbst ohne Tippfehler kann man mit Bitsquatting – Domains, die sich durch 1 Bit von Namen populärer Websites unterscheiden – Traffic aus verschiedensten Computerfehlern abgreifen.
Es gibt dazu auch Paper mit Beispielen.
[1] https://en.wikipedia.org/wiki/Bitsquatting
[2] https://www.securitee.org/files/bitsquatting_www2013.pdf
Im Grunde registriert man dabei, soweit möglich, Tippfehler-Domains mit Editierdistanz 1 mit.
Laut Wikipedia ist Akamai einer der Kunden von Markmonitor, daher ist es überraschend, dass diese Domain nicht bereits registriert war.
Nicht-Ländercode-Domains können ebenfalls mit Formen kollidieren, bei denen bei einer Ländercode-Top-Level-Domain ein Zeichen fehlt; das ist also kein großer Unterschied.
Solche Fehlkonfigurationen sollten gute DNS-Prüftools allerdings erkennen können.
Das zeigt sich etwa daran, dass einer der registrierten Nameserver nicht auflösbar ist oder dass die Nameserver untereinander nicht dieselbe Zonen-Seriennummer beziehungsweise nicht dieselben tatsächlichen Antworten zurückgeben.
Bei
.ismusste man früher zwei funktionierende Nameserver angeben, um eine Domain zu registrieren;.comist inzwischen nicht mehr so streng.Dieser Domainname hätte an akamai übergeben werden sollen.
An dieselbe Adresse gehen auch andere Anfragen, und akamai sollte verantwortungsvoll damit umgehen.
„Wir haben uns selbst untersucht und kein Fehlverhalten festgestellt“ ist die typische Reaktion.
Mastercard ist ein börsennotiertes Milliardenunternehmen mit weltweit mindestens 3,4 Milliarden Karten unter eigener Marke und hat im dritten Quartal 2024 weltweit 44,3 Milliarden Kredit-, Debit- und Bargeldtransaktionen verarbeitet.
Fehler einzugestehen kann dem Markt kurzfristig schaden, aber eine Kultur des Leugnens ruiniert die Unternehmenskultur.
Das ist nicht anders als bei ClownStrike, und es ist an der Zeit, dass in räuberische, parasitäre Kredit- und Debit-Netzwerke Unruhe kommt.
Aussagen nach dem Muster „Der Tippfehler wurde korrigiert und es bestand kein Risiko für die Systeme“ sind immer gleich, und solche Statements machen mich wirklich wütend
Wenn sie das Problem einräumen, könnten Millionen Dollar an Börsenwert vernichtet werden; wenn sie es abstreiten, jammern nur ein paar Nerds etwas länger herum.
Ohne Beweise für einen Einbruch ist es schwer, etwas zu erzwingen, und mit Beweisen für einen Einbruch landet man im Gefängnis.
Wer sich auskennt, fühlt sich nur selten sicher genug, um kategorisch zu behaupten, dass etwas nicht ausgenutzt werden kann.