Steve Gibson (15:05)
Yeah, I know that, that is, that was annoying that when like, because I had, you know, I. We all had had series one tivos and they became somewhat endangered at some point anyway since I tend to stick with things until I'm forced to switch, you know, the approach of just, you know, putting the money in up front and then riding it out a long way, that's always worked well for me. So anyway, just to follow up on my raves about EM Client last week, I wanted to say I'm even more pleased now with my switch than I was then and I heard from many of our listeners who were saying things like what took you so long? They had discovered EM Client years ago and similarly love it. So in addition to thanking everyone who wrote to make sure that I knew that it was possible to own it outright and that it I oh, and that it's 100% free to take it out for a spin for 30 days to see whether you might feel the same way about it as I do. Anyway, in my opinion, you know, they really got the user experience right. And of course Leo, you perked up upon hearing that it also fully supports end to end encrypted GNU PG email and address books. So that's in there too. So anyway, my entire reason for mentioning my own discovery of EM Client last week was to make sure that everyone at least had the opportunity to check it out and that if, you know, if they too were feeling frustrated with our current solution, whatever they might be using, they would know about it. And that was a success. Dan Taylor, one of our listeners, said, hi Steve, I realize that you receive a ton of email these days and your time is valuable so I'll attempt to keep this short. I just feel the need to thank you for mentioning EM Client on the podcast. I hope you saw my message about the one time purchase option they have. It's not at all obvious on the pricing page, but it's there. And for what it's worth, I did have other people say they didn't see it either. So maybe the EM Client people could do a better job of although they probably would rather like you paid for it for the rest of your life every month. You know, I think what what you like after four years you is the break even point or something. So it's like okay, I'm going to be using this. Well more than that anyway, he said, he said Dan Taylor said I had no previous knowledge of its existence. In a nutshell, it's wonderful exclamation point. He said. I have only one Gmail account. I also own two domains via Cloudflare, which forwards all email destined for those domains to my Gmail. He said, I've configured some aliases, one of which I'm using to send this to you. It's very cool, he said. Also, I know you know this, but you've done an outstanding job on Spinrite61 as I type this My Zima board is churning away on a 256 gigabyte flash drive that's been giving me problems. I've already run a level three on another one which improved its performance. Thanks again. So Dan's need for only a single domain where he's got the other ones forwarding into it suggests that he may be able to use EM client's free single account offering forever and so never need to go. I've got four domains that I need minimum. So anyway, just wanted to close the loop on that. Thank you all of our listeners. With the audience size we have, when I make a mistake like this I get corrected. And so I'm I'm happy to stand corrected on this because I am so happy that I own this thing. Okay, this week's first piece of security news is as as they would say in the UK is gobsmacking. Our friend Brian Krebs over at Krebs on Security shared a wonderfully surprising piece of news last Wednesday under his headline MasterCard DNS error went unnoticed for Years. And before we go any further into that exactly, you know what exactly went unnoticed, I want to first highlight that it wasn't unnoticed for minutes or days or weeks or even months, but literally for years. Which is what like puts a sharp point on this. Brian wrote the payment card giant MasterCard just fixed a glaring error in its domain name server settings that could have allowed anyone to intercept or divert Internet traffic for the company by registering an unused domain name. The misconfiguration persisted for nearly five years, he writes, until a security researcher spent $300 to register the domain and prevent it from being grabbed by cybercriminals. Now Brian's article then posts the output of a DNSDIG command which returns the name servers for a portion of the MasterCard.com domain. I have a screenshot of the command's output in the show notes. Even knowing that something is wrong with this picture, you would need to be sharp eyed to catch the mistake. I missed it the first time I looked at it. I looked at the screen without having read the text yet because it's big on Brian's page and I kind of scanned over it, okay, looked okay, Brian explains. He said from June 30 of 2020 until January 14 of 2025, thanks to the work of this security researcher, he said one of the core Internet servers that MasterCard uses to direct traffic to portions of the MasterCard.com network was misnamed. MasterCard.com, he says relies on five shared domain name system DNS servers at the Internet infrastructure provider Akamai. All of the Akamai DNS server names that MasterCard uses are supposed to end in akam.net but one of them was misconfigured to rely on the domain Akam ne. Yes, whoever created this is me talking. Whoever created, edited or updated the DNS record for that mastercard.com domain on June 30th of 2020, which lists the five authoritative DNS name servers that should be referred to when looking up any IP address for MasterCard.com subdomains made a tiny and earth shaking mistake. Just a simple typo when they were entering the names of the five name servers and it's as plain as day once you know what to look for. The first name server is named a129.akam.net the second one is a767.akam.net the fourth one is a 2666. Who knows why those are the machine names but and the fifth one is a 964akam.net but the one in the middle of those five. The third one is a 2265 Akam NE. The final T of. NET was never entered and boy does that make a difference. Brian continues to tell the story, writing this tiny but potentially critical typo was discovered recently by Philippe Catoregli, founder of the security consultancy Ceralis S E R A L Y S Cataregli said he guessed that nobody had yet registered the domain Akam Ne, which is under the purview of the top level domain authority for the West African nation of Niger. And Leo in that picture on the screen, the four, the third item of the five very clearly AKA E N E. They've dropped that final T. So Cataragli said it took $300 and nearly three months of waiting to secure the domain with the registry in Niger. After enabling a DNS server on Akam Ne, he noticed hundreds of thousands of DNS requests hitting his server each day from locations around the globe. Now I'm not sure about this, Brian wrote. Apparently MasterCard wasn't the only organization that had fat fingered a DNS entry to include Akam Ne, but they were by far the largest. Now, I don't know, maybe he was seeing other DNS queries to other domains not clear to me. If so, that really makes you wonder how common these sorts of mistakes might be. Like it would be worth. I don't want to give bad guys any ideas, but you know, there might be others, Brian said. Had he enabled an email server on his new domain, akam ne. Catarigli likely would have received wayward emails directed toward mastercard.com or other affected domains. If he'd abused his access, he probably could have obtained website encryption certificates, I'm sure he could have, that were authorized to accept and relay web traffic for affected websites. He may even have been able to passively receive Microsoft Windows authentication credentials from employee computers at affected companies. But the researcher said he didn't attempt to do any of that. Instead, he alerted MasterCard that the domain was theirs if they wanted it. Copying this author, meaning Brian Krebs, on his notifications a few hours later. Okay, quickly. To their credit, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations. Uh huh, right. A MasterCard spokesperson wrote, quote, we have looked into the matter and there was not a risk to our systems. This typo has now been corrected. Okay, Now I suppose technically it's true that there was not a risk to their systems, but there was certainly a serious risk to anyone who might be relying upon the security of of MasterCard's systems, since that flew out the window with this typo, and that was five years ago. Brian continues writing. Meanwhile, Cataract Lee received a request submitted through bugcrowd, a program that offers financial rewards and recognition to security researchers who find flaws and work privately with the affected vendor to fix them. You know, in other words, responsible disclosures and bug bounties. Brian says the message suggested his public disclosure of the MasterCard DNS error via a post on LinkedIn after he'd secured the akam.ne domain was not aligned with ethical security practices and passed on a request from MasterCard to have the LinkedIn post removed. Cataregli said he does have an account on bug crowd, has never submitted anything through the bugcrowd program, and that he reported the issue directly to mastercard. Cataregli wrote in reply, quote, I did not disclose this issue through bugcrowd before making any public disclosure. I ensured that the affected domain was registered to prevent exploitation, mitigating any risk to MasterCard or its customers. This action, which we took at our own expense, demonstrates our commitment to ethical security practices and responsible disclosure, unquote. Now most organizations have at least two authoritative domain name servers, and that's true. That's what Brian wrote and that's what I do for grc. And that's typical. That's why most people will see two DNS servers in their own computers. This has always been done to create some redundancy for the sake of DNS lookup reliability, Brian says. But some handle so many DNS requests that they need to spread the load over additional DNS server domains, which is also true. And in fact, DNS deliberately responds when there is a list of available DNS servers, it will send them in round robin fashion so that successive requests get a differently ordered list of name servers in order to further cause them to get spread out. So if they always listed the first one first, then everyone would just choose that one. And so you would wouldn't really get much effect of having five. So in MasterCard's case, that number is five. So it stands to reason that if an attacker managed to seize control over just one of those five domains, they would be able to see about one fifth of the overall DNS requests coming in. But Cataragli explained that the reality is many Internet users are relying, at least to some degree. And this is what Brian is writing on public traffic forwarders or DNS resolvers like cloudflare and Google. Okay, now, I would strengthen that statement a lot to say that there is, I would argue, no one who is not relying upon caching resolvers. As we've often discussed on the podcast, caching DNS is, is critical. It's the only way this hierarchical system of distributed domain name resolution is able to function. You know, when you turn on your computer for the first time in the morning and you go to Amazon.com, you're not hitting Amazon.com's name server to find out a list of IP addresses. Your ISP has obtained that from any other of the customers of its customers who you are sharing the ISPs DNS server with. So it's in the DNS server's cache for eight hours a day, who knows how long. So caching is crucial for this whole process, Cataragli said, quote so all we need is for one of those resolvers to query our name server and cache the result. And here's the key. By setting their DNS server records with a long ttl, which is the time to live, a setting that can adjust the lifespan of data packets on the network. Actually, it's the lifespan of the cache of the DNS record, which is cached throughout the DNS hierarchy, an attacker's poisoned instructions for the target domain can be propagated by large cloud providers. He said, with a long ttl, we may reroute a lot more than just one fifth of the traffic. Okay, and so that's absolutely true. Typical TTLs, you know, are maybe an hour or two depends upon. I mean, it's entirely up to the discretion of the person who's setting up an entity's DNS. The longer the TTL that you publish, that is how long you are telling the rest of the DNS caching hierarchy out on the Internet, it can wait before it comes back to refresh your IP address. The longer that is, the fewer requests you're going to get. Right, because a greater percentage of the request will be handled by all the caching out on the Internet. So back in the, you know, two decades ago when G. When GRC was, was first being a victim of DDoS attacks, I would decrease our TTL so that I could change IPs. Well, that's no longer feasible because it's not about changing IPs. Today's attacks just swamp the bandwidth, so there's no point in doing anything except just waiting. But if an organization's IP addresses are very stable, then it can make sense to set a TTL to 24 hours, for example. And many of them are. In fact, if you try to set it too low, many caching resolvers will ignore a too low setting and just set their own minimum, ignoring what you have asked for. Anyway. Cataragui said he hoped that MasterCard might thank him or at least offer to cover the cost of buying the domain. He wrote in a follow up post on LinkedIn regarding Mastercard's public statement, quote, we obviously disagree with this assessment, but we'll let you judge. Here are some of the DNS lookups we recorded before reporting the issue. And then his post, which Brian quoted and has a picture of in Brian's own reporting, shows a sobering list of the queries that were coming into his NE domain. We can see West Europe, east us, West US au, Southeast au, East Australia east and more. And remember that this DNS record was last changed and had been incorrect for the past four and a half years. So let's just say that if this had fallen into the hands of a malicious Russian or Chinese attacker, you know, who repeatedly demonstrated that they're looking for any advantage they can find over the west, the story we would be reporting today would have a very different ending. Now that said, mistakes happen and anyone can make an innocent mistake. I'm sure that's all this was. This was just that, you know, at least MasterCard had the good sense and grace not to threaten this researcher who helped them significantly in return for nothing other than some recognition for his sharp eyes and, you know, the demonstration of his own integrity within his community. But wow. And again, the. The thing that, the thing that really caught me out here was the suggestion that this wasn't just me. Mastercard.com queries that were coming in as a result of this typo, that would suggest that there were other places where this Azure stub domain was being referred to and somebody was referring to somebody else had it, as in their own DNS, not just MasterCard, which again, you really sort of wonder how many typos exist in DNS and how many opportunities there are to get up to some real mischief. You know, we've talked often. I mean, when Dan Kaminsky discovered that DNS recursive resolver queries had insufficient randomization in their queries, which allowed for their caches to be poisoned by bad guys guessing what a query would be and inserting a malicious response that panicked the entire industry so much that in, in a matter of 24 hours, all DNS resolvers were updated in a, like in a pre planned, staged, secret update. I mean, it was that big a deal. This is that scale. So I hope, I hope the news gets out and people check their DNS records because, you know, a typo, as we've seen here, can go unseen for five years and could cause some real damage again, not to the company, but to the people who are relying on the security of its services. Wow. And Leo, we're a little. After a little more than half an hour in, let's take a break and then we're gonna. We're gonna look at what happens when script kiddies think they're getting away with something.
