Onderzoeker vindt beveiligingsrisico door typfout in DNS-records Mastercard

Mastercard had volgens een beveiligingsonderzoeker ruim vier jaar een typfout in zijn DNS-records. Kwaadwillenden hadden dit foutieve domein vervolgens kunnen gebruiken om verkeer bedoeld voor Mastercard te onderscheppen. Het probleem is intussen opgelost.

Onderzoeker Philippe Caturegli schrijft dat Mastercard in zijn DNS-records verwees naar vijf zogenoemde Domain Name System-servers van het bedrijf Akamai, zo merkte Security.nl op. Een van die verwijzingen was 'a22-65.akam.ne', terwijl dat 'a22-65.akam.net' had moeten zijn. De onderzoeker meldde het beveiligingsprobleem bij Mastercard en registreerde het foutieve domein uit voorzorg.

De Amerikaanse techjournalist Brian Krebs schrijft in een nieuwsbericht op basis van verdere uitleg van Caturegli dat er ook een DNS-server op het foutieve adres opgezet werd, waarop vervolgens 'dagelijks honderdduizenden verzoeken' geregistreerd werden. Er bleken meer organisaties een foutieve 'akam.ne'-verwijzing te hebben, al was het creditcardbedrijf verreweg de grootste.

Mastercard ontkent volgens de onderzoeker dat de typfout een beveiligingsrisico veroorzaakte, maar heeft het probleem wel opgelost. Het bedrijf zou oorspronkelijk niet op de melding van Caturegli hebben gereageerd en ondernam volgens hem pas actie nadat Krebs hier iets over publiceerde.

Reacties (55)

[Nikel]

Ik had een beetje hulp nodig om te snappen waarom dit nou zo erg is. Zowel het t.net artikel als de LinkedIn post leggen dat niet echt duidelijk uit.

Het probleem hier is niet dat iemand verkeer kan onderscheppen (dat is hooguit erg irritant). Het probleem is dat als je de DNS-server beheert je een werkend certificaat kunt aanvragen voor mastercard.com omdat je bij het aanvraagproces vaak alleen maar een paar records in de DNS hoeft aan te maken als verificatie dat je de eigenaar bent van de domeinnaam.

En als je én het verkeer naar jezelf kunt leiden, én je hebt een valide certificaat, dán is het natuurlijk wel behoorlijk mis.

[djwice]

Het gast het hier om een name server.

Een op de 5 DNS requests voor de Availability Zone az.mastercard.com gaat naar een domein in Nigeria Niger (.ne) dat niet in beheer is van Mastercard.

Op de Availability Zone kan master card van alles hosten. Opvallend dat ze 4 jaar lang geen "could not resolve" errors hebben gehad, of niet genoeg om op te vallen in iedergeval.

Akamai Technologies, Inc.
Is de cloud provider die eigenaar is van akam.net

akam.ne is niet geregistreerd.
Typisch scant een grote marktpartij of er een domeinnaam geregistreerd wordt met hun merk of domein er in. De kans is klein dat de registratie van akam.ne onopgemerkt zou blijven.

[Reactie gewijzigd door djwice op 24 januari 2025 12:01]

[Napsju]

.ne is het TLD van Niger. Nigeria (TLD .ng) is een heel ander land.

[djwice]

Thanks.

[eborn]

En zoals hierboven gezegd wordt is de kans dat je geldige email kan versturen ook 1 op 5, aangezien de ontvangende server vaak Round Robin de DNS servers af gaat.

Sterker nog: als ik een MX record instel en daar een catch-all op gooi ontvang je vermoedelijk aardig wat mail bedoelt voor echte mastercard.com medewerkers. En daarvan zal het overgrote deel niet beveiligd zijn.

[DarkForce]

Nog leuker gezegd, je kun het domein gedurende een wel hele lange tijd onbruikbaar maken voor mastercard. Hoe? Het SOA Record een TTL geven van tenminste één jaar alsmede voor de A en AAAA records.

Tot het TTL verstrijkt, blijft een recursor het antwoord geven of te wel... dik een jaar als een kwaadwillende dit wilt. Het enige wat mastercard kan doen is iedereen dan dringend verzoeken de cache van de recursur een harde flush te geven zodat de records vergeten worden. Maar zelfs daaraan geef lang niet iedereen gehoor.

Met die lage TTL die ze zelf hanteren (300) is de kans steeds weer dat op den duur toch net even die f*cked up nameserver geselecteerd wordt met alle gevolgen van dien.

Zeer kwalijk eigenlijk voor een tent waarvan je mag verwachten dat ze dit soort kleine foutjes niet maken.

[djwice]

Wat zouden de juridische consequenties zijn voor jou als je dat (opzettelijk) doet met kritische infrastructuur zoals die van Mastercard?

[sdsnatcher73]

Ligt er natuurlijk aan waar „jij“ je bevindt. De meeste “professionals” zitten natuurlijk ergens waar ze niet snel uitgeleverd zullen worden aan de VS.

[Raymond Deen]

Wat zouden die zijn voor mc zelf als blijkt dat er schade is geleden door die foutieve setting?

[Kees]

En dan kun je de 'time to live' (TTL) ook nog eens erg hoog zetten, zodat elke DNS server jouw responses erg lang in zijn cache houd zodat je nog meer kans hebt dat willekeurige mensen jouw antwoord krijgen.

De default TTL voor mastercard.com is 300 seconden. Dus elke 300 seconden zal de dns cache een nieuwe aanvraag doen. Als hij dan jouw server krijgt, en die geeft hem een response met een TTL van een week, dan zul je vrij snel alleen nog maar jouw responses terug krijgen van de grote dns servers.

[NiGeLaToR]

Er is nog meer - hoewel Mastercard geen zin heeft om de onkosten die de onderzoeker maakte te dekken - blijkt een collega onderzoeker wel te hebben gevonden dat er een DNS registratie is geweest voor dit domein vanuit Rusland die sporadisch resolved is:

But interestingly, as Brian Krebs noted, "someone in Russia registered this typo'ed domain back in 2016 and had it sporadically resolve to an IP address in Germany for a few years (185.53.177.31)".

Dat lijkt niet direct te duiden op enorme misbruik, maar wel op het gegeven dat de DNS wordt gecheckt en misbruikt als mogelijk zoals in dit geval.

[Jaldea]

Deze DNS-validatie van domeinen is enkel beschikbaar voor single domain/domain validation SSL-certificaten, indien je een organisatie zoals Mastercard bent wil je toch wel minimaal organisation level validatie en wildcards waarop je hele organisatie van deze security mee ligt, dan wordt er namelijk op 3 niveau's controle uitgevoerd en is enkel met een DNS (txt) record je SSL of domein gespoofd.

[kodak]

Als crimineel dns verzoeken ontvangen en dns reacties terugsturen alsof ze betrouwbaar zijn geeft wel meer risico's dan alleen maar irritante gevolgen.

Zo kan bijvoorbeeld ook mail naar verkeerde mailservers verstuurd laten worden om belangrijke en persoonlijke gegevens te kunnen ontvangen. Of naar andere webservices worden verwezen.

Afhankelijk van welke betrouwbaarheid de ontvanger nog meer wil en betrouwbaar kan controleren heeft dat niet perse grote gevolgen. Maar die controles worden dus ook niet altijd maar uitgevoerd.

Dat is ook waarom het vertrouwen van verkeerde domeinen al eerder in het nieuws is geweest.

[Thermobaric]

Wie zegt dat het 'typefout' is.
Misschien is het bewust of idd een typefout bij domeinregistratie,dus wel een werkend domein voor die server.

[devilkin]

Je moet dus het domein akam.ne hebben, daar een dns server op draaien die antwoorden geeft op de Mastercard.com zone (niet zo moeilijk) maar dan ook nog een certificaat kunnen genereren op az.Mastercard.com.

Dat laatste is al een pak moeilijker, zeker als je het wil laten accepteren door browsers.

Een redirect op poort 80 kan altijd, maar hsts is actief op Mastercard.com met preload. Dus daar geraak je ook al niet zomaar rond...

Kan iemand even detailleren welk risico er juist was?

(edit: spellingsfouten)

[Reactie gewijzigd door devilkin op 23 januari 2025 20:37]

[CAPSLOCK2000]

maar dan ook nog een certificaat kunnen genereren op az.Mastercard.com.

De aanvaller vraagt zelf een certificaat aan (bv bij LetsEncrypt) en de onderschept ook de validatie.

Dat probleem kun je deels ondervangen met CAA-records, maar ook die heeft Mastercard niet.
Ik hoop dat ze wel aan Certificate Transparancy doen en de logs goed monitoren, maar op grond van het voorgaande betwijfel ik dat.

Bij mail is het probleem nog groter omdat het daar nog heel gewoon is verbindingen te accepteren van ongeldige/oncontroleerbare certificaten. Soms wordt DNS daar gebruikt als extra beveiliging (DANE/TLSA) maar dat werkt niet als DNS zelf het zwakke punt is.

[Reactie gewijzigd door CAPSLOCK2000 op 23 januari 2025 20:33]

[devilkin]

Ok. duidelijk!

[moonlander]

Mastercard ontkent volgens de onderzoeker dat de typefout een beveilgingsrisico veroorzaakte maar heeft het probleem wel opgelost.

Mag hopen dat dit bericht van de klantenservice komt en niet van hogerop

[latka]

Op security.nl staat: "MasterCard reageerde tegenover Krebs en verklaarde dat er geen risico voor de systemen was en de typfout was verholpen" wat als marketingspeak uitspraak klinkt die technisch waar is maar de klant in de regen zet... het probleem is dat phising van klanten mogelijk wordt, niet het hacken van de servers van mastercard. Combineer dat met de melding van Krebs dat het domein eerder (in 2016) al in russische handen was en een phising attack met een fake certificaat niet te signaleren is door mastercard is het eigenlijk gewoon kwaadaardig liegen.

[GoBieN-Be]

Als je een log hebt van alle DNS requests die binnenkomen zie je ook de gevraagde A records.
Sommige van die A records zijn bedoeld voor endpoint voor API toegang.

Je vraag via DNS validatie een wildcard (*) certificaat aan bij lets encrypt.
Je zet in jouw DNS server een wildcard (*) A record of je zet manueel A records die interessant lijken, verwijzend naar een IP van een webserver die je opzet.
Op de webserver gebruik je het wildcard certificaat en je luistert naar alle verzoeken op poort 443.
Je onderschept API verkeer, mogelijk met long-living tokens.
Je kan nu proberen de de echte mastercard server te compromiteren.

Hoeft trouwens ook niet allemaal API te zijn. Er is misschien ook een simpele weblogin ergens op een host in dat domein. Je zet een script op de server die alle POST requests logt, misschien heb je geluk en krijg je gewoon plaintext login en wachtwoorden binnen.

De mogelijkheden zijn eindeloos omdat er geen DNSSEC is.

[Reactie gewijzigd door GoBieN-Be op 24 januari 2025 00:05]

[CAPSLOCK2000]

Mastercard ontkent volgens de onderzoeker dat de typefout een beveilgingsrisico veroorzaakte maar heeft het probleem wel opgelost.

Mastercard kan veel roepen maar dit was wel degelijk een risico.

Ze ondersteunen niet eens DNSSEC dus een kwaadwillende had hier echt wel misbruik van kunnen maken door mensen naar een fake-website toe te sturen die zich voordoet als de echte mastercard website.

Laat ik de gelegenheid dus maar gebruiken om iedereen er op te wijzen om DNSSEC in te schakelen. Dat haalt de angel uit dit soort blunders die nu eenmaal niet echt te voorkomen zijn. Fouten zijn niet zo erg als je maar een manier hebt om ze op te vangen en te corrigeren. DNSSEC is een mooi extra vangnet.

[Scriptkid]

Hoe helpt dns sec hier, je wordt dior gestuurd naar een dns server van iemand anders beheerd door iemand anders

[CAPSLOCK2000]

Hoe helpt dns sec hier, je wordt dior gestuurd naar een dns server van iemand anders beheerd door iemand anders

De server waar je naar toe gestuurd wordt heeft een andere handtekening waardoor je onmiddelijk ziet dat het antwoord niet echt van mastercard komt. Zo'n handtekening namaken of per ongeluk de vekeerde invoeren is eigenlijk niet mogelijk.

[Reactie gewijzigd door CAPSLOCK2000 op 23 januari 2025 18:43]

[dasiro]

dat is toch ook het geval met een gewoon certificaat van een traditionele DNS?

[dieter001]

Je bedoelt waarschijnlijk een SSL certificaat op de website? Je moet helemaal niet hun private key te pakken zien te krijgen, je maakt er gewoon een nieuwe aan bij Sectigo. Het enige wat je moet doen is een veldje in DNS aanmaken om te bewijzen dat jij MasterCard bent en de controle had hij daar dus over. Je browser vertrouwt Sectigo en kan met de public key de nieuwe private key gewoon decrypteren en gaat er dus verkeerdelijk van uit dat je op de legitieme MasterCard zou zitten.

[Raymond Deen]

Bijna goed. De private key wordt niet gedecrypteerd hoor, want die zit helemaal niet in het certificaat dat gedecrypteerd wordt. Gelukkig maar, want anders was de waarde van die private key niet zo hoog meer…

[CAPSLOCK2000]

Ik snap niet wat je bedoelt met een gewoon certificaat van een traditionele DNS.

[Scriptkid]

Dat is toch juist niet het geval want het is een valide doorsturing , alleen wissel je dan van dns sec naar non sec. Dat zou geen error mogen geven want je doet een valide ns doorgeven.

[Reactie gewijzigd door Scriptkid op 23 januari 2025 21:56]

[gertvdijk]

Ook voorstander van DNSSEC, maar dat heeft op dit probleem bij MasterCard weinig betrekking. Een legitieme maar foutief record value naar een extern domein was dit, daar doet DNSSEC alleen maar een signature overheen die vervolgens gewoon valideert.

[CAPSLOCK2000]

Een legitieme maar foutief record value naar een extern domein was dit, daar doet DNSSEC alleen maar een signature overheen die vervolgens gewoon valideert.

De beveiliging komt één stap later, als de client naar de "valse" DNS-server gaat kan die niet antwoorden met de juiste sleutel. De sleutel die de DNS-server gebruikt om z'n eigen records te ondertekenen moet namelijk gepubliceerd worden in de parent zone. Een foute verwijzing in de parent zone is geen probleem zolang de ontvanger geen beschikking heeft over die sleutel.

[zenlord]

[...]
Laat ik de gelegenheid dus maar gebruiken om iedereen er op te wijzen om DNSSEC in te schakelen. Dat haalt de angel uit dit soort blunders die nu eenmaal niet echt te voorkomen zijn. Fouten zijn niet zo erg als je maar een manier hebt om ze op te vangen en te corrigeren. DNSSEC is een mooi extra vangnet.

Maar als een aanvaller zelf een DNS server kan opzetten die gequeried wordt, dan kan die toch ook valse DNSSEC RR's genereren?
Ik ben helemaal voor DNSSEC, en heb het al vele jaren op mijn privedomein draaien, maar denk niet dat het deze situatie had kunnen voorkomen.

[CAPSLOCK2000]

Maar als een aanvaller zelf een DNS server kan opzetten die gequeried wordt, dan kan die toch ook valse DNSSEC RR's genereren?

Nee, dat kan die server niet. Om precies te zijn kan die server niet de juiste handtekening zetten waardoor onmiddelijk duidelijk is dat die records onbetrouwbaar zijn.

Het zou pas fout gaan als de beheerder niet alleen en tikfout maakt maar ook de handtekening (sleutel) van de valse server toevoegt. Dat laatste kan echt niet zomaar gebeuren op grond van een tikfout.

[zenlord]

Excuses. Jullie hebben gelijk! Was even die glue records vergeten (en had beter moeten weten, want ik heb onlangs nog een subdomein beveiligd :-/)

[ZinloosGeweldig]

DS Records

[mrdemc]

Alleen op jouw DNS server de dnssec aanmaken en je records ondertekenen heeft niet zoveel zin. Je zult aan je registrar wel moeten doorgeven welke key erbij hoort zodat deze doorgegeven wordt van bovenaf. Dan is er een volledige chain. Aangezien je het domein niet zelf geregistreerd hebt, kun je ook niet doorgeven welke key erbij hoort en werkt het niet.
Daarnaast ging het in dit geval ook nog eens om subdomeinen.

[Reactie gewijzigd door mrdemc op 23 januari 2025 18:41]

[zenlord]

Excuses. Jullie hebben gelijk!

[KoeKk]

Maar die RR’s valideren niet omdat de echte zsk en ksk niet in handen zijn van de kwaadwillende, toch?

[Triblade_8472]

Mastercard ontkent volgens de onderzoeker dat de typefout een beveilgingsrisico veroorzaakte maar heeft het probleem wel opgelost. Het bedrijf zou oorspronkelijk niet op de melding van Caturegli hebben gereageerd en ondernam volgens hem pas actie nadat Krebs hier iets over publiceerde.

Ik hoop zo dat een overheid of een DNB-achtige toko dit oppakt en ze flink beboet voor verzuim.

Het niet onderkennen èn niet reageren is echt zo fout en niet modern. In onze digitale wereld kan dit echt gewoon niet meer.

Fouten maken mag, ontkennen ervan niet.

[Huugje]

Ze ontkennen dan ook helemaal niet dat er een fout gemaakt is, enkel dat die fout geen veiligheidsrisico inhield. Of dat laatste zo is zou ik niet kunnen zeggen.

[latka]

In een ander artikel hierover las ik dat Mastercard aangaf dat er geen veiligheidsrisico voor de infrastructuur van Mastercard was. Dat is wel een geweldige spin, want dat klopt. Het zijn alleen je klanten die geld afhandig gemaakt kunnen worden hiermee, maar dat is geen veiligheidsrisico, maar business-as-usual.

[wiseger]

Hoe dan? Hoe verliest een klant zijn geld als de app naar een verkeerd IP adres gestuurd wordt?

Vervelend dat de app dan niet werkt maar veel verder ook niet.

[latka]

Valse inlogpagina. 2FA fake pagina's etc. Het standaardadvies "kijk of de URL klopt en er een slotje staat" valt in het water: er staat een slotje en de URL lijkt ok.

[wiseger]

Inlog pagina? Je betaald met een creditcard door de naam, het nummer, verval datum en de code achterop de kaart in te voeren. Daarna vaak via de app autoriseren.

[latka]

Kijk voor een uitgebreider verhaal anders even hier.

[laurxp]

Oh, het is zelfs nóg erger! Mastercard heeft de onderzoeker na publicatie gevraagd om de post te verwijderen, en beschuldigd hem van onethisch en onprofessioneel gedrag.

Als het geen beveiligingsrisico is, waarom moet hij dan de post offline halen?

[michelr]

Dus dat, en dit saillante detail mis ik in de post hier. Het lijkt er nl. sterk op dat er een poging was om de onderzoeker de mond te snoeren onder het mom van "responsible disclosure".

[bartje]

Stond dit bericht niet 2wekeb terug ook al op tweakers?

[edit]
Na de reacties hieronder denk ik dat in het ergens anders gelezen heb. Maar ik heb dit zeker voorbij zien komen incl dezelfde screenshot.

[Reactie gewijzigd door bartje op 23 januari 2025 18:35]

[Bart.net]

Philippe heeft dit zelf pas een week geleden op zijn linkedin gedeeld (exacte datum onbekend), en deze screenshot is van 9 dagen terug. En ik heb dit bericht niet eerder gelezen. Dus ik denk het niet.

[HKLM_]

16 januari 2025 https://a42.tech/blog/en/...tercard-exposed-for-years

[zenlord]

Lijkt me sterk - Caturegli heeft het zelf pas een week geleden op LinkedIn geplaatst, en Krebs heeft er gisteren over geblogged.
De foute configuratie zal wel vaker voorvallen, maar dat het bij een reus als Mastercard in een gevoelige sector als betalingsverkeer óók gebeurt en zo lang ongemerkt blijft, is toch enigszins verontrustend.
De opgezette DNS server kreeg requests voor MX records, wat wil zeggen dat de onderzoeker de SPF en DKIM configuratie kon vervalsen - weliswaar enkel voor die toestellen die tijdelijk van zijn DNS-server gebruik maakten, maar toch: enkele DNS records, een nagemaakte website (met een A/AAAA RR) en een phishing mail naar enkele duizenden mensen, en je email krijgt een perfect groen vinkje bij een subset van de ontvangers, waarna je er misschien wel in slaagt om hen hun wachtwoord te laten ingeven...

[HKLM_]

Ik heb het inderdaad een week of twee geleden ook al ergens langs zien komen in een bericht online.

Gevonden is van 16 januari 2025
https://a42.tech/blog/en/...tercard-exposed-for-years

[Reactie gewijzigd door HKLM_ op 23 januari 2025 18:35]

[SunnieNL]

Volgens de post op linkedin had niet hij maar iemand uit rusland het domein geregistreerd

"someone in Russia registered this typo'ed domain back in 2016 and had it sporadically resolve to an IP address in Germany for a few years (185.53.177.31)". 😱

[usr-local-dick]

Er zijn tools waarmee je allerlei checks kan doen op een domein. Ik ben zelf fan van Zonemaster. Heel erg uitgebreid en zeer volwassen.
Is standalone ook prima te gebruiken. En ze hebben containers, wat handig is want perl.
Omdat wij toch al een paar nagios dozen hadden heb ik een nagios plugin gemaakt voor zonemaster, wij monitoren nu een trits domeinen die voor ons belangrijk zijn.

We hadden een keer een secondary die ergens anders in Europa staat, bij een andere organisatie, en waar iets in de config omgevallen was, waardoor die niet meer vond dat hij authoritative was. Maar het was dus een van vier secondaries, als je daar niet specifiek naar zoekt ga je dat bijna niet merken. Dit is ongeveer hetzelfde als het Akamai issue.

Onze monitoring pikte het direct op.

Je moet deze monitoring natuurlijk wel aanzetten voordat iemand een rogue nameserver neerzet op een typo squatted adres van je

[kodak]

Dat mastercard een incident heeft wat ze zonder redelijke argumenten geen probleem vinden is ernstig. Zeker omdat er ook aanwijzingen zijn dat criminelen dit mogelijk al eens misbruikt hebben. Genoeg redenen dat toezichthouders onderzoek naar Mastercard gaan doen.

Maar de onderzoeker heeft ook wat uit te leggen. Hij legt niet uit wanneer hij wat precies gedaan heeft om het probleem meteen op te lossen zonder eigen belangen voorop te stellen. Het is niet bekend wanneer hij mastercard voor het eerst gewezen heeft op het probleem. Het is niet duidelijk waarom hij wel maanden de tijd nam om het domein te kopen. En volgens Brian Krebs is er een waarschuwing naar Mastercard verzonden, meer worden niet genoemd. Onderzoek doen om een punt te maken terwijl al 30 jaar bekend is wat de risico's zijn lijkt meer op niet weten hoe je die resultaten kan gebruiken, het risico zelf niet snappen of perse het eigen experimenteren belangrijker vinden dan het probleem zo snel mogelijk laten oplossen. Laat daarom als onderzoeker ook minstens ook zien wanneer je precies bent gaan waarschuwen en waarom je het nodig vond liever te wachten en meer onderzoek te doen.