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.
I’m not sure he’d want to, it would seem like he might want to point to his own scam. But if he did, I imagine he could add back your TXT record after looking it up in any of a large number of historical DNS databases. I can’t vouch for the quality, but a casual Google suggests there are still many, primarily paid but some free-ish, in the mix. Examples:
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.
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.
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.
- 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.
> Stay within the cloud provider's ecosystem as much as possible, including for domain registration and DNS
Alas, if you follow this advice to mitigate this particular risk, you're completely hosed if your cloud account gets taken down or compromised. Which is why the standard advice is to do exactly the opposite and make sure your domains and DNS are separate from your cloud provider.
What if you have your domain registered outside of your cloud provider, but have your nameserver on your cloud provider's infra.
You can have another cloud platform configured with a duplicate nameserver, then go to your registrar and change the nameserver for your domain.Your replacement nameserver would then control any subdomain provisioning.
I think that would deal with the risk somewhat, though could be missing something.
> your cloud account gets taken down or compromised
In risk assessment this risk should be resolved as „avoid“, because loosing DNS will be the secondary concern. Data is even more important. I agree that domains should be registered elsewhere and it’s good idea to have the backup of the zone.
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 help run our bug bounty program at a mid-sized company, and we regularly get subdomain-takeover submissions where the reporter has put zero effort into validating the report before submitting it.
They appear to be running some subdomain or certificate search for our domains, then running curl over the results. If they get a 404 they submit it to us as a subdomain-takeover report.
We use a bunch of vendors where we've got foo.example.com CNAMED over to the vendor, but the vendor's servers only serve traffic off some sub-path, and requests to https://foo.example.com/ are going to get 404.
So, I could understand larger organisations simply banning them outright.
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.
I am not a security person, and when I tried to report an vulnerability in the authentication signing in the QuickBooks Ruby gem, the process caused me to end up just saying nothing. Intuit pushed me to H1, and I did not feel comfortable with the H1 process, or that I had an advocate for a legal process that I was unfamiliar with.
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.
If a short-term-thinking decision-maker has a KPI for low vulnerabilities, they'd rather take the chance of a massive compromise of the company, than to have vulnerabilities reported and definitely hurt their bonus/promotion?
In the U.S. the opposite is encouraged as we lack a lot of safe harbor laws surrounding responsible disclosure. Something as simple as seeing individual's social security numbers hardcoded into HTML could get you dragged through the mud by your state's leaders and the potential threat of jail time.
It's why you'll see a black & white approach to this among bug hunters, instead of a grey / middle-of-the-road one. Some will try to disclose responsibly, the company will deny, and by disclosing through their BBP you've technically agreed to their NDA, so you can't say a word about it even if it still exists a year later. Others will find it and just post it publicly right away, as they don't want to agree to an NDA, and a public action leads to them actually fixing it quickly instead of letting the vuln sit around forever.
> 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.
> If the reporter is trying to get paid for not reporting, that's blackmail.
That's not what happened here and isn't usually what happens, though? The reporter usually gives a timeline for fixing the bug before reporting externally, and often extends that deadline if it's clear the Company is working on it. This is separate from bug bounty payments.
> The more you pay people to find them, the harder they look...
I agree that you don't want to create a protection racket market, and that's what I was thinking when I said "being alerted to their own security mess-ups".
Your own staff and vendors are creating security vulnerabilities, and you wisely run a bounty program, to detect and alert you. And you only pay when they find a problem. It can be very economical hedge against both mistakes and systemic dysfunction.
Also, if the researchers were criminally-inclined, they could make more money selling vulnerabilities to someone, not alerting you.
Not to mention, short term cost cutting is what ever business tends to prioritize. Companies would prefer not to pay anyone for anything, including random "researchers".
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?
It's both. I got 3ds triggered on a vendor I used all the time, but one time I bought from it while I was in Vietnam - hello secondary verification screen. Also happened for vendor that I had no issues with, but when I used my card from not-US bank - secondary verification screen.
Suspicion on the vendor usually, at least with my banks, triggers a fraud alert that I have to respond. 3DS on the other hand is to verify that the person making a payment is the rightful cardholder.
Masterpass also doesn't always redirect to that verification screen.
> 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?"
.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.
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"
Modern cell phones don't even dial the number. They just record that you dialed an emergency number, and route an emergency call.
Tried dialing 112 once just to see what would happen, and it immediately connected me to 911. Interesting conversation with the dispatcher when I told them that I had not, in fact, dialed 911.
Also of note (most people know this, but might be worth sharing anyways) I believe emergency calls get special handling by the network, and can go over any tower, not just your carriers'. So if you're somewhere with no reception and you have an emergency, try making the call anyways - it might still go through. This is presumably why cellphones differentiate "Emergency Calls Only" from having no service entirely.
112 is an emergency number "by specification", it will always work (on GSM/UMTS/Vo LTE networks, NOT on landlines)), no matter what country you're in. I think this also applies to 911, although I'm not 100% sure about this.
Numbers like 000 are a different matter, there are scenarios in which they might not work even if you're in Australia (when you have a non-australian SIM or no SIM at all, for example).
AFAIR, 112 is defined by some ITU or 3GPP standard, which is honored in at least Europe/Russia region. In other places different numbers might as well be routed to it or (even better) redefined inside terminal software (SIM). But I no longer work in that area, so can't be 100% sure.
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.
Wild! I wonder if the line was shorting out and pulse-dialing random numbers, and it just happened to be 911 sometimes, but that's a total shot in the dark. (I vaguely thought payphones had some kind of special connection to the CO, not like a normal phone line you can just DTMF or pulse dial on, but maybe that's made up.)
That was my first thought. In NZ, 911 has redirected to our emergency number 111 for about 25 years now, but before that, 911 led to a recorded message telling you to hang up and dial 111. I found this out by getting there by accident by pressing the hang-up button a lot of times quickly (for curiosity reasons). In NZ pulse coding for 911 is 1 pulse, then 9 pulses, then 9 again (our rotary dials going the other way is why we use an emergency number starting with 1). I probably pressed the hang-up button once, then decided to press it a bunch more times.
(I vaguely thought payphones had some kind of special connection to the CO, not like a normal phone line you can just DTMF or pulse dial on, but maybe that's made up.)
FWIW, at one time (relative to here in the US at least) there were at least two different major "kinds" of payphones. COCOTS (Customer Owned Coin Operated Telephones)[1] and what I call (for lack of a better term) "telephone company payphones". The latter being owned and controlled by the local telco. Part of the difference is how signaling works. For a COCOT, it is the case that the line is a plain jane line, that you could - ahemcough theoretically cough - beige box onto and dial calls using DTMF or pulse dialing. For those phones, the "magic" that made it a "pay" phone was inside the phone itself. For the "telephone company payphones" the line was configured differently and tones were sent in-band over the line to tell the switch that the coins had been deposited. This is the idea behind the old "red box" notion of recording the coin tones and playing them back to get free calls.
So yeah, a COCOT line could almost certainly be subject to something like random shorts being interpreted as pulse dialing and could possibly call 911. For a telephone company payphone I'm less sure if those supported pulse dialing or not. The lack of coin tones shouldn't matter since calls to 911 are always free, but I'm not sure if the line was different in other ways as well, or not.
Which one the BHI phone was, I never knew. But this was in the late 90's and by then a lot of the old skool telephone company payphones had disappeared in favor of COCOT's so if I had to guess, I'd guess it was a COCOT.
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.)
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.
Yep. In a number of places the old ILEC's have publicly declared their intention to deprecate the old copper based PSTN. In other areas, they seem to be practicing a sort of "malicious neglect" and just letting it decay on the vine, to avoid spending money on maintenance.
It's unrelated (as far as I know) but in an interesting bit of synchronicity, a BHI public safety officer died under somewhat mysterious/controversial circumstances somewhere in that area. It was a few years after I moved out of the area and I'm not familiar with all of the details.
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).
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.
I think most recursive servers will try more than one of the authoritatives before giving up. And it's common to keep stats on which servers work, and send traffic to those.
So if you get the glue that says mastercard has 5 servers, and you already know 4 of them are good, probably send your query to one and don't even bother trying to find the address of the .ne server.
I'd be surprised if it bubbles up in logging unless all/ maybe most of the authoritative servers for a popular hostname/domain name are unresponsive.
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.
My brother and I have the same initial letter, same problem, but it was possible to use the first two letters as initial with some services. But in practice my mom would open letters to see who it was for, lol.
He should have offered the domain name to akamai. Other requests are also coming to the same address. And akamai should have the integrity to handle them
> A few hours later, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations.
> “We have looked into the matter and there was not a risk to our systems,” a MasterCard spokesperson wrote.
This is a classic, “we have investigated ourselves and found no wrongdoing”, response
This is a multibillion dollar public company that has at least 3.4B branded cards in the wild, and processed 44.3B credit/debit/cash transactions across the globe in Q3 2024.
Admitting wrongdoing is a _short term_ mistake in the market, but sets a shitty company culture. Just like ClownStrike.
A disruption to predatory/parasitic credit/debit networks is well overdue.
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.
Seems to me that there needs to be a third-party validation authority:
1. It grants a seal/hologram to its members that can be put on products to communicate to the customers that the company takes security validation seriously. Otherwise, they can tell during the marketing presentation that they are not a member and risk making an adverse impression about the security of their product upon their customers (this idea has a dependency on the network-effect which can be hard to get during initial days).
2. Member companies, research companies and individual researchers pay annual membership fees that go towards the operating costs of this authority. The amount is reasonably small for individual researchers or small companies so that it is not a burden.
3. This authority mainly acts as custodian of bug bounties i.e. all bug bounty programs of members are published on its website and it is designated the authorized validator of bounty claims.
4. There is a disclosure framework that this authority, member companies and researchers sign up to.
5. Member companies agree to allow this authority to do the necessary testing of the validation of bounties without threat of suing it.
6. When a researcher finds a vulnerability, it reports the specifics to the authority, instead of risking consequences of legal issues due to any actions by themselves.
7. Upon successful validation, a small percentage of the bounty (e.g. 5 to 10%) goes to the authority and the rest of it is released to the researcher. This acts as an incentive for the authority to vigorously validate the reports.
Yeah. What they really mean is "we talked to a clueless drone in our IT department, who had a personal incentive not to find any exposure, and that person couldn't think of a way to exploit it in 15 seconds".
If you actually know what you're talking about, you basically never feel safe enough to categorically say that something can't be exploited.
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.
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...
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.
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.
I reported weird shit happening with SYN and PING and what I got was "how dare you insult my reports" from Paul Vixie; but I used to work for him. Ultimately I blocked all SYNs and ICMP ping inbound from Amazon addresses, spoofed or not. Problem solved. Boohoo soi disant "security researchers".
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.
> 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.
Oh yes, I forgot to tell you, facebook.com/whitehat is pretty good at escalating issues to the right team, but I don't know if someone would triage it and say it's not a security issue and then it has no urgency.
Well, I have a pretty good idea, and the answer won't comfort you.
To further elaborate on this pointless saga: last December, I actually met a FB engineering executive while on holiday, happened to mention this issue in casual conversation (I know: sad!) and they were going to put me in touch with All The Right People who were going to Fix This Immediately.
Guess what? The "oh, if the remote rDNS ends with mail-mail.facebook.com, just don't advertise STARTTLS" 'fix' is still very much in place, and probably will be indefinitely, even if that enables the entire Internet to eavesdrop on potentially-exciting stuff like login recovery tokens.
And, yeah, the saddest part is that I could actually live-troubleshoot this issue with anyone at any time, providing PCAPs, updating the outgoing mail server behavior on demand, whatever. But that's just not the way the Internet (or, I guess, anything) works anymore, I'm afraid: 25 years-or-so ago I had, like, the pager number of the person running the national backbone, and we had many late-night conversations fixing subtle-but-annoying BGP/DNS/whatever issues, which was cool.
These days? Being ignored is the best you can hope for, which goes back to my original point that everything is awful. Depressing, really...
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.
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.
Update: they responded to my disclosure with a canned response "there was not enough information to answer your question, please go through our contact form again". I guess that's an invitation to publish.
So here is the primer:
the Belgian National Lottery used to be e-lotto.be. They decided to change (in French) to loterie-nationale.be. You might notice that in Belgium lotto has 2 T, same for "lottery" in English while the organization is "Loterie Nationale" with 1 T.
They didn't register lotterie-nationale.be. I suggested it to them, got ignored. So I did it. If you go there now, you'll get a banner informing you about your mistake. I have a couple of victims every day, a lot more on Friday 13 etc.
There was a recent scandal that our former Finance Minister is accused of money laundering 800,000€ through that platform, so it's not a small website.
Damn, OVH broke the TLS. I migrated it to my server and it's not properly served with a valid TLS. I'll let it run for a few days before publishing the details and insisting at their security contact point.
Thanks
It's not a bank or payment provider per se but still processing a large amount of money. I sent them a new notification. I hope that they won't take too much time to respond.
MasterCard saying there was not a risk to their system after being shown how it could have been just shows how inadequate their concern for security is.
Having worked with payment gateways, most people would be appaled at the sloppy code, documentation, and setup of the systems their payment methods are running through.
It's just amazing that more exploitation isn't happening (though a lot of financial cybercrime never gets busted), and a good chunk of security is probably only reliant on the conscience of coders.
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.
Yeah, buy a mistyped domain in question, setup recursive dns to build the picture of requests, build a “apigw” and route users’ requests to your own api gateway, continue until you phish users’ data or steal their money.
Mastercard was too lucky noone had done that and instead it was a good samaritan who secured the domain name to actually protect the giant corp and had reported it directly to them before disclosing it in public(as far as I understood the sequence of events).
And they are lucky there is zero impact(is it?) and unless this story goes viral outside IT/security research bubbles they won’t even care to correct their reputation and also help Bugcrowd find the definition of “ethical” and “professional” in the dictionary.
Stories like this and Andres Freund who caught a supply chain attack before it was deployed to practically all linux servers help me realize that, sometimes, all it takes is for a decent person doing decent things at the right time to help a lot of people avoid a lot of suffering.
These security vulnerabilities, if exploited, could cause massive suffering. But the people who caught them modestly corrected the issue by exercising their competence and decency.
You could register and pay for a DNS name with a noscript/basic (x)html browser... that was destroyed in the last few year, and now you MUST use a google/apple web engine to do so (geeko|blink/webkit)...
The toxic and filthy agenda of big tech is moving forward, nobody does anything, and it seems they got even trump in their pocket, and democrat regulators were not able to acheive anything pertinent.
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.
Most American financial service companies don't use DNSSEC; most American companies don't use DNSSEC; most of the tech industry doesn't use DNSSEC. Just to note that not finding a DS on mastercard.com is unsurprising.
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.
Really it should be both, where the app asks you to input a code given from the person on the phone (confirms to you they're actually from the bank), and then gives you a code that you tell the person on the phone (confirms to them that you're really the customer).
Of course the more automation you put around this, the easier it becomes to MITM it, like a scammer simultaneously calls both you and the bank and passes the codes back and forth, pretending to you that the call is about a credit card offer, while using the call with the bank to drain your account. That's a lot harder to pull off with a human in the loop as the real bank person will get suspicious at the delayed responses, even barring some amount of stalling ("oh hang on I left my phone downstairs, let me find it oh god it's updating again, let me just get you that code, give me a sec here"). But it becomes trivial if the authentication is moved to IVR and by the time the human operator is on the line the call is already considered safe.
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.
There's always some third party thing I'm trying to figure out why it's telling me 'no' and not providing useful error messages and it's because they can't tell me without also telling the mischief-makers.
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 is very common to test stolen cards at gas stations (relatively anonymous and available, and easy to just drive away if the card fails). If that car wash was attached to a gas station, fraud detection algorithms have a tendency for false positives at gas stations because of that.
On the flip side, it's somewhat difficult to buy an expensive TV without showing up on camera at some point. As methods for monetizing stolen cards go, it's pretty uncommon.
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.
Ironically enough, that's somewhat part of their point. They're lightly mocking the parent poster who wants to erroneously correlate human intuition on what "looks" or "feels like" the obvious problem despite it having no relation to the outcome. There's absolutely no solid conclusion anyone can draw from their story about why they called for the car wash vs the expensive tv, but they wanted to pretend that it's a clear sign of fault in their fraud detection system versus any plausible explanation. I could very easily craft a narrative to flip your expectation of what should be the 'right' outcome, and in the end it's still completely irrelevant to the topic of security.
Which is to say, if someone used a random number generator and received 12345 and then huffed online about how it isn't generating 'real' random numbers in a security thread, you would be right to second guess anything they had to say if they start with an immediately false premise.
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.
* 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.
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.
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.
Give the plumber $2 million and he still won’t be taken seriously at the country club. He can try to buy influence from local politicians, but that only works until an older family disagrees with him and offers something better. Like a job for their niece. Or not to publish those pictures from that party.
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.
> 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.
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.
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.
Details matter, and the examples you came up with are ridiculously off base.
In this case there was a bug bounty program, so it is not as unsolicited as someone washing your windshield at a stoplight.
Secondly this is not a personal residence, thirdly the property was never broken into by the researcher (nor locks changed), finally there's is fiduciary duty from the company to their clients/users.
Since you are keen on hypothetical scenarios, let me present to you a more similar scenario. A school is situated near an old tree in a nearby lot that has a risk of falling, either on the school or on the public sidewalk, the researcher notices it, rents the nearby lot and safely chops down the tree. Then sends a bill to the school for chopping down the tree.
It is important to note that I didn't ask the question in order to get the opinion of strangers on what should happen based on personal ethics, rather I asked the question in case someone knowledgeable about the law knew the actual answer as to what the courts rule.
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?
We were talking about "reasonable", which your reply seems to miss completely. Reasonable can mean a lot of things, including a predefined rate or a fixed way to calculate compensation owed.
"For example, to state a claim for unjust enrichment in New York, a plaintiff must allege that (1) defendant was enriched; (2) the enrichment was at plaintiff's expense; and (3) the circumstances were such that equity and good conscience require defendants to make restitution.[1]"
Of course that (3) is the contentious point typically, but you haven't even gotten (1) right. How does you reading my comment provide value to me?
It's also funny that, excluding the element of a relationship previously existing, This is the way most business on an hourly basis is made.
Suppose you have a lawyer, you agree on 300$/hr, then you ask them to draft a contract and pay them 600$/hr. If someday you are imprisoned and your lawyer is contacted by law enforcement, and they have to bail you out of jail. They would typically send you an invoice even if you didn't solicit that specific service.
While it's not insignificant that you had a previous hourly arrangement for a different type of work, it's certainly not a sufficient reason to claim that you owe them for their time and bond monies.
I feel you are just applying a classic example from ethical hacking 101 that doesn't apply at all.
The common example is that a house can have a door without lock, but it is still a crime to enter. Similarly, entering into a vulnerable system or a system without password even is not legal (although of course the existence of a password or lock mechanism makes undeniable the fact that the place is not for public entry)
In this case there is no entering into any system. There is no lock picked, no server accessed.
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
Unfortunately it doesn't work for instances of, say, a bank accidentally depositing extra money in your account, or their ATMs accidentally dispensing too much cash.
Why would it? The situations are entirely different; in the mail package situation, the outside company is attempting to get you to pay for something that you did not request. In the Bank/ATM, the company made a mistake.
For the bank situation to work, they would have to add an unrequested service to your account and then attempt to charge you for it. i.e. Bank adds overdraft protection to you checking account and then bills you for it.
Say you have an internet plan with a 5GB download limit and after 5GB the connection would no longer send data, one month it lets you download 7GB and then they send you a bill for going over. You probably would not have to pay the bill since they changed their behavior and provided extra without prior notification.
Re:Optics, I agree, but I think they would be counterweighted by the dimension of the issue fixed.
To put a hypothetical example, if I fix a life threatening electrical or structural issue in a children's hospital unsolicited, whatever hit to my reputation I take by charging for unsolicited work, is dwarved and possible restored and reversed by the gravity of the issue fixed and the consquences avoided.
Of course this is contingent on whether the value was actually provided and whether it is provable.
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
> 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...
I’m not sure he’d want to, it would seem like he might want to point to his own scam. But if he did, I imagine he could add back your TXT record after looking it up in any of a large number of historical DNS databases. I can’t vouch for the quality, but a casual Google suggests there are still many, primarily paid but some free-ish, in the mix. Examples:
https://dnshistory.org/
https://whoisfreaks.com/tools/dns/history/lookup
I really don’t think a TXT record is a good place to keep a secret… although it is a good place to prove you control a domain.
> * 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...
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.
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.
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.
> AWS probably has something for Route53.
Called alias records.
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.
> Stay within the cloud provider's ecosystem as much as possible, including for domain registration and DNS
Alas, if you follow this advice to mitigate this particular risk, you're completely hosed if your cloud account gets taken down or compromised. Which is why the standard advice is to do exactly the opposite and make sure your domains and DNS are separate from your cloud provider.
What if you have your domain registered outside of your cloud provider, but have your nameserver on your cloud provider's infra.
You can have another cloud platform configured with a duplicate nameserver, then go to your registrar and change the nameserver for your domain.Your replacement nameserver would then control any subdomain provisioning.
I think that would deal with the risk somewhat, though could be missing something.
> your cloud account gets taken down or compromised
In risk assessment this risk should be resolved as „avoid“, because loosing DNS will be the secondary concern. Data is even more important. I agree that domains should be registered elsewhere and it’s good idea to have the backup of the zone.
Relevant, dangling cloud resources.
DEF CON 32 - Secrets & Shadows: Leveraging Big Data for Vulnerability Discovery - Bill Demirkapi
https://www.youtube.com/watch?v=-KXgcWuv-Ug&t=288s
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?
> A record to an non-elastic IP, and the box gets rebooted
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
new startup idea?
> 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 help run our bug bounty program at a mid-sized company, and we regularly get subdomain-takeover submissions where the reporter has put zero effort into validating the report before submitting it.
They appear to be running some subdomain or certificate search for our domains, then running curl over the results. If they get a 404 they submit it to us as a subdomain-takeover report.
We use a bunch of vendors where we've got foo.example.com CNAMED over to the vendor, but the vendor's servers only serve traffic off some sub-path, and requests to https://foo.example.com/ are going to get 404.
So, I could understand larger organisations simply banning them outright.
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.
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 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.
I am not a security person, and when I tried to report an vulnerability in the authentication signing in the QuickBooks Ruby gem, the process caused me to end up just saying nothing. Intuit pushed me to H1, and I did not feel comfortable with the H1 process, or that I had an advocate for a legal process that I was unfamiliar with.
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.
I'm sure there are Bugcrowd employees here, perhaps they can explain that email
> 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.
Quite simply, fixing security vulnerabilities costs a lot more money than being such a raging dick to researchers that no one ever reports.
No reports means no vulnerabilities and thus no expenditure.
If a short-term-thinking decision-maker has a KPI for low vulnerabilities, they'd rather take the chance of a massive compromise of the company, than to have vulnerabilities reported and definitely hurt their bonus/promotion?
Classic management think right there.
Yeah because only ethical hackers ever look for vulnerabilities
In the U.S. the opposite is encouraged as we lack a lot of safe harbor laws surrounding responsible disclosure. Something as simple as seeing individual's social security numbers hardcoded into HTML could get you dragged through the mud by your state's leaders and the potential threat of jail time.
It's why you'll see a black & white approach to this among bug hunters, instead of a grey / middle-of-the-road one. Some will try to disclose responsibly, the company will deny, and by disclosing through their BBP you've technically agreed to their NDA, so you can't say a word about it even if it still exists a year later. Others will find it and just post it publicly right away, as they don't want to agree to an NDA, and a public action leads to them actually fixing it quickly instead of letting the vuln sit around forever.
> 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.
If the reporter is trying to get paid for not reporting, that's blackmail. If the blackmail is organized, it's a racket.
Plus, if the attack surface is huge and/or fractal, you will never run out of exploits. The more you pay people to find them, the harder they look...
> If the reporter is trying to get paid for not reporting, that's blackmail.
That's not what happened here and isn't usually what happens, though? The reporter usually gives a timeline for fixing the bug before reporting externally, and often extends that deadline if it's clear the Company is working on it. This is separate from bug bounty payments.
> The more you pay people to find them, the harder they look...
Yeah... that's the point...
People will look for bugs regardless, better incentivize them to report to you first
[dead]
I agree that you don't want to create a protection racket market, and that's what I was thinking when I said "being alerted to their own security mess-ups".
Your own staff and vendors are creating security vulnerabilities, and you wisely run a bounty program, to detect and alert you. And you only pay when they find a problem. It can be very economical hedge against both mistakes and systemic dysfunction.
Also, if the researchers were criminally-inclined, they could make more money selling vulnerabilities to someone, not alerting you.
Not to mention, short term cost cutting is what ever business tends to prioritize. Companies would prefer not to pay anyone for anything, including random "researchers".
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.
Ooh, wait.
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?
masterpass et all are triggered more by suspicion of the vendor than the client. but i guess it can be both...
It's both. I got 3ds triggered on a vendor I used all the time, but one time I bought from it while I was in Vietnam - hello secondary verification screen. Also happened for vendor that I had no issues with, but when I used my card from not-US bank - secondary verification screen.
Suspicion on the vendor usually, at least with my banks, triggers a fraud alert that I have to respond. 3DS on the other hand is to verify that the person making a payment is the rightful cardholder.
Masterpass also doesn't always redirect to that verification screen.
> 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
Technically, John Johnson?
Yep. John Smith would be Ivan Kuznetsov.
Thanks, will use the name from now on
> 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.
Glad to clear that up for you.
> 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.
Spill the beans already!
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.
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).
“Not a risk to our system”
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
Knowing what inflated security researcher egos usually are I wouldn't hold my breath to find out the truth here.
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
Back in 2018, I was wondering how that paper was still relevant, considering all the new security features added to web browsers.
The consensus seemed to be that it wasn't that impactful anymore (if it ever was).
https://security.stackexchange.com/q/185435/76718
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?"
Isn't that the more dangerous space to have a typo? Less noticable and more valuable traffic from the data it contains?
Seems odd MarkMonitor wouldn't prioritize that
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?
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"
Modern cell phones don't even dial the number. They just record that you dialed an emergency number, and route an emergency call.
Tried dialing 112 once just to see what would happen, and it immediately connected me to 911. Interesting conversation with the dispatcher when I told them that I had not, in fact, dialed 911.
Also of note (most people know this, but might be worth sharing anyways) I believe emergency calls get special handling by the network, and can go over any tower, not just your carriers'. So if you're somewhere with no reception and you have an emergency, try making the call anyways - it might still go through. This is presumably why cellphones differentiate "Emergency Calls Only" from having no service entirely.
That is correct. You don't even need a SIM card to place an emergency call.
I use an old thrift store flip phone to make 911 calls when I would prefer to stay anonymous. 911 can even call you back using the IMEI!
It's not well known but I believe all of 911(us), 112(eu), 000(au) will work in all of the above countries. And others, almost certainly.
112 is an emergency number "by specification", it will always work (on GSM/UMTS/Vo LTE networks, NOT on landlines)), no matter what country you're in. I think this also applies to 911, although I'm not 100% sure about this.
Numbers like 000 are a different matter, there are scenarios in which they might not work even if you're in Australia (when you have a non-australian SIM or no SIM at all, for example).
For more about this, see e.g.
https://nickvsnetworking.com/tales-from-the-trenches-emergen...
AFAIR, 112 is defined by some ITU or 3GPP standard, which is honored in at least Europe/Russia region. In other places different numbers might as well be routed to it or (even better) redefined inside terminal software (SIM). But I no longer work in that area, so can't be 100% sure.
At least 112 and 911 are standardised in GSM. https://www.gsma.com/newsroom/wp-content/uploads//NG.119-v1....
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.
Wild! I wonder if the line was shorting out and pulse-dialing random numbers, and it just happened to be 911 sometimes, but that's a total shot in the dark. (I vaguely thought payphones had some kind of special connection to the CO, not like a normal phone line you can just DTMF or pulse dial on, but maybe that's made up.)
Some payphones (at least around here) had special buttons that would one-click dial fire/police/ambulance, with no payment required of course.
It's not unbelievable to me that water could get into one of these and "short out" one of these buttons.
That was my first thought. In NZ, 911 has redirected to our emergency number 111 for about 25 years now, but before that, 911 led to a recorded message telling you to hang up and dial 111. I found this out by getting there by accident by pressing the hang-up button a lot of times quickly (for curiosity reasons). In NZ pulse coding for 911 is 1 pulse, then 9 pulses, then 9 again (our rotary dials going the other way is why we use an emergency number starting with 1). I probably pressed the hang-up button once, then decided to press it a bunch more times.
(I vaguely thought payphones had some kind of special connection to the CO, not like a normal phone line you can just DTMF or pulse dial on, but maybe that's made up.)
FWIW, at one time (relative to here in the US at least) there were at least two different major "kinds" of payphones. COCOTS (Customer Owned Coin Operated Telephones)[1] and what I call (for lack of a better term) "telephone company payphones". The latter being owned and controlled by the local telco. Part of the difference is how signaling works. For a COCOT, it is the case that the line is a plain jane line, that you could - ahem cough theoretically cough - beige box onto and dial calls using DTMF or pulse dialing. For those phones, the "magic" that made it a "pay" phone was inside the phone itself. For the "telephone company payphones" the line was configured differently and tones were sent in-band over the line to tell the switch that the coins had been deposited. This is the idea behind the old "red box" notion of recording the coin tones and playing them back to get free calls.
So yeah, a COCOT line could almost certainly be subject to something like random shorts being interpreted as pulse dialing and could possibly call 911. For a telephone company payphone I'm less sure if those supported pulse dialing or not. The lack of coin tones shouldn't matter since calls to 911 are always free, but I'm not sure if the line was different in other ways as well, or not.
Which one the BHI phone was, I never knew. But this was in the late 90's and by then a lot of the old skool telephone company payphones had disappeared in favor of COCOT's so if I had to guess, I'd guess it was a COCOT.
[1]: https://payphone411.com/cocot.html
That makes sense! I've heard the telco/COCOT distinction before, but never summarized quite so succinctly.
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.)
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.
Yep. In a number of places the old ILEC's have publicly declared their intention to deprecate the old copper based PSTN. In other areas, they seem to be practicing a sort of "malicious neglect" and just letting it decay on the vine, to avoid spending money on maintenance.
That a good start on a good horror or thriller story.
It's unrelated (as far as I know) but in an interesting bit of synchronicity, a BHI public safety officer died under somewhat mysterious/controversial circumstances somewhere in that area. It was a few years after I moved out of the area and I'm not familiar with all of the details.
https://crimejunkiepodcast.com/mysterious-death-davina-buff-...
https://www.southernfriedtruecrime.com/38-officer-davina-buf...
https://portcitydaily.com/local-news/2013/12/17/brunswick-da...
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.
Notably, this is only guaranteed by law to work as of 2020 - see Kari's Law: https://www.911.gov/issues/legislation-and-policy/kari-s-law... It is, unfortunately, one of those rules that's written in blood.
Before that, on some systems you'd have to dial 9 to get outside, and then "911" again, so "9911".
Germany has 112 for emergencies and 110 for the police, kinda easy to mistype. So only true for certain degrees of "nobody".
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).
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.
I think most recursive servers will try more than one of the authoritatives before giving up. And it's common to keep stats on which servers work, and send traffic to those.
So if you get the glue that says mastercard has 5 servers, and you already know 4 of them are good, probably send your query to one and don't even bother trying to find the address of the .ne server.
I'd be surprised if it bubbles up in logging unless all/ maybe most of the authoritative servers for a popular hostname/domain name are unresponsive.
yeah you're probably right actually, likely not enough noise to be meaningful
mastercard.net mastercar.net astercard.net nastercard.net... your suggestion changes nothing.
Email addresses, physical addresses, phone numbers, etc are always one letter/digit from another one.
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.
My brother and I have the same initial letter, same problem, but it was possible to use the first two letters as initial with some services. But in practice my mom would open letters to see who it was for, lol.
Yep, when .cm (cameroon) and .co (colombia) started, there were many many domains registered hoping for typo errors for .com.
He should have offered the domain name to akamai. Other requests are also coming to the same address. And akamai should have the integrity to handle them
> A few hours later, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations.
> “We have looked into the matter and there was not a risk to our systems,” a MasterCard spokesperson wrote.
This is a classic, “we have investigated ourselves and found no wrongdoing”, response
This is a multibillion dollar public company that has at least 3.4B branded cards in the wild, and processed 44.3B credit/debit/cash transactions across the globe in Q3 2024.
Admitting wrongdoing is a _short term_ mistake in the market, but sets a shitty company culture. Just like ClownStrike.
A disruption to predatory/parasitic credit/debit networks is well overdue.
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.
> 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.
Their thinking is .. one hand if we ack the problem we risk losing millions in share value. If we deny, a bunch of nerds will whine a bit more.
Without a proof of compromise, sadly it's difficult to force. With a proof of compromise, you're going to jail.
Seems to me that there needs to be a third-party validation authority:
1. It grants a seal/hologram to its members that can be put on products to communicate to the customers that the company takes security validation seriously. Otherwise, they can tell during the marketing presentation that they are not a member and risk making an adverse impression about the security of their product upon their customers (this idea has a dependency on the network-effect which can be hard to get during initial days).
2. Member companies, research companies and individual researchers pay annual membership fees that go towards the operating costs of this authority. The amount is reasonably small for individual researchers or small companies so that it is not a burden.
3. This authority mainly acts as custodian of bug bounties i.e. all bug bounty programs of members are published on its website and it is designated the authorized validator of bounty claims.
4. There is a disclosure framework that this authority, member companies and researchers sign up to.
5. Member companies agree to allow this authority to do the necessary testing of the validation of bounties without threat of suing it.
6. When a researcher finds a vulnerability, it reports the specifics to the authority, instead of risking consequences of legal issues due to any actions by themselves.
7. Upon successful validation, a small percentage of the bounty (e.g. 5 to 10%) goes to the authority and the rest of it is released to the researcher. This acts as an incentive for the authority to vigorously validate the reports.
Yeah. What they really mean is "we talked to a clueless drone in our IT department, who had a personal incentive not to find any exposure, and that person couldn't think of a way to exploit it in 15 seconds".
If you actually know what you're talking about, you basically never feel safe enough to categorically say that something can't be exploited.
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.
Would you please name the bank that had/has this issue?
> “We have looked into the matter and there was not a risk to our systems,”
I'll be honest, that doesn't appear to be the case to me. Almost certainly if that researcher was allowed to go ahead and register an HTTPS cert for the domain there'd be plenty of juicy traffic merely protected by SSL and nothing more.
> he alerted MasterCard that the domain was theirs if they wanted it,
feels wrong, considering all the other domains making the same typo.
Yeah, huge surprise.
Have you ever tried to report a technical issue to a Big Tech company, like, at all? If so, 'silence' is the best you can expect, with 'a threatening letter' and 'a SWAT visit' being the runners-up.
Example of the first: if your mail server uses the default-Windows-2016-TLS stack, Facebook's mail servers will immediately disconnect after issuing a STARTTLS command and receiving your server certificate. Why? No idea, everyone else seems to be fine, but this has been ongoing for years.
Second example: you can steal any Dutch "OV bike" simply by impersonating the MiFare classic UID of any valid subscriber, without any rate limits on those attempts. I reported this issue to them in 2016, they tried to sue me and failed, then tried to talk me and failed to listen, and to this day this vulnerability exists.
Third example: phew, none (SWATs are not as eager to mobilize around here), but I would not be surprised, like, at all, if I were to get an early-morning wake-up call just for trying to correct someones SPF records via an advisory email...
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.
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
I reported weird shit happening with SYN and PING and what I got was "how dare you insult my reports" from Paul Vixie; but I used to work for him. Ultimately I blocked all SYNs and ICMP ping inbound from Amazon addresses, spoofed or not. Problem solved. Boohoo soi disant "security researchers".
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.
On a quarterly scale, history shows it typically has little to no effect on e.g. stock valuations.
> 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.
Oh yes, I forgot to tell you, facebook.com/whitehat is pretty good at escalating issues to the right team, but I don't know if someone would triage it and say it's not a security issue and then it has no urgency.
> but I don't know if someone would triage it
Well, I have a pretty good idea, and the answer won't comfort you.
To further elaborate on this pointless saga: last December, I actually met a FB engineering executive while on holiday, happened to mention this issue in casual conversation (I know: sad!) and they were going to put me in touch with All The Right People who were going to Fix This Immediately.
Guess what? The "oh, if the remote rDNS ends with mail-mail.facebook.com, just don't advertise STARTTLS" 'fix' is still very much in place, and probably will be indefinitely, even if that enables the entire Internet to eavesdrop on potentially-exciting stuff like login recovery tokens.
And, yeah, the saddest part is that I could actually live-troubleshoot this issue with anyone at any time, providing PCAPs, updating the outgoing mail server behavior on demand, whatever. But that's just not the way the Internet (or, I guess, anything) works anymore, I'm afraid: 25 years-or-so ago I had, like, the pager number of the person running the national backbone, and we had many late-night conversations fixing subtle-but-annoying BGP/DNS/whatever issues, which was cool.
These days? Being ignored is the best you can hope for, which goes back to my original point that everything is awful. Depressing, really...
I have with Apple. Got a very generous bounty that paid for my university though it did take close to a year
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.
That’s insane. What a huge step backwards. I hope they see consequences.
[dead]
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.
Anyone care to venture a guess as to the institution?
Update: they responded to my disclosure with a canned response "there was not enough information to answer your question, please go through our contact form again". I guess that's an invitation to publish.
So here is the primer: the Belgian National Lottery used to be e-lotto.be. They decided to change (in French) to loterie-nationale.be. You might notice that in Belgium lotto has 2 T, same for "lottery" in English while the organization is "Loterie Nationale" with 1 T. They didn't register lotterie-nationale.be. I suggested it to them, got ignored. So I did it. If you go there now, you'll get a banner informing you about your mistake. I have a couple of victims every day, a lot more on Friday 13 etc.
There was a recent scandal that our former Finance Minister is accused of money laundering 800,000€ through that platform, so it's not a small website.
Firefox warned me about mismatching certificate on your site. I don't think most people would click accept risk seeing the scary page.
Damn, OVH broke the TLS. I migrated it to my server and it's not properly served with a valid TLS. I'll let it run for a few days before publishing the details and insisting at their security contact point. Thanks
It's not a bank or payment provider per se but still processing a large amount of money. I sent them a new notification. I hope that they won't take too much time to respond.
MasterCard saying there was not a risk to their system after being shown how it could have been just shows how inadequate their concern for security is.
Having worked with payment gateways, most people would be appaled at the sloppy code, documentation, and setup of the systems their payment methods are running through.
It's just amazing that more exploitation isn't happening (though a lot of financial cybercrime never gets busted), and a good chunk of security is probably only reliant on the conscience of coders.
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.
It's absulutely shameful that Mastercard said there was no risk. I hope he alerts the U.S. regulators about this (https://www.consumerfinance.gov/).
> Caturegli said it took $300 and nearly three months of waiting to secure the domain with the registry in Niger
Oh, that sounds a lot like how much fun I had trying to register a Tajikistan .tj domain from the USA a number of years ago.
> there was not a risk
Yeah, buy a mistyped domain in question, setup recursive dns to build the picture of requests, build a “apigw” and route users’ requests to your own api gateway, continue until you phish users’ data or steal their money.
Mastercard was too lucky noone had done that and instead it was a good samaritan who secured the domain name to actually protect the giant corp and had reported it directly to them before disclosing it in public(as far as I understood the sequence of events).
And they are lucky there is zero impact(is it?) and unless this story goes viral outside IT/security research bubbles they won’t even care to correct their reputation and also help Bugcrowd find the definition of “ethical” and “professional” in the dictionary.
Stories like this and Andres Freund who caught a supply chain attack before it was deployed to practically all linux servers help me realize that, sometimes, all it takes is for a decent person doing decent things at the right time to help a lot of people avoid a lot of suffering.
These security vulnerabilities, if exploited, could cause massive suffering. But the people who caught them modestly corrected the issue by exercising their competence and decency.
There is another thing which went "unnoticed":
You could register and pay for a DNS name with a noscript/basic (x)html browser... that was destroyed in the last few year, and now you MUST use a google/apple web engine to do so (geeko|blink/webkit)...
The toxic and filthy agenda of big tech is moving forward, nobody does anything, and it seems they got even trump in their pocket, and democrat regulators were not able to acheive anything pertinent.
In the last few years, it was the democrat regulators running the show.
The revolving door just keeps spinning, no matter the party.
I don't blame the democrat regulators. It is very hard to go against thousands of billions.
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).
Most American financial service companies don't use DNSSEC; most American companies don't use DNSSEC; most of the tech industry doesn't use DNSSEC. Just to note that not finding a DS on mastercard.com is unsurprising.
Why wouldn't they update the SOA?
Someone remind me what value business people add to society?
netsec is a joke. i still remember this elevated bash execution which was lying in plain sight since ever, no one saw it.
Mastercard: "We have looked into the matter and there was not a risk to our systems"
Also Mastercard: has expressed concerns about the public nature of this disclosure.
Good for him for making it all public. The only way to (sometimes) get big companies to fix their mistakes (besides the legal system) is to shame them into it.
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.
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 you are talking to on the bank side and asks you to confirm that you’re on a call with that person
Really it should be both, where the app asks you to input a code given from the person on the phone (confirms to you they're actually from the bank), and then gives you a code that you tell the person on the phone (confirms to them that you're really the customer).
Of course the more automation you put around this, the easier it becomes to MITM it, like a scammer simultaneously calls both you and the bank and passes the codes back and forth, pretending to you that the call is about a credit card offer, while using the call with the bank to drain your account. That's a lot harder to pull off with a human in the loop as the real bank person will get suspicious at the delayed responses, even barring some amount of stalling ("oh hang on I left my phone downstairs, let me find it oh god it's updating again, let me just get you that code, give me a sec here"). But it becomes trivial if the authentication is moved to IVR and by the time the human operator is on the line the call is already considered safe.
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...
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.
This is truly the next level of "Security by Obscurity"! :'D
If they don’t know, at least the fraudsters won’t, either!
I hate that this is true.
There's always some third party thing I'm trying to figure out why it's telling me 'no' and not providing useful error messages and it's because they can't tell me without also telling the mischief-makers.
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 is very common to test stolen cards at gas stations (relatively anonymous and available, and easy to just drive away if the card fails). If that car wash was attached to a gas station, fraud detection algorithms have a tendency for false positives at gas stations because of that.
On the flip side, it's somewhat difficult to buy an expensive TV without showing up on camera at some point. As methods for monetizing stolen cards go, it's pretty uncommon.
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.
Ironically enough, that's somewhat part of their point. They're lightly mocking the parent poster who wants to erroneously correlate human intuition on what "looks" or "feels like" the obvious problem despite it having no relation to the outcome. There's absolutely no solid conclusion anyone can draw from their story about why they called for the car wash vs the expensive tv, but they wanted to pretend that it's a clear sign of fault in their fraud detection system versus any plausible explanation. I could very easily craft a narrative to flip your expectation of what should be the 'right' outcome, and in the end it's still completely irrelevant to the topic of security.
Which is to say, if someone used a random number generator and received 12345 and then huffed online about how it isn't generating 'real' random numbers in a security thread, you would be right to second guess anything they had to say if they start with an immediately false premise.
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.
If anything, the publicity (more mentions of their company name) may have even led to a slight uptick in sales.
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.
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.
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.
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.
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.
There are time and probability elements which can only be reduced down to NPV (net present value) my making assumptions and analysis.
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.
Give the plumber $2 million and he still won’t be taken seriously at the country club. He can try to buy influence from local politicians, but that only works until an older family disagrees with him and offers something better. Like a job for their niece. Or not to publish those pictures from that party.
Not sure how many times I have to acknowledge non-monetary power before it sticks…
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.
> 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.
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.
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.
Additionally in this case the company has a bug bounty policy / program, so it isn't quite unsolicited.
Details matter, and the examples you came up with are ridiculously off base.
In this case there was a bug bounty program, so it is not as unsolicited as someone washing your windshield at a stoplight.
Secondly this is not a personal residence, thirdly the property was never broken into by the researcher (nor locks changed), finally there's is fiduciary duty from the company to their clients/users.
Since you are keen on hypothetical scenarios, let me present to you a more similar scenario. A school is situated near an old tree in a nearby lot that has a risk of falling, either on the school or on the public sidewalk, the researcher notices it, rents the nearby lot and safely chops down the tree. Then sends a bill to the school for chopping down the tree.
It is important to note that I didn't ask the question in order to get the opinion of strangers on what should happen based on personal ethics, rather I asked the question in case someone knowledgeable about the law knew the actual answer as to what the courts rule.
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?
We were talking about "reasonable", which your reply seems to miss completely. Reasonable can mean a lot of things, including a predefined rate or a fixed way to calculate compensation owed.
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?
"For example, to state a claim for unjust enrichment in New York, a plaintiff must allege that (1) defendant was enriched; (2) the enrichment was at plaintiff's expense; and (3) the circumstances were such that equity and good conscience require defendants to make restitution.[1]"
Of course that (3) is the contentious point typically, but you haven't even gotten (1) right. How does you reading my comment provide value to me?
It's also funny that, excluding the element of a relationship previously existing, This is the way most business on an hourly basis is made.
Suppose you have a lawyer, you agree on 300$/hr, then you ask them to draft a contract and pay them 600$/hr. If someday you are imprisoned and your lawyer is contacted by law enforcement, and they have to bail you out of jail. They would typically send you an invoice even if you didn't solicit that specific service.
While it's not insignificant that you had a previous hourly arrangement for a different type of work, it's certainly not a sufficient reason to claim that you owe them for their time and bond monies.
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.
most door locks can be easily picked.
can i go from house to house, pick locks and then demand payment?
(spoiler: no)
I feel you are just applying a classic example from ethical hacking 101 that doesn't apply at all.
The common example is that a house can have a door without lock, but it is still a crime to enter. Similarly, entering into a vulnerable system or a system without password even is not legal (although of course the existence of a password or lock mechanism makes undeniable the fact that the place is not for public entry)
In this case there is no entering into any system. There is no lock picked, no server accessed.
irrelevant.
can i just decide on my own to do some work, and then *demand* payment for such work?
the answer is still no.
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
Unfortunately it doesn't work for instances of, say, a bank accidentally depositing extra money in your account, or their ATMs accidentally dispensing too much cash.
Why would it? The situations are entirely different; in the mail package situation, the outside company is attempting to get you to pay for something that you did not request. In the Bank/ATM, the company made a mistake.
For the bank situation to work, they would have to add an unrequested service to your account and then attempt to charge you for it. i.e. Bank adds overdraft protection to you checking account and then bills you for it.
Say you have an internet plan with a 5GB download limit and after 5GB the connection would no longer send data, one month it lets you download 7GB and then they send you a bill for going over. You probably would not have to pay the bill since they changed their behavior and provided extra without prior notification.
Re:Optics, I agree, but I think they would be counterweighted by the dimension of the issue fixed.
To put a hypothetical example, if I fix a life threatening electrical or structural issue in a children's hospital unsolicited, whatever hit to my reputation I take by charging for unsolicited work, is dwarved and possible restored and reversed by the gravity of the issue fixed and the consquences avoided.
Of course this is contingent on whether the value was actually provided and whether it is provable.
Of course not.
That sounds like a fine, not an invoice. If you can compel them to pay, sure. ;)
No.
A fine is punitive, an invoice is compensatory.
They can not.
[dead]
[dead]
[flagged]
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”