I'll chime in here as this is (very) related to my research.

This instance of openly-registerable nameservers is just one (relatively rare) subset of a wide class of dangling DNS issues [1].

Much more common is direct mapping of names to IP addresses on cloud providers that can be obtained by attackers [2][3]. Because of the scope and lack of global visibility that often comes with cloud services, an enterprise that uses is the cloud is very likely to have some vulnerabilitity like this under some subdomain.

Unfortunately bug bounty programs often blanket exclude any form of "subdomain takeover" as a valid security threat, despite the fact that they're easily exploitable once discovered. We have internal (and public[4]) data showing all manner of sensitive information leaked as a result of this sort of configuration mismanagement.

Ultimately, as others have observed, the current vulnerability disclosure landscape makes it far too easy for corporations to weasel out of acknowledging bona fide vulnerabilities, and of course ethical and legal expectations make it impossible for good-faith researchers to meet the bar of proof expected by these providers.

To others' comments: yes, these vulnerabilities are trivially exploited to provision TLS certificates in practice, a risk that is unfortunately downplayed.

[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

The Bugcrowd portion of this story is not something I expected to see. The screenshot of the mail is apparently sent from the "Platform Behavior Standards Team," which means that either Bugcrowd are taking a rather expansive view of their platform standards [1] by attempting to police behaviour outside the platform, or Mastercard are impersonating official Bugcrowd staff.

Neither option is particularly palatable.

[1] https://www.bugcrowd.com/resources/hacker-resources/platform...

> acknowledged the mistake, but said there was never any real threat to the security of its operations.

Doesn't behavior like this mean that security researchers are more likely to intrude further next time -- at this company and others -- to gather more evidence of impact, expecting the company to lie about it otherwise?

If you want some corporate spokesperson to be able to say "nothing to see here", shouldn't you reward the researcher amply enough that they're fine with the impact being downplayed?

Then kinda going after the researcher in trying to suppress the news, after (AFAICT) the researcher already did the right thing... Does the credit card company have a reason to do that? Or is it more likely some misguided PR staff thinking that's their job? Or some exec ultimately responsible for the infosec mistake, personally not wanting that embarrassment on their watch, and using company resources to try to suppress news of it?

A few years ago in Ukraine all (most?) online transactions had to be verified via their service called "masterpass". I guess it's their approach to 3DS or something.

Anyway, their SSL certificate expired, as it naturally does with enterprise webs.

All (most?) online transactions with certain class of MasterCard cards were completely SOL at that moment.

They did not renew the cert for more than a year. No amount of communication attempts with MasterCard could help, neither from customers (me) nor from banks' IT departments. Then they just quietly dropped the service altogether.

While I was poking I have found that the service is written in microsoft-something (IIS), certificate chain was unusually long with intermediates which I never heard of and all of that is hosted in a third-world country quite far away from Ukraine. But that's another story.

> One final note: The domain akam.ne has been registered previously — in December 2016 by someone using the email address um-i-delo@yandex.ru. The Russian search giant Yandex reports this user account belongs to an “Ivan I.” from Moscow. Passive DNS records from DomainTools.com show that between 2016 and 2018 the domain was connected to an Internet server in Germany, and that the domain was left to expire in 2018. > This is interesting given a comment on Caturegli’s LinkedIn post from an ex-Cloudflare employee who linked to a report he co-authored on a similar typo domain apparently registered in 2017 for organizations that may have mistyped their AWS DNS server as “awsdns-06.ne” instead of “awsdns-06.net.” DomainTools reports that this typo domain also was registered to a Yandex user (playlotto@yandex.ru), and was hosted at the same German ISP — Team Internet (AS61969).

Yeesh

> If he’d abused his access, he probably could have obtained website encryption certificates (SSL/TLS certs) that were authorized to accept and relay web traffic for affected websites.

> “We have looked into the matter and there was not a risk to our systems,” a MasterCard spokesperson wrote.

One of them have to be incorrect, and both have the incentive to lie/embellish.

Obviously this was a huge mistake on Mastercards part, but does anyone else think it's a mistake to even /have/ domains that are literally one letter away from the original TLD's? For instance .com and .co, .net and .ne. It just seems to be asking for trouble. If those didn't exist, they couldn't be registered and the erroneous DNS request would just go nowhere.

He should have offered the domain name to akamai. Other requests are also coming to the same address. And akamai should have the integrity to handle them

> A few hours later, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations.

> “We have looked into the matter and there was not a risk to our systems,” a MasterCard spokesperson wrote.

This is a classic, “we have investigated ourselves and found no wrongdoing”, response

This is a multibillion dollar public company that has at least 3.4B branded cards in the wild, and processed 44.3B credit/debit/cash transactions across the globe in Q3 2024.

Admitting wrongdoing is a _short term_ mistake in the market, but sets a shitty company culture. Just like ClownStrike.

A disruption to predatory/parasitic credit/debit networks is well overdue.

> A few hours later, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations.

> “We have looked into the matter and there was not a risk to our systems,” a MasterCard spokesperson wrote. “This typo has now been corrected.”

Always the same. These statements make my blood boil.

We recently had a production security incident because our vendor was using Vercel and decided to change the domain name entry to something else. They left the previously registered domain go back to the pool where an attacker picked it up seconds after let go from the vendor's infra. We started to see our website spreading malware in minutes after this.

I am not sure why anybody would take these matters lightly.

MasterCard is not alone. On of the [smaller] Canadian banks and Canada Post had similar issues and yes, reply was also in a style "We have looked into the matter and there was not a risk to our systems". It seems that Canada Post fixed that eventually, while the bank fixed it ... and then re-introduced it recently again.

> “We have looked into the matter and there was not a risk to our systems,”

I'll be honest, that doesn't appear to be the case to me. Almost certainly if that researcher was allowed to go ahead and register an HTTPS cert for the domain there'd be plenty of juicy traffic merely protected by SSL and nothing more.

> he alerted MasterCard that the domain was theirs if they wanted it,

feels wrong, considering all the other domains making the same typo.

Yeah, huge surprise.

Have you ever tried to report a technical issue to a Big Tech company, like, at all? If so, 'silence' is the best you can expect, with 'a threatening letter' and 'a SWAT visit' being the runners-up.

Example of the first: if your mail server uses the default-Windows-2016-TLS stack, Facebook's mail servers will immediately disconnect after issuing a STARTTLS command and receiving your server certificate. Why? No idea, everyone else seems to be fine, but this has been ongoing for years.

Second example: you can steal any Dutch "OV bike" simply by impersonating the MiFare classic UID of any valid subscriber, without any rate limits on those attempts. I reported this issue to them in 2016, they tried to sue me and failed, then tried to talk me and failed to listen, and to this day this vulnerability exists.

Third example: phew, none (SWATs are not as eager to mobilize around here), but I would not be surprised, like, at all, if I were to get an early-morning wake-up call just for trying to correct someones SPF records via an advisory email...

Not a good look for BugCrowd to try to intimidate users on their customers' behalf.

Lots of gaslighting in that email, which shows the real purpose of platforms like Bugcrowd: to provide control over the narrative back to companies. They have completely subverted the meaning of "responsible disclosure".

I don't know if it would be a good or a terrible idea to have, as a last resort, a law entitling researchers to a reward for vulnerabilities, similar to laws that give someone who finds a lost item a right to a reward. Hopefully, in most cases it would not need to be invoked and the issue would be settled privately.

It's funny because I own such a domain. A large financial institution in my country changed its main domain name to something that had a very clear potential for a typo.

I informed them, was ignored and just registered the domain myself. I'm showing a large banner and added GDPR friendly analytics (Vince, I like its simplicity and efficiency). I'm getting a couple of victims every day.

Maybe this is a sign to get in touch again with them and if they ignore me, just publish it.

I'm surprised Akamai didn't have any alerting in place to tell Mastercard that the nameservers they had configured were wrong.

MasterCard saying there was not a risk to their system after being shown how it could have been just shows how inadequate their concern for security is.

Having worked with payment gateways, most people would be appaled at the sloppy code, documentation, and setup of the systems their payment methods are running through.

It's just amazing that more exploitation isn't happening (though a lot of financial cybercrime never gets busted), and a good chunk of security is probably only reliant on the conscience of coders.

It's absulutely shameful that Mastercard said there was no risk. I hope he alerts the U.S. regulators about this (https://www.consumerfinance.gov/).

> Caturegli said it took $300 and nearly three months of waiting to secure the domain with the registry in Niger

Oh, that sounds a lot like how much fun I had trying to register a Tajikistan .tj domain from the USA a number of years ago.

> there was not a risk

Yeah, buy a mistyped domain in question, setup recursive dns to build the picture of requests, build a “apigw” and route users’ requests to your own api gateway, continue until you phish users’ data or steal their money.

Mastercard was too lucky noone had done that and instead it was a good samaritan who secured the domain name to actually protect the giant corp and had reported it directly to them before disclosing it in public(as far as I understood the sequence of events).

And they are lucky there is zero impact(is it?) and unless this story goes viral outside IT/security research bubbles they won’t even care to correct their reputation and also help Bugcrowd find the definition of “ethical” and “professional” in the dictionary.

Stories like this and Andres Freund who caught a supply chain attack before it was deployed to practically all linux servers help me realize that, sometimes, all it takes is for a decent person doing decent things at the right time to help a lot of people avoid a lot of suffering.

These security vulnerabilities, if exploited, could cause massive suffering. But the people who caught them modestly corrected the issue by exercising their competence and decency.

There is another thing which went "unnoticed":

You could register and pay for a DNS name with a noscript/basic (x)html browser... that was destroyed in the last few year, and now you MUST use a google/apple web engine to do so (geeko|blink/webkit)...

The toxic and filthy agenda of big tech is moving forward, nobody does anything, and it seems they got even trump in their pocket, and democrat regulators were not able to acheive anything pertinent.

DNSSEC would have made the typo slightly less problematic. But [az.]mastercard.com does not do DNSSEC ...

See all issues on: https://internet.nl/site/mastercard.com/3122570

Nameserver is not reachable on advertised IPv6:

    $ dig +short +tcp @dns1.mastercard.com dns1.mastercard.com AAAA
    2607:3c00:6404:4::53

    $ dig +tcp @2607:3c00:6404:4::53 mastercard.com SOA
    ;; Connection to 2607:3c00:6404:4::53#53(2607:3c00:6404:4::53) for mastercard.com failed: timed out.

Also: no HSTS on apex, while HSTS with "includeSubDomains ; preload" on www, this does not work! And it's worse, they do some geo-redirect, so apperantly for US IP addresses http://www.mastercard.com redirects to https://www.mastercard.us/en-us.html (see https://hstspreload.org/api/v2/preloadable?domain=www.master...)

I also would expect an IPv6 on the apex/www, since there are quite some ISP's with IPv6 where IPv4 is a GCNAT, if there is a noisy user on the IPv4, it's tricky to block those, except if the ISP supports IPv6 and the web server too.

Weirdly enough the SOA serial which is in YYYYMMDDnn (see https://datatracker.ietf.org/doc/html/rfc1912#section-2.2) was not updated (still indicates 2011):

    $ dig +short +tcp @dns1.mastercard.com mastercard.com SOA
    dns1.mastercard.com. hostmaster.mastercard.com. 2011127982 14400 3600 2419200 300

Some other SOA record abnormalities:

    $ dig +short @a22-65.akam.net. az.mastercard.com SOA
    a1-29.akam.net. hostmaster.az.mastercard.com. 2020068768 3600 600 604800 300

Indicates 2020, and hostmaster@az.mastercard.com is not reachable because az.mastercard.com does not have an MX record, nor A/AAAA record.

Sadly nobody recorded this in either DNSViz history (https://dnsviz.net/d/az.mastercard.com/Z5ErUw/dnssec/ is the first) or ZoneMaster history (see https://www.zonemaster.net/en/result/3fa42e8e683db1bf).

Someone remind me what value business people add to society?

netsec is a joke. i still remember this elevated bash execution which was lying in plain sight since ever, no one saw it.

Mastercard: "We have looked into the matter and there was not a risk to our systems"

Also Mastercard: has expressed concerns about the public nature of this disclosure.

Good for him for making it all public. The only way to (sometimes) get big companies to fix their mistakes (besides the legal system) is to shame them into it.

[dead]

[dead]

[flagged]