Leo Laporte (2:54)

Oh dear.

Steve Gibson (2:56)

We've got Russia to follow China's vulnerability reporting laws to no good end. For the West a pair of scattered spider UK teen hackers were arrested and I'm just. It's so Sad. I mean, 18 and 19 years old, your life, your, your life is screwed.

Leo Laporte (3:15)

Yeah.

Steve Gibson (3:16)

Facebook, Instagram and TikTok are violating the EU's DSA. What's going to come of that? Microsoft Teams is bringing user WI fi tracking by policy to the teams platform. Wouldn't that sound like a great idea? I know. So you backed up. That's great. Did you test that backup? Turns out many backups don't work. Coveware reports an all time low in ransomware payment rates and boy, they've got some great insight into what's going on with the way ransomware negotiators. Well, I mean the, the, they are a ransomware negotiator and they've got some great feedback from their position as a ransomware negotiator on, on how the bad guys get in. We're going to look at all of that. We've got lots of listener thoughts and feedback about NIST password policy. Oh boy, that mean that just really. Wow. We have got people.

Leo Laporte (4:23)

Whoa.

Steve Gibson (4:23)

We got people defending changing your passwords every five minutes. So we'll cover that. And also someone who was very happy with the fact that Azure or Entra or something allowed them to further lock down the ability of their listeners to sidestep those policies. Lots of good stuff. And finally, against all reason and begging credulity, it seems that we still haven't managed to put high quality random number generators into our DNS resolvers. It's like, what, how, what, what? You could even use that, that NSA sketchy PRNG and be in better shape than this. And I'm going to make the point, make the case that there is so absolutely no excuse for anything on a network not to have, like to have solved this problem long ago because packet timing is unpredictable and gives you a source that you can then use.

Leo Laporte (5:36)

You've got, you've, you've got a, ran a really random source. Yeah.

Steve Gibson (5:39)

Yes. If you're a little embedded thing on some blob with no access to the world, then you could see it would have a hard time coming up with entropy if, I mean, it's all deterministic. But nothing on a network is deterministic by definition. A DNS resolver is on a network. So yeah, anyway, we're going to go all through that and I'll, I'll kind of try to calm down, but we'll.

Leo Laporte (6:09)

Also find out, and I'm anxious too, why you need a random number generator. But you'll answer that question, I'm sure.

Steve Gibson (6:14)

Yes. We're going to go back and do a little bit of recap. But more than anything, Leo, I've been told that punning is the lowest form of humor. I don't really understand why, but Great Britain's public voted for the name of their new train track. Leaf Clearing Train. And that's our picture of the week because.

Leo Laporte (6:39)

Okay.

Steve Gibson (6:40)

No one is going to believe it.

Leo Laporte (6:41)

Okay. It's not Boating with Boatface.

Steve Gibson (6:44)

No. But it is reminiscent of.

Leo Laporte (6:46)

They should have learned from that.

Steve Gibson (6:49)

Actually, there was a reference to bodeface in the BBC's coverage of what Great Britain chose.

Leo Laporte (6:57)

They've got to stop letting the public choose these names. I'm sorry. We'll find out in a moment. It's our picture of the week. All right, Steve, if you can turn yourself down just a little bit. You're clipping a little.

Steve Gibson (7:10)

I'm going to step back a little. Just calm. I'm going to calm myself.

Leo Laporte (7:13)

Maybe it's because you were a little. Back off on the coffee. Okay. You know, it's funny, I, I used to drink coffee before this show to get in sync with you. Right. And I, But I can't sleep if I drink coffee this late in the day. So now I'm just gonna sit here.

Steve Gibson (7:29)

It is afternoon. Yeah.

Leo Laporte (7:30)

Yeah. I try to have one cup in the morning and stop there.

Steve Gibson (7:33)

Because otherwise, for what it's worth, espresso has much less caffeine. I know actual.

Leo Laporte (7:38)

I drink espresso. Oh. Which makes me vulnerable.

Steve Gibson (7:41)

That's the problem. Set themselves. I, you know, I.

Leo Laporte (7:46)

I, I'm very.

Steve Gibson (7:47)

Modest, set my own clocks.

Leo Laporte (7:49)

So there's one device in the house, the microwave, that I still have to go set. Even the stove is on WI fi. The refrigerator is on WI fi. Everything in here is either on WI FI or WWV or something. It's getting its time. But. Oh, and there's a, there actually, there's a little red clock across from me. But like the Nixie clock even sets itself. Everything sets itself except for my microwave and one red clock across from me. So I have my chores set up for me on Sunday. John used to do that. Right, John, you used to do that clock.

Steve Gibson (8:23)

Wrong.

Leo Laporte (8:25)

No, it's UTC.

Steve Gibson (8:27)

Ah, of course. So it's unusable. It's unusable.

Leo Laporte (8:31)

It's 24 hour UTC. So, yeah, you have to do math to understand what time it is.

Steve Gibson (8:36)

You do like to give our listeners the UTC time?

Leo Laporte (8:39)

I do, because.

Steve Gibson (8:41)

So you can just turn around to.

Leo Laporte (8:42)

Find out we have people in every time zone. Well, not every but many different time zones and I can't give you all the time zones, so I give you UTC and I let you do the math. That's really my motto.

Steve Gibson (8:56)

That would be nice.

Leo Laporte (8:57)

Let you do the math. You do the math.

Steve Gibson (9:01)

That works for the podcast.

Leo Laporte (9:03)

Also. We're going to get to the picture of the week in just a moment, but first, a word from our sponsor. This show brought to you today by Hawks Hunt. Oh, man. You need Hawks Hunt. As a security leader, what's your job to protect your company and cyber attacks. Right? Job one. But that job is getting harder and you know it. With more cyber attacks than ever before. And nowadays phishing email. Used to be you could look at a phishing email and if you were clued in, you could almost always go, yeah, that's. Come on, really? That's a phishing email. Nowadays they generate emails with AI that are perfect. They're letter perfect. They're really deceptive. Which means your legacy one size fits all awareness program really doesn't stand a chance. You know, I mean, they send at most 4 generic trainings a year. And most employees look at them and go, oh, please. And it just, you know, they don't. Either they ignore them or if they're forced to click through them, they go, yeah, yeah, yeah, yeah, yeah. And, and the worst thing is when somebody, you know, clicks on one of these fraudulent, you know, these, these test emails, they're forced into embarrassing training programs that makes, that makes them feel like they're being punished. You can't learn if you're being punished. That's why more and more organizations are trying Hawks Hunt. Hawks Hunt is real. This works. It goes way beyond security awareness. It changes behaviors, and it does it by making it fun. It rewards good clicks and coaches away the bad clicks. So you send an email, you know, you're phishing your test emails. And when an employee suspects that email might be a scam and clicks on it, hawkshunt tells them, you know, practically with fireworks, they, they tell them instantly your. Your employee is going to get a dopamine rush. It feels good. They go, oh, this is great. And they're gonna. And they were gonna click and they're gonna learn and they're gonna protect your company. Cause they enjoy it. It's. It's more fun. And you'll enjoy it as an admin because Hawkshunt makes it easy to automatically deliver phishing simulations across every possible path. We'll talk about this later in the show. All the ways the bad guys are getting in email slack teams plus, you can use Hawkshunt's built in AI to mimic the latest real world attacks, so you can design custom attacks. The simulations are personalized to every employee based on apartment and location and all the stuff that you know about them, which means they're really good. And these instant micro trainings, they're not punishment, they're fun, they solidify understanding. They literally drive lasting, safe behaviors. You can trigger gamified security awareness training that awards employees with stars and badges. You might say, oh, come on, that's silly. No, no, no, really, they love it. I love it. When you get a gold star, man, you feel good. That boosts completion rates and ensures compliance. And you can choose from a huge library of customizable training packages. You can even generate your own with the AI. So it's completely to fit your needs. Hawkshun has everything you need to run effective security training. It's all in one platform, meaning it's easy to measurably reduce your human cyber risk at scale. You got to measure it if it's going to work right. You don't have to take my word for it. Over 3,000 user reviews on G2 make Hawk Hunt the top rated security training platform for the enterprise, including easiest to use and best results. It's also recognized by Gartner as a customer's choice. Thousands of companies use it. Qualcomm is a customer, AES, Nokia. These companies are using it to train millions of employees all over the globe. Visit hoxhunt.com securitynow to learn why modern secure companies are making the switch to Hawkshunt. That's hoxhunt.com securitynow h o x Like Fox Hunt with an H. H O X H u n t hawkshunt.com securitynow we thank them so much for supporting the show and for the work they're doing to help our lovely listeners stay safe and secure. Hawkshunt.com SecurityNow all right, I have queued up the official picture of the week.

Steve Gibson (13:19)

So once again, this was the name of the train. The official Network Rail train. Yes, which Great Britain's public voted for. The train's job is to blow leafs off the track, which apparently is a big problem in the fall. There's like a leaf problem and they.

Leo Laporte (13:47)

Painted the name on the side of the train.

Steve Gibson (13:50)

That's right, the train. The official name in Great Britain for the train track leaf clearing train is Control Alt D Leaf.

Leo Laporte (14:02)

Oh my God, that's brilliant. You know what? That's so much better than Boaty McBoatface. Brilliant, isn't that now I'm glad they voted on it.

Steve Gibson (14:09)

The public said this is what we want to see barreling down the tracks. Control alt delif.

Leo Laporte (14:16)

I love it.

Steve Gibson (14:17)

I thought that was great and I thank you to one of our listeners for saying that and seeing it and thinking, okay, this is Steve's got to see this for the podcast. So thank you. Okay. Under the topic of haven't we heard this before? We have a story published in Futurism.com with the headline man alarmed to discover his smart vacuum was broadcasting a secret map of his house. Secret map is. But okay, so covering this hacker's blog posting, Futurism wrote, forget your phone spying on you. Maybe it's your vacuum you should really be worried about. In a post on his blog, Small World, the computer programmer and electronics enthusiastic Harish Hakanar Narayanan. Narayanan. I think that's as good as I can get. Narayanan detailed a startling find. Steve was startled. Leo he made about his 300 smart vacuum, not a cheap one. It was transmitting intimate data out of his home. So imagine that. Who would have, you know, we did talk about like the danger of robot vacuums and mapping back, you know, years ago. Narayanan, they wrote, had been letting his iLife A11. So it's iLife A11 smart vacuum, which is turns out to be a popular gadget that's gained mainstream media coverage, they wrote, do its thing, you know, vacuuming for about a year before he became curious about its inner workings. He wrote, quote, I'm a bit paranoid, the good kind of paranoid. So I decided to monitor its network traffic as I would with any so called smart device. He said within minutes he discovered a steady stream of data being sent to servers, quote, halfway across the world, unquote. Like again, that's where they are, those servers. He wrote, my robot vacuum was constantly communicating with its manufacturer, transmitting logs and telemetry that I had never consented to share. That's when I made my first mistake. I decided to stop it. The engineer says he stopped the device from broadcasting data, though kept the other network traffic like firmware updates running as usual. The vacuum kept cleaning for a few days after that until early one morning it refused to boot up. He wrote. I sent it off for repair. The service center assured me it works perfectly here, sir, he wrote. They sent it back and miraculously, it worked again for a few days. Then it died again. Narayanan would repeat this process several times until eventually the service center refused to do any more work on it, saying the device was no longer in warranty. He said. Just like that, my $300 smart vacuum transformed into a mere paperweight. Okay. Now, in all fairness, he was screwing around with its network traffic, right? So, okay, I would argue that he got what he's asked for. But the story continues, he said. More curious than ever, Narayanan now had no reason, it being out of warranty, not to tear the thing apart. And apparently he was going to keep his floors clean. Some other means looking for answers. Which is exactly what he did after reverse engineering the vacuum, a painstaking process which included reprinting the devices circuit boards.

Leo Laporte (18:22)

Wow.

Steve Gibson (18:22)

He had a lot of time on his hands. And testing its sensors, he found something. Android Debug Bridge, a program for installing and debugging apps on devices, was, quote, wide open to the world. Well, yeah, you know, like a few connection points on a circuit board, so you know, the world can't get to it. But he could, Narayanan said. In seconds, I had full root access. No hacks, no exploits, just plug and play. Meaning he didn't have to do anything except hook up some wires to it. Fine. Through a process of trial and error, he was able to create an SSH connection from the vacuum to his computer. That's when he discovered a bigger surprise. The device was running Google Cartographer, an open source program designed to create a 3D map. 3D, I guess. Well, I was. I would seem that 2D would be enough, but okay, a 3D map of his home data, which the gadget was transmitting back to its parent company. In addition, Narayanan says he uncovered a suspicious line of code broadcasted from the vacuum or from the company to the vacuum, timestamped to the exact moment it had stopped working, he wrote. Someone or something had remotely issued a kill command, he said. I reversed the script change and rebooted the device. It came back to life instantly.

Leo Laporte (20:06)

Oh my God.

Steve Gibson (20:08)

They hadn't merely incorporated a remote control feature. They had used it to permanently disable my device.

Leo Laporte (20:15)

They had a kill switch.

Steve Gibson (20:16)

They had a kill switch. In short, he said the company had made the device that had made the device, quote, unquote, had the power to remotely disable devices and used it against me for blocking in in response to blocking their data collection. Whether it was intentional punishment or automated enforcement of compliance, the the result was the same. A consumer device had turned on its owner, unquote. Narayanan warns that the dozens of smart vacuums are likely operating similar systems. And actually, in his blog posting, which I did read fully, he talked about why. There was a reason, a reason to believe that the that the guts had been, you know, spread among many other vacuum manufacturers that, you know, that it was, you know, basically white labeled internally. And many people were using the same thing. He said our homes are filled with cameras, microphones and mobile sensors connected to companies we barely know, all capable of being weaponized with a single line of code.

Leo Laporte (21:31)

This is why people were upset about Amazon's bid to buy Roomba last year was, oh, well, Amazon will get all the mapping data because these devices do have to make a map of your home. That's how they work.

Steve Gibson (21:45)

They do. One could argue they need not be sending it back to. Right.

Leo Laporte (21:49)

To the mothership. Yeah.

Steve Gibson (21:51)

So he, he. So the article in Futurism.com says at the end of the day, it's a stark reminder that for profit tech often comes at a hidden cost and one that doesn't end after you pay at the register. Okay, now this article and Narayanan's original blog posting, as I said, which I both of which I read, strike me as being somewhat sensationalized. Like it was a huge surprise that this no, like this very capable 300 robot vacuum, which he did not design and program, might be doing things that he didn't expect. But the essence of the reality of today's IoT devices is that electronics and memory have become so inexpensive and at the same time powerful that a tremendous amount of processing and communications capability is sitting inside even our smallest connected devices. The little vacuum was running Linux and Google cartography system. So, I mean, yikes, you know, written in go probably. And he was able to log on to his vacuum and see the various scripts and running it had a file system in there. So.

Leo Laporte (23:23)

Well, it's an Android device, right?

Steve Gibson (23:25)

That's the whole point. Yes.

Leo Laporte (23:27)

Like an Android phone, it's got adb. You use ADB and you get into it and you can root it.

Steve Gibson (23:32)

Right.

Leo Laporte (23:32)

But the other point is that iLife is a Chinese company. So remember when you bought that Chinese switch, the on off switch?

Steve Gibson (23:42)

Yeah.

Leo Laporte (23:43)

You had the same concern.

Steve Gibson (23:45)

So. Right. Narayanan's blog expresses surprise at finding his network's unencrypted WI FI access credentials sitting in the device's file system. How did he expect it to be on his network if it wasn't able to use his WI FI access credentials to log itself on? And his blog claimed with some indignity that those credentials were being sent back to the device's manufacturer. He wrote, quote, at this point, I had enabled SSH port access, allowing me to connect to the system from a computer. Then I reassembled the entire device, because he'd taken the whole thing apart. After experimenting with Linux access for a while, I found logs, configurations and even the unencrypted WI FI credentials that the device had sent to the manufacturer's servers. Okay, so none of this should come as any surprise to our listeners, but the reason I wanted to take some time to share it is that it's one thing to assume that something could happen, but it's something more to examine and confront a real world instance where it actually is happening. In other words, this is happening. And you know, essentially any device that's connected to a network that requires authentication credentials, and they all do, in order to hook to your WI fi, no matter how small and innocuous that device may appear to be, will have those credentials, which it could very well be leaking back to the device's home servers. There's no reason it ever should. Doesn't need to in order to function. But nothing prevents it. And it's easy to imagine some coder geek somewhere thinking that it would be cool to collect and archive every one of their customers home router logon credentials for no other reason than it's possible. And storage is cheap.

Leo Laporte (26:00)

Well, and there are reasons because Amazon does this. When you set up an Amazon device it says, you know, I could just remember your credentials. And then when you set up another Amazon device it'll be. It'll just join the network.

Steve Gibson (26:12)

How comforting.

Leo Laporte (26:13)

Yeah, and if you had a bunch of I life devices, you might say, oh yeah, look, I just hook them all up automatically.

Steve Gibson (26:20)

Yeah, magic. It's not like they're talking to each other. They're talking back to the mothership, the home.

Leo Laporte (26:26)

The home office.

Steve Gibson (26:26)

Yeah, that's right.

Leo Laporte (26:27)

In Shenzhen, China.

Steve Gibson (26:29)

That's right. It's also important to appreciate that any connected device will be providing the entities that designed the device with full access behind the network's router to the internal residential network to which the device is authenticated. In his blog, Marianan also noted quote, the device came with RTTY software installed by default. This small piece of software allows remote root access to the device, enabling the manufacturer to run any command or install any script remotely without the customer's knowledge, of course. Again, it's a rolling Linux platform that you've given access to your network to and it's phoning home. So anyone using one of these will implicitly have invited a powerful network awareness Linux powered consumer computing device into their home and given it full access to their home's internal network. We all know the story of the Trojan Horse. One of the many reasons I pray that hostilities with our friends in the east never escalate is that there must be people inside the government of the PRC that understand quite well that they already have persistent access into the internal residential networks of all of the more upscale homes in the West. I'm certain that none of these devices were designed to be Trojan horses, but any of them with sufficient flexibility can fill that bill. The emergence of of isolated guest WI FI accounts in, you know, capabilities in consumer routers has been a very good thing. But it's still necessary to be certain to enable that guest WI FI account network isolation, not to just have an additional SSID and password for your guests. Isolation is typically not the default because the barriers it deliberately erects between your main network and the guest network can result in some additional overhead when devices on the primary network need to contact devices on the private or the guest network. I'm sure that virtually no regular consumers appreciate what it means to have invited IoT gadgets in into their homes. It's almost certain that nothing would ever come. Probably this will all amount to nothing. Let's hope nothing will ever come of having done so. But at the very least it's something that all security aware users, like everyone listening to this podcast, should just, you know, take up some residence in the back of their mind that all of these IoT things, Leo, as you said, they phoned hone to, to Shanghai or Shenzhen or who knows where and they've got connections and there's no, there's no justifiable reason for this vacuum rolling around the floor to be streaming data back to central headquarters. I mean, the problem is storage is cheap for them there, bandwidth is cheap for us everywhere. Now. Nothing prevents it from happening. And it is happening.

Leo Laporte (30:20)

Yeah, you should assume it is.

Steve Gibson (30:23)

Yeah, yeah. I mean it is. And one of the things I've, I've often wanted to do, but I've never had the time. Maybe once I get all of the other software that I really want to get done as a, as my primary finished is, it is quite frightening to look at one's actual bandwidth at the router. I'm sitting at my computer doing nothing and suddenly a huge amount of data leaves my network. Why? Nothing I did, but I can see it happening. It would be really cool to be able to disambiguate all of that traffic and create a user interface that shows users who care who, who's talking to who, what is all this going on? Because our networks are very, very busy and we have no visibility into that.

Leo Laporte (31:18)

Well, I mean, we used to be able to do that with wireshark, right? I mean, you could run something like that.

Steve Gibson (31:23)

Yeah. But all you get is a raw packet dump. I mean, it's not doing any great. I mean, I'd love to know what to say. Oh, that's apple.com. don't worry, that's just your eye things.

Leo Laporte (31:33)

Right.

Steve Gibson (31:34)

Doing some work. But, you know, if it's heading off to ch, there's like large bandwidths of stuff going off to China. It'd be nice to know which of your devices, you know, is doing that talking.

Leo Laporte (31:45)

And I bet you could record with wireshark and then send it to an AI, have it kind of translated or analyze it. I bet you you could do that.

Steve Gibson (31:54)

Yeah, A lot of steps. I just like for zapier, I would like to have a, you know, a nice little UI or maybe upload it to GRC and a page at GRC will show you.

Leo Laporte (32:06)

Okay, Steve, who's in charge there?

Steve Gibson (32:12)

Somebody who's very busy, it turns out.

Leo Laporte (32:14)

Oh, somebody who's scrambling.

Steve Gibson (32:17)

Yeah. I expected I would have the benchmark finished before Andy had his website published, but right now it's kind of nick and neck.

Leo Laporte (32:24)

I'm not sure it is. It's a race.

Steve Gibson (32:27)

Okay. So I was looking at a bit of news about some new Russian legislation that was interesting but not particularly compelling. And I thought, okay, I'm not going to put this in the podcast until that article tied back to the apparent results from the similar legislation that China had put in place four years ago. We talked about it at the time. It's going to be familiar to our, to our listeners. But this suggests that all of this is important. So here's what happened. Russian lawmakers, this is, I'm reading from the. The piece of news that I found are working on a new bill that would require security researchers, security firms, and other white hat hackers to report all vulnerabilities they find to the state in a law. That's similar in spirit to a law already in effect in China since 2021. Remember, we talked about this in China, where you actually, like, organizations were ranked and like, got a higher reputation level if they submitted more vulnerabilities to the state. And there was even like a minimal, a minimum required reporting level in order to like, stay on the good guys list. I mean, they really made it a, like a save saving face sort of thing for the Chinese culture there. Anyway, the article said. We will circle back to that in a second. The article says the bill is currently be the Russia bill is currently being discussed among lawmakers and no official draft is available yet. It is part of Russia's efforts to regulate its white hat ecosystem, a process officials began working toward three years ago in 2022. All previous efforts have failed, with the most recent one being knocked down in the Duma in July on the grounds that it did not take into account the special circumstances and needs of reporting bugs in government and critical infrastructure networks. Now, according to sources who spoke to Russian business magazine rbc, a new draft of the bill is being prepared. The biggest change in this upcoming version is the addition of a requirement to not only report all vulnerabilities to the vendor or network owner, but also to Russian authorities. Three state agencies will be in control of this new unified system that takes in vulnerability reports and will be making new rules or requirements for researchers going forward. They they include the country's main internal intelligence service, you know, the well known fsb, the National Coordination center for Computer Incidents, which is sort of a cert like organization created and operated under the FSB since 2018, and the FSTEC, which is Russia's cryptography export control and dual use technology agency under the country's military. So under this proposed new forthcoming legislation, security researchers who fail to report bugs to this state unified system will face criminal charges for unlawful transfer of vulnerabilities. In other words, a new thing is going to get created like where you have to transfer vulnerabilities by law to the state and if you don't then you are you face criminal charges under unlawful transfer. The bill will also introduce a new concept of registries for companies that run run bug bounty programs and for registries for researchers themselves. You have to register to be a researcher where white hats will have to provide their real names to the state. No more of these hacker monikers. This last part has been a contention in previous versions of the bill, with the private sector and security researchers pushing back hard against it for some legitimate reasons. As the RBC piece, which is the the that that Russian business magazine points out, researchers are uncomfortable with providing the government with their real names. They argue that a leak or a hack of this system would pose serious threats to their safety, being at risk of being kidnapped by criminal groups and forced to produce vulnerabilities under the threat of violence. Yikes. They also fear their data falling into the hands of foreign governments which may sanction their accounts or arrest them on trips abroad for conferences or vacations. And yes, all of that's been seen. So yeah they they so the the, the guys who are finding the vulnerabilities want to remain anonymous, and they're making a strong case for that because they're seen as elite hackers whose work product has real value not only to the Russian government to, but to the criminal side. So the bill is intended to cover all facets of the white hat ecosystem, from criminal commercial bug bounty programs to internal vulnerability rewards programs, you know, bug bounties at private corporations, and from individual researchers doing hobby work to pen testing assignments. So basically, anybody who is in a position to ever find a bug in any software who's inside of Russia, all bugs, no matter where and how they were found, must be reported. And researchers will receive legal liability protection if they follow the rules. So they cannot be, you know, sued by a, a commercial company for reporting a bug in that commercial software. So that's important legal liability protection so long as they abide by these rules. The liability protection, however, was not enough to get the Russian infosec community on the government side last time and may still not be enough to convince them this time around that it's in their best interests to reveal their real names and give the government a copy of all their research for free, which is what this also amounts to. So Russia is working toward legislation which would require all security researchers to register with the Russian government, giving them their real name and identity information and mandatory reporting of anything they might discover in software that doesn't work as it should. Now, here's the part, while not surprising, is most worrisome. And believe it or not, we didn't even get there yet. In July of 2021, which we talked about at the time, the Chinese government passed a similar law that required all Chinese researchers and security firms to report bugs to the government no more than 48 hours after its discovery. People were worried that the Chinese government would abuse the intent behind these reports of unpatched bugs, unpatched and unknown bugs to benefit its own offensive offensive operations. And time has proven that to be happening. The use of zero days by Chinese APTS advanced Persistent Threat Groups has increased dramatically since the Chinese law went into effect four years ago. A draft for Russia's new White Hat research law is expected to reach the Duma by the end of the year, although it's unclear if it will pass, since this whole thing has had three years worth of controversy attached to it already, with the Russian infosec community making a good argument against it, or at least the public registry part of it. Okay, so this update caused me to go digging a bit further and I found a piece of think tank research about the status of this Chinese program. The think tank wrote the Cyberspace Administration of China, cac, the Ministry of Public Security, the mps, and the Ministry of Industry and Information Technology. The MIIT published the regulations on the management of network Product security vulnerabilities, known as the RMSV, in July of 2021. So four years ago, even before the regulations were implemented in September of that year, analysts had issued warnings about the new regulation's potential impact. At issue is the regulation's requirement that software vulnerabilities, you know, flaws in code that attackers can exploit will know that they would be reported to the MIIT within 48 hours of their discovery by industry. The rules prohibit researchers from publishing information about vulnerabilities before a patch is available unless they coordinate with the product owner and the MIIT publishing proof of concept code used to show how to exploit a vulnerability. And they're not allowed to exaggerate the severity of the vulnerability. In effect, the regulations, the think tank wrote, push all software vulnerability reports to the MIIT before a patch is available.

Leo Laporte (42:40)

Oh, that's the key. Before the patch is available, yes.

Steve Gibson (42:45)

Conversely, the system currently in place in the US relies on voluntary reporting to companies with vulnerabilities sourced from researchers chasing money and prestige or from cybersecurity companies that observe exploitation in the wild, they wrote. Software vulnerabilities are not some mundane part of the tech ecosystem. Hackers often rely on these flaws to compromise their targets. For an organization tasked with offensive operations, such as a military or intelligence service, it is better to have more vulnerabilities. Critics consider this akin to stockpiling an arsenal. When an attacker identifies a target, they can consult a repository of vulnerabilities that enable their operation. Collecting more vulnerabilities can increase operational tempo, success and scope. Operators with a deep bench of tools work more efficiently. But companies patch and update their software regularly, causing old vulnerabilities to expire. In a changing operational environment, a pipeline of fresh vulnerabilities is particularly valuable, they wrote. Again, I'm going to wrap this up by jumping way down to some of this very long and detailed reports conclusions. Here are the four paragraphs that really make the case. The report finishes writing Three earlier reports contour China's software vulnerability ecosystem. Combined, they demonstrate a decrease in software vulnerabilities being reported to foreign firms and the potential for these vulnerabilities to feed into offensive operations. So here they are three. First, the Atlantic Council's Dragon Tales report demonstrates that China's software vulnerability research industry is a significant source of global vulnerability disclosures and that U.S. legislation prior to China's disclosure requirements significantly decreased the reporting of vulnerabilities from specific foreign firms, adding to the US Entities list, removing an important source of security research from the ecosystem. Second, Microsoft's Digital Defense Report 2022, so that was only one year after the the new legislation went into effect in China, showed a corresponding uptick in the number of zero days deployed by PRC based hacking groups. Microsoft explicitly attributes the increase as a likely result of the rmsv, which is this new reporting requirement. Although less than a year's worth of data do not make a trend, both reports gesture at the impact of the regulation in expected ways based on China's past behavior of weaponizing the software vulnerability disclosure pipeline. And finally, third, Recorded Future published a series of reports in 2017 with evidence indicating that critical vulnerabilities reported to China's National Information Security Vulnerability Database. That's that cnnvd, which is run by the mss, were being withheld from publication for use in offensive operations. So way before this became a law, it was already happening. Now with it being a law, it is happening more. So this all leaves very little doubt that China, as a sober and aggressive cyber war participant, is doing everything it can to marshal and weaponize the vulnerabilities that are continually being discovered in deployed software. And now it appears that Russia will soon be formalizing a similar strategy if they can get a buy in from the existing infosec ecosystem. Maybe they'll have to, you know, soften the registration requirements a bit, but clearly they want to be at parity with the strategy that China has taken, which is benefiting China at everybody else's expense. It turns out LEO software is not perfect.

Leo Laporte (47:30)

Ever. Who would have thought, who would have thunk it?

Steve Gibson (47:33)

You know one thing that is perfect though?

Leo Laporte (47:36)

Our advertisers.

Steve Gibson (47:37)

I knew you were going to guess correctly.

Leo Laporte (47:42)

Let's take a little break. We will come back. Actually, I was thinking as you were talking about how I could use Zapier to automate a wire so I could have Wireshark. Well, Zapier is their sponsor, so I should probably explain that I could have Wireshark get all the packets going outside the network and then have Zapier use AI to process that and deliver to me a finished report. Seems like it'd be fairly easy to do. In fact, I probably should have done it while I was thinking about it. This episode of Security now brought to you by Zapier. I. I actually am always thinking about ways I Can use Zapier to make my life easier. Zapier lets you connect all the different tools you use and it supports thousands of them, pretty much everybody. It lets you connect those tools in ways that save you time into workflows. But now things have changed with Zapier in a way that's very exciting. I've been using Zapier for years for all sorts of stuff, home automation. I use it for work. Every time I bookmark a story, it's automatically tooted, sent to my Mastodon instance, but it's also sent, formatted and sent to a Google spreadsheet as a line on the spreadsheet which the producers then use to create the show notes. I mean, it's really a very useful tool. But now Zapier has added a new feature that makes me even more excited. We're always talking about AI on the show. I mean, everybody has been talking about AI for the last few months. But talking about trends doesn't help you be more efficient at work. For that you need to the right tools, you need Zapier. Zapier is how you break the hype cycle and put AI to work across your company. What is Zapier? Well, Zapier is how you actually deliver on your AI strategy, not just talk about it. Think of Zapier as an AI orchestration platform where you can bring the power of AI to any workflow so you can do more of what matters, you know, have Zapier run Wireshark, get the Wireshark information, process it through Claude, have Claude and you can have all the scripting for Claude, you know, what, what the prompt is and everything, interpret it and generate a, an easy to use report so that you can figure out what's what your devices are talking to. You could have the report be a spreadsheet with the device name, the URL that it's contacting, a sample of the packets it's sending, that kind of thing. Very easy to do. With Zapier, it lets you bring AI to any workflow so you can do more of what matters. I could have it with my bookmark workflow automatically do a summary of all the stories I've bookmarked for a show so I can have a briefing book.

Steve Gibson (50:19)

It's.

Leo Laporte (50:20)

Well, the uses are endless. Connect top AI models, all of the big ones, ChatGPT, Claude, whatever to the tools your team already uses. And this is the key you probably, if you use Zapier, I'm sure you have many workflows where they call them zaps that you use all the time. I know I do. I have a whole library of them. Well, now I can. I'm going to go back through them and look and see where I could add AI. Just plug it in wherever I need it. Whether that's an AI powered workflow or an autonomous agent, a customer chatbot, or just using AI to interpret the data that's flowing through the Zapier workflow. I mean, the sky's the limit. If you could think of it, you can orchestrate it with Zapier. And by the way, you don't have to be a coder. This is. This. Zapier is for everyone. You don't have to be a tech expert. Teams have already automated over 300 million AI tasks using Zapier. Join the millions of businesses transforming how they work with Zapier and AI. Get started for free, visit zapier.com security now that's Z-A P I E R.com/security now. It's funny, Quippy in our chat room has just posted in the discord. This is a really cool technology. It is. I mean, one of the problems with AI is, you know, okay, I'm sitting at the prompt now what do I do? You know, Zapier makes it easy. You don't have to think about that. You say, here's the data, here's what I need. Produce it, it's easy. Zapier.com/security. Now try it for free. I think you'll like it. I gotta warn you, you'll be hooked on we go. Let's talk about scattered spiders. But don't be scared, there's no insects involved here, so just some evil people.

Steve Gibson (52:14)

Three. Well, it's sad. Three days ago.

Leo Laporte (52:17)

Yeah. We were all hackers as teenagers, right? I know you were.

Steve Gibson (52:20)

I've. I've said many times, if I were in high school today. Oh, well, I mean, I have a strong sense of ethics, so.

Leo Laporte (52:28)

Yeah. You wouldn't be ransomwaring companies or anything?

Steve Gibson (52:31)

No, I. I had a. As I mentioned once before, maybe at least once I had a master key to the district. The entire school district opened any door in the high school and any high school.

Leo Laporte (52:45)

Oh my God. But you didn't use it for evil.

Steve Gibson (52:48)

No. What? And, and the principal who had me in his office finally said, you know, you kids, because there was a small group of us would be in real trouble. Except we know when the janitor lost his master key ring and we. So we know how long you've had these keys. No one has reported any theft or problem at all. And we said, yeah, you know, we just thought it was cool to have.

Leo Laporte (53:22)

You know, if, if it had been my, my principal, he would have said, see, I've always said you were an underachiever, Laporte. No ambition at all. Never use that key once.

Steve Gibson (53:34)

So, okay. Three days ago, the BBC carried some news about the arrest of a pair of teens who were members of the Scattered Spider hacking collective, which, you know, we've been talking about so much recently since. It's not worth losing sight of the fact that. Or I should say it's worth not losing sight of the fact that hackers are being caught and held responsible. You know, I don't say that often enough. I see the stories go by. These are those people, you know, they, they got nabbed and everything. But it doesn't often make the podcast. So I thought, let's, let's just pause here for a second to make sure people understand that these kids, hackers are not getting away with this, like forever. Although it is weird what time delay there is. I'll explain this. So, the BBC reported on this incident three days ago. They wrote, two teenagers having appeared in court facing computer hacking charges in connection with last year's. Last year's cyber attack on Transport for London TfL. The 18 and 19 year olds were charged with conspiring to commit unauthorized acts under Computer Misuse act, rather broad. They appeared at a hearing at Southwark Crown Court on Friday and spoke only to confirm their names. Judge Tony Bomgartner scheduled a further hearing for 21st November with a trial date set for June 8th of 2026. The cyber attack caused three months of disruption to Transport for London last year and affected Live Tube information, online journey history and payments on the Oyster app. Don't know what any of that is, but I guess if you're in in London, you do. The teenagers were recently arrested by the National Crime Agency. So recently arrested, meaning a lot of time went by during which they thought they'd gotten away with this. Recently arrested by the National Crime Agency and City of London police on 16 September. So, you know, a few weeks ago, and were charged two days later. The NCA said it believed that the hack, which began on August 31 last year, was carried out by members of cyber criminal group Scattered Spider. TFL said the hack cost it £39 million in damage and disruption. Following the hack, TFL wrote to around 5,000 customers to say there may have been unauthorized access to their personal information, such as bank account numbers, emails and home addresses. So again, 18 and 19 years old and now they'll have an adult computer criminal crime record for the rest of their lives. They presumably have some software skills and enjoy computing technology. But in, you know, an environment where software skills are not scarce, who in their right mind would hire either of them to do anything that was computer related, you know, flip burgers, fine, but stay away from our point of sale terminals because you guys are computer criminals and they always will be. So boy, you know, sad that, that, that, you know, they messed up by, by doing that. Last Thursday, the day before the European Union found that Facebook, Instagram and Tick Tock apps were and are in violation of terms of the EU's DSA, which is the Digital Services Act. The act has some teeth in it for this breach since Meta and Tick Tock could be fined an attention grabbing 6% up to 6% of their total global revenue, which is some cash and that'll get their attention. The EU's press release explained what's going on, they wrote Today, the European Commission preliminarily found both Tick Tock and Meta in breach of their obligation to grant researchers adequate access to public data under the Digital Services Act. Again, the dsa. The Commission also preliminarily found Meta for both Instagram and Facebook in breach of its obligations to provide users, their users simple mechanisms to notify of illegal content, as well as to allow them to effectively challenge content moderation decisions. Right. There should be an easy way to do that as a user of the platform, both to notify Meta and and to challenge a decision that Meta has made. The Commission's preliminary findings show that Facebook, Instagram and TikTok may have put in place burdensome procedures and tools for researchers to request access to public data. Right. We wouldn't want that because researchers might, you know, get up to some research. This often leaves them with partial or the researchers with partial or unreliable data impacting their ability to conduct research such as whether users, including minors, are exposed to illegal or harmful content. Allowing researchers access to platforms data is an essential transparency obligation under the DSA as it provides public scrutiny into the potential impact of platforms on our physical and mental health. When it comes to Meta, neither Facebook nor Instagram appear to provide a this is still the U the European Commission speaking neither Facebook nor Instagram. This is the eu the European Commission's opinion on this after lots of research into this appear to provide a user friendly and easily accessible notice and action mechanism for users to flag illegal content such as child sexual abuse material and terrorism content. The mechanisms that Meta currently applies seems to impose several unnecessary steps and additional demands on users. In addition, both Facebook and Instagram appear to use so called dark patterns or deceptive interface designs when it comes to the notice and action mechanisms. And of course, anybody who was trying to resist the Upgrade from Windows 7 to Windows 10 a few years ago knows all about dark patterns. Would you like to update now or later, as opposed to never? Such practices, they wrote, can be confusing and dissuading. Meta's mechanisms to flag and remove illegal content may therefore be ineffective under the dsa. Notice and action mechanisms are key to allowing EU users and trusted flaggers to inform online platforms that certain content does not comply with EU or national laws. Online platforms do not benefit from the DSA's liability exemption in cases where they have not acted expeditiously after being made aware of the presence of illegal content on their services. Okay, so on one hand, you can kind of see where the platform would like to put up some resistance, a little bit of back pressure, like, you know, the same way insurance companies do of denying your first claim. And then you've got to fight them a little bit and then they go, okay, fine, well, yeah, we'll, we'll honor that because, you know, that that reduces the, the, the, the influx and the flood at the same time. If they don't, if they could be shown not to be responding in a timely fashion, that opens them to action under the DSA and they lose their liability protection. So they're walking, you know, a thin line here. The EU wrote. The DSA also gives users in the EU the right to challenge content moderation decisions when platforms remove their content or suspend their accounts. At this stage, the decision appeal mechanisms of both Facebook and Instagram do not appear to allow users to provide explanations or supporting evidence to substantiate their appeals. This makes it difficult for users in the EU to further explain why they disagree with Meta's content decision, you know, arguing for its restoration, limiting the effectiveness of the appeals mechanism. Essentially, Facebook and Instagram don't want to, you know, spin up a big mechanism for doing what the DSA requires it requires them to do. It's not going to be easy to do this. They'd rather just kind of push back a lot, the Commission writes. The Commission's views related to Meta's reporting tool, Dark Patterns and complaint mechanism are based on an in depth investigation. These are preliminary findings which do not prejudge the outcome of the investigation. Facebook, Instagram and TikTok now have the possibility to examine the documents in the Commission's investigation files and reply in writing to the Commission's preliminary findings. The platforms can take measures to remedy the breaches. In parallel, the European Board for Digital Services will be consulted. If the Commission's views are ultimately confirmed, the Commission may issue a non compliance decision, which can trigger a fine of up to 6% of the total worldwide annual revenue of the provider. The Commission can also impose periodic penalty payments to compel a platform to comply. New possibilities for researchers will open up on October 29, tomorrow of 2025 as the delegated Action on Data Access comes into force. That's the next part of the dsa. This act will grant access to non public data from very large online platforms and search engines, aiming to enhance their accountability and identify potential risks arising from their activities. Okay, so my takeaway from this is that, details aside, what all of this amounts to is more evidence of a significant changing tide for the entire online tech industry. The next 10 years are not going to look like the last 10 years. Up to this point, the online world has been, and anything goes free for all. This state of affairs has existed since the world began to discover an alternative to using their telephone modems to dial into aol. It's called the Internet. In retrospect, it has taken a surprisingly long time, right? I mean, we've had decades of this for the political class to recognize that it's able to create and then enforce regulations on the behavior of these global online behemoths. And it's probably the fault of the tech companies who have for so long thumbed their noses at polite governmental requests for online app behavioral changes. We've been covering that throughout the life of this podcast. The legislatures finally grew tired of asking for voluntary changes and decided to enact some laws with teeth. I expect we're going to be seeing the government compliance departments of these large companies becoming much larger. And there's going to be a need for a culture change, a change in thinking about what we get to do with tech companies online. Somewhere along the road to success and world domination, when an app's reach becomes sufficiently influential, that service begins to more closely resemble a public utility and its influential behavior is going to be regulated. Now, every week we cover various aspects of this struggle because they're in the news, they're what's happening, and they are determining the shape of our future. Until now, Big Tech has had total freedom to do as it pleases in a lawless and unregulated playground. I think it should be clear to everyone by now that this status quo is changing Leo.

Leo Laporte (66:54)

Yeah, I agree. It's interesting. The only issue is whether the government is acting, who the government is acting in the on behalf of. So if they're acting on behalf of us to protect us, great, I'm all for it. If they're acting as I think often the EU is on behalf of European companies, you know, a lot of the people think that the EU protectionism. Right, yeah. That the EU's attack on Apple is at the behest of Spotify. Well, it is Spotify complain. And so, you know, so, and of course, if they're, if they're acting against these companies for political reasons, that's a third reason that maybe isn't so good either. So as long as you're acting on our behalf, that's fine.

Steve Gibson (67:41)

Another example is what we saw and we covered this. When Google was trying to get Europe to agree to its anti tracking technology, which was really good. It was European advertisers who said, we don't like this.

Leo Laporte (67:58)

That's come up again. By the way, the EU is now complaining about Apple's ad track, what do they call it? App tracking. You know, that switch that pops up where you said you want to allow this app to track you across the.

Steve Gibson (68:11)

Right.

Leo Laporte (68:12)

And the EU is complaining about. Apple's actually thinking of disabling it for EU customers. But it's a good thing for customers, right?

Steve Gibson (68:20)

Yes, it notifies you.

Leo Laporte (68:22)

Yeah. So that's an example. I'm sure that that's advertisers have complained and so it's protection because people, yes.

Steve Gibson (68:29)

People are saying, no, I don't want to be tracked. I didn't realize I was, but now that you ask me, thank you, no, I don't want no.

Leo Laporte (68:36)

Right. Like 90% of people who see that say, no, don't track me.

Steve Gibson (68:41)

So I understand exactly what you mean, Leo, about who is to benefit, but it also doesn't matter, right? I mean if it's EU law and our big tech has to operate within the laws of the prevailing jurisdiction, then this is going to happen. And I, I, again, I, I, I think that, you know, we had, we've had this like wild west attitude where you know, where really disruptive technologies have just come barreling in and no one said anything. It's interesting that like suddenly I don't know what it is in the air, but this year in 2025, it's like, okay, the governments everywhere are saying, we've had enough of this. We're gonna, we're gonna put some laws down here. And I mean, and it's no one's saying it's not creating a mess. We keep talking about it like the age verification disaster. You know, it's a mess. But they finally said, okay, you know, we're gonna have age verification. You got. You geeks figure out how to do that. Yep, not our problem. Speaking of geeks, if all of that wasn't enough to put a chill in your step, how about the news that starting this December, a month and a half, Microsoft Teams will be adding WI Fi tracking that can be forced upon its users, I.e. the users of teams clients. I first saw a little blurb about this, which read Microsoft Teams to get WI Fi tracking feature. It said a new Microsoft Teams feature will let organizations track employees based on nearby WI Fi networks. The feature is designed to let employers know what building an employee is working from based on nearby networks. According to privacy experts, the new feature will allow companies to track to crack down on workers who dodge their return to office mandates. The new WI Fi tracking is expected to roll out in December for the team's Mac and Windows desktop clients. So that's all the little blurb said. That made me curious, so I tracked down Microsoft 365 roadmaps. Notice Microsoft's title for this is quote Microsoft Teams colon Automatically update your work location via your organization's WI Fi. Well, that sounds nice, right? Innocuous enough. Who would want to have that turned on? Microsoft short summary of that reads, when users connect to their organization's WI Fi teams will soon be able to automatically update their work location to reflect the building they're working from. This feature will be off by default. Tenant admins will decide whether to enable it and require end users to opt in. In other words, by policy it can be forced on. So it's not clear from that from that wording, what happens if you were to connect from your local Starbucks WI Fi, but it at least suggests that corporate would know you were not on campus. I imagine we'll hear from some of our teams using listeners once this starts rolling out at the end of the year, I'll be interested to find out, you know, like what sort of granularity this provides if you're logging in from Starbucks. Does it just say off campus or we don't know or maybe it'll say, oh, you're at Starbucks. One bit of news stood out for me amid a long article about the current global ransomware threat landscape. The quote from the deeply researched article, and we're going to talk about that a little bit more in a minute. Read 95% of survey respondents are confident in their ability to recover from a ransomware attack. Okay, right, 95%.

Leo Laporte (73:03)

Almost everybody.

Steve Gibson (73:04)

We're good. We're good. Bring it on, baby. We can recover.

Leo Laporte (73:08)

We're ready.

Steve Gibson (73:08)

Out. Only 15% of those confident. 95 were actually able their data.

Leo Laporte (73:18)

Yeah, so. So only. Okay, this explains a lot, Steve, because I keep wondering, why are people suffering? You know, why did Jaguar. Why were they down for a month?

Steve Gibson (73:31)

Yes. And all their suppliers went bankrupt. And yeah, the UK's economy like 2 billion.

Leo Laporte (73:40)

So that's because now I understand the executives, the IT guys, the security guys at Jaguar were confident we could. Confident we are not gonna have a. We could recover from anything. And they couldn't.

Steve Gibson (73:56)

They pushed the backup button and it went.

Leo Laporte (74:02)

We have a sponsor for that, but we'll save that for a little later.

Steve Gibson (74:05)

Well, Coveware is the leading ransomware negotiation company, so these guys are right in the thick of things. A bit of surprising and welcome news which drew me to their end of third quarter 2025 report which they published last Friday, was that for the first time ever, ransomware payment rates had seen a drop below 25%. Below 25, they are down to 23%, meaning fewer than one in four are now paying ransom. I put the chart for this in the show notes at the top of page 10 here because it's a beautiful looking chart.

Leo Laporte (74:57)

It's dropping. That's interesting.

Steve Gibson (74:59)

Yes, yes. It shows the percentage of ransoms paid across the past six years. From the start of 2019 through this just ended third quarter of 2025. Ransom payout rates started at 85% when this chart, when Coveware began charting this six years ago, 85% of ransoms were being paid. So they were nearly a sure thing. As the chart shows, the probability of a ransom being paid has been dropping more or less steadily ever since. Until today, the chance of being paid a ransom has fallen to less than 1 in 4. As I said, you know, we're always looking at companies being attacked and commenting that enough is not being done. But this chart suggests that in fact a great deal has changed over the past six years. Partly this might be more companies just saying no and refusing. So that's part of the non payment reason. But it also likely means that more companies are able to say no and refuse to pay because their IT departments have assured them that they'll be able to recover without paying for the criminal's help. And hopefully those are not part of those 85% that turn out not to be able to restore from backup, because only 15 apparently can. But as I said, that interesting tidbit was what first drew me to this report. Cove Wares perspective on attacks is very interesting, illuminating, and insightful. And they're the people who know because they're involved. They're like the tip of the spear in negotiating. And, Leo, after our next break, we're going to look at a very interesting report from Coveware.

Leo Laporte (77:14)

Okay. I do think, though, that cover might have a little bit of a vested interest in this statistic. Like, see, we can help you not pay their ransomware because we'll negotiate with the bad guys, right? Could be.

Steve Gibson (77:29)

Although. Although, what I'm focusing on is the. The information they have about attacks, which.

Leo Laporte (77:34)

Is really good, that would be of.

Steve Gibson (77:36)

Great value, like how the bad guys get in.

Leo Laporte (77:39)

Is it only their customers, I wonder? Must be, because how else would they know, right? Yeah. All right, we'll talk about how bad guys get in. You know, people are banging at the door to sponsor this show because they know that if you're listening, you're scared. If your job is to protect your company, all this show does is make you think, oh, God, oh, no, I better do something about this. Right? And our sponsors say, well, we stand ready to help you. And I'll tell you about one of them right now. 1Password. I know you know the name 1Password. They are, if not the most. I think they are the most popular password program in the world there is. If not the most, there's certainly the top two or three. But they do more than just protect your credentials. Let me. Let me talk about another issue that you're facing. If you're an IT professional, over half of IT pros say that their biggest challenge is securing SaaS apps. I think if you think about it, that makes sense because every single one of your employees has a browser. Every single one of your employees is connected to the Internet. Right. Every single one of your employees probably has tried a thing or two. You know, with a SaaS app, maybe an unapproved SaaS app, a shadow it kind of a thing. You know, with a growing problem of SaaS sprawl and shadow it, it's not hard to see why this is an issue for IT departments. Thankfully, there is a solution. 1Password Extended Access Management, EAP and Trelica, which is 1Password's solution to help you discover and secure access to all your apps, whether they are managed or not. Trelica T R E L I c a by 1Password inventories. Every app and use in your company. Every app, even apps you don't know about every app. The pre populated app profiles and they have them for everything by the way. Assess the SaaS risks let you manage access. You can decide to turn it on or off, optimize spend, you got a spending limit for instance. And enforce security best practices across every app your employees use. Trelica knows for instance. Oh, that's a setting you never should enable on that app, things like that. And it will help you make sure that those, you know, approved apps are being used and unapproved apps aren't. And you totally control it. You can manage. Shadow also helps you in other ways like you can use it to securely onboard and off board employees. And it helps you meet compliance goals because you have a record of everything. Trelica by 1Password provides a complete solution for SaaS access governance. It's just one of the ways that extended Access management from 1Password helps teams strengthen compliance and security. Of course, 1Password's award winning password manager is trusted by millions of users. Over 150,000 businesses. IBM to Slack. Everybody uses 1Password now they're securing more than just passwords with 1Password. Extended Access Management. And of course 1Password is secure. ISO 27001 certified with regular third party audits and the industry's largest bug bounty. 1Password exceeds the standards set by various authorities and is a leader in security. So take the first step to better security for your team by securing credentials and protecting every application, even unmanaged. Shadow it. Learn more@1Password.com SecurityNow that's 1Password.com SecurityNow all lowercase. Thank you 1Password for supporting Steve Gibson and security now. Actually, if you think about it, Steve, when we started, you downloaded an app, you put it on your hard drive, you ran it locally, you ran it on prem. Nowadays almost everything is run in the cloud, right? It's a SaaS app. And so that's a whole different process of protecting. You need something a little bit more sophisticated anyway.

Steve Gibson (81:56)

Yeah, I mean, let's hear how. Yeah, authentication has become everything.

Leo Laporte (82:01)

Job one. Let's talk about how hackers get into your system. I'm fast.

Steve Gibson (82:05)

Okay, so there I want to. I'm going to share two pieces of a very long report and I've got the link to the entire report in the show notes only because it is so full of really juicy tidbits. So here's how the report begins. They wrote, as we enter the final quarter of 2025, the cyber extortion landscape has split along two clear paths. Volume driven ransomware as a service campaigns Targeting the mid market and high cost targeted intrusions aimed at larger enterprises. Okay, so that's part of. I mean this report has so much really interesting stuff in it. In the volume category, mid market companies remain the most impacted by traditional ransomware as a service. RAAS groups, the Akira RAS group leveraged a vulnerability that resulted in record breaking attack volumes between July and August. This quantity over quality approach is low cost for the attackers, generally results in lower demands, but achieves a ransom payment rate that is higher than average. Akira maintains substantial RAS infrastructure supporting a broad spectrum of attacks against enterprises. This is in line with their long standing methodology that seeks to maximize the total number of attacks regardless of victim size and profile. This model gives Akira a sustained market share advantage over groups that prioritize selective high profile targets. Other actors get caught up with Shiny Object syndrome, an attempt to tailor attacks only to enterprises above a certain size or perceived financial capacity. That latter strategy is substantially more expensive for attackers, resulting in lower than average ransom payment rates despite higher ransom demands. While mid market companies have historically been the most impacted cohort of victims, larger enterprises periodically drift into focus when extortion campaigns materialize that leverage to exploit widely used software or hardware. Examples of this are Clops, campaigns against various file transfer appliances and scattered Spiders, campaigns that exfiltrate data from common SaaS applications. In Q3, we see ransomware groups that have previously limited their efforts to smaller companies expanding into enterprise environments with targeted higher cost methods. So as I said, this report is just so full of fascinating insights. Much later they address the initial access vectors question about what they have discovered about the way attackers get in. They write initial Access activity in Q3 reflected the continued evolution of attacker behavior more than any dramatic shift in tactics. The same foundational pillars, remote access, compromise, phishing, social engineering and software vulnerability exploitation, those are the three, right? Remote access phishing, social engineering software vulnerabilities remain at the core of intrusion activity, but the distinctions between them are increasingly blurred. The modern intrusion no longer begins with a simple phishing email or an unpatched vpn. It starts with a convergence of identity, trust and access across both people and platforms. Remote access compromise remained the dominant vector, accounting for more than half of all observed incidents. Credential based intrusions through VPNs, cloud gateways and SaaS integrations. That was of course was the whole salesforce mess continued to drive compromise, particularly in organizations navigating infrastructure migrations or complex authentication models. Right? You just get tripped up over, you know, this whole system of gluing external services together and then having to pass credentials and authentications back and forth across networks. Mistakes happen, they wrote. Even where technical patching was current, attackers found success exploiting lingering configuration debt such as old local accounts, unrotated credentials, or insufficiently monitored OAuth tokens. Exactly what we were just talking about. Q3 also underscored how remote access and social engineering have effectively merged. Adversaries increasingly attain access not just by logging into a system, but by convincing someone else to provision it for them. Campaigns that blurred these lines, such as those impersonating SAS support teams or abusing Help Desk processes to gain OAuth authorization. Again, the whole scattered spider phishing mess demonstrated, you know, with with Cloudflare, demonstrated how human trust can be engineered and into a technical foothold. This hybrid technique redefines remote access as much psychological as technical software Vulnerability exploitation rose modestly, but remains a critical access path for opportunistic campaigns. The most exploited vulnerabilities this quarter were not cutting edge zero days, but well known vulnerabilities in network appliances and enterprise apps where patching lagged or migration hygiene fell short. Even fully patched environments were compromised when legacy credentials or partial configurations reopened an old door. The lesson remains consistent. Technical remediation without procedural rigor still leaves gaps wide enough for for exploitation. Wow, this is so well written. Anyway, all of that, all of what Coveware reported exactly tracks with what we've been seeing and covering as we as they wrote, the most exploited vulnerabilities this quarter were not cutting edge zero days, but well known vulnerabilities in network applications and enterprise apps were patching lagged or migration hygiene fell short. Remember there was an instance, can't remember which. I think it was Cisco where where the people who are.

Leo Laporte (89:30)

It's always Cisco by the way. I know.

Steve Gibson (89:34)

It's a safe bet the people upgrading failed to notice Cisco saying be sure to rotate your credentials when you do this. And they didn't. And so whoops, that caused a problem. So in other words, these are preventable intrusions whose causes could be traced to devices that have been neglected and left unpatched. This. Anyway, the report is so fascinating as I've said that, you know, I was tempted to share more about it, but we've got other things we need to get to so I put a link to it here at the bottom of page 11 in the show notes and anybody who's interested in this topic and wants more, or maybe you know, send the link on to your IT people or your SE suite people to get their attention because you know the this Coveware group, they've got a great, you know, microscope into the way this is all happening.

Leo Laporte (90:28)

You. You could spend a whole show talking about these. I mean, it's just endless. Yeah.

Steve Gibson (90:33)

Yeah. Garrett Smith said.

Leo Laporte (90:36)

Hello.

Steve Gibson (90:37)

Stephen, Leo, hello. I just wanted to say hello. I wanted to say I started watching and listening to the show and I absolutely love it. I've been working as an information security analyst for just over a year, and I wish I had found this sooner. I was only a young buck when the show started. He said, friends, a toddler.

Leo Laporte (91:04)

So pretty much most of our audience, probably, I.

Steve Gibson (91:08)

He said, I really feel like going back and listening to the rest of them. There are probably so many important things that I have missed. I guarantee it. Gareth, it. But he says if life ever slows down, which. Okay, that's not going to happen. He said. Looking forward to tuning in every week for as long as it keeps rolling. Glad to have found a great resource finally. Thanks again, Gareth. Okay, so first of all, thank you for taking the time to send your note. If you've only been listening for a while, please do allow me to encourage you to go back. I know the 20 years of material can be quite daunting, but back in the earlier days of the podcast, it was a lot shorter. Also, there were a couple of series that we created. One series of episodes carefully explained pretty much all of how the Internet itself works, and it became a classic run of episodes, and another series focused on the operation of CPUs. It turns out nothing has changed since then. Even though those are, you know, legacy episodes, they're still as relevant today as they were back then. And I don't have at the tip of my tongue the episode numbers, but I know that our listeners are going to be sending me email during this intervening week, so I will have those episodes to report next week. And I also should note, Gareth, that since you're young and we're old, there will be an end to this podcast eventually. I don't know why or how it will happen, but it will. But it will come. That's when. That's when you'll be able to go back and suck up all the old ones and start listening to them, because you're not going to have any new ones.

Leo Laporte (93:07)

So that's what I said when I was watching last night's World Series game between the Dodgers and the Blue and the Jays. Someday there will be an end to this game. I know you're not a baseball fan, but you might be interested to know it went 818 innings, twice the normal number. And it didn't finish till after midnight. California time, after 3:00am East coast time. That's a lot. Yes, that's a lot. Wow. I. I couldn't make it. I tried.

Steve Gibson (93:33)

And was it exciting?

Leo Laporte (93:35)

Yeah. I mean, if you like baseball, baseball's not inherently that exciting.

Steve Gibson (93:39)

I've been told that, like. Yeah, you have a lot of time to walk around and get a lot.

Leo Laporte (93:44)

Of time to have hot dogs. Yeah. Yeah. It's mostly about sitting in the sun, eating beer and drinking hot dogs. Or the other way around.

Steve Gibson (93:53)

Kevin Van Haron said, hey, Steve, I'm talking about the change. I'm sorry, in talking about the change in NIST's password policy in episode 1048, you mentioned there is no reason to change your password unless there's been a breach. I do think there's a scenario where changing your password very occasionally does have a benefit. The classic example would be LastPass. LastPass updated their encryption system, but it wasn't used for users with existing passwords until a user changed their password. Someone changing their password every three to five years would have avoided any issues. Obviously, LastPass's problems were their own fault, not users. But I see changing my password Manager Password Every 5 years to be a bit of belt and suspenders. I think one reason people avoid this is because when you say new password, you mean completely new password. My policy for changing passwords when there's not been a breach is to use my existing password but add a 1 to 3 random characters to the end. This has the added benefit of slowly making your password longer as well. Finally, you talked about companies having a policy of not being able to reuse your last five passwords and people just changing their password five times to get back to the original. The policy at my company is you cannot use your last 10 passwords. Plus once you change your password, you can't change it again for 48 hours. With that, it would take 20 days to get back to your original password, which you probably forgot by then anyway. Signed Kevin Van Haren. So, okay, Kevin has a point about LastPass and that you know, that particular password manager not updating its password protection features. Remember the. The number of times that is that the password is hashed before it's. It's used to generate the key? You know, that seems like a special case to me. Kevin's note about appending one to three additional random characters to the end, causing his password to grow over time. Okay, that's interesting. Presumably, and this is what he said. This is for something like the master password which you know yourself, which is then used to unlock all other passwords. Since those all other passwords would likely and hopefully be totally random gibberish. Doesn't make any sense to add any characters to them. So I'm sure that by now most of us have absolutely no idea what any of our individual passwords are. I certainly don't. They're just all gibberish, you know. But I need to unlock Windows and my various Apple devices using a password that I do know. So for what it's worth, those are very few and far between Jane said Greetings Steve. In the episode it was mentioned that the F Droid app itself would first need to be obtained from the Google Play Store, unquote. However, as someone who uses a phone with no Google services and gets most apps from F Droid, I'd like to correct this. F Droid was never available in Google Play Store. Rather you download it from their website more so I don't think Google would even allow it in their store given some of the apps they carry, such as third party third party YouTube clients which are leagues ahead of the official one I might add. So I don't think quote so tech and here she's quoting me. So technically it's an application which accesses a repository. It's not a store. Unquote is quite right given that F Droid is both the app which you can use with multiple third party repositories like Izzy on Droid and the main repository which you don't have to use the official app to access. And she said see droidify. She said. However, this makes one think of another method of downloading apps which indeed isn't a store at all. Which is which is obtainium. You can point it to a variety of sources like git repos or again F Droid would even individual self hosted git servers have to comply with the same rules? She said. Can't wait for Leo to try graphene os exclamation point. I've been its user for more than a year now and could not be happier de Googled mobile oss are more relevant than ever. They need more public publicity from more sources.

Leo Laporte (98:55)

I agree, I agree. I have my Pixel 9 right here ready to go so I think I'll just yeah, maybe I'll do it on a special club special so you can watch me.

Steve Gibson (99:07)

So Jane, I appreciate the corrections and clarifications. Having myself zero experience with F droid I should have been more careful with my pontificating. I'm glad everyone heard what you were able to clarify and add. Many years ago, when I was experimenting with the discontinued Zeo Sleep tracking headband, I needed to side load the Zio app for Android since it had long since been retired from the Play Store. Doing that was simply a matter of copying the file to the proper place within the Android file system. So it sounds as though F Droid is similarly installed. Just a simple side loading this does bring up the question of the legal status of F Droid and the open source programs it catalogs. If Texas SB2420 should survive to take effect on January 1st, you know, against the against the suits which have been filed, you know, since it seems clear that F Droid and its apps would not be compliant. So, you know, if F Droid is worried about that, they've got till the beginning of the year to figure out what they want to do. Doesn't sound like they're going to be willing to require people to assert their age. So again, all of this legislation is creating a huge message. So Jane, thanks again, CJ said. Steve, as a longtime Security now listener, Club Twit member and Spinrite owner, I'm deeply immersed in the Twit ecosphere. Having gained valuable insights from you. I believe this email explanation will only serve as a reminder of the importance of certain security strategies, including why there's actually a case to be made for changing passwords with some frequency. So CJ says the primary objective of changing passwords regularly is to mitigate the risk of unauthorized access to your accounts by someone who's gotten your password without your knowledge before they have a chance to try it. It's a timing game. The clock starts as soon as they have your password and someone gets around to using it, remembering that there is a lag from exfiltration to discovery of the treasure, then probably being posted for sale on the dark web to the point when someone will actually try it. It may be a month or more. If you have routinely changed it in that time, you may dodge that bullet. Risk Reduction Given the inherent difficulty entrusting third parties to safeguard our secrets, it's crucial to recognize that relying on them to promptly inform us of potential breaches can be a fool's folly. Examples that come to mind are the notorious notification delays experienced by Yahoo and LastPass, underscoring the futility of relying on companies for timely breach notifications. Certainly no argument there. Underscoring the risk. A few moments after you reported the announcement of the NIST Don't Change policy, you talked about another method where our passwords are being compromised without any warning. They may be transmitted via satellite, making them vulnerable to worldwide reception. You're not, you're not, you're not going to receive a notice about that anytime soon. True, he said. To effectively reduce the risk of unauthorized access, I still think it's advisable to change passwords with a frequency commensurate with the sensitivity of the information being protected. For my Brownie baking blog, no change necessary, but for my millions, maybe quarterly, for my trillions monthly, and for the nuclear codes weekly, he said Given the convenience of password manage I don't know if CJ is the he or she, but CJ said given the convenience of password managers which allow for effortless changes in under a minute, I will continue to allow passwords change reminders from my financial institution regardless of a lack of NIST recommendations, especially since my bank has abysmal MFA options. This practice exemplifies a prudent risk mitigation strategy and a fundamental security practice. Not expecting to change your or Leo's mind, but hopefully you can acknowledge to your listeners that there's truly some merit to changing key passwords without having to wait for a notification. Knowing the risk and how to mitigate it puts the decision into the hands of information owners. Enjoy the show and looking forward to tuning my DNS with the latest and greatest tool. Respectfully, CJ. Okay, so fair enough. I wanted to share CJ's thoughts since I thought that they accurately and clearly expressed the alternate reasoning in support of periodic password change. One of the most significant changes that has occurred which has been enabled by the popularity and success of password managers is that no single password is being used today by more than one third party service. So this prevents us from from having all of our passwords in a single basket. It's true that our password manager's master password is literally all of our passwords in a single basket, but in any properly designed password manager that password is only used locally to decrypt the encrypted vault blob. The other thing I would note is that any and all of our high value accounts, you know those millions and trillions that CJ mentions should really be protected by more than any static password no matter how often it has changed. Today we have one time passwords which are inherently in constant flux and pass keys which don't even have any password that needs changing that is being given to an outside entity. So I guess my reply to CJ would be that I understand and can appreciate his or her points, but as our needs for increased security have grown and certainly they have. The use of very powerful password replacement authentication technologies have also become available. So where rapid password changing might have once been a useful strategy, and I mean, decades ago when NIST adopted those rules, today we have superior solutions where, where and when we really need extra security. Well.

Leo Laporte (106:12)

Changing the password kind of implies that it will somehow be discovered.

Steve Gibson (106:18)

Correct? Right.

Leo Laporte (106:18)

Or brute force cracked. But if you're passly, if your password is long, mine's I don't know, 30 or 40 characters y. And it's not going to be brute force, not going to be brute forced.

Steve Gibson (106:30)

No.

Leo Laporte (106:31)

And I'm not writing it down anywhere. I'm not.

Steve Gibson (106:34)

And any satellite that's broadcasting it would be broadcasting the hash, which is all the bank has to lose. Right. So I mean, it's, I, I mean, I guess, I guess I want to give, I, I want to give some deference to somebody who is insanely security conscious, who wants to like over, over change their.

Leo Laporte (106:58)

I would use the word paranoid.

Steve Gibson (107:00)

Okay.

Leo Laporte (107:04)

I'm not to look, of course it's easy with a password manager. Be my guest. Change it as often as you like. The reason it's a bad advice in a corporation is, is what we've talked about about, which is that people don't use password managers. They just add a number or, you know, they have bad passwords to begin with. And making a second bad password doesn't improve security, it's just, it's security theater is, I guess the point.

Steve Gibson (107:31)

Yeah. Also one concern about password changing is we don't know what happens with the password. You enter into their password change form, it's in the clear. It's your password that you're providing. If it's hashed on the browser, then that's a good thing.

Leo Laporte (107:52)

Right.

Steve Gibson (107:52)

But if it's sent to the other end, then it's being sent in the clear Every time you change it. Every time you change it represents an opportunity. Yes. You're increasing the number of instances of vulnerability right up from zero, essentially.

Leo Laporte (108:12)

Right.

Steve Gibson (108:12)

If you don't change it, it's never being set in the clear. So you'd have to really know what's being sent to the other end. It's going to be sent over HTTPs, so that's going to be encrypted. But if the concern is that it's going to be intercepted, then you could have a manual attack.

Leo Laporte (108:29)

Yeah.

Steve Gibson (108:30)

Yes. And we know that today's topic is DNS cache poisoning. The reason you poison a cache is to divert users to some other server. So I'm happy leaving my passwords as they are crazy long total gibberish cannot be brute forced and never going over any wires in the clear.

Leo Laporte (108:55)

And if you're worried, go to have I been pwned every once in a while and use their password checker and. And see if your password's been discovered somehow. Magically. Yeah, that if you, if you need something to do. I don't know. I don't mean to dismiss it, cj. Of course. Change it as often as you feel like it.

Steve Gibson (109:18)

Okay, we're past an hour and 30, time for a break and then we're going to continue with some feedback from our listeners. Before we get to our main topic.

Leo Laporte (109:25)

95% of of security professionals believe that they can recover from a ransomware attack. But in fact, when the attack happens, only 15% of those actually could. The rest, the rest of you. The 15% should be listening. This is what probably the fifth. That's right, the 15% are probably using our sponsor, Veeam V E E A M. When your data goes dark, Veeam turns the light back on. It's the. The term is data resilience. Veeam keeps enterprise businesses running when digital disruptions like ransomware strike. How. How can they possibly do that? You say? Well, by giving businesses powerful data recovery options that ensure you have the right tool for any scenario. I'd say in addition to powerful, reliable, something you can trust, they give you broad, flexible workload coverage from clouds to containers and everything in between. And that's important too, because nobody's just living on prem or in the cloud. Our stuff is everywhere, isn't it? Veeam also gives you full visibility into the security readiness of every part of your data ecosystem. So if somebody asks you, are you ready? You can say with confidence, yes, I am. Veeam tested, documented and provable recovery plans that can be deployed with the click of a button. That's why veeam is the number one global market leader in data resilience. In fact, just call them the global leader in helping you stay calm under pressure. With Veeam, it's all good. Keep your business running@veeam.com that's v e e a m.com I I am really happy to be able to tell people about this sponsor because if you're in that 15% who you know, hey, yeah, we got it back, you don't have to worry. You're probably using VM. But if you're in the 85% who thought you were covered and you weren't VM.com that's all. That's all I can say. It's a. It's a solvable problem. There's no reason to suffer. All right, back to the show.

Steve Gibson (111:45)

Steve, they just bought somebody.

Leo Laporte (111:48)

Somebody just bought them. Yeah, there's a. Yeah, there's I. I remember reading a story about Veeam.

Steve Gibson (111:53)

Well, I think maybe they got purchased, but they also purchased somebody in today's podcast. I mean, like, oh, you're kidding. Here. No. So maybe they bought.

Leo Laporte (112:04)

Oh, they did. They bought Security with an eye. Yes, they did. You're right. I'm sorry. Nobody bought them. Veeam acquire or has assigned an agreement to acquire security AI a data privacy management innovator 1.6 there's somebody else.

Steve Gibson (112:19)

I don't know.

Leo Laporte (112:20)

There's somebody else.

Steve Gibson (112:21)

I don't think it was Coveware, but it was one of the something that we. I was talking about. I saw that they had just been acquired by Veeam. I thought, oh, they're a sponsor.

Leo Laporte (112:29)

Yeah.

Steve Gibson (112:30)

Anyway, Nathan Ramsey said hi, Steve. Today Java voluntarily asked me if I wanted to remove it because I had not used it in six months.

Leo Laporte (112:42)

Yeah.

Steve Gibson (112:44)

I love that, he said. I was so confused, then impressed. Yeah, he said, my my hat goes off to you, Java. What software in its right mind would volunteer to remove itself? To keep my PC's attack surface a little smaller, the model is usually more akin to let me get my hooks in so I can stay here forever and offer you more services and apps in the future. Unquote. Nathan wrote for reference, this happened when the Java update icon popped up in my system tray. He says, okay, fine, we'll call it the notification area. He says, as is normal when a new update is available. I couldn't remember why I had needed Java in the past, but I clicked Update anyway, which is when it proceeded to recommend its own removal. Google shows me comments about this from at least four years ago, so I guess this is old news, but it was new to me. I thought you and Leo would appreciate it too, if you didn't know. Longtime listener. Thanks for all you do. Yada, yada, yada slash NATO. Okay, so I recall the same thing happening for me many years ago, and I agree that this is the way all security software should work. Imagine that an IT professional logs into an enterprise device and is greeted with an intercept message which reads, you know, no one has successfully logged into this device's publicly exposed SSH server in the past six months, but 14,723,402 attempted logins have failed. If this service is not needed, perhaps it should be disabled. Would you like me to do so for you now, wouldn't that be something if we lived in a world like that? Along those lines. And Leo, this is to your point about Apple iOS asking if you'd like to, you know, this app to keep tracking you. I Apple's iOS recently notified me of some access permissions I had previously given to some app and it proactively asked me, you know, at a reasonable time whether I wished to continue granting that permission. You know, not enough of the world works this way. Security culture really needs to catch up, you know. And so Nathan, thank you for the reminder about Java. You know, they're getting it right and you know, bravo for them and it.

Leo Laporte (115:24)

By the way, you're right. Veeam owns Coveware.

Steve Gibson (115:27)

Ah, that's what it was.

Leo Laporte (115:28)

They bought them last year. Yeah, thank you to Paul for finding that cool. They bought them in April of 2024 and they coveware runs independently. But yeah, it just shows you the Veeam really is has it.

Steve Gibson (115:40)

They're on it.

Leo Laporte (115:40)

Our sponsor is on it. Yep. Yep.

Steve Gibson (115:43)

David Benedict wrote. Hi Steve, sorry, this is probably like the fifth or sixth email I've sent on this on this episode. But you know, people like pause and then write email and then they hit continue. Right. But I if I don't send the email now all caps, the the thoughts sometimes escape my skull, never to be found again. He said, you seemed very excited at the prospect of what could come forth from the IABW3C workshop coming. Probably already happened. He and and that was the one where they were going to be beginning to get serious about age verification and building the technology into Internet standards. David said, I find this a bit worrisome. If they do in fact come up with some sort of filtering methodology, who's to say that our government won't suddenly decide? LGBTQ websites all require being over 18. Or maybe all websites about Islam all require being over 18. I think this could be a slippery slope to start down. Just my two cents. Thanks. David Benedict. Okay, so David is suggesting, or at least wondering whether making privacy respecting online age determination more accessible and technically feasible might open the floodgates for politicians to more readily start age, restricting much wider swaths of behavior and Internet access. I certainly don't like the idea of that happening, but it seems to me that the pervasive and widespread pattern of behavior we're seeing from politicians here in the us, in the uk, in the eu, in Australia and elsewhere is that they're already enacting access restriction laws without any regard for how those laws will be technically implemented. I would imagine that somewhere in the bowels of their inner sanctums, you know, we techies are being derided with a wave of their hands and, and statements like, well, those techy geeks will figure out how to do it. That's not our problem. Our job is to tell them what they need to do. So I doubt that the lawmakers have much concern for how any of this would actually be accomplished. They just want to get the laws on the books so they can campaign on their success in having done so. And in the wake of those laws, it falls to us techies to figure out how to preserve as much of everyone's privacy as possible while accomplishing what the laws require. So on balance, I see no evidence so far that politicians would be much more inclined toward restrictions if it were made any easier to do. But I also see David's point in the abstract. It's certainly possible to imagine a future where the well accepted ability of any content provider to obtain its online visitors age range without compromising their identity or other aspects of privacy could facilitate the passage of additional legal restrictions. But even if this were to come to pass, the proper venue for challenging those laws is not the technology, but legal challenges using whatever governing constitution may be in effect. And it seems though it seems to, to that end, since we already have such laws about the technology happening, making them safe and privacy preserving as our top priority is what needs to happen as soon as possible. So yeah, I remain excited about the IAB and the W3C's work because that is where these standards will emerge from. And it's a little dispiriting that they're, they appear to be in the so early stages of well, what problems are we really trying to solve here? And blah blah, blah. It's like okay, just you know, please like work on weekends. A listener of ours, Charles Turner, dug out the specific requirements from the lengthy document which I summarized last week. The precise requirements are interesting and they're what we're likely to eventually see taking effect. So I just. There are only nine points. I'm going to go through them because Charles, Charles sent them to me. He's, he wrote. Steve, just a quick note to follow up on your coverage of the updated password verifiers in NIST SP 863B. The following requirements apply to passwords and they are. First, verifiers and CSPs shall require passwords that are used as a single factor authentication mechanism to be a minimum of 15 characters in length. Verifiers and CSPs may allow passwords that are only used as part of a multi factor authentication process to be shorter, but shall require them to be a minimum of eight characters in length. Okay, so 15 characters if it's a single factor, a minimum of eight if there's something else that is required for authentication. Second, verifiers should permit a maximum password length of at least 64 characters. So maximum password length of at least 64. Third, verifiers should accept all printing ASCII characters and the space character in passwords. Fourth, verifiers should accept Unicode characters in passwords. Each Unicode code point shall be counted as a single character when evaluating password length. Boy, Leo, that's going to cause some problems.

Leo Laporte (122:02)

Wow. Yeah.

Steve Gibson (122:04)

Five, verifiers shall not impose other composition rules requiring mixtures of different character types for passwords. Six, verifiers shall not require subscribers to change passwords periodically. However, verifiers shall force a change if there is evidence that the authenticator has been compromised. 7. Verifiers shall not permit the subscriber to store a hint that is accessible to an unauthenticated claimant. 5. Verifiers shall not permit prompt subscribers to use knowledge based authentication. You know, for example, what was the name of your first pet or security questions when choosing passwords? And finally, verifiers shall request the password to be provided in full, not a subset of it, and shall verify the entire submitted password, not a truncation of it.

Leo Laporte (123:14)

Good.

Steve Gibson (123:14)

So, yeah.

Leo Laporte (123:15)

Anyway, these all seem sensible.

Steve Gibson (123:17)

Yeah. Except Unicode.

Leo Laporte (123:20)

Well, I understand you have to because there's foreign language speakers.

Steve Gibson (123:25)

Yeah.

Leo Laporte (123:26)

Yeah. Unicode is a recipe for disaster. I understand what you're saying.

Steve Gibson (123:32)

Boy. Yeah. Charles finishes thing. As mentioned previously, I am a Navy retiree and currently working in the defense contracting realm. It will be interesting to see how long it takes for the NIST's updated guidance on passwords to take effect throughout the federal government. And yes, it will be. It will not be happening overnight.

Leo Laporte (123:55)

Yeah. These all seem sensible, though. They seem like they're up to date. They're correct, I think. Yeah.

Steve Gibson (124:00)

I think they are 100% workable. That's.

Leo Laporte (124:03)

I love it that they're requiring 15 characters. That's. And they.

Steve Gibson (124:06)

Yes.

Leo Laporte (124:06)

And they say you must allow a password longer than 64 because so many bank sites, you know.

Steve Gibson (124:12)

Oh, yeah. Based on weird backend technology, they're stuck at eight.

Leo Laporte (124:18)

Right. Yeah. Although I'm not crazy about if you're doing two factor. It can be as as short as eight, but I guess that makes sense. It's good.

Steve Gibson (124:28)

Yeah, it is. And thank you, Charles. David Eckard wrote. Please encourage TWiT TV to pull your NIST password segment and release it as a YouTube short. This topic is too important to not do that.

Leo Laporte (124:43)

Oh good, David. Yes, that's a great.

Steve Gibson (124:45)

I will say that it has definitely captivated a large portion of our listeners, and I agree that it would likely make a good twitch short. Fortunately, our chief Twit and company have all just heard your suggestion and the ball is now in their court.

Leo Laporte (125:02)

I am sending it off right now. They they may have already done that. I don't know. They they they pick a lot of clips and your clips are often the most viral clips and that would be a natural for virality. So I'll send that along.

Steve Gibson (125:16)

Yeah, A frequent writer of of from the show Notes named Michael Cunningham sent me a note. He said, hi Steve, in regards to episode 1048 where you talked about NIST's guidelines changing it made me think of several experiences I've had in a corporate environment that might justify having password rotation. I call it poor password hygiene, and I wanted to hear your thoughts. Not long ago, I was still doing desktop support on occasion, and I went to a user's desk to help with an issue, but she'd stepped away. I said out loud to myself, she's not here. And she locked her computer so I can't help her. At which point her nearby co workers immediately said, oh, her password is monkey123exclamation point. My thoughts were, well, at least I know within 90 days it won't be that any longer. Yeah, the reasons why they knew her password seemed to relate to them needing he has in quotes to access her PC when she's away for whatever reason. What if a user uses their corporate password on an external site and then that site gets compromised? Bad guys might try to use the same password on other accounts they can tie to the user. I've also had more than once a user just accidentally send me their password because they went to type it in but had the wrong window in focus and sent it to me instead. Another story to share is about the changing your password five times to get back to the first one. I had a user tell me he did this, so I thought, maybe there's a fix for that. And sure enough, in Active Directory you can set a minimum password age in days to try to discourage this, which I did a few weeks later the user came by and simply said to me, you're evil. And he finished. Anyways, hoping to hear if you have thoughts on this. Sincerely, Mike Cunningham, Spinrite Owner Club Twit Member Watching Leo since zdtv.

Leo Laporte (127:39)

Wow.

Steve Gibson (127:40)

Okay, so I Michael, I appreciated the your evil sentiment, which is easy to understand right from that employee. In this case, I'm unable to see what's gained by increasing the friction between it and the rest of the company's workers. I think my takeaway is that users will be users, and that there's a limited amount of corralling, cajoling and forcing that any reasonable person should or will tolerate before they rebel. No one likes being told what to do, especially when what they're being told to do is indefensible, annoying, and makes no sense. The clear consensus with the industry has finally awoken, which is to arbitrarily force people to change their passwords for no reason and without any explanation as to why is abusive harassment. Is it possible to force people to constantly change their password? Yeah, of course, technology can force that. But it's also a huge inconvenience, which, as we've seen, users will actively struggle to work around. And users are basically sane. They understand the way the world works, so they rightly see that. You know, those geeks from the dreaded IT department are forcing them to do something for no reason other than that they can. The employees are powerless and they're pissed. This is why those NIST guidelines were finally changed. Harassing users for no good reason causes users to hate security.

Leo Laporte (129:33)

Exactly.

Steve Gibson (129:34)

And that's not good. That's not good for anyone, right?

Leo Laporte (129:37)

Bingo.

Steve Gibson (129:38)

Having people upset with and annoyed by their company's IT staff is not only bad politics, it's bad for actual security, since reasonable people are turned into rogue employees who don't want to follow arbitrary seeming rules. Oh, don't click on that link. Well, I'll show them. Having an employee come by to tell you that you're evil after making their lives further difficult for no reason other than that you can doesn't feel like progress to me. Instead of being everyone's villain, how about becoming everyone's hero right now, today? Take the high road. Implement the NIST guidelines immediately. Drop all forced password changes because they serve no purpose whatsoever, enforce minimal password length and nothing else. Take credit for bringing the light and start receiving your fellow employees. Thanks for having made their lives a bit easier. Be invited to parties. Who wouldn't want that?

Leo Laporte (130:57)

That's funny.

Steve Gibson (130:58)

NIST has just given you permission to be the good guy take it.

Leo Laporte (131:03)

Well done, well done. That's very good. Put that on the, on the refrigerator at work.

Steve Gibson (131:14)

We're time for our last break, Leo, and we're going to talk about the return of DNS cash poisoning.

Leo Laporte (131:20)

Oh man. Is this a propeller hat or not?

Steve Gibson (131:24)

No.

Leo Laporte (131:25)

No.

Steve Gibson (131:26)

Okay, a little bit.

Leo Laporte (131:30)

You know what that means if Steve says a little bit? You might want to get your, your propeller hats ready. Ladies and gentlemen, this portion of security now brought to you by the world's largest cloud security platform, Numero Uno, Zscaler. Love Zscaler. As organizations leverage AI to grow their business and support workforce productivity, they're faced with a challenge because they can't rely anymore on traditional network centric security solutions that don't protect against emerging threats and AI attacks. The AI, it's a double edged sword. AI is great for enterprise, it improves efficiency, it lets you do all sorts of interesting things. Every business is looking at using AI right now, but there's, there's problems with the use of public AI and private AI. You want to be careful about the data you're using. If you're using public AI, you could be sending that, all sorts of important data out to the cloud in some unknown repository. Even if you're using private AI, what data are using for the training? Is it, is it appropriate? Then there's the issue of course, of bad guys using AI. Bad actors are using these tools to create powerful attacks that are almost impossible to, you know, fight against. They're using powerful AI agents across all four attack phases. They're using them to discover the attack surface. And if you're using a vpn, as most businesses with perimeter defenses are, that IP address, that's an attack surface, they're using AI to compromise, to move laterally once they get in. And once they, and if they can move at will laterally, they're going to find everything and they can then exfiltrate that data and blackmail you. And we're seeing it happen again and again and again, many times every single day. Traditional firewalls and VPNs aren't helping. They're expanding your attack surface. They're enabling lateral threat movement. Or really it's not that they enable it, it's just that if you have perimeter defenses and then you assume that anybody who penetrates those is a good guy, anybody inside the network must be an employee, right? You're asking for trouble. You're asking for trouble. Plus, you know, these traditional perimeter defenses are much more easily exploited nowadays thanks to AI attacks. It's time for a modern approach. And that's where Zscaler comes in. Because Zscaler is Zero Trust plus AI. It removes your attack surface, it secures your data everywhere, it safeguards your use of public and private AI and it protects against ransomware and AI powered phishing attacks. It's kind of does it all. Ask Stephen Harrison. He's CISO of MGM Resorts International. That's a name that should ring a bell. You may remember it. They got a ransomware attack a few years ago, cost them a lot of money. They weren't going to let that happen again. They chose Zscaler. And Steven says, quote, we hit zero trust segmentation across our workforce in record time and the day to day maintenance of the solution with data loss protection, with insights into our applications. These were really quick and easy wins from our perspective. That's a lot of trust. That's a lot of trust. That's zero trust. Zero trust. It's a lot of trust. That's confusing with zero Trust plus AI. Zero trust means you don't assume that somebody inside your network is a good guy. You don't trust anybody. And it works. It really works, even against completely novel attacks. Zero days. With zero Trust plus AI, you can thrive in the AI era. You can stay ahead of the competition. You can use public and private AI with confidence, securely. And you can remain resilient even as the threats and risks evolve. Learn more@zscaler.com security that's zscaler.com security and we thank him so much for supporting the good work Steve is doing here. It's security now. Now let's talk about DNS cash poisoning. I thought we were done with that. I thought we was over.

Steve Gibson (135:50)

An objective observer could be forgiven for concluding that some things appear to be difficult to get right. Since trouble surrounding DNS cash poisoning is once again in the news, our longtime listeners will likely remember Dan Kaminsky's discovery. This was in 2008, that the Internet's DNS resolvers were issuing easily predictable queries to upstream more authoritative DNS name servers. Dan realized that the super efficient lean and mean UDP protocol used by DNS itself contained no mechanism of any kind for authentication and that the DNS protocol also provided none. This meant that nowhere in the DNS resolving system was any authentication provided. The ancient system upon which the entire Internet depended. DNS is based on trust. So how could this trust be abused? A clever attacker would send a DNS query to a resolver asking for the IP of a domain that had just expired from its cache. Since every DNS query returns the remaining cache life of any cached domain, every response tells you how much longer that will be in the cache. So it's possible to know when a request for a domain will not be served from a resolver's cache and will instead cause that resolver to ask an upstream, more authoritative name server for the domain's IP address. So the attacker issues their request to the victim DNS resolver. The attacker knows that this will cause that resolver to in turn ask another name server for the domain's ip. Since the domain's IP is no longer being cached locally, it will have expired, and the attacker knows exactly when that occurred. But before the upstream authoritative name server, the real one, the authentic one, has had a chance to reply, the attacker themself supplies their own fraudulent answer to the waiting DNS resolver. And because neither the UDP nor DNS protocols contain any authentication mechanisms, there's no way for the waiting DNS resolver to know that the answer it received immediately to its query is fraudulent, and that it was not returned by the name server that it actually asked for the answer. So consider what that means. Each DNS record contains its own ttl, its time to live parameter, which is the length of time in seconds that the record is allowed to remain in a resolver's cache. Since this TTL could specify, for example, a full 24 hours, if a bad guy is able to sneak their own fraudulent DNS record into a DNS resolver's cache, it could even be, you know, well that that would be a TTL that would be sitting in there for one day. It's even possible for it to be a week in some cases. From that moment on, as soon as that fraudulent record is snuck into the cache with a TTL of a day or a week, anyone and everyone who asks that cache poisoned resolver for the IP of that poisoned domain will receive instead whatever IP address the attacker managed to plant into the resolver's cache. In this fashion, cache poisoning allows for wholesale Internet traffic redirection at scale. This is why the whole industry went nuts in 2008 and basically created a secret synchronized replacement of all the of the of the buggy DNS servers at the time, fixing them all at once, because they couldn't even allow a window of opportunity for this attack, because it is so feasible, and it could, at the time in 2008, have been so devastating. Successfully poisoning a DNS cache requires a remote attacker to be able to spoof the reply that the requester is expecting to receive from the authentic authoritative name server. For this to be done, the fraudulent DNS replies parameters need to match what's expected. UDP packets are issued from the resolvers IP and port to a destination IP and port 53. And in order to determine which replies match up with which queries, every query also contains a 16 bit ID. Back in 2008, Dan Kaminsky realized that the DNS resolvers of the era were asking their underlying operating systems to assign an outbound port to assign them an outbound port for the query that's going to be made upstream. And also he realized that the resolvers were simply assigning consecutive 16 bit IDs to the queries. No reason not to. The IDs were not a security mechanism. They were just there to tag each query so that for example, if this, if, if the same remote resolver were given three queries, they would have different ID numbers so that when the three replies came back, they could be assigned to the proper weighting outstanding queries. So since the operating systems tended to assign ports in upward consecutive order, they just, you know, they, they, they gave it like an outbound query, you know, port 30129, then 3013-030131-30132, just consecutive all the way up until they hit a, a configured upper limit. Then they wrapped around back to the beginning. So DNS queries in 2008 were being sent from a readily predictable port with a readily predictable ID number. And that was the problem. Sequential ports and sequential IDs. If an attacker could arrange to observe a query, a fresh query made from the targeted resolver, the resolver it was targeting to poison, they would be able to see which 16 bit port the query had just been emitted from and which 16 bit query ID it used. This would allow the attacker to generate an accurate guess for spoofing their subsequent attack reply. And as it turns out, it's easy to cause a resolver to send a request that an attacker can observe simply by causing the resolver to ask for the IP address of any domain whose DNS name server the attacker can monitor, right? So if you ask that resolver for the IP address of a domain whose DNS name server, the attacker's traffic can monitor. So they just set up their own name server, then they immediately know what port that came to them from and what I, what 16 bit ID was used. They know exactly where that resolvers counters are and the, and the OS counter. So that allows them that ability and everything is now in place for an attack. How does that happen? The attacker waits until a domain they wish to spoof and poison has just expired from the targeted resolvers cache. This means that a fresh request for that domain's IP will need to be provided by an upstream authoritative name server. So the attacker first requests the IP of a domain whose name server they're monitoring. This tell them tells them which IP, which 16 bit port and 16 bit ID was just used by the targeted resolver. They then ask the targeted resolver for the IP of the domain they wish to spoof. They know that the resolver will use the next successively greater port issued by the underlying operating system and the next successive query ID issued by the resolver's own query software. Then, immediately after issue, after issuing the request, they send a barrage of spoofed replies clustered around the expected source ports and query IDs, hoping that one will match up with the actual query and beat the real name servers reply. And it turns out that in practice, this works. The integrity of the domain name system is relied upon for so many purposes beyond just finding the proper IP for a remote website. For example, DNS is commonly used now to prove control over a domain by asking a domain owner to place a specific text record into a domain zone.

Leo Laporte (146:22)

I've done.

Steve Gibson (146:22)

That's how I get my certificates.

Leo Laporte (146:24)

Yep, I've done that many times.

Steve Gibson (146:26)

Yes, it's how we often. Yeah, yep. It's like put this text record in your DNS and then we'll verify you there that you've proven ownership of the domain. And that's how Digicert verifies my ownership of GRC.com so over time, DNS has become quite an authentication workhorse. So having it compromised represents a real problem. Back in 2008, Dan's solution was simple and straightforward. Don't allow a DNS resolvers queries to be predictable. Rather than having queries issued from successive 16 bit port numbers carrying a 16 bit query ID simply require those parameters to be random. Since port numbers are 16 bits and query IDs are 16 bits, this gives us 32 bits of potential entropy per query. Now, in this day and age, 32 bits isn't very much, so everyone would feel much more comfortable if we had a lot more. But this was, you know, unfortunately, even in 2008, it was way too late to go back and change the DNS protocol for this purpose. This was all designed long before bad guys were even a consideration. So 32 bits is the only thing that's available. But still 32 bits gives us 4.3 billion port and ID possibilities per query, so that's likely sufficient to dodge this very worrisome bullet. Now our listeners will also know that back in 2008 I created another GRC online service. You know, somewhat similar to GRC's shields up port Scanner, but this one was able to test what I called the spoofability of whatever DNS resolvers the visitor was using. You know, if you go to GRC.com DNS DNS HTM, that's our spoofability tester. And it literally, it it forces the user's resolvers to send GRC a huge number of queries and, and GRC looks at the source ports and query IDs and charts them on it on all kinds of grids and scales and, and, and does statistical analysis and all kinds of cool stuff. Anyway, that's there so Today's podcast is titled DNS Cash Poisoning Returns because it has turned out that things are not as settled and put to bed as we hoped and assumed. Ars Technica's Senior Security editor Dan Guden explained the new worries in his piece just last Wednesday. Writing the makers of Bind, the Internet's most widely used software for resolving domain names, are warning of two vulnerabilities that allow attackers to poison entire caches of results and send users to malicious destinations that are indistinguishable from the real ones, he writes. The vulnerabilities tracked as CVE 20, 25, 47, 78 and 4780 stem from a logic error and get this, a weakness in generating pseudo random numbers, respectively. Unbelievable. What year is it? Leo they each they each carry a severity rating of 8.6. Separately, makers of the domain name system resolver software Unbound warned of similar vulnerabilities that were reported by the same researchers. The unbound severity score is 5.6. The vulnerabilities can be exploited to cause d this is Dan writing exploited to cause DNS resolvers located inside thousands of organizations to replace valid results for domain lookups with corrupted ones. The corrupted results would replace the IP addresses controlled by the domain name operator for existence. You know 31511961 for Ars technica.com with malicious ones controlled by the attacker. Patches for all three vulnerabilities became available Wednesday. In 2008, researcher Dan Kaminsky revealed one of the most one of the more severe Internet wide security threats ever known as DNS cache poisoning. It made it possible for attackers to send users en masse to imposs imposter sites instead of the real ones belonging to Google, bank of America or anyone else with industry wide coordination, Thousands of DNS providers around the world, in coordination with makers of browsers and other client applications, implemented a fixed that averted this doomsday scenario. The vulnerability was the result of DNS's use of UDP packets because they're sent in only one direction, by which he means there's no TCP handshake. There was no way for DNS resolvers to use passwords or other forms of credentials when communicating with authoritative servers, meaning that those have been officially designated to provide IP lookups for a given top level domain such as dot com. What's more, UDP traffic is generally trivial to spoof, indeed meaning it's easy to send UDP packets that appear to come from a source other than their true origin. Dan got all that correct. He then explains the problem that we all understand and that the solution implemented 17 years ago back in 2008 turned out to be insufficient, he writes. At least one of the bind vulnerabilities, that's the CVE 4780 effectively weakens those defenses, the bind developers wrote in Wednesday's disclosure. Quote in specific circumstances, due to a weakness in the pseudo random number generator, the PRNG that is used in it is possible for an attacker to predict the source port and query ID that Bind will use. Bind can be tricked into caching attacker responses if the spoofing is successful, unquote. And I say to that unfriend believable that in 2025 that could be true. But Dan says the CVE 778 also raises the possibility of reviving cache poisoning attacks, the developers explained. Quote under certain circumstances, Bind is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache. Forged records can be injected into cache during a query, which can potentially affect resolution of future queries, he says. Even in such cases, the resulting fallout would be significantly more limited than the scenario envisioned by Kaminsky. Red Hat wrote in its disclosure of 4780, which is the PRNG one because exploitation is non trivial, requires network level spoofing and precise timing, and only affects cache integrity without server compromise, the vulnerability is considered important rather than critical and and Dan finishes the vulnerabilities nonetheless have the potential to cause harm in some organizations. Patches for all three should be implied or should be installed as soon as practical okay, so the first two of the CVEs the 4780 is titled Binds. The the official CVE Title for this is cash poisoning due to weak prng. To which I say, really? What? First of all, one of the main topics of discussion throughout the the early years of this podcast was the crucial need for high quality random numbers for cryptography and Internet security in general. Even when we're using public key crypto, public or private keys are used to encrypt and decrypt a secret symmetric key that's used to perform all of the actual work. And that symmetric key better darn be random. So the generation of utterly and absolutely unpredictable random keys has always been, still is, and probably always will be of utter importance. You need entropy in order to have security. So when we learn that in the year 2025, 17 years after the absolute importance of randomly selected 16 bit ports and randomly generated 16 bit query IDs, that the PRNG, the pseudo random number generator being used by the Internet's most used DNS resolvers bind and unbound, are weak. Well, you really have to shake your head. We, we know, we get it that embedded systems which are cut off from the rest of the world when they're just sitting there in a, you know, like in an unlike unconnected wristwatch or some, you know, a sports app or something, you know, if you have no access to the rest of the world, it's an embedded thing. You know, it's your dishwasher, your toaster, who knows what. They could have great trouble generating randomness. True, like anything unpredictable because they start from a known state and they lack any source of unpredictable events or timing data. They're just a little island, you know, they, they, it's understandable that they could have trouble generating anything that cannot be predicted. Every single time they boot they're going to do the same thing. So they can be forgiven. But they could also be hardly less. I mean that, that their, their lack of, their, the, the isolation and lack of having any contact with the world could hardly be any less true for any DNS resolver. DNS resolvers are sitting by definition on a network where they're continually receiving unpredictably timed and sized DNS queries. They are bathing in unpredictability. The queries being received from completely unpredictable ports, completely unpredictable IPs. And with completely unpredictable timing, you never know when they're going to come in. So DNS resolvers are continually subjected to, to a virtual blizzard of entropy. The only way any DNS resolver could possibly be starved of sufficient entropy for collection and use in continually reseeding is pseudo random number generator. If its designers just really don't care or. Or just are like somehow clueless about the way the world works and we don't want them designing our DNS resolution. The phrase due to a weak PRNG just really annoys me because 5 yes, no device on any busy network has any business having a weak pseudo random number generator. It is just unconscionable. Now the other CVE 4778 whose title is cash poisoning, attacks with unsolicited RRs that those are resource records. That's interesting since it suggests that there. There had been a means until this patch last Wednesday for and at which which both bind and unbound were subjected to, where an attacker was able to supply unsolicited, which is to say unrequested DNS replies resource records in. In response to a query that would have been accepted into the resolver's cache in such a way that they could be abused that those. That those unsolicited resource records could be abused by an attacker. So that's a bug that has been fixed and that's good. I did look around a bit and I was unable to easily dig up any additional details about what exactly was meant by a weak prng. And frankly I'm too disgusted to like look any further. I don't want to know what like how it could possibly have been bad because they had to try to not accept any additional entropy from the network they're connected to.

Leo Laporte (160:47)

They probably just use some library, right? That.

Steve Gibson (160:52)

Sadly. Sadly, yes.

Leo Laporte (160:54)

Yeah. They didn't want to write their own even.

Steve Gibson (160:59)

Even True Crypt, remember True Crypt back in the day when you were setting up a volume, it said move your mouse around for a while, right? And there it was. Brilliant. A source of unpredictable. No one could ever know how you moved your mouse and you're streaming position data in and you know, and I talked about. I called it. Entropy harvesting is the first component of the Squirrel system I wrote. It harvested entropy from all different sources inside the computer. No, the crazy intel chips have all these performance counters, branches predicted branch predictions missed. You know, I mean how I'm feeling today. I mean, just, just all this stuff.

Leo Laporte (161:47)

Let me ask a question. Just. I mean it's called a PRNG because it's a pseudo random number generator. They cycle, they repeat because no one's come out with a. I mean you're not. You wouldn't want to generate a new truly random number again and again and again. You, you use a random number generator is with a. Is the entropy that you're adding. Is that because most of the time when I use a random number generator, it allows me to start it with a seed. Is the seed the chaos or is it more complicated than that?

Steve Gibson (162:20)

So we, we start with a, with a CPU that is predictable.

Leo Laporte (162:28)

Right?

Steve Gibson (162:28)

Right. So, so if you deterministic. Yeah, determine it. It's entirely deterministic. So if, so any algorithm given a star, an initial starting state will always do the same thing. Yeah, well, yeah, it will repeat hopefully in a long time. But while it's doing that, it may be, but it will be a predictable sequence.

Leo Laporte (162:53)

The whole sequence is predictable. And so the seed starts the sequence somewhere. Yes, in the middle of the sequence.

Steve Gibson (162:59)

So today's good pseudo random number generators have a pool, what they call an entropy pool. And they're mixing this, this pool and hope. And so the real problem is that that is the rate at which pseudo random numbers can be needed. So as you take entropy from the pool, you're, you're, you're literally depleting. I mean this is all really bizarre, but it's, you're literally extracting entropy from a pool, reducing its entropy. And if you, so if you take entropy out at a greater rate than you're putting it in, then it, then this pool gets starved of entropy. And, and so, so I mean it's, it's really abstract. We're, we're so far away from, from a pseudo random number generation generator being multiply this and add this to get the next number.

Leo Laporte (163:59)

Right.

Steve Gibson (164:00)

Those were simple minded pseudo random number. They were, they are pseudo random number generators, but they're really dumb. So there are, there are. Mercine Twister for example, is the name of a pseudo random number generator which does this amazing stuff. But ultimately it's still deterministic. Run out. Yes, it's still deterministic and it can run out of entropy. So you need to be, you need to be constantly receding.

Leo Laporte (164:28)

I see.

Steve Gibson (164:30)

With new entropy.

Leo Laporte (164:31)

And that keeps it from repeating. I get it.

Steve Gibson (164:34)

Exactly. And so it just keeps sending it off in different directions. And, and the idea is that, that the design keeps any short sequence from being predictable. And by the time it might start to be predictable, it's gone off in a different direction. So you've receded the entropy before it was predictable enough to start being useful.

Leo Laporte (165:03)

The sad thing is this whole problem with DNS cache poisoning was discovered by, as you mentioned, dan Kaminsky in 2008. 17 years ago.

Steve Gibson (165:15)

Right.

Leo Laporte (165:16)

So. And what's really sad is Dan of course passed away in 2021. We talked to his mom, remember we interviewed his mom. After he passed away, he, he's in the Internet hall of fame for that and many other accomplishments. But he's very well known for having, you know, found this issue that could have been a crisis on the Internet, many say saved the Internet.

Steve Gibson (165:39)

I were, he and I were on stage together at one point for the.

Leo Laporte (165:43)

You had some great stories about him. Yeah, yeah. And so it's very sad that it's back again posthumously, but unbelievable.

Steve Gibson (165:51)

Maybe this time, you know, maybe the guy, the, the, the crotchety old idiots who fixed it in 2008 are gone. And so, you know, we got people. Right? Just ask Dan Bernstein, he's still around. He'll tell you how to do a pseudo random number generators.

Leo Laporte (166:11)

It's confusing. There are three different Dan's. There's Dan Kaminsky, who discovered it. Dan Gooden, who did this fabulous write up. He is the security report at Ars Technica and universally great. Everything he writes fantastic. And then Dan Bernstein, who knows how to write a pseudo random number generator.

Steve Gibson (166:29)

Yeah. And he, he is the, the, the father of the, the primary elliptic crypt. The elliptical curve that we're all using.

Leo Laporte (166:39)

Okay.

Steve Gibson (166:40)

Yeah.

Leo Laporte (166:40)

All right.

Steve Gibson (166:40)

I mean the guy's really, you know, and he and I co invented, what do we call it, it was a, it was an early DDOS thing. He had, he had come up with the idea, oh, sin cookies problem. Yeah, yeah. And so I had come up with it and then implemented it. And then someone said, hey, you know, Bernstein did that already. I go, oh, no kidding. Of course I, I used it on Windows and he had it over on Linux, I think, or Unix or something. Anyway, crazy world.

Leo Laporte (167:14)

All right, Mr. Gibson, once again you hit it out of the park and it didn't take you 18 innings to do it. Although it did take you 2 hours and 46 minutes. But that's, you know, that's not bad. That's not bad. It's a lot shorter than that, the.

Steve Gibson (167:25)

Way we roll these days.

Leo Laporte (167:28)

By the way, we did the math for poor Garrett, who hasn't, who just joined us for the first time last year and is saying, should I. You know, I don't know if I have time to listen to all of the past. How many? 1,400.

Steve Gibson (167:40)

This is going to discourage him. Leo, this is going to be discouraging.

Leo Laporte (167:42)

I had Patrick.

Steve Gibson (167:45)

The earlier ones are shorter.

Leo Laporte (167:47)

That's not going to help. It will take you of non stop listening. 77 days, 23. 3 hours, 2 minutes and 21 seconds, not including this episode. But you already heard the other hand.

Steve Gibson (167:58)

On the other hand when there's no new podcasts coming, what are you gonna do? Back the clock.

Leo Laporte (168:04)

Yeah, someday we'll be.

Steve Gibson (168:06)

Don't listen to them in reverse order though. You'll hurt yourself. So you need. You need to start at the beginning.

Leo Laporte (168:14)

Thank you, Mr. G. Steve Gibson's@grc.com There are many reasons to go there, of course. Course, his bread and butter spin, right? The world's best mass storage maintenance, recovery and performance enhancing utility, version 6 1. The latest version just came out. You can get a copy right there. I would suggest buying it. If you've got mass storage, you need it, you should have it. Everybody should have a copy. There's many other free things there you can use. Like never 10decombobulator. Shoot the messengers. I'm going way back now. Going way in control. And soon DNS, the DNS Benchmark Pro. I'll tell you, you want to get notified about that. He has a mailing list. There's two mailing lists. One is the weekly mailing list for the show Notes, which you want to get because he does the best show notes I've ever seen. I mean it is how many pages? 18, 19 pages this week it's quite a few pages.

Steve Gibson (169:12)

23.

Leo Laporte (169:13)

Okay. And there's links, there's illustrations. It's. It is complete. It is everything you need to know about the show we just did. But you can get that ahead of time just by subscribing to the mailing list. Now here's what you do. You go to grc.com email the main purpose of that page really was to. To white list your email address so you can send Steve things like pictures of the week, like the. What was it? Control, alt, del or comments or suggestions. And so. But he won't accept the email unless you've whitelisted it. So go there to whitelist it. But you'll see at the bottom, after you've entered the email, there are two boxes unchecked, because Steve would never, you know, involuntarily subscribe you anything. But if you want them, you can get that newsletter and you can get the regular. Well, it's not so regular. There's only been one. But you can get the soon to come email that will tell you the announcement of DNS Benchmark Pro. It's a good, that's a very low traffic email list and it's a good one to get on GRC.com email. There's plenty of other things there, including this show. Steve has all unique versions of this show. There's A reason to go to GRC to get the show. I mean you can get it from us, you can subscribe, but if you go to GRC com you will get. There are available 16 kilobit version, very scratchy, sounds like Thomas Edison recorded it on a cylinder. But it is the smallest version audio version of the show. There's actually even smaller version which is the transcripts crafted by a human, the wonderful Elaine Ferris. So if you like to read along while you listen or use those transcripts for searching, you can get those there. He also has a full fidelity 64 kilobit audio version. That's GRC.com, the show notes are there too for download if you want to just get it at any point after the fact. Now we also have copies of the show at our website, which is Twitter TV SN. We have 128 kilobit audio. Get all the bits or you don't. Half of them you don't need, but you can get them all. And then we also have the video because we shoot video of the show. And if you'd like to see Steve's mustache at work, that's the place to go. Or the YouTube channel dedicated to the show. Actually that's a good place to go to share clips of the show. Like that nist password story from last week until we get that up on TikTok and YouTube shorts. You can do it yourself by just going to the YouTube channel and clipping that and sending it off to your IT department. I presume they are smart enough to play a YouTube video. Most people are, but you never know. You can also subscribe in your favorite podcast client. In fact, that's the best thing to do. That way you get it automatically the minute it's available. It's free audio or video or both. Leave us a good review too if you if you have the time, that would be nice to help spread the word. We thank our club members for making this possible. They support everything we do here. 25% of our operating income comes from the club and we need it. Believe me, if you enjoy this show or any of our shows, if you want to Support us, TWiT TV Club TWiT get ad free versions of the show's access to our exclusive members only Disco. Well, it's Discord, but I call it the Disco you can also and we do a lot of special events in there like our Dungeons and Dragons we did last week. So join the club. Twitter tv Club Twit. There's a coupon on there right now for a discount discount. This would be good for a gift to the geek in your life or just a gift to yourself. That will expire Christmas Day. So don't wait go there to get that. There's also two week free trial, a variety of other things. Twit TV Club Twit. We do stream the show live if you want the freshest version. We do it every Tuesday right after Mac break weekly. That's usually around 1:30 Pacific, 4:30 Eastern. And now here comes the propeller head part of my day because we are on Pacific Daylight Time, but next week will be on Pacific Standard Time because we're setting our clocks back spring forward, fallback. That means it's going to still be 1:30pm Pacific, 4:30 Eastern. But if you were in a time zone elsewhere, you're going to do the math based on Universal Coordinated Time, UTC. And that is 1930, if my math is correct. Not this week it was 1830, but it'll be 1930 UTC. Wouldn't.

Steve Gibson (173:49)

Wouldn't UTC be Universal time coordinated?

Leo Laporte (173:53)

There is. Therein lies a tale. You should look it up on Wikipedia. It's in French, but oddly the acronym doesn't refer to any existing language. Utc. Because we could call it uct, but then the French would be mad and they would call it CUT or something and if they did that, we would be mad. So they came up with an acronym, utc. That doesn't work in any language. They're thinking the itu, they're thinking it makes no sense. But I. It's what it is. We used to call it Greenwich Meantime. And see, that's the problem is. No, is the, the French. You can't call it Greenwich Meantime. Are you crazy? It's Paris Meantime. No, it's not that either. So we, we had to work out a compromise. Where was I? 1930 UTC. Yes, because we. Because we're going to set our clocks back in during the weekend.

Steve Gibson (174:52)

Well, you're not. They're going to set themselves back, apparently.

Leo Laporte (174:55)

Well, all but that one in the microwave.

Steve Gibson (174:57)

Yeah.

Leo Laporte (174:58)

You. You have to go around. What do you got? Grandfather clocks? What are you doing there? Big Ben? Yes. Every night I just see Steve going up and going, you gotta wind them.

Steve Gibson (175:10)

You gotta wind them. Leo. If you don't wind them after a couple days, they just stop swinging. That's right. So our, our closing advice here is. Yes, adopt the NIST guidelines and be invited to parties.

Leo Laporte (175:25)

I've forgotten the party part.

Steve Gibson (175:27)

And, and.

Leo Laporte (175:28)

Oh, you will be invited to parties then. If you don't, that's Right.

Steve Gibson (175:33)

You won't. That's right.

Leo Laporte (175:35)

Carrot and the stick, baby. Thank you, Steve. Have a great week. We'll see you next time on Security.

Steve Gibson (175:39)

See you in November.

Leo Laporte (175:44)

Security now. Morning, Zoe. Got donuts.

Steve Gibson (175:54)

Jeff Bridges, why are you still living above our garage? Well, I dig the mattress and I.

Leo Laporte (176:00)

Want to be in a T mobile commercial like you teach me. So, Dana.

Steve Gibson (176:04)

Oh no, I'm not really prepared. I couldn't possibly at T Mobile get the new iPhone 17 Pro on them. It's designed to be the most powerful iPhone yet and has the ultimate pro camera system. Wow, impressive. Let me try.

Leo Laporte (176:17)

T mobile is the best place to get iPhone 17 Pro because they've got the best nuclear work. Nice.

Steve Gibson (176:23)

Jeffrey, you heard them. T Mobile is the best place to get the new iPhone 17 Pro on us with eligible traded in any condition.

Leo Laporte (176:32)

So what are we having for lunch?

Steve Gibson (176:33)

Dude, my work here is done. The 24 month bill credit is on experience beyond for well qualified customers. Plus tax and 35 device connection charge credit send and balance due if you.

Leo Laporte (176:40)

Pay off earlier, Cancel Finance agreement. IPhone 17 Pro 256 gigs 1099.99 and.

Steve Gibson (176:44)

New line minimum 100 plus a month plan with auto pay plus taxes and fees required. Best mobile network in the US based.

Leo Laporte (176:48)

On analysis by Oklahoma Speed Test Intelligence Data 1H 2025 Visit t mobile.com AI agents are everywhere, automating tasks and making decisions at machine speed.

Steve Gibson (176:58)

But agents make mistakes. Just one rogue agent can do big.

Leo Laporte (177:03)

Damage before you even notice.

Steve Gibson (177:05)

Rubrik Agent Cloud is the only platform.

Leo Laporte (177:08)

That helps you monitor agents, set guardrails and rewind mistakes so you can unleash agents agents, not risk. Accelerate your AI transformation at rubrik.

Steve Gibson (177:18)

Com that's R U B R I K Com.