The payment card giant MasterCard just fixed a glaring error in its domain name server settings that could have allowed anyone to intercept or divert Internet traffic for the company by registering an unused domain name. The misconfiguration persisted for nearly five years until a security researcher spent $300 to register the domain and prevent it from being grabbed by cybercriminals.
A DNS lookup on the domain az.mastercard.com on Jan. 14, 2025 shows the mistyped domain name a22-65.akam.ne.
From June 30, 2020 until January 14, 2025, one of the core Internet servers that MasterCard uses to direct traffic for portions of the mastercard.com network was misnamed. MasterCard.com relies on five shared Domain Name System (DNS) servers at the Internet infrastructure provider Akamai [DNS acts as a kind of Internet phone book, by translating website names to numeric Internet addresses that are easier for computers to manage].
All of the Akamai DNS server names that MasterCard uses are supposed to end in “akam.net” but one of them was misconfigured to rely on the domain “akam.ne.”
This tiny but potentially critical typo was discovered recently by Philippe Caturegli, founder of the security consultancy Seralys. Caturegli said he guessed that nobody had yet registered the domain akam.ne, which is under the purview of the top-level domain authority for the West Africa nation of Niger.
Caturegli said it took $300 and nearly three months of waiting to secure the domain with the registry in Niger. After enabling a DNS server on akam.ne, he noticed hundreds of thousands of DNS requests hitting his server each day from locations around the globe. Apparently, MasterCard wasn’t the only organization that had fat-fingered a DNS entry to include “akam.ne,” but they were by far the largest.
Had he enabled an email server on his new domain akam.ne, Caturegli likely would have received wayward emails directed toward mastercard.com or other affected domains. 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. He may even have been able to passively receive Microsoft Windows authentication credentials from employee computers at affected companies.
But the researcher said he didn’t attempt to do any of that. Instead, he alerted MasterCard that the domain was theirs if they wanted it, copying this author on his notifications. 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.”
Meanwhile, Caturegli received a request submitted through Bugcrowd, a program that offers financial rewards and recognition to security researchers who find flaws and work privately with the affected vendor to fix them. The message suggested his public disclosure of the MasterCard DNS error via a post on LinkedIn (after he’d secured the akam.ne domain) was not aligned with ethical security practices, and passed on a request from MasterCard to have the post removed.
MasterCard’s request to Caturegli, a.k.a. “Titon” on infosec.exchange.
Caturegli said while he does have an account on Bugcrowd, he has never submitted anything through the Bugcrowd program, and that he reported this issue directly to MasterCard.
“I did not disclose this issue through Bugcrowd,” Caturegli wrote in reply. “Before making any public disclosure, I ensured that the affected domain was registered to prevent exploitation, mitigating any risk to MasterCard or its customers. This action, which we took at our own expense, demonstrates our commitment to ethical security practices and responsible disclosure.”
Most organizations have at least two authoritative domain name servers, but some handle so many DNS requests that they need to spread the load over additional DNS server domains. In MasterCard’s case, that number is five, so it stands to reason that if an attacker managed to seize control over just one of those domains they would only be able to see about one-fifth of the overall DNS requests coming in.
But Caturegli said the reality is that many Internet users are relying at least to some degree on public traffic forwarders or DNS resolvers like Cloudflare and Google.
“So all we need is for one of these resolvers to query our name server and cache the result,” Caturegli said. By setting their DNS server records with a long TTL or “Time To Live” — a setting that can adjust the lifespan of data packets on a network — an attacker’s poisoned instructions for the target domain can be propagated by large cloud providers.
“With a long TTL, we may reroute a LOT more than just 1/5 of the traffic,” he said.
The researcher said he’d hoped that the credit card giant might thank him, or at least offer to cover the cost of buying the domain.
“We obviously disagree with this assessment,” Caturegli wrote in a follow-up post on LinkedIn regarding MasterCard’s public statement. “But we’ll let you judge— here are some of the DNS lookups we recorded before reporting the issue.”
Caturegli posted this screenshot of MasterCard domains that were potentially at risk from the misconfigured domain.
As the screenshot above shows, the misconfigured DNS server Caturegli found involved the MasterCard subdomain az.mastercard.com. It is not clear exactly how this subdomain is used by MasterCard, however their naming conventions suggest the domains correspond to production servers at Microsoft’s Azure cloud service. Caturegli said the domains all resolve to Internet addresses at Microsoft.
“Don’t be like Mastercard,” Caturegli concluded in his LinkedIn post. “Don’t dismiss risk, and don’t let your marketing team handle security disclosures.”
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).
Wow, this is so vindicating. We use the Mastercard Virtual Card service for making payments. I’m fairly certain this issue was effecting email validation, as we had a lot of random payment emails get rejected for failing to match the Mastercard listed servers.
They told us for months it was our problem. Probably 98% of the payments worked fine, but then we’d get a couple bounces a week. We ended up changing all the header info to avoid it, but that caused other issues.
MC appears to have fallen victim to slothful practices, as evidenced by the shameful attempt to deflect responsibility and avoid finding a solution.
I was once a subscriber to LifeLock services. Upon renewal, I noticed that the LifeLock website stored my credit card information (everything, including the CVV2 code) in clear text on my computer (the customer’s computer). I politely and respectfully notified LifeLock. Their response was childish and downright hostile. I would guess that their website still does that. They, and their QSA, should be ashamed.
That’s bad but honestly what the fuck does this have to do with the subject of the article beyond “companies suck at security”
Between your screen name and your rude response, might be better if you were neither seen nor heard.
You should have reported it to the credit card company. All the major credit card companies have rules in their Merchant Agreements prohibiting storing the CVV2 code. The credit card companies will tell you to contact the issuing financial institution to report it. They in turn will report it to the credit card company, which according to the terms of the merchant agreement gives them the power to levy fines on a per violation basis. When they get their bill for credit card processing, the’d be in for a shock.
Since Rob Ellison posted about LifeLock, let’s remind everyone about their bad practices:
“LifeLock, an identity-theft protection company, was fined $100 million by the Federal Trade Commission (FTC) in December 2015 for violating a 2010 federal court order[1][4]. This fine represents the largest monetary award obtained by the FTC in an order enforcement action[4].
“The FTC alleged that LifeLock violated the 2010 order in four ways:
1. Failing to establish and maintain a comprehensive information security program to protect users’ sensitive personal information[4].
2. Falsely advertising that it protected consumers’ data with the same safeguards used by financial institutions[4].
3. Falsely claiming it would immediately alert consumers of potential identity theft[4].
4. Failing to comply with the order’s recordkeeping requirements[4].
“Of the $100 million fine, $68 million was allocated for redress to consumers who were allegedly injured by LifeLock’s behavior[3]. The remaining funds were to cover additional settlements with state attorneys general and any leftover money would be returned to the FTC[3].
“This settlement followed a previous FTC action against LifeLock in 2010, where the company agreed to pay $35 million in total, including refunds to consumers and fines to the FTC and state attorneys general[3].
“In October 2019, the FTC began sending refund checks totaling more than $31 million to LifeLock customers as part of the settlement[5].
Citations:
[1] https://phys.org/news/2015-12-identity-theft-firm-fined-mn.html
[2] https://www.phoenixnewtimes.com/news/lifelock-ordered-to-pay-100-million-for-deceptive-ads-and-bad-security-7903740
[3] https://www.insideprivacy.com/data-security/ftc-obtains-record-100-million-settlement-with-lifelock/
[4] https://www.ftc.gov/news-events/news/press-releases/2015/12/lifelock-pay-100-million-consumers-settle-ftc-charges-it-violated-2010-order
[5] https://www.ftc.gov/news-events/news/press-releases/2019/10/ftc-sends-checks-totaling-more-31-million-lifelock-customers
[6] https://content.next.westlaw.com/practical-law/document/I02f47330a46e11e598dc8b09b4f043e0/LifeLock-to-Pay-100-Million-in-FTC-Settlement?contextData=%28sc.Default%29&transitionType=Default&viewType=FullText
[7] https://www.fredlaw.com/alert-lifelock-to-pay-100-million-to-settle-ftc-charges-of-deceptive-advertising
[8] https://en.wikipedia.org/wiki/LifeLock
Not surprised. There was someone from my old company who outright lied to Mastercard about their role and experience. They’re now in charge of helping maintaining their infrastructure.
A few concerned employees disclaimed this to Mastercard but the individual is still employed. And my old company bosses couldn’t care less.
The role title was made up and the duties were all made up too.
Lmfao 3 months and $300. Could have just contacted their security team or direct emailed the CIO.
Comically stupid.
Duh, why didn’t I think of that! Must be nice reporting vulnerabilities in your magical world where CIOs and security teams act from a single unsolicited email!
hahahahaha rc, you doing alright bruh? because you look toastyyyyyy hahaha.
Hey smoothbrain, why don’t you go back to watching My Little Pony and leave the conversation here to the grownups!
Hey brainrot… why don’t you go back to eating that junk cereal with the other toddlers and leave the conversation to the real grownups.
I agree that this article is as ridiculous as the actions of the “security expert”.
Us industry professionals know this is a nothing burger with extra cheese, the rest of the World thinks they have gotten a peak behind the curtain, ads were displayed, clicks registered and the planet has been allowed to spin for yet another 24 hours.
I don’t get it, why talk to MasterCard and not Akamai? While the issue was affecting MasterCard, it was also affecting others that made the same typo. Control of the domain if anything, should go to Akamai.
Akamai provides a list of NS entries to the customer (Mastercard, in this case). The customer then adds them to THEIR DNS. Akamai can’t add/edit the entries in Mastercard’s DNS.
The chances of reaching the right person at MC on first contact are about zero.
Let me guess: All of these glaring errors are a result of DEI programs – for white coders only.
Dude, overprivileged white guys make at least as many glaring errors as so-called DEI hires. There’s no monopoly on incompetence.
Please run that DNS response over to ChatGPT and ask “What’s wrong with these DNS records?” I’m curious about whether our Digital Overlords would have caught it.
Global and regional Mastercard CTOs plus all IT Security Personal must be FIRED immediatley!
So theoretically, some evil trillionaire could purchase all available .ne addresses and “squat” until the same address with .net become registered and DNS errors start to pay out.
Now I know what to do with my trillions. Thanks.
So much misinformation in the article.
First, the NS records point to the authoritative DNS servers. Until the misspelled domain was registered and assigned an IP through an A record, that NS record would simply not resolve and the DNS client would try another from the list.
Second, NS records are _not_ used for directing email. MX records are used for that.
Third, security certificates are issued to the website domain, not the nameserver domain name. It would not be a simple matter to get a valid SSL certificate for *.MasterCard.com just by controlling a DNS server.
What could happen? The rogue DNS server could be configured to return records pointing to IP addresses for servers they control. Browsers trying to access MasterCard.com would load a rogue site. If they have visited mastercard.com before HSTS would generate an error. If it’s their first visit, they wouldn’t likely see the charms indicating a secure connection.
Email would likely be able to be redirected to a rogue server. Last I checked SSL isn’t commonly enforced for SMTP delivery.
Windows machines have SSL certificates in place to protect the domain. Windows would not have shared any credentials or other sensitive info with rogue servers.
tldr;: Sure it’s bad. But the description provided in the article is incorrect and blown out of proportion. I’m surprised the article isn’t overtly sponsored by some company peddling the “solution.”
Thanks for the DNS mansplaining! While some of your points are valid, they don’t actually contradict the article. The article doesn’t claim that NS records directly handle email or grant automatic access to SSL certificates. The article highlights how a rogue DNS server, resulting from this misconfiguration, could create downstream risks, such as redirecting traffic, manipulating MX/TXT/PTR records, or even enabling the issuance of DV SSL certificates under certain conditions.
From my perspective, the article is written for a general audience. While it doesn’t go into technical details like MX record mechanisms or HSTS protections, that doesn’t make it inaccurate. The key takeaway remains the same: a DNS misconfiguration like this introduces risks and attack vectors that threat actors could exploit.
Nothing to sell here… just trying to raise awareness about an overlooked issue.
Is ‘t there something called DNSSEC to prevent stuff like that?
As long as the domain is used. This domain is not even used.
‘Blah, blah, blah, blah … tldr;: Sure it’s bad. But … blah, blah, blah, blah’
I think you are contradicting yourself there Champ. If it is bad, Brian should and is raising awareness. What is your problem?
Here’s my take: It’s becoming more and more normal for corporations to be dismissive or hostile towards security researchers that are simply trying to help them.
It makes no sense ethically or financially, when you send people the message:
“We won’t acknowledge your help, or we will even come after you for it”. Now people are inventivised to sell their exploits to someone who will be grateful: criminals.
I will avoid business with MC until they apologize for their toxicity towards security researchers. I do not trust that they are secure nor do they really care to be secure based on their actions.
That’s partially because of the smug satisfaction and clout chasing endemic to the world of “security researchers.” This goes way back to when hacking and cracking was a very competitive niche subculture, not a trillion-dollar industry.
The performative white knighting that some “security researchers” display is clearly rooted in a need for attention and social validation of an extremely niche hobby, which is often tied up in a savior complex.
I respect the guy for finding a bug, even though it seems like some Russian creep found it a long time ago, but when you copy a web journalist on your disclosure as an “insurance policy” to ensure that you’re taken seriously, it comes off as coercive.
It’s easy to think of a huge multinational company as a monolithic entity, but this entity is ultimately composed of individual devs who have to fix their mistakes. The right thing to do is reach out to the company first, or use a confidential bug disclosure platform that can coordinate with the affected entity. If the bug isn’t fixed after a certain period of time, you could perhaps consider reaching out to a journalist or some other neutral third party. But when you show up at the door for your first visit with the media at your side, the person you’re visiting is probably going to question your motives.
“but when you copy a web journalist on your disclosure as an “insurance policy” to ensure that you’re taken seriously, it comes off as coercive.”
Coercive of what, of fixing the glaring DNS bug that could leak personal info of millions if exploited? We don’t know the full disclosure effort back/forth, but we know that when it was finally disclosed (publicly, yes) the company didn’t take it seriously (deliberate denial) and tried to silence the whistleblower on at least 1 platform. This is after the threat has been completely explained, explored and removed by said researcher. It would be BETTER PR to say “wow, thanks” and maybe even give him a $300 debit card unprompted for catching their glaring, serious, superbowl of a typo. But no, they wanted to play it down. Ever see someone trip hard on the sidewalk and try to play it off? Sure, blame the sidewalk.
Philippe Caturegli in my amateur opinion you should have got payed something/anything? and a sincere thank you from MC but in this day and age that might be a long time coming. Cheers and thank you from the peanut gallery.
if you are sitting on any other items involving this company i recommend you sell it to the highest bidder and let the company get burned. disgusting behaviour towards the researcher.
I am an IT professional for the last 30 years working in Operations/DevOps environments.
The erroneous had a TTL of 1 hour. That means that your systems is ADVISED to hold on to that record for 1 hour before checking again.
The whole thing could have been cleared up in…..one hour. So, going through the heroic exercise of taking three months to secure domain in order to intercept malicious or misdirected traffic really only extended MCs exposure. The security expert could and should have alerted MC immediately if they really cared about addressing the security aspect.
Notice in the article they did not want the domain, no need once you modify the record.
Also, when the author discusses TTL with regard to network packets living on the network, “a setting that can adjust the lifespan of data packets on a network”, he is actually mentioning a network packet TTL. That is a completely different thing and arguably should not be called a TTL. The rest of that state, made by the author, is just scifi.
It really leaves me wondering why this article was written, I guess I should follow the money.
Oh nose. Lookout DevOps has arrived. Turn off all your security protocols so they can deliver all the projects they promised management, due yesterday … again. Sigh.
You are aware this is Security Investigations and not a DevOps Blog?
You are right in that this could have been cleared up in an hour, but it didn’t. It took 5 f*cking years! And for the response MasterCard gave to it; THAT is abysmal. In the world of Occupational Health & Safety this is equivalent to a ‘near miss’, if not for an external researcher, a reportable event with serious consequences. Where were the audits and red flags? Such a basic simple typo error, not self resolved by a corporation with US$42 billion in assets is a disgrace, and you want to sit there and defend them with ‘nothing to see here’. You my friend, are part of the problem. As long you take your six figure salary home everyday, who cares about Security right?
Hey Hey, SecDevOps is here, dude went out of the way to buy the domain AFTER realizing MC was not respoding to him. So not only did MC did not perfom anual DNS record audits as defied by their security complice standards, MC also failed to review bounty reporting. For an organization of this size IF it took 1 year to respond to the issue it would be a notibe secryt breach on the annnual report, but the fact that it took 5 years … managers in multiple positions need to fired, annual insurace costs may be affected etc.
It is both absurd and terrifying that it took so long to fix this. Really enjoy your articles!
It’s very difficult to protect your comany’s identity by registering every possible TLD variation. Akamai.xxx anyone? Up for grabs! There are comapnies that will do it for you, it’s not cheap, and I don’t think that even includes keeping an eye on Web3 Domain variants.
It’s very difficult to protect your comany’s identity by registering every possible TLD variation. Akamai.xxx anyone? Up for grabs! There are companies that will do it for you, it’s not cheap, and I don’t think that even includes keeping an eye on Web3 Domain variants.
This is EXACTLY one of the problems with inventing obscure TLD’s on a whim.
But the actual incident happened on .ne which wasn’t invented on a whim, it’s a country code.
I posted about this to Mastercard’s Facebook page and it was deleted with seconds.
Bugcrowd is a joke anyway.
So, basically, spelling IS important?
Everyone knows how to spell “net.” Anyone can make a typo. We all know how to spell the words involved.
(In before “AI doesn’t make typos, should solve all problems”)
Man, if all those Nigerian Prince scams back in the day had gotten a hold of this…..
Wrong commeNt