Mastercard DNS error went unnoticed for years
krebsonsecurity.com
krebsonsecurity.com
This instance of openly-registerable nameservers is just one (relatively rare) subset of a wide class of dangling DNS issues [1].
Much more common is direct mapping of names to IP addresses on cloud providers that can be obtained by attackers [2][3]. Because of the scope and lack of global visibility that often comes with cloud services, an enterprise that uses is the cloud is very likely to have some vulnerabilitity like this under some subdomain.
Unfortunately bug bounty programs often blanket exclude any form of "subdomain takeover" as a valid security threat, despite the fact that they're easily exploitable once discovered. We have internal (and public[4]) data showing all manner of sensitive information leaked as a result of this sort of configuration mismanagement.
Ultimately, as others have observed, the current vulnerability disclosure landscape makes it far too easy for corporations to weasel out of acknowledging bona fide vulnerabilities, and of course ethical and legal expectations make it impossible for good-faith researchers to meet the bar of proof expected by these providers.
To others' comments: yes, these vulnerabilities are trivially exploited to provision TLS certificates in practice, a risk that is unfortunately downplayed.
[1] https://dl.acm.org/doi/pdf/10.1145/2976749.2978387 [2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf [3] https://pauley.me/post/2022/cloud-squatting/ [4] https://arxiv.org/pdf/2204.05122
Think:
* CNAME pointing to an S3 bucket, and the S3 bucket gets released
* CNAME pointing to Azure Website/WebApp Instance
* A record to an non-elastic IP, and the box gets rebooted
* DNS name using a Route53 name server that no longer part of the org's AWS account
* CNAME pointing to a Heroku/Shopify/GitHub pages account and the account gets deleted/deactivated freely up those names for registration
* MX record pointing to old transaction email provider start up that dies, and someone else registers that domain name...
Why does that happen?
* Decentralization of IT means people spinning up infrastructure not knowing what they are doing
* Great a spinning up infra, but when decomissioning they forget about DNS
* Lots of subsidiaries, lots of brands, different groups, operating in different geographies. All this makes it difficult to discover and enforce proper policies
* Geo-specific websites/apps (Think of all the country-specific websites Coke runs)
* Using some 3rd party vendor and never telling security about it (Marketing spinning up some landing pages on some fly-by-night martech provider or wordpress host, and never turning them off)
I am the Field CTO at a venture backed Israeli cyber security company in this space. I was literally talking to a major computer part company yesterday about the dozen or so Indonesian gambling websites that are "running" on their domain names using their pagerank and links. This is a weekly conversation
It helps not using the cloud.
Otherwise, good IaC can help but even in larger companies, I see more ClickOps then I should.
Called alias records.
- 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.
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.
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.
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.
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...
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...
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.
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
DEF CON 32 - Secrets & Shadows: Leveraging Big Data for Vulnerability Discovery - Bill Demirkapi
I am still curious though - how does AMP make such exploits easier? Would you happen to know?
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.
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.
Neither option is particularly palatable.
[1] https://www.bugcrowd.com/resources/hacker-resources/platform...
If they're regular enough to see your comment, they may be able to expand the idea and explain it better.
I will say that Google's VRP is the exception. They have top notch people who answer the initial report, will keep you in the loop (usually) and will consider impact if you'd gone further. BC or H1 are hit or miss, and more often miss.
Doesn't behavior like this mean that security researchers are more likely to intrude further next time -- at this company and others -- to gather more evidence of impact, expecting the company to lie about it otherwise?
If you want some corporate spokesperson to be able to say "nothing to see here", shouldn't you reward the researcher amply enough that they're fine with the impact being downplayed?
Then kinda going after the researcher in trying to suppress the news, after (AFAICT) the researcher already did the right thing... Does the credit card company have a reason to do that? Or is it more likely some misguided PR staff thinking that's their job? Or some exec ultimately responsible for the infosec mistake, personally not wanting that embarrassment on their watch, and using company resources to try to suppress news of it?
Yes. They want to make security researchers too afraid to publish their findings.
"Discreetly let us know, at the earliest sign of vulnerability, sign a contract with NDA, and we'll investigate, fix, and compensate you promptly. We'll also publicly acknowledge, in vague terms, for your career development, that you successfully discovered a vulnerability that has been addressed. (But if you intrude beyond the boundaries we've clearly specified, then we don't have a business relationship, and we have appropriate government offices on speed-dial.)"
That's if the company wants NDA. I'm not saying that's how it should be done; just suggesting what seems like a more vendor relationship, business transaction way of being alerted to their own security mess-ups, if that's what they want.
> 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.
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.
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...
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...
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.
No reports means no vulnerabilities and thus no expenditure.
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.
Ooh, wait.
Anyway, their SSL certificate expired, as it naturally does with enterprise webs.
All (most?) online transactions with certain class of MasterCard cards were completely SOL at that moment.
They did not renew the cert for more than a year. No amount of communication attempts with MasterCard could help, neither from customers (me) nor from banks' IT departments. Then they just quietly dropped the service altogether.
While I was poking I have found that the service is written in microsoft-something (IIS), certificate chain was unusually long with intermediates which I never heard of and all of that is hosted in a third-world country quite far away from Ukraine. But that's another story.
I don't remember it's ever expiring, at least in the US. IDK how they handle traffic in different countries. It sounds a lot more like your traffic got routed somewhere else and not MC?
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.
Yeesh
“Ivan I” likely stands for “Ivan Ivanov” which is the Russian equivalent of “John Smith” a fake common name
> “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.
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.'
At least that's my guess, but it's not super clear what attacks would be possible here.
Also, if you knew the culture in there, you would appreciate the extreme irony of them making a mistake like this.
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).
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.
Glad to clear that up for you.
I have no doubt that’s heavily lawyered and is justifiable. What is their “system”… Define it the way you want and the statement is true
[1] https://en.wikipedia.org/wiki/Bitsquatting
[2] https://www.securitee.org/files/bitsquatting_www2013.pdf
The consensus seemed to be that it wasn't that impactful anymore (if it ever was).
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.
Remember tpc.int?
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.
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.)
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.
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...
It's not unbelievable to me that water could get into one of these and "short out" one of these buttons.
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.
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.
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...
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!
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.
Before that, on some systems you'd have to dial 9 to get outside, and then "911" again, so "9911".
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.
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.
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.
According to Wikipedia, Akamai is one of Markmonitor's customers, so it is surprising that this wasn't already registered by them.
Seems odd MarkMonitor wouldn't prioritize that
> “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 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.
If you actually know what you're talking about, you basically never feel safe enough to categorically say that something can't be exploited.
Without a proof of compromise, sadly it's difficult to force. With a proof of compromise, you're going to jail.
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.
I am not sure why anybody would take these matters lightly.
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.
feels wrong, considering all the other domains making the same typo.
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...
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.
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.
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...
"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.
They don't do bug bounties though
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".
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 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've never heard of such a law, is it common? In which jurisdiction?
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.
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.
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.
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.
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.
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.
The revolving door just keeps spinning, no matter the party.
See all issues on: https://internet.nl/site/mastercard.com/3122570
Nameserver is not reachable on advertised IPv6:
$ dig +short +tcp @dns1.mastercard.com dns1.mastercard.com AAAA
2607:3c00:6404:4::53
$ dig +tcp @2607:3c00:6404:4::53 mastercard.com SOA
;; Connection to 2607:3c00:6404:4::53#53(2607:3c00:6404:4::53) for mastercard.com failed: timed out.
Also: no HSTS on apex, while HSTS with "includeSubDomains ; preload" on www, this does not work! And it's worse, they do some geo-redirect, so apperantly for US IP addresses http://www.mastercard.com redirects to https://www.mastercard.us/en-us.html (see https://hstspreload.org/api/v2/preloadable?domain=www.master...)I also would expect an IPv6 on the apex/www, since there are quite some ISP's with IPv6 where IPv4 is a GCNAT, if there is a noisy user on the IPv4, it's tricky to block those, except if the ISP supports IPv6 and the web server too.
Weirdly enough the SOA serial which is in YYYYMMDDnn (see https://datatracker.ietf.org/doc/html/rfc1912#section-2.2) was not updated (still indicates 2011):
$ dig +short +tcp @dns1.mastercard.com mastercard.com SOA
dns1.mastercard.com. hostmaster.mastercard.com. 2011127982 14400 3600 2419200 300
Some other SOA record abnormalities: $ dig +short @a22-65.akam.net. az.mastercard.com SOA
a1-29.akam.net. hostmaster.az.mastercard.com. 2020068768 3600 600 604800 300
Indicates 2020, and hostmaster@az.mastercard.com is not reachable because az.mastercard.com does not have an MX record, nor A/AAAA record.Sadly nobody recorded this in either DNSViz history (https://dnsviz.net/d/az.mastercard.com/Z5ErUw/dnssec/ is the first) or ZoneMaster history (see https://www.zonemaster.net/en/result/3fa42e8e683db1bf).
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.
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.
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.
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.
Where do I send the invoice?
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.
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?
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?
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.
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.
It will be a colossal waste of everyone's time and money, though, because they will never prevail.
A fine is punitive, an invoice is compensatory.
can i go from house to house, pick locks and then demand payment?
(spoiler: no)
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.
can i just decide on my own to do some work, and then *demand* payment for such work?
the answer is still no.
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.
That cost has to be factored into the return from pivoting.
* 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.
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.
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.
Like I said, money isn’t the only power. But power is the only thing money is.
No one cared.
The challenge is for customers and companies to communicate and agree to the new social contract.
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.
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.
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)
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...
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.
Seriously?!?
Everybody knows that's not a random number.
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.
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.
Disclaimer: my bank does this
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.
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.
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.
They did stop putting hyperlinks in email communications though. It’s a start.
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.