16 ms·
Mastercard DNS error went unnoticed for years
- deleted 2y ago[deleted]
- pizzalife 2y agoNot 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".
- Avamander 2y agoYup, 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.
- cedws 2y agoI 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.
- addams 2y ago> ... 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.
- diggan 2y ago> 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.
- silisili 2y agoI 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.'
- diggan 2y agoI 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.
- cowsandmilk 2y agoIf JavaScript is served from those domains, there may be something interesting. Or if data is submitted to the domains.
- sfjailbird 2y agoWithout 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.
- baobun 2y ago
- thedanbob 2y agoMastercard: "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.
- zettabomb 2y agoYeah, 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.
- JohnMakin 2y agothis 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.
- TZubiri 2y agoCan 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?
- ziddoap 2y agoThe 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.
- thatguy0900 2y agoThe 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
- fuzzer371 2y agoObviously 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.
- abound 2y agoNot 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 https://en.wikipedia.org/wiki/Bitsquatting [2] https://www.securitee.org/files/bitsquatting_www2013.pdf https://www.securitee.org/files/bitsquatting_www2013.pdf
- esnard 2y agoBack 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 https://security.stackexchange.com/q/185435/76718
- mattl 2y agoWhat's your solution for Niger and Colombia ISO 3166-2 codes?
- betaby 2y agoMasterCard 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.
- Throwthrowbob 2y agoWould you please name the bank that had/has this issue?
- antithesis-nl 2y agoYeah, 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...
- xyst 2y agoThe 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
- antithesis-nl 2y ago> 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.
- deleted 2y ago[deleted]
- 2y ago
- xyst 2y ago> A few hours later, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations. > “We have looked into the matter and there was not a risk to our systems,” a MasterCard spokesperson wrote. This is a classic, “we have investigated ourselves and found no wrongdoing”, response This is a multibillion dollar public company that has at least 3.4B branded cards in the wild, and processed 44.3B credit/debit/cash transactions across the globe in Q3 2024. Admitting wrongdoing is a _short term_ mistake in the market, but sets a shitty company culture. Just like ClownStrike. A disruption to predatory/parasitic credit/debit networks is well overdue.
- gnfargbl 2y agoThe 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-behavior-standards/ https://www.bugcrowd.com/resources/hacker-resources/platform...
- xnorswap 2y agoSomeone 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.
- mjg59 2y agoI 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.
- bradly 2y agoI 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.
- NitpickLawyer 2y ago> 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.
- jcarrano 2y agoI 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.
- tredre3 2y ago> 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?
- thenickdude 2y agoJapan has a finders' fee of 5-20%: https://www.police.pref.ehime.jp/foreigner/otoshimono/2.pdf https://www.police.pref.ehime.jp/foreigner/otoshimono/2.pdf
- donatj 2y ago> 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.
- nashashmi 2y agoHe 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
- neilv 2y ago> 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?
- staunton 2y ago> Does the credit card company have a reason to do that? Yes. They want to make security researchers too afraid to publish their findings.
- neilv 2y agoThen 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.
- sdwr 2y ago> 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.
- jiveturkey 2y ago> he alerted MasterCard that the domain was theirs if they wanted it, feels wrong, considering all the other domains making the same typo.
- lulznews 2y agoSomeone remind me what value business people add to society?
- nrvn 2y 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.
- londons_explore 2y ago> “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.
- edarchis 2y agoIt'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.
- rkagerer 2y agoAnyone care to venture a guess as to the institution?
- edarchis 2y agoIt'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.
- edarchis 2y agoUpdate: 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.
- hbossy 2y agoFirefox warned me about mismatching certificate on your site. I don't think most people would click accept risk seeing the scary page.
- resters 2y ago[flagged]
- Argonaut998 2y agoIt 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”
- ericpauley 2y agoI'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 https://dl.acm.org/doi/pdf/10.1145/2976749.2978387 [2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf [3] https://pauley.me/post/2022/cloud-squatting/ https://pauley.me/post/2022/cloud-squatting/ [4] https://arxiv.org/pdf/2204.05122 https://arxiv.org/pdf/2204.05122
- billyhoffman 2y agoBeyond 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
- aaronmdjones 2y agoI'm surprised Akamai didn't have any alerting in place to tell Mastercard that the nameservers they had configured were wrong.
- kmoser 2y agoYou'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.
- qwertox 2y ago> A few hours later, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations. > “We have looked into the matter and there was not a risk to our systems,” a MasterCard spokesperson wrote. “This typo has now been corrected.” Always the same. These statements make my blood boil.
- Hizonner 2y agoYeah. 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.
- emmelaich 2y agoTheir 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.
- noisy_boy 2y agoSeems 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.
- egorfine 2y agoA 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.
- 0x457 2y agomasterpass 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?
- 1oooqooq 2y agomasterpass et all are triggered more by suspicion of the vendor than the client. but i guess it can be both...
- 0x457 2y agoIt'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.
- bwblabs 2y agoDNSSEC 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 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 http://www.mastercard.com redirects to https://www.mastercard.us/en-us.html https://www.mastercard.us/en-us.html (see https://hstspreload.org/api/v2/preloadable?domain=www.mastercard.com 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 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/ https://dnsviz.net/d/az.mastercard.com/Z5ErUw/dnssec/ is the first) or ZoneMaster history (see https://www.zonemaster.net/en/result/3fa42e8e683db1bf https://www.zonemaster.net/en/result/3fa42e8e683db1bf).
- datadeft 2y agoWe 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.
- whimsicalism 2y ago> 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
- charliebwrites 2y agoJust a note: “Ivan I” likely stands for “Ivan Ivanov” which is the Russian equivalent of “John Smith” a fake common name
- deleted 2y ago[deleted]
- SoftTalker 2y agoTechnically, John Johnson?
- sudahtigabulan 2y agoYep. John Smith would be Ivan Kuznetsov.
- tryauuum 2y agoThanks, will use the name from now on
- mcbebu 2y agoThe best UFC fighter of all time?
- unit149 2y ago[dead]
- 11944351 2y ago[dead]
- larodi 2y agonetsec is a joke. i still remember this elevated bash execution which was lying in plain sight since ever, no one saw it.
- fortran77 2y agoIt's absulutely shameful that Mastercard said there was no risk. I hope he alerts the U.S. regulators about this (https://www.consumerfinance.gov/ https://www.consumerfinance.gov/).
- sylware 2y agoThere 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.
- themaninthedark 2y agoIn the last few years, it was the democrat regulators running the show. The revolving door just keeps spinning, no matter the party.
- sylware 2y agoI don't blame the democrat regulators. It is very hard to go against thousands of billions.
- etruong42 2y agoStories 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.
- neycoda 2y agoMasterCard 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.