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.
Beyond just IPs, there is a giant class of "DNS record pointing to X shared cloud resource that organization no longer controls" issues. The bigger the company, the more widespread the problem. These resource names get released back into a common pool that anyone can register.
Think:
* CNAME pointing to an S3 bucket, and the S3 bucket gets released
* CNAME pointing to Azure Website/WebApp Instance
* A record to an non-elastic IP, and the box gets rebooted
* DNS name using a Route53 name server that no longer part of the org's AWS account
* CNAME pointing to a Heroku/Shopify/GitHub pages account and the account gets deleted/deactivated freely up those names for registration
* MX record pointing to old transaction email provider start up that dies, and someone else registers that domain name...
Why does that happen?
* Decentralization of IT means people spinning up infrastructure not knowing what they are doing
* Great a spinning up infra, but when decomissioning they forget about DNS
* Lots of subsidiaries, lots of brands, different groups, operating in different geographies. All this makes it difficult to discover and enforce proper policies
* Geo-specific websites/apps (Think of all the country-specific websites Coke runs)
* Using some 3rd party vendor and never telling security about it (Marketing spinning up some landing pages on some fly-by-night martech provider or wordpress host, and never turning them off)
I am the Field CTO at a venture backed Israeli cyber security company in this space. I was literally talking to a major computer part company yesterday about the dozen or so Indonesian gambling websites that are "running" on their domain names using their pagerank and links. This is a weekly conversation
What types of actions can you do to correct and prevent this class of errors? I think you could probably enforce deployment and shutdown checklists, perhaps, or have automated DNS checking software to see if any of the issues exist (I bet you guys have a solution for that) but there are so many human-error problems in manufacturing, and I kinda consider the large-scale deployment of apps to have similar issues and failure modes on the human side.
Azure has options when you use their DNS that they tie resource, Public IP, Azure WebApp and other to DNS. If resource is deleted, the record will be NXDomain. AWS probably has something for Route53.
Otherwise, good IaC can help but even in larger companies, I see more ClickOps then I should.
We have an inventory of everything running, and where they are supposed to be running. If service X does not respond on resource Y the team responsible get an ticket. Check is on IP and names, and some other services. There are no good ways to do this other than being meticulous IMHO. Getting dumps of what is running where from all services is rather hard but more or less doable.
- Stay within the cloud provider's ecosystem as much as possible, including for domain registration and DNS. All records then should be pointing to resources that include your account id in them and can't be taken over by others. If you delete the entire account, there'd be nothing to take over.
- Do everything with Infrastructure as Code, including DNS. If a single "terraform apply" creates everything, then a single "terraform destroy" deletes it all, leaving nothing dangling, provided of course that it is setup correctly and doesn't error out midway through a run.
Otherwise, it's a matter of being thorough. Automate what you can, including creating and deleting resources, if not through a single cloud provider API or some standard IaC product, then roll your own software to do it, but have software do it. Regularly roll out and tear down entire test installations of full systems, including valid DNS records. When you intend for them to be gone, ensure they are really, truly gone.
If you can't automate it, then yeah, checklists.
It's one of those things that is simple but not easy. It takes an organization that respects the tedious and time-consuming nature of ops, plans for it, and doesn't push people to cut corners for the sake of speed when the first time trying to do something takes much longer than someone's uninformed first guesstimate.
Really, automate. At a small enough scale, it doesn't matter, but if you're Mastercard doing this kind of thing thousands of times over the course of decades, humans will inevitably make mistakes. Software will make mistakes, too, but at least when you test software, it will do the same thing every time it is tested. Humans do not provide that guarantee, even if they have checklists.
Edit: Note the above is not true for LLMs, so when I say use software, I mean classical deterministic software. Don't have AI do it for you, because LLMs can and will produce different responses every time you make the same request. Don't devolve to making software that is just as flaky as humans.
At least Gitlab (similar to Github pages, I never used Github Pages, always Gitlab Pages) gives you a verification TXT record in your Gitlab Account, which needs to stay in DNS as TXT. So if I used to host hi.example.com on Gitlab (& my own TXT record was hosted, and publicly visible), now I don't own example com, or gitlab account got deleted (but still left DNS CNAME records intact) and scammer gets the domain, when he grabs domain and adds hi.example.com to his Gitlab Account to scam people, his Gitlab Account will have his own TXT record. (now) His hi.example.com can never point to "my" gitlab project or page.
> 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.
This sounds as if it should be more differentiated by how easy the domain would be able to obtain.
Like, it's obvious that "If I somehow took over google.com, I could compromise Google users" is no valid security vulnerability. But if taking over unregistered (or lapsed) domains results in a compromise, as demonstrated here, this should be seen as a valid vulnerability.
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.
Someone else here, although I don't remember who, regularly argues that Bug Bounty platforms exist to capture and prevent responsible disclosure, not encourage it.
If they're regular enough to see your comment, they may be able to expand the idea and explain it better.
> exist to capture and prevent responsible disclosure, not encourage it.
I will say that Google's VRP is the exception. They have top notch people who answer the initial report, will keep you in the loop (usually) and will consider impact if you'd gone further. BC or H1 are hit or miss, and more often miss.
I don't think I make this argument regularly and I wouldn't absolutely say that's the goal of the platforms themselves, but it's an effective outcome - in most cases participating in the program means accepting terms that say you won't disclose without permission, and if the vendor never grants permission you have the choice of disclosing (and potentially being kicked off the platform and also losing any safe harbor protections you had) or just saying nothing.
The wording is also downright terrible. It's phrased as if you've been judged to have done wrongdoing, and your options are to either comply or ask for further clarification why you're in the wrong. No chance given to explain how you're not the one at fault.
From my experience BugCrowd attempts everything to tarpit and delay reports from reaching the actual company. From company perspective this reduces cost (less bounties paid out and less reports to screen by their own staff) while at the same time having plausible deniability for legal reasons.
> 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).
> 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?
Then why not offer them a good (not great) nondisclosure deal?
"Discreetly let us know, at the earliest sign of vulnerability, sign a contract with NDA, and we'll investigate, fix, and compensate you promptly. We'll also publicly acknowledge, in vague terms, for your career development, that you successfully discovered a vulnerability that has been addressed. (But if you intrude beyond the boundaries we've clearly specified, then we don't have a business relationship, and we have appropriate government offices on speed-dial.)"
That's if the company wants NDA. I'm not saying that's how it should be done; just suggesting what seems like a more vendor relationship, business transaction way of being alerted to their own security mess-ups, if that's what they want.
> From a distance, white hat "vulnerability disclosures" start to look like a protection racket.
A pretty big distance.
If a mobster threatens to burn down a building unless you buy their "insurance", that's a protection racket.
If someone finds a major fire code violation and threatens to tell the fire marshal about it unless they fix it within a certain timeframe, that's not a protection racket, even though there's technically a threat involved. If the building owner is a dick about it, then next time that person will probably just go directly to the fire marshal.
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.
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.
> 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.
One of them has an incentive sized in the billions of dollars to lie/embellish. The other thinks about worst-case scenarios from sophisticated attackers all day long. Worst-case attacks from sophisticated attackers are an embellishment when you're talking about a CS:GO server, but not when you're talking about one of the largest payment processors in the world.
I think it heavily depends on what az.mastercard.com actually is or does.
Receiving email directed to x@mastercard.com doesn't sound right, since this is only a subdomain of unknown(to me) use. TLS? Probably, but again, the risk depends on what it is, and wouldn't affect users visiting 'mastercard.com.'
I think the idea was that because this typod domain was being used behind the CDN, you could trick mastercard.com (that uses the CDN) somehow to serve from the hijacked domain that was misconfigured at the CDN.
At least that's my guess, but it's not super clear what attacks would be possible here.
My first thought is using one of the ACME-based certificate providers, since DNS control of a domain is sufficient (either TXT record or directing requests to a HTTP server you control).
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.
Not exactly, since typos can occur anywhere in the name, not just the TLD. Hell, even without typos, you can bitsquat [1] on domains one bit away from popular site names (usually CDNs) and get some traffic because of various computer glitches. Here's a random paper I found (and skimmed) with some examples [2]
I'd expect big companies to use Markmonitor to handle this problem -- basically, they _also_ register all of the one-edit-distance away typos that they can.
According to Wikipedia, Akamai is one of Markmonitor's customers, so it is surprising that this wasn't already registered by them.
I've found that Markmonitor is generally signed up for "public" address like akamai.com but rarely signed up for service domains since "who is going to screw up the service domain?"
I had a friend whose phone number was 591-1XXX and if I picked up the phone and dialed too fast, the 5 might not get recognized by the switch and I'd end up on 911, where I had to say "sorry, wrong number"
Apropos of nothing in particular... that brings back a memory (I used to dispatch for a 911 center in the 910 area code). You get some weird stuff in 911 centers sometimes (go figure, right?). In this case, the thing that sticks in my mind is this payphone that used to be on Bald Head Island by the gazebo. It apparently developed some sort of intermittent fault (possibly due to exposure to salt air, but who really knows?) where it would occasionally call 911 on its own. Or at least that seemed to be the case. We'd occasionally get a call from it, with no one speaking on the other end, and we'd send BHI public safety out there and they wouldn't find anybody around it.
Now you might speculate that it was kids playing or something, but based on the time(s) of the calls, the demographics of the island, etc. we always believed it was just some sort of phone malfunction.
I do IT support for a 911 center. We get about one of these per month coming from landlines on the ILEC's old copper cable plant.
On one serendipitous occasion the fault came from a school district I also support. The fault came from a contingency landline kept around in case the VoIP phone system lost digital PSTN connectivity. I was able to plug-in to the line w/ a butt set and hear clicky, buzzy, nightmarishly bad PSTN sounds thru it.
We turned it over to the ILEC and they "fixed" it. Given the number of "roadkill" splice pedestals I see in my area I feel pretty confident the ILEC isn't doing any maintenance of the copper cable plant at all. (It makes me pretty irritated, considering the favorable tax subsidies they received to build it.)
And yet, almost every private PBX uses "9" as the magic "get an outside line" number. Which then if one is calling a "long distance" number, one's next digit is "1", and "9" followed by "1" is only one mis-dialed digit away from becoming a "911" call.
I.e., New York's original area code is 212, someone in CA, dialing "long distance" to New York needs to dial 9 1 212 xxx xxxx. One button off on the first "2" and they just made a call to 911.
You seem to have no clue what numbers are sensitive? Bank or government phone number could be used to impersonate and steal people's identities, among a whole host of other numbers. Not everything is a life and death matter (and neither was the Mastercard incident).
I mean, the ISO 3166-1 alpha-2 TLDs are clearly useful, but given the address space, there's lots of one away typos there. It's not a big difference when the non contry code domains are also one dropped letter away from an ccTLD.
On the other hand, this sort of misconfiguration would show up in any sort of good DNS checking tool. One of your registered nameservers doesn't resolve and/or one of your name servers doesn't return the same zone serial (likely) or actual response if you check a name.
In .is, they wouldn't let me register a domain unless I provided two known good nameservers, but .com isn't picky anymore.
I would think you'd get client query errors from time to time as well if one of the auth NS names doesn't even route/not registered. Even a big cacher like Google or CF might have noticed query errors and I'd actually be surprised if there wasn't communication from one of those entities to MC about the issue.
.int is a fun one, some orgs squat on it to use as an internal TLD.
It used to be easy to trawl through certificate transparency logs and find certificate mis-issuance on the .int TLD because there are very few organizations allowed to be registered in this zone legitimately.
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
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.
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.
You'd think there would be a service that informs you if any of your DNS servers are unregistered, let alone point to a server they shouldn't point to. What's more surprising to me is that every Fortune 1000 company, at the very least, hasn't either used that service or deployed such automated checks themselves, so that this wouldn't be an issue at all.
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 wrote a comment to similar effect yesterday: I have almost zero motivation for responsible disclosure schemes anymore. It's a bunch of paperwork only to be told it's "expected behaviour" or "not a bug", or at best receive a measly reward that barely justifies the time investment. I would rather just dump the vuln anonymously on Pastebin, save myself the headache, and then we'll find out if it's "not a bug" or not.
> ... I have almost zero motivation for responsible disclosure schemes anymore. It's a bunch of paperwork only to be told it's "expected behaviour" or "not a bug", or at best receive a measly reward that barely justifies the time investment.
I agree, it is thankless work.
Microsoft recently updated their bug bounty program to disqualify ANY reports that tangentially involve open source repositories. Even if you compromise their private source code or internal cloud resources, your report will now be closed with a measly $0.
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.
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.
> 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.
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...
I reported a vulnerability to Amazon last year. I got initial response within 24 hours. And follow up emails every week until it was patched. Was kind of well handled.
Here's Renee Burton's (at Infoblox) comment on Philippe Caturegli's post on LinkedIn:
"When we contacted DNS providers about sitting ducks attacks ONGOING in their network via lame delegation... some responded with aggression and others with ambivalence. no criminals were disrupted and it was a waste of our resources even though it was the right thing to do."
And I can personally vouch that's mostly my experience and expectation as well, and not just for DNS issues.
> 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.
Ok, nerd sniped. I can't likely get this fixed because I don't think I have any FB contacts for outbound mail, but I want to see a pcap and have a look at the TLS negotiation, if you provide the server hostname so I can run more starttls trials, that would also be neat. email in my profile.
But yeah, good luck getting a response to big tech, I just want to know!
In theory, facebook should have a postmaster that would look at email issues, but probably nobody looks at that address cause it's mostly junk.
The common issue I notice amongst companies that fail to admit fault is that they are _public_. Admitting fault means a poor market signal. Poor market signal means leadership perceived as inept and “failing to deliver shareholder value”.
Of course this isn’t unique to public companies. Have seen private companies do the same for less to avoid embarrassment or perhaps they think it would harm their IPO
Nah, not really. I sincerely doubt that Facebook admitting "yeah, our outgoing mail servers did TLS cert verification improperly in some cases", or the Dutch National Railways saying "yeah, we make renting bikes easy, maybe too easy" would affect their valuation.
But: that does not mean that the underlying issues should not be addressed and/or that the reporter doesn't deserve a meaningful reply.
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.
Just before Christmas my Canadian bank (RBC) texted me to say that they'd blocked a suspicious transaction. In the text message they included a phone number that I could call to get more information about the incident. It felt fishy but out of curiosity I called it and they wanted to ask me my "security questions" to confirm my identity.
I hung up and instead called the actual number on the back of the card. The whole thing was real, the bank had actually contacted me by text and sent me a follow up phone number.
Truly I don't understand what they're thinking sometimes.
The bank app was the first thing I checked when I got the text message, because I was so surprised they wouldn't have just sent me a push notification through there. And there was no indication in there was any kind of problem with the card, no sign of the pending/blocked transaction, nothing.
And they definitely have the 2FA-through-app capability because it's used for auth when I sign into online banking on a computer— the app has to grant permission for the new device. But hilariously they don't seem to have it wired up yet for phone interactions.
That reminds me of my rant over some recent IRS free-filing stuff. They were basically telling users to go ahead and trust a third-party service named id.me with all their sensitive personal identifying information.
FFS guys, at the bare minimum you should have white-labeled that behind a domain like id.irs.gov! Not just to avoid mis-educating users into terrible security habits, but also to avoid giving some Montenegro DNS folks the ability to intercept or man-in-the-middle all the information.
I had my card paused SEVERAL times over the years for sketchy stuff like getting gas at the same gas station I always get gas at or buying a delivery of pizza on a Big Name Company's website. Then, two times in the past year, someone bought thousands of dollars in iPhones, rental apartments, and gasoline on my card on a different body of land than the one I live on thousands of miles away in rapid succession and each of the two times it was ME who caught it because of notifications I have setup! Fraud departments at banks and card companies are fucking useless.
Another story: I was abroad, and someone got my card details and made purchases for thousands of $ in a different part of the country that I don't usually visit and certainly doesn't purchase there stuff for that amount of money.
Nobody even cared, but a payment I made for 2 euros wasn't accepted becuase reasons, and every online purchase needed some authorization.
When I called them, they said they'll look into the purchases. Well, they cancelled the purchases quite fast, but the surrealism of it all...
When I worked at another large credit card issuer, I was told the algorithm to detect fraud was essentially a black box. No one left at the company really knew how it worked or how to change it, so it was left intact and new rules were simply added on top.
This is increasingly not a thing. I haven't had to do this in a very long time and my primary credit cards don't even have it in the apps/website anymore.
It seems more unreasonable to me to make arbitrary exceptions like that. I would want my RNG to be predictably random so that if 123456788 comes up I know that it's not some sort of kludge to avoid a more interesting number.
Companies have little direct motivation to have good security practices, they're only motivated to manage their reputation. Any attention they pay to security is only a side-effect of caring about reputation management.
And as we've learned from significant breaches, there is rarely a reputational hit for even the biggest breaches. Anyone remember that time Target accidentally doxxed 70 million people? I don't think there was any noticeable difference in their income or profits.
And ultimately, the only reason they care about their reputation is because it affects their profits. For-profit companies optimize for profits, as always :)
So the mom-and-pop donut shop on the corner always optimizes for profits? The local donut shop?
Most companies do not actually optimize for profit. If they did they'd stop whatever it is they are currently doing and switch to whatever industry makes the most profit. They don't though, they keep making/doing whatever it is they start with generally. That means they aren't actually optimizing for profit.
Not all work is equal. Value is derived from having an edge over the competition. If you are a good baker then baking may be optimizing for profit. Also if everyone just switched to X it wouldn't be the best option anymore.
Profitability is important to any size business. Profit growth is what many large business C-levels obsess over because they get to eat a slice of the expanding pie.
Its almost like if they want a piece of the expanding pie hell be damned, they should recieve actual liabillity criminal and civil for the trouble and take away any profit incentive that drove them in the first place
Any business will optimize for profit > 0, otherwise it’s a loss making business and will shut down sooner or later. Not all businesses optimize for maximum possible profit.
* if everyone who sold donuts suddenly went into AI there'd be a huge profit opportunity in donuts - optimizing for profits would be to wait for the other donut sellers to switch into AI and rake in the cash.
* the cost of retooling constantly based on the latest profit fad would just make the toolmakers the main profit center, and the toolmakers would just use their own gear to take all the profits in abandoned markets.
* the constant shift of areas of business would be sub-optimal because most people entering it would know nothing of how to succeed in that field, it's not optimal for your company to be incompetent in an area with much competition.
* labor costs in the "only profitable field" would be through the roof as everyone scrambled to hire competent people - not an optimal way to maximize profit in a crowded industry (also, this compounds with the above point).
In fact this idea is so bad (and yet weirdly beleived by many) that every boom there's memes and jokes about how absurd it is that random companies from completely different industries are getting involved... as if they have a chance to compete against the established players. And even more jokes about how they predictably go out of business.
Umm… continuing the donut example, the owners are likely maximising their return given their skill sets, knowledge, time, etc. But return is pretty nuanced too bc it probably is not just be profits, but family time etc. in any event, I think you’re right that businesses don’t just focus on profits. But the example doesn’t prove the point.
No. There’s prestige and power in running high profile companies.
It’s a middle class fantasy that money is power. Look at the Cheeto. How many times has he been bankrupt? What does he say about bankruptcy? He knows he’ll be fine because power brings money, not the other way around.
Taxing billionaires will help the economy absolutely, but it won’t control the billionaires, because a lot of their deals aren’t denominated in hard currency. We don’t know how to tax favors or threats.
Money is definitionally power. Its sole purpose is to convince other people to do things you want them to do. Thats what power is.
There are other sources of power besides money, but money is definitely one kind.
Consider Twitter. Musk managed to get institutions to put up a fabulous amount of money, but he still had to pay a massive amount himself. If he had $1,000 in the bank and nothing else, that deal would never have happened. Heck, even with $1 billion it wouldn’t have happened. As it was, he got to take a couple dozen billion units of monetary power and convert them into massive non-monetary power.
Companies do have a motivation to have good security practices (and disclosure), because they are motivated by their reputation which is essential for customers to trust them to be customers, even more with the proliferation of SaaS means more longterm relationships and customer data.
The challenge is for customers and companies to communicate and agree to the new social contract.
Mastercard should be heavily fined for this. And I mean really heavily, like some percentage, or fraction of a percentage of global revenue. That's how you get them to take security seriously.
According to German law, a competitor (possibly Visa) can sue a company for uncompetitive behaviour that has the potential to affect the consumer negatively.
This means that at least in theory a security researcher could work as a contractor at a competing firm to then let their legal department send a cease and desist letter and demand recouperation of the legal fees including the money paid to the security researcher to find the vulnerability.
Anyone who quotes me on this in their court case is an idiot.
Yeah, isn't it pretty standard to first report privately, then report publicly if they don't take any action (and you believe it to still be an issue)? That seems consistent with mosr organization's responsible disclosure practices.
this is standard, but there are people out there that believe this is malicious/blackmailing behavior. I think it’s the most responsible thing you can do here. This guy could’ve made a bucket off this find, instead reports it responsibly and mitigates the risk (with his own money invested) and gets told to pound sand.
> The only way to (sometimes) get big companies to fix their mistakes (besides the legal system) is to shame them into it.
in the golden years of twitter the quickest way to get proper support from companies was to talk shit about their services on twitter.
i was always amazed by how quick i could get in touch with an actual human being using that strategy.
this remind me of some other borderline unethical techniques i read online...
basically when dealing some kind of problems with non-IT infrastructure, if you cannot get "support" to acknowledge issues then you change your strategy and write to the lawyers from the company or public entity managing that piece of infrastructure and inform them of the legal liability deriving from the issue that you noticed.
once that is done, if ANYTHING happens, they cannot deny knowledge of the issue.
they will involve whoever is needed, internally, to get the issue fixed.
so yeah... basically often times to get technical issues fixed you're better off resorting to a human (rather than technical) approach.
Can security researchers send an invoice for a reasonable amount conmesurate with the value of the service provided and then sue for quantum meruit if it is not paid?
Why would you be able to bill for a service that you weren’t asked to provide?
This can happen; if you're found unconscious and taken to the hospital, you can be billed for medical care which you didn't ask for, based on the doctrine of presumed consent.
One could imagine a parallel -- a critical emergency where it's impossible to communicate but it's reasonable to presume that they would want to have the issue fixed if they were aware. I don't think it necessarily applies here, but it's at least possible that another case could meet that bar.
Well, in a case such as this: because they're putting other people's data/money at risk and should have payed somebody to discover flaws like this in the first place. It's not the law but maybe it should be.
Well, the users of the system should be able to recoup some of their costs for services (security) not rendered and then pay the researcher for that.
In a more well-coordinated society none of this would happen because the company would have avoided the predictable outcome by hiring a security person in the first place.
And if you can’t see out of your dirty windshield, you could cause an accident. If your neighbor’s door is unlocked all day, someone could break in and steal their TV.
I mean, why should I even need to apply for any job? McDonald’s always needs workers; do you think they’ll mind if I walk into the kitchen, start flipping burgers, and then name my hourly rate at the end of the day?
The only people that I know do this are "Beg Bounty" "Security Researchers" that are, essentially, attempting to extort people.
Even if it would be legally possible (I don't think you can force your 'services' on an unwilling entity and then force them to pay), it would be absolutely awful optics.
The closest I can think is the old scam where a business would mail you a package then demand payment for the item mailed to you. That was solved by just making anything shipped to you yours with no legal obligation to send it back
It wasn’t taken seriously and it was more of a joke internally, but I shit you not there were teams who were forced by some managers (probably by a sole exec) to change their “master” branch to “main”
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
Beyond just IPs, there is a giant class of "DNS record pointing to X shared cloud resource that organization no longer controls" issues. The bigger the company, the more widespread the problem. These resource names get released back into a common pool that anyone can register.
Think:
* CNAME pointing to an S3 bucket, and the S3 bucket gets released
* CNAME pointing to Azure Website/WebApp Instance
* A record to an non-elastic IP, and the box gets rebooted
* DNS name using a Route53 name server that no longer part of the org's AWS account
* CNAME pointing to a Heroku/Shopify/GitHub pages account and the account gets deleted/deactivated freely up those names for registration
* MX record pointing to old transaction email provider start up that dies, and someone else registers that domain name...
Why does that happen?
* Decentralization of IT means people spinning up infrastructure not knowing what they are doing
* Great a spinning up infra, but when decomissioning they forget about DNS
* Lots of subsidiaries, lots of brands, different groups, operating in different geographies. All this makes it difficult to discover and enforce proper policies
* Geo-specific websites/apps (Think of all the country-specific websites Coke runs)
* Using some 3rd party vendor and never telling security about it (Marketing spinning up some landing pages on some fly-by-night martech provider or wordpress host, and never turning them off)
I am the Field CTO at a venture backed Israeli cyber security company in this space. I was literally talking to a major computer part company yesterday about the dozen or so Indonesian gambling websites that are "running" on their domain names using their pagerank and links. This is a weekly conversation
What types of actions can you do to correct and prevent this class of errors? I think you could probably enforce deployment and shutdown checklists, perhaps, or have automated DNS checking software to see if any of the issues exist (I bet you guys have a solution for that) but there are so many human-error problems in manufacturing, and I kinda consider the large-scale deployment of apps to have similar issues and failure modes on the human side.
Azure has options when you use their DNS that they tie resource, Public IP, Azure WebApp and other to DNS. If resource is deleted, the record will be NXDomain. AWS probably has something for Route53.
Otherwise, good IaC can help but even in larger companies, I see more ClickOps then I should.
We have an inventory of everything running, and where they are supposed to be running. If service X does not respond on resource Y the team responsible get an ticket. Check is on IP and names, and some other services. There are no good ways to do this other than being meticulous IMHO. Getting dumps of what is running where from all services is rather hard but more or less doable.
It helps not using the cloud.
The simplest things you can do are either:
- Stay within the cloud provider's ecosystem as much as possible, including for domain registration and DNS. All records then should be pointing to resources that include your account id in them and can't be taken over by others. If you delete the entire account, there'd be nothing to take over.
- Do everything with Infrastructure as Code, including DNS. If a single "terraform apply" creates everything, then a single "terraform destroy" deletes it all, leaving nothing dangling, provided of course that it is setup correctly and doesn't error out midway through a run.
Otherwise, it's a matter of being thorough. Automate what you can, including creating and deleting resources, if not through a single cloud provider API or some standard IaC product, then roll your own software to do it, but have software do it. Regularly roll out and tear down entire test installations of full systems, including valid DNS records. When you intend for them to be gone, ensure they are really, truly gone.
If you can't automate it, then yeah, checklists.
It's one of those things that is simple but not easy. It takes an organization that respects the tedious and time-consuming nature of ops, plans for it, and doesn't push people to cut corners for the sake of speed when the first time trying to do something takes much longer than someone's uninformed first guesstimate.
Really, automate. At a small enough scale, it doesn't matter, but if you're Mastercard doing this kind of thing thousands of times over the course of decades, humans will inevitably make mistakes. Software will make mistakes, too, but at least when you test software, it will do the same thing every time it is tested. Humans do not provide that guarantee, even if they have checklists.
Edit: Note the above is not true for LLMs, so when I say use software, I mean classical deterministic software. Don't have AI do it for you, because LLMs can and will produce different responses every time you make the same request. Don't devolve to making software that is just as flaky as humans.
> CNAME pointing to a Heroku/Shopify/GitHub
At least Gitlab (similar to Github pages, I never used Github Pages, always Gitlab Pages) gives you a verification TXT record in your Gitlab Account, which needs to stay in DNS as TXT. So if I used to host hi.example.com on Gitlab (& my own TXT record was hosted, and publicly visible), now I don't own example com, or gitlab account got deleted (but still left DNS CNAME records intact) and scammer gets the domain, when he grabs domain and adds hi.example.com to his Gitlab Account to scam people, his Gitlab Account will have his own TXT record. (now) His hi.example.com can never point to "my" gitlab project or page.
https://docs.gitlab.com/ee/user/project/pages/custom_domains...
> * CNAME pointing to Azure Website/WebApp Instance
Microsoft has made it possible to have your webapps CNAME record be unique to your AzureAD tenant and never to be reused.
This prevents these kinds of attacks.
More info here: https://techcommunity.microsoft.com/blog/azurenetworkingblog...
> 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.
This sounds as if it should be more differentiated by how easy the domain would be able to obtain.
Like, it's obvious that "If I somehow took over google.com, I could compromise Google users" is no valid security vulnerability. But if taking over unregistered (or lapsed) domains results in a compromise, as demonstrated here, this should be seen as a valid vulnerability.
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...
Someone else here, although I don't remember who, regularly argues that Bug Bounty platforms exist to capture and prevent responsible disclosure, not encourage it.
If they're regular enough to see your comment, they may be able to expand the idea and explain it better.
> exist to capture and prevent responsible disclosure, not encourage it.
I will say that Google's VRP is the exception. They have top notch people who answer the initial report, will keep you in the loop (usually) and will consider impact if you'd gone further. BC or H1 are hit or miss, and more often miss.
I don't think I make this argument regularly and I wouldn't absolutely say that's the goal of the platforms themselves, but it's an effective outcome - in most cases participating in the program means accepting terms that say you won't disclose without permission, and if the vendor never grants permission you have the choice of disclosing (and potentially being kicked off the platform and also losing any safe harbor protections you had) or just saying nothing.
The wording is also downright terrible. It's phrased as if you've been judged to have done wrongdoing, and your options are to either comply or ask for further clarification why you're in the wrong. No chance given to explain how you're not the one at fault.
From my experience BugCrowd attempts everything to tarpit and delay reports from reaching the actual company. From company perspective this reduces cost (less bounties paid out and less reports to screen by their own staff) while at the same time having plausible deniability for legal reasons.
> 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
Just a note:
“Ivan I” likely stands for “Ivan Ivanov” which is the Russian equivalent of “John Smith” a fake common name
> 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?
> Does the credit card company have a reason to do that?
Yes. They want to make security researchers too afraid to publish their findings.
Then why not offer them a good (not great) nondisclosure deal?
"Discreetly let us know, at the earliest sign of vulnerability, sign a contract with NDA, and we'll investigate, fix, and compensate you promptly. We'll also publicly acknowledge, in vague terms, for your career development, that you successfully discovered a vulnerability that has been addressed. (But if you intrude beyond the boundaries we've clearly specified, then we don't have a business relationship, and we have appropriate government offices on speed-dial.)"
That's if the company wants NDA. I'm not saying that's how it should be done; just suggesting what seems like a more vendor relationship, business transaction way of being alerted to their own security mess-ups, if that's what they want.
> Some guy is poking around our system looking for exploitable weaknesses. Should we tell him to go away?
> Nah, let's pay him instead!
is a solution, but obviously can't be the solution. From a distance, white hat "vulnerability disclosures" start to look like a protection racket.
> From a distance, white hat "vulnerability disclosures" start to look like a protection racket.
A pretty big distance.
If a mobster threatens to burn down a building unless you buy their "insurance", that's a protection racket.
If someone finds a major fire code violation and threatens to tell the fire marshal about it unless they fix it within a certain timeframe, that's not a protection racket, even though there's technically a threat involved. If the building owner is a dick about it, then next time that person will probably just go directly to the fire marshal.
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.
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.
> 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.
One of them has an incentive sized in the billions of dollars to lie/embellish. The other thinks about worst-case scenarios from sophisticated attackers all day long. Worst-case attacks from sophisticated attackers are an embellishment when you're talking about a CS:GO server, but not when you're talking about one of the largest payment processors in the world.
I think it heavily depends on what az.mastercard.com actually is or does.
Receiving email directed to x@mastercard.com doesn't sound right, since this is only a subdomain of unknown(to me) use. TLS? Probably, but again, the risk depends on what it is, and wouldn't affect users visiting 'mastercard.com.'
I think the idea was that because this typod domain was being used behind the CDN, you could trick mastercard.com (that uses the CDN) somehow to serve from the hijacked domain that was misconfigured at the CDN.
At least that's my guess, but it's not super clear what attacks would be possible here.
If JavaScript is served from those domains, there may be something interesting. Or if data is submitted to the domains.
Knowing what inflated security researcher egos usually are I wouldn't hold my breath to find out the truth here.
re: SSL/TLS certs
My first thought is using one of the ACME-based certificate providers, since DNS control of a domain is sufficient (either TXT record or directing requests to a HTTP server you control).
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.
Not exactly, since typos can occur anywhere in the name, not just the TLD. Hell, even without typos, you can bitsquat [1] on domains one bit away from popular site names (usually CDNs) and get some traffic because of various computer glitches. Here's a random paper I found (and skimmed) with some examples [2]
[1] https://en.wikipedia.org/wiki/Bitsquatting
[2] https://www.securitee.org/files/bitsquatting_www2013.pdf
I'd expect big companies to use Markmonitor to handle this problem -- basically, they _also_ register all of the one-edit-distance away typos that they can.
According to Wikipedia, Akamai is one of Markmonitor's customers, so it is surprising that this wasn't already registered by them.
I've found that Markmonitor is generally signed up for "public" address like akamai.com but rarely signed up for service domains since "who is going to screw up the service domain?"
How is this any different from having a phone number that's just one digit away from another sensitive one?
Well nobody has the phone number 912 for instance. We specifically make sensitive numbers distinct from "regular" numbers. 911, 411, 311, 999, etc.
I had a friend whose phone number was 591-1XXX and if I picked up the phone and dialed too fast, the 5 might not get recognized by the switch and I'd end up on 911, where I had to say "sorry, wrong number"
I had almost the same experience. Getting 911 by accident was pretty scary at age 6 or so.
Also the 910 area code
Apropos of nothing in particular... that brings back a memory (I used to dispatch for a 911 center in the 910 area code). You get some weird stuff in 911 centers sometimes (go figure, right?). In this case, the thing that sticks in my mind is this payphone that used to be on Bald Head Island by the gazebo. It apparently developed some sort of intermittent fault (possibly due to exposure to salt air, but who really knows?) where it would occasionally call 911 on its own. Or at least that seemed to be the case. We'd occasionally get a call from it, with no one speaking on the other end, and we'd send BHI public safety out there and they wouldn't find anybody around it.
Now you might speculate that it was kids playing or something, but based on the time(s) of the calls, the demographics of the island, etc. we always believed it was just some sort of phone malfunction.
I do IT support for a 911 center. We get about one of these per month coming from landlines on the ILEC's old copper cable plant.
On one serendipitous occasion the fault came from a school district I also support. The fault came from a contingency landline kept around in case the VoIP phone system lost digital PSTN connectivity. I was able to plug-in to the line w/ a butt set and hear clicky, buzzy, nightmarishly bad PSTN sounds thru it.
We turned it over to the ILEC and they "fixed" it. Given the number of "roadkill" splice pedestals I see in my area I feel pretty confident the ILEC isn't doing any maintenance of the copper cable plant at all. (It makes me pretty irritated, considering the favorable tax subsidies they received to build it.)
And yet, almost every private PBX uses "9" as the magic "get an outside line" number. Which then if one is calling a "long distance" number, one's next digit is "1", and "9" followed by "1" is only one mis-dialed digit away from becoming a "911" call.
I.e., New York's original area code is 212, someone in CA, dialing "long distance" to New York needs to dial 9 1 212 xxx xxxx. One button off on the first "2" and they just made a call to 911.
You seem to have no clue what numbers are sensitive? Bank or government phone number could be used to impersonate and steal people's identities, among a whole host of other numbers. Not everything is a life and death matter (and neither was the Mastercard incident).
I mean, the ISO 3166-1 alpha-2 TLDs are clearly useful, but given the address space, there's lots of one away typos there. It's not a big difference when the non contry code domains are also one dropped letter away from an ccTLD.
On the other hand, this sort of misconfiguration would show up in any sort of good DNS checking tool. One of your registered nameservers doesn't resolve and/or one of your name servers doesn't return the same zone serial (likely) or actual response if you check a name.
In .is, they wouldn't let me register a domain unless I provided two known good nameservers, but .com isn't picky anymore.
I would think you'd get client query errors from time to time as well if one of the auth NS names doesn't even route/not registered. Even a big cacher like Google or CF might have noticed query errors and I'd actually be surprised if there wasn't communication from one of those entities to MC about the issue.
mastercard.net mastercar.net astercard.net nastercard.net... your suggestion changes nothing.
What's your solution for Niger and Colombia ISO 3166-2 codes?
Easy, get rid of .net and .com so accidentally adding a letter won't be a problem anymore :)
Get rid of .int too, incase people mistake it for India.
.int is a fun one, some orgs squat on it to use as an internal TLD.
It used to be easy to trawl through certificate transparency logs and find certificate mis-issuance on the .int TLD because there are very few organizations allowed to be registered in this zone legitimately.
Yeah, I've encountered maybe a handful of .int domain names ever.
Remember tpc.int?
Email addresses, physical addresses, phone numbers, etc are always one letter/digit from another one.
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
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.
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.
> similar to laws that give someone who finds a lost item a right to a reward.
I've never heard of such a law, is it common? In which jurisdiction?
Japan has a finders' fee of 5-20%:
https://www.police.pref.ehime.jp/foreigner/otoshimono/2.pdf
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.
You'd think there would be a service that informs you if any of your DNS servers are unregistered, let alone point to a server they shouldn't point to. What's more surprising to me is that every Fortune 1000 company, at the very least, hasn't either used that service or deployed such automated checks themselves, so that this wouldn't be an issue at all.
> 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.
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".
Yup, same applies to HackerOne. Absolutely horrible for any responsible disclosure. Should be entirely boycotted for being so garbage.
Just dump the vuln to PasteBin and leave it at that, it's way more responsible than the endless ghosting and gaslighting those platforms enable.
I wrote a comment to similar effect yesterday: I have almost zero motivation for responsible disclosure schemes anymore. It's a bunch of paperwork only to be told it's "expected behaviour" or "not a bug", or at best receive a measly reward that barely justifies the time investment. I would rather just dump the vuln anonymously on Pastebin, save myself the headache, and then we'll find out if it's "not a bug" or not.
> ... I have almost zero motivation for responsible disclosure schemes anymore. It's a bunch of paperwork only to be told it's "expected behaviour" or "not a bug", or at best receive a measly reward that barely justifies the time investment.
I agree, it is thankless work.
Microsoft recently updated their bug bounty program to disqualify ANY reports that tangentially involve open source repositories. Even if you compromise their private source code or internal cloud resources, your report will now be closed with a measly $0.
> 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.
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:
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):
Some other SOA record abnormalities: 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).
> 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.
> 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.
> he alerted MasterCard that the domain was theirs if they wanted it,
feels wrong, considering all the other domains making the same typo.
Someone remind me what value business people add to society?
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...
I reported a vulnerability to Amazon last year. I got initial response within 24 hours. And follow up emails every week until it was patched. Was kind of well handled.
They don't do bug bounties though
Here's Renee Burton's (at Infoblox) comment on Philippe Caturegli's post on LinkedIn:
"When we contacted DNS providers about sitting ducks attacks ONGOING in their network via lame delegation... some responded with aggression and others with ambivalence. no criminals were disrupted and it was a waste of our resources even though it was the right thing to do."
And I can personally vouch that's mostly my experience and expectation as well, and not just for DNS issues.
> 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.
Ok, nerd sniped. I can't likely get this fixed because I don't think I have any FB contacts for outbound mail, but I want to see a pcap and have a look at the TLS negotiation, if you provide the server hostname so I can run more starttls trials, that would also be neat. email in my profile.
But yeah, good luck getting a response to big tech, I just want to know!
In theory, facebook should have a postmaster that would look at email issues, but probably nobody looks at that address cause it's mostly junk.
The common issue I notice amongst companies that fail to admit fault is that they are _public_. Admitting fault means a poor market signal. Poor market signal means leadership perceived as inept and “failing to deliver shareholder value”.
Of course this isn’t unique to public companies. Have seen private companies do the same for less to avoid embarrassment or perhaps they think it would harm their IPO
> Admitting fault means a poor market signal
Nah, not really. I sincerely doubt that Facebook admitting "yeah, our outgoing mail servers did TLS cert verification improperly in some cases", or the Dutch National Railways saying "yeah, we make renting bikes easy, maybe too easy" would affect their valuation.
But: that does not mean that the underlying issues should not be addressed and/or that the reporter doesn't deserve a meaningful reply.
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.
Also Mastercard:
You don’t usually buy much but today you bought a very expensive TV and then got a car wash in a part of town you haven’t been to for two years.
We aren’t calling you about the TV. We’re calling about the $8 car wash.
(Actual incident)
Just before Christmas my Canadian bank (RBC) texted me to say that they'd blocked a suspicious transaction. In the text message they included a phone number that I could call to get more information about the incident. It felt fishy but out of curiosity I called it and they wanted to ask me my "security questions" to confirm my identity.
I hung up and instead called the actual number on the back of the card. The whole thing was real, the bank had actually contacted me by text and sent me a follow up phone number.
Truly I don't understand what they're thinking sometimes.
This is solved by them having you do a 2fa via the bank app whenever you and the bank talk regardless who called who.
Disclaimer: my bank does this
The bank app was the first thing I checked when I got the text message, because I was so surprised they wouldn't have just sent me a push notification through there. And there was no indication in there was any kind of problem with the card, no sign of the pending/blocked transaction, nothing.
And they definitely have the 2FA-through-app capability because it's used for auth when I sign into online banking on a computer— the app has to grant permission for the new device. But hilariously they don't seem to have it wired up yet for phone interactions.
My bank has a banner at the top of the app if you are on a call with them. It's great if you know to check...
Yes, please just read the numbers out to me on the phone so I can confirm who you are...
It’s the other way around - the app shows you who are you talking to on the bank side and asks you to confirm
That reminds me of my rant over some recent IRS free-filing stuff. They were basically telling users to go ahead and trust a third-party service named id.me with all their sensitive personal identifying information.
FFS guys, at the bare minimum you should have white-labeled that behind a domain like id.irs.gov! Not just to avoid mis-educating users into terrible security habits, but also to avoid giving some Montenegro DNS folks the ability to intercept or man-in-the-middle all the information.
My bank does the same thing and I tel at them every time.
They did stop putting hyperlinks in email communications though. It’s a start.
I had my card paused SEVERAL times over the years for sketchy stuff like getting gas at the same gas station I always get gas at or buying a delivery of pizza on a Big Name Company's website. Then, two times in the past year, someone bought thousands of dollars in iPhones, rental apartments, and gasoline on my card on a different body of land than the one I live on thousands of miles away in rapid succession and each of the two times it was ME who caught it because of notifications I have setup! Fraud departments at banks and card companies are fucking useless.
This experience actually says more about what's been going on at that car wash you visited...
Largest and nicest chain in town. If someone was using it for money laundering then they sure were doing a good job of keeping up the facade.
Another story: I was abroad, and someone got my card details and made purchases for thousands of $ in a different part of the country that I don't usually visit and certainly doesn't purchase there stuff for that amount of money.
Nobody even cared, but a payment I made for 2 euros wasn't accepted becuase reasons, and every online purchase needed some authorization.
When I called them, they said they'll look into the purchases. Well, they cancelled the purchases quite fast, but the surrealism of it all...
When I worked at another large credit card issuer, I was told the algorithm to detect fraud was essentially a black box. No one left at the company really knew how it worked or how to change it, so it was left intact and new rules were simply added on top.
If they don’t know, at least the fraudsters won’t, either!
Did you alert them to your upcoming travel?
This is increasingly not a thing. I haven't had to do this in a very long time and my primary credit cards don't even have it in the apps/website anymore.
It's kinda like how Linux's RNG code has no special case to keep from outputting 123456789.
Seriously?!?
Everybody knows that's not a random number.
It seems more unreasonable to me to make arbitrary exceptions like that. I would want my RNG to be predictably random so that if 123456788 comes up I know that it's not some sort of kludge to avoid a more interesting number.
Really struggling to understand what this has to do with the topic.
Companies have little direct motivation to have good security practices, they're only motivated to manage their reputation. Any attention they pay to security is only a side-effect of caring about reputation management.
And as we've learned from significant breaches, there is rarely a reputational hit for even the biggest breaches. Anyone remember that time Target accidentally doxxed 70 million people? I don't think there was any noticeable difference in their income or profits.
No one cared.
And ultimately, the only reason they care about their reputation is because it affects their profits. For-profit companies optimize for profits, as always :)
So the mom-and-pop donut shop on the corner always optimizes for profits? The local donut shop?
Most companies do not actually optimize for profit. If they did they'd stop whatever it is they are currently doing and switch to whatever industry makes the most profit. They don't though, they keep making/doing whatever it is they start with generally. That means they aren't actually optimizing for profit.
Not all work is equal. Value is derived from having an edge over the competition. If you are a good baker then baking may be optimizing for profit. Also if everyone just switched to X it wouldn't be the best option anymore.
Profitability is important to any size business. Profit growth is what many large business C-levels obsess over because they get to eat a slice of the expanding pie.
Its almost like if they want a piece of the expanding pie hell be damned, they should recieve actual liabillity criminal and civil for the trouble and take away any profit incentive that drove them in the first place
That is optimising for profit. One of the problems with any comparative advantage argument is that capital is destroyed during any pivot.
That cost has to be factored into the return from pivoting.
Any business will optimize for profit > 0, otherwise it’s a loss making business and will shut down sooner or later. Not all businesses optimize for maximum possible profit.
There are time and probability elements which can only be reduced down to NPV (net present value) my making assumptions and analysis.
No, that's absurd for so many different reasons:
* if everyone who sold donuts suddenly went into AI there'd be a huge profit opportunity in donuts - optimizing for profits would be to wait for the other donut sellers to switch into AI and rake in the cash.
* the cost of retooling constantly based on the latest profit fad would just make the toolmakers the main profit center, and the toolmakers would just use their own gear to take all the profits in abandoned markets.
* the constant shift of areas of business would be sub-optimal because most people entering it would know nothing of how to succeed in that field, it's not optimal for your company to be incompetent in an area with much competition.
* labor costs in the "only profitable field" would be through the roof as everyone scrambled to hire competent people - not an optimal way to maximize profit in a crowded industry (also, this compounds with the above point).
In fact this idea is so bad (and yet weirdly beleived by many) that every boom there's memes and jokes about how absurd it is that random companies from completely different industries are getting involved... as if they have a chance to compete against the established players. And even more jokes about how they predictably go out of business.
Umm… continuing the donut example, the owners are likely maximising their return given their skill sets, knowledge, time, etc. But return is pretty nuanced too bc it probably is not just be profits, but family time etc. in any event, I think you’re right that businesses don’t just focus on profits. But the example doesn’t prove the point.
No. There’s prestige and power in running high profile companies.
It’s a middle class fantasy that money is power. Look at the Cheeto. How many times has he been bankrupt? What does he say about bankruptcy? He knows he’ll be fine because power brings money, not the other way around.
Taxing billionaires will help the economy absolutely, but it won’t control the billionaires, because a lot of their deals aren’t denominated in hard currency. We don’t know how to tax favors or threats.
Money is definitionally power. Its sole purpose is to convince other people to do things you want them to do. Thats what power is.
There are other sources of power besides money, but money is definitely one kind.
Consider Twitter. Musk managed to get institutions to put up a fabulous amount of money, but he still had to pay a massive amount himself. If he had $1,000 in the bank and nothing else, that deal would never have happened. Heck, even with $1 billion it wouldn’t have happened. As it was, he got to take a couple dozen billion units of monetary power and convert them into massive non-monetary power.
Money is the cover charge, to get access. Have you not seen how old money treats new money?
Have you ever seen the difference in a plumber’s behavior when you pay them versus when you don’t?
Like I said, money isn’t the only power. But power is the only thing money is.
Companies do have a motivation to have good security practices (and disclosure), because they are motivated by their reputation which is essential for customers to trust them to be customers, even more with the proliferation of SaaS means more longterm relationships and customer data.
The challenge is for customers and companies to communicate and agree to the new social contract.
Mastercard should be heavily fined for this. And I mean really heavily, like some percentage, or fraction of a percentage of global revenue. That's how you get them to take security seriously.
By who?
According to German law, a competitor (possibly Visa) can sue a company for uncompetitive behaviour that has the potential to affect the consumer negatively.
This means that at least in theory a security researcher could work as a contractor at a competing firm to then let their legal department send a cease and desist letter and demand recouperation of the legal fees including the money paid to the security researcher to find the vulnerability.
Anyone who quotes me on this in their court case is an idiot.
Yeah, isn't it pretty standard to first report privately, then report publicly if they don't take any action (and you believe it to still be an issue)? That seems consistent with mosr organization's responsible disclosure practices.
this is standard, but there are people out there that believe this is malicious/blackmailing behavior. I think it’s the most responsible thing you can do here. This guy could’ve made a bucket off this find, instead reports it responsibly and mitigates the risk (with his own money invested) and gets told to pound sand.
> The only way to (sometimes) get big companies to fix their mistakes (besides the legal system) is to shame them into it.
in the golden years of twitter the quickest way to get proper support from companies was to talk shit about their services on twitter.
i was always amazed by how quick i could get in touch with an actual human being using that strategy.
this remind me of some other borderline unethical techniques i read online...
basically when dealing some kind of problems with non-IT infrastructure, if you cannot get "support" to acknowledge issues then you change your strategy and write to the lawyers from the company or public entity managing that piece of infrastructure and inform them of the legal liability deriving from the issue that you noticed.
once that is done, if ANYTHING happens, they cannot deny knowledge of the issue.
they will involve whoever is needed, internally, to get the issue fixed.
so yeah... basically often times to get technical issues fixed you're better off resorting to a human (rather than technical) approach.
Can security researchers send an invoice for a reasonable amount conmesurate with the value of the service provided and then sue for quantum meruit if it is not paid?
Can those people who wash your windshield at red lights actually make you pay?
If your neighbor leaves their door unlocked while they’re at work, can you go change the locks (for their safety!) and bill them for your time?
No, of course not. Why would you be able to bill for a service that you weren’t asked to provide?
Why would you be able to bill for a service that you weren’t asked to provide?
This can happen; if you're found unconscious and taken to the hospital, you can be billed for medical care which you didn't ask for, based on the doctrine of presumed consent.
One could imagine a parallel -- a critical emergency where it's impossible to communicate but it's reasonable to presume that they would want to have the issue fixed if they were aware. I don't think it necessarily applies here, but it's at least possible that another case could meet that bar.
Well, in a case such as this: because they're putting other people's data/money at risk and should have payed somebody to discover flaws like this in the first place. It's not the law but maybe it should be.
Legal extortion you way?
Well, the users of the system should be able to recoup some of their costs for services (security) not rendered and then pay the researcher for that. In a more well-coordinated society none of this would happen because the company would have avoided the predictable outcome by hiring a security person in the first place.
And if you can’t see out of your dirty windshield, you could cause an accident. If your neighbor’s door is unlocked all day, someone could break in and steal their TV.
I mean, why should I even need to apply for any job? McDonald’s always needs workers; do you think they’ll mind if I walk into the kitchen, start flipping burgers, and then name my hourly rate at the end of the day?
They can smash your window
Not legally.
I spent a minute reading this. My time is worth $300/hr and I bill in tenths of an hour.
Where do I send the invoice?
The only people that I know do this are "Beg Bounty" "Security Researchers" that are, essentially, attempting to extort people.
Even if it would be legally possible (I don't think you can force your 'services' on an unwilling entity and then force them to pay), it would be absolutely awful optics.
The closest I can think is the old scam where a business would mail you a package then demand payment for the item mailed to you. That was solved by just making anything shipped to you yours with no legal obligation to send it back
Of course not.
most door locks can be easily picked.
can i go from house to house, pick locks and then demand payment?
(spoiler: no)
Yes, they can. Anyone can sue anyone else for any reason.
It will be a colossal waste of everyone's time and money, though, because they will never prevail.
That sounds like a fine, not an invoice. If you can compel them to pay, sure. ;)
They can not.
I guess it's a little late to mention this as it is a "woke" concern, but was there pressure on Mastercard to rebrand?
It wasn’t taken seriously and it was more of a joke internally, but I shit you not there were teams who were forced by some managers (probably by a sole exec) to change their “master” branch to “main”