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
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.
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.
Do these Indonesian gambling sites somehow exploit the AMP cache? The apex domain of my blog was recently hijacked by such a site. I was only using the blog.* subdomain. One day I noticed on the Google search console that someone had verified themselves as a co-owner, and there was an entry for an AMP page (this was the gambling page). Putting a parking page at the apex url seemed to stop the redirects to the AMP page - and that's the solution I have for now.
I am still curious though - how does AMP make such exploits easier? Would you happen to know?
> 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.
Would "provide a working proof-of-concept that doesn't require DNS configuration on the client" not cover the difference? Maybe it'd be nice to still care about moderate-risk theoretical stuff without needing a fully functional PoC, but this would at least stop cases where bug reporters show a working exploit and still get ignored and not paid (I was reading just yesterday about the [Zendesk Slack takeover bug](https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...) where that happened; in that case, there was a real Zendesk vulnerability which Zendesk first ignored, then later withheld payment for because the reporter shared a working PoC for Slack takeovers with companies affected by the Zendesk vulnerability after Zendesk had stated it was out of scope for them.)
I'd like to offer that it also depends on the utility of the domain. If I got a bug bounty submission that demonstrated takeover of b2938978-us-east-2-testing-box.mycompany.com I would classify it as less severe than if you were able to take over say, signin.mycompany.com (even if signin.mycompany.com hasn't ever been in use) since that's highly valuable for phishing. And of course, a subdomain like api.mycompany.com that is in active use, that would probably be the most severe of all since you might be able to say, tell all garage door openers that phone home to immediately open.
Might bug bounty programs be more effective, if disclosures are also automatically reported to a government agency, like the FCC, and the relevant company's email cc'd on that? They'd need to provide clear evidence that a report warrants dismissal, and if an exploit is proven to have some from such a report, or if they make any changes and the reproduction recorded in the report stops working, then they are obligated to pay up and/or face fines.
On a certain crypto exchange, they whitelist IP addresses that can access faster load balancers with no application level control. We got a bunch more capacity than originally by just allocating a metric ton of cloud IPs and rinsing and repeating till we found stale ones - and then we blasted them with the higher rate limits. I don't think this would work anymore. Everyone knows this.
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 can see why; if it's software that isn't easily or frequently patched or it takes a long time to update everyone and roll out the update, AND the exploit isn't known elsewhere yet / actively abused, keeping the report under wraps to try and protect the unpatched installations for as long as possible makes sense. Yes it's security by obscurity, but if you're the first to find it then the obscurity was effective.
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.
> 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.
That doesn’t make any sense though. The only reason they could want that is if they were never going to be held account for exposing the financial details of millions of people.
I hope researchers will find ways to publish their findings in other discrete ways then, so that the company behaving like a dick will get hit by black hat people. Would serve them right.
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.
masterpass is MC's version of 3DS. It's used by MC worldwide when transaction is sus. I guess, in MC's eyes, transactions in your country are considered sus by default even if they entirely between local entities.
I don't remember it's ever expiring, at least in the US. IDK how they handle traffic in different countries. It sounds a lot more like your traffic got routed somewhere else and not MC?
> 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).
> 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.
Anybody who has any understanding of how certs are issued knows that he's right and MasterCard is full of shit. So would anybody who put in 10 minutes of research.
> One of them have to be incorrect, and both have the incentive to lie/embellish.
If it has no impact, they should give him permission to publish the entire list of DNS queries he captured. They won't do that because it gives bad actors hints about their infrastructure.
MasterCard is either lying or ignorant and incompetent.
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.'
Without saying too much, I can tell you that this is no obscure subdomain. That traffic he showed represents the gateways for almost all web traffic into Mastercard solutions that run on Azure.
Also, if you knew the culture in there, you would appreciate the extreme irony of them making a mistake like this.
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?"
The North American Numbering Plan specifically reserves numbers to forbid that (to the extent that the DTMF for 1 is actually handled differently by the line discipline, or at least was 20 years ago)
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.
Sometimes physical addresses are even 0 letters from each other!
In my (distant) family, there was a guy who married a woman whose name was the same as his sister's, and she changed her family name to his. They all lived together for a short while.
Letters addressed to his wife and his sister would have the exact same address and exact same name on them, with no way to distinguish who the letter was for.
One more edge case to add to the "falsehoods programmers believe about names" list.
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
Readit News
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
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
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...
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...
DEF CON 32 - Secrets & Shadows: Leveraging Big Data for Vulnerability Discovery - Bill Demirkapi
https://www.youtube.com/watch?v=-KXgcWuv-Ug&t=288s
I am still curious though - how does AMP make such exploits easier? Would you happen to know?
Oh mate, I've seen that happen with a company that was selling security-adjacent services, which were running on servers with just random IPs ffs
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.
Neither option is particularly palatable.
[1] https://www.bugcrowd.com/resources/hacker-resources/platform...
If they're regular enough to see your comment, they may be able to expand the idea and explain it better.
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.
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?
Yes. They want to make security researchers too afraid to publish their findings.
"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.
Ooh, wait.
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.
I don't remember it's ever expiring, at least in the US. IDK how they handle traffic in different countries. It sounds a lot more like your traffic got routed somewhere else and not MC?
Yeesh
“Ivan I” likely stands for “Ivan Ivanov” which is the Russian equivalent of “John Smith” a fake common name
Deleted Comment
> “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.
Glad to clear that up for you.
If it has no impact, they should give him permission to publish the entire list of DNS queries he captured. They won't do that because it gives bad actors hints about their infrastructure.
MasterCard is either lying or ignorant and incompetent.
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.'
Also, if you knew the culture in there, you would appreciate the extreme irony of them making a mistake like this.
At least that's my guess, but it's not super clear what attacks would be possible here.
Deleted Comment
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).
I have no doubt that’s heavily lawyered and is justifiable. What is their “system”… Define it the way you want and the statement is true
[1] https://en.wikipedia.org/wiki/Bitsquatting
[2] https://www.securitee.org/files/bitsquatting_www2013.pdf
The consensus seemed to be that it wasn't that impactful anymore (if it ever was).
https://security.stackexchange.com/q/185435/76718
According to Wikipedia, Akamai is one of Markmonitor's customers, so it is surprising that this wasn't already registered by them.
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.
In my (distant) family, there was a guy who married a woman whose name was the same as his sister's, and she changed her family name to his. They all lived together for a short while.
Letters addressed to his wife and his sister would have the exact same address and exact same name on them, with no way to distinguish who the letter was for.
One more edge case to add to the "falsehoods programmers believe about names" list.