SN 1049: DNS Cache Poisoning Returns - Ransomware Payments Plummet

[00:00:00] It's time for Security Now. Steve Gibson is here. He's got the story of an android robot vacuum that doesn't suck. Well, maybe it does, actually. We're going to talk about the arrest of two UK hackers. Steve's maybe a little bit sympathetic to their plight. We'll talk about how ransomware gets in and then the sad return of a bug in DNS that was fixed in 2008. That and a whole lot more coming up next on Security Now.

[00:00:32] Podcasts you love. From people you trust. This is TWiT. This is Security Now with Steve Gibson, Episode 1049. Recorded Tuesday, October 28th, 2025. DNS Cache Poisoning Returns.

[00:00:54] It's time for Security Now. I know you wait all week for this. I do, too. Every Tuesday, Steve Gibson joins us to talk about the latest in security, privacy, technology, and security. And technology in general. Hello, Mr. G. Yo, Leo. How are you today? It's great to be with you. Great. Believe it or not, one of our old friends is back this week. DNS cache poisoning. I thought we'd handled that.

[00:01:23] We thought, well, how long ago was 2008? 17 years. You'd think that 17 years we could have gotten it right. Yeah. New. So that's our title for today. DNS cash poisoning returns for this 28th of October, pre-Halloween, pre-daylight savings times, doing whatever it's going to do on Sunday, Episode 1049.

[00:01:51] And I was glad to hear before that you were as confused as I am about when you fall back, does that mean that it's earlier or later? And what happens? Every six months I have to do this math in my head. I think, because we move, but UTC doesn't. I think we, I don't, we're now minus eight is what I think.

[00:02:13] I do like the spring when we spring forward, because that makes it easier to set your digital clocks forward an hour. It's much easier. Do you still have a clock you have to set? Oh yeah. I like, I like clocks. And we got, but all my clocks set themselves. No, I have analog clocks, but they all set themselves. Yeah. Well, I don't. You have a West clocks. I'm going to turn the knob on the back.

[00:02:41] We got a, believe it or not, we have a bunch of fun things to talk about. We're going to talk about the unsuspected sucking power of a Unix based robot vacuum. And what is sucking is not your dust. Oh dear. 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.

[00:03:09] I mean, 18 and 19 years old, your life is screwed. Facebook, Instagram, and TikTok are violating the EU's DSA. What's going to come of that? Microsoft teams is bringing user wifi tracking by policy to the teams platform. Wasn't that sound like a great idea? I know. I, you know, so you backed up. That's great.

[00:03:38] 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, uh, uh, insight into what's going on with the way ransomware negotiators. Uh, uh, well, I mean, the, the, the, at, they are a ransomware negotiator and they've got

[00:04:04] some great feedback from their position as a ransomware negotiator 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. I mean, that just really, we have people, whoa, we got people defending changing your passwords every five minutes. So we'll cover that.

[00:04:29] Uh, and also someone who was very happy with the fact that, uh, Azure or Entra or something allowed them to further lock down the, the, the ability of their listeners to sidestep those policies, lots of good stuff. Uh, and finally, against all reason and begging credulity, it seems that we still haven't managed

[00:04:54] 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

[00:05:22] on a network, not to have a, like to have solved this problem long ago. Cause packet timing is unpredictable and gives you a source that you can then use. You've got, you've, you've got a ran, a really random source. Yeah. 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.

[00:05:51] If I mean, it's all deterministic, but nothing on a network is deterministic. And by definition, a DNS resolver is on a network. So yeah. Anyway, we're going to go all through that. I don't, I'll kind of try to calm down, but we'll also find out. And I'm anxious to why you need a random number generator, but you'll answer that question. I'm sure. Yes.

[00:06:15] 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 no one is going to believe it. Okay. It's not Boaty McBoatface.

[00:06:43] I take my, no, but it is reminiscent of. They should have learned from that. There actually, there was a reference to Boaty McBoatface in, in the BBC's coverage of what great Britain chose. They've got to stop letting the public choose these names. I'm sorry. All right. 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. I'm going to just step back a little. Just calm. I'm going to calm myself down.

[00:07:13] Maybe it's because you were a little. I'll back off on the coffee. Yeah. Okay. You know, it's funny. I used to drink coffee before this show to get in sync with you. Right. But I can't sleep if I drink coffee this late in the day. So now I'm just going to sit here. It is afternoon. Yeah. I try to have one cup in the morning and stop there because otherwise. For what it's worth, espresso has much less caffeine. I know. I drink espresso. Oh, okay. Which makes me vulnerable. That's the problem. And your clocks set themselves.

[00:07:43] I, you know, my clocks need to set my own clocks. I'm very modern. So there's one device in the house, the microwave that I still have to go set. Even the stove is on wifi. The refrigerator is on wifi. Everything in here is either on wifi 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.

[00:08:12] Everything sets itself except for my microwave and one red clock across from me. So I have my chores set up for me on the Sunday. John used to do that, right? John, you used to do that. Is it the Nixie clock wrong? No, it's UTC. Ah, of course. So it's unusable. It's unusable. It's 24 hour UTC. So yeah, you have to do math to understand what time it is. Although you do like to give our listeners the UTC time. I do because.

[00:08:41] So you could just turn around to find out. Yeah. 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. That would be nice. Let you do the math. You do the math. You do the math. That works for the podcast also. We're going to get to the picture of the week in just a moment.

[00:09:07] 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 against cyber attacks, right? Job one. But that job is getting harder. 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.

[00:09:36] 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 four generic trainings a year and most employees look at them and go, oh, please. And it just, you know, they don't either ignore them or if they're forced to click through them, they go, yeah, yeah, yeah, yeah, yeah.

[00:10:03] And the worst thing is when somebody, you know, clicks on one of these fraudulent, you know, these test emails, they're forced into embarrassing training programs. 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, this works. It goes way beyond security awareness. It changes behaviors. And it does it by making it fun.

[00:10:31] 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, Hawks Hunt tells them, you know, practically with fireworks, they tell them instantly, your employee is going to get a dopamine rush. It feels good. They go, oh, this is great. And they're going to click and they're going to learn and they're going to protect your company because they enjoy it. It's more fun.

[00:11:01] And you'll enjoy it as an admin because Hawks Hunt 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 Hawks Hunt'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 department and location and all the stuff that you know about them, which,

[00:11:31] 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.

[00:11:59] 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. Hawks Hunt 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.

[00:12:22] Over 3,000 user reviews on G2 make Hawks 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.

[00:12:47] Visit hawkshunt.com slash security now to learn why modern, secure companies are making the switch to Hawks Hunt. That's hawkshunt.com slash security now. H-O-X. Like Fox Hunt with an H. H-O-X-H-U-N-T. Hawkshunt.com slash security now. 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 slash security now. All right.

[00:13:16] I have queued up the official picture of the week. So once again, this was the name of the train. The official network rail train. Yes. Great Britain's public voted for. Uh, 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. Ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha.

[00:13:46] And they painted the name on the side of the train. That's right. The train, the official name in Great Britain for the train track leaf clearing train is control alt D leaf. oh my god that's brilliant you know what that's so much better than body mcboatface brilliant isn't that now i'm glad they voted on it the public said this is what we want to see

[00:14:12] barreling down the tracks control alt d leaf i love it i thought that was great and a 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

[00:14:38] his smart vacuum was broadcasting a secret map of his house that's a great headline secret map is but okay um 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

[00:15:03] the computer programmer and electronics enthusiast harish hakanar uh uh uh uh uh narayanan narayanan i think that's as good as i can get narayanan detailed a startling find steve was startled uh he made about his 300 smart vacuum not a cheap one it was transmitting intimate data

[00:15:32] out of his home so imagine that who would have i 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 i life a 11 so it's i life a 11 smart vacuum which is turns out to be a popular gadget that's gained mainstream

[00:15:59] 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

[00:16:22] 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 uh uh uh 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

[00:16:51] 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

[00:17:15] 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 now reenan 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

[00:17:45] okay now in all fairness he was screwing around with its network traffic right so okay i would argue that he got what he 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

[00:18:13] after reverse engineering the vacuum a painstaking process which included reprinting the device's circuit boards wow 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 unquote to the world well yeah you know like a few connection points on a circuit board

[00:18:42] 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

[00:19:06] 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 what's 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

[00:19:34] in addition narayanan says he uncovered a suspicious line of code broadcasted from the vacuum or from the company to the vacuum time stamped 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

[00:20:02] it came back to life instantly oh my god they hadn't merely incorporated a remote control feature they had used it to permanently disable my device they had a kill switch they had a kill switch in short he said the company had made the device that that had made the device quote had the power to

[00:20:25] 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 dozens of smart vacuums

[00:20:52] 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 uh you know spread among many other vacuum manufacturers that you know that it was you know basically white labeled internally and

[00:21:15] 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 this is why people were upset about amazon's bid to buy rumba last year was oh well amazon will get all the mapping data because these these devices do have to make a map of your home that's how they work

[00:21:44] they do one could argue they need not be sending it back to right to the home office yeah so he uh 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 the register okay now this article and narayanan's

[00:22:11] 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

[00:22:31] 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

[00:23:00] 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 well it's an android device right that's the whole point yes like an android phone

[00:23:28] it's got 80 b you use adb and you get into it and you can root it right but the other point is that i life is a chinese company so remember when you bought that chinese switch the on off switch yeah you had the same concern so right narayanan's blog expresses surprise at finding his network's unencrypted

[00:23:52] 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

[00:24:16] 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

[00:24:40] 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

[00:25:04] 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

[00:25:28] 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

[00:25:55] then it's possible and storage is cheap well and there are reasons because uh 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 how comforting yeah and if you had a bunch of iLife devices you might say oh yeah look i just hook them all up automatically yeah magic it's not like they're talking to each other they're talking back to the mothership

[00:26:25] the home the home office yeah that's right in shenzhen china 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

[00:26:51] nary yanan 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

[00:27:13] of course again it's a rolling linux platform that you've given you access to your network to and it's phoning home so anyone using one of these will implicitly have invited a powerful network

[00:27:37] aware, 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

[00:28:00] 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

[00:28:25] with sufficient flexibility can fill that bill. The emergence 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

[00:28:49] 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

[00:29:12] network. You know, I'm sure that virtually no regular consumers appreciate what it means to have invited IOT gadgets 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,

[00:29:40] 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 home to Shanghai or Shenzhen or who knows where, and they've got connections. And there's no justifiable reason for this vacuum rolling around

[00:30:03] the floor to be streaming data back to central headquarters. I mean, the problem is storage is cheap for them. Their bandwidth is cheap for us everywhere now. Nothing prevents it from happening. And it is happening. Yeah. You should assume it is. Yeah. Yeah. I mean, it is. And one of the things 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

[00:30:33] 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. Um, it would be really cool to be

[00:31:00] able to disambiguate all of that traffic and create a user interface that shows users who care who's talking to who, what is all this going on? Cause our networks are very, very busy and we have no visibility into that. Well, I mean, we used to be able to do that with Wireshark, right? I mean, you could run something like, yeah, but all you get is a raw packet dump. I mean, it's not doing

[00:31:26] any great, I mean, I'd love to be able to say, Oh, that's apple.com. Don't worry. That's just your eye things, you know, doing some work, but you know, if it's heading off to change, 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 and you could record with Wireshark and then send it to an AI, have it kind of translate it or analyze it. I bet you, you could do that. Yeah. A lot of steps. I just like job

[00:31:56] for Zapier. I would like to have a, uh, you know, a nice little UI or maybe uploaded to GRC and a page at GRC will show you. Okay. Steve, who's in charge there? Somebody who's very busy. It turns out. Somebody who's scrambling. Yeah. I expected I would have the benchmark finished before Andy

[00:32:21] had his website published, but right now it's kind of neck and neck. I'm not sure. It is. It's a race. Okay. So, uh, 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

[00:32:49] 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. Um, but this suggests that all of this is important. So here's what happened. Russian lawmakers. This is, I'm reading from the piece of news that I found are working on a new

[00:33:12] 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

[00:33:37] 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 safe saving face sort of thing for, uh, the Chinese culture there. And what the article said, we will circle back to that in a

[00:34:04] second. The article says the bill is currently being the, the Russian 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

[00:34:31] 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,

[00:35:01] 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 regular 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

[00:35:30] 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,

[00:35:50] 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 there 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.

[00:36:20] The bill will also introduce a new concept of registries for companies that run, run bug bounty programs and for registries 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

[00:36:49] the bill with the private sector and security researchers pushing back hard against it for some legitimate reasons. As the RBC piece, which is 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,

[00:37:15] 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, so the guys who are finding the vulnerabilities want to remain anonymous and they're making a strong case for that

[00:37:44] because they're seen as elite hackers whose work product has real value, not only to the Russian government, but to the criminal side. So the bill is intended to cover all facets of the white hat ecosystem from 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.

[00:38:14] 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.

[00:38:37] So they cannot be, you know, sued by 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,

[00:38:57] 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.

[00:39:17] 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.

[00:39:45] In July of 2021. What 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.

[00:40:03] 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 operations. And time has proven that to be happening.

[00:40:24] 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.

[00:40:47] 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,

[00:41:11] 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.

[00:41:37] Even before the regulations were implemented in September of that year, analysts had issued warnings about the new regulations' potential impact. At issue is the regulations' requirement that software vulnerabilities, you know, flaws in code that attackers can exploit, that they would be reported to the MIIT within 48 hours of their discovery by industry.

[00:42:04] The rules prohibits the rules prohibiting the rules, and the rules prohibiting the MIIT, 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.

[00:42:29] In effect, the regulations, the think tank wrote, push all software vulnerability reports to the MIIT before a patch is available. Oh, that's the key. Before the patch is available. Yes. Yes.

[00:42:45] Conversely, the system currently in place in the U.S. 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.

[00:43:13] For an organization tasked with offensive operations, such as a military or intelligence service, it is better to have more vulnerabilities. Yeah. 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.

[00:43:43] 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 report's conclusions.

[00:44:11] 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.

[00:45:08] 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 new legislation went into effect in China. Showed a corresponding uptick in the number of zero days deployed by PRC-based hacking groups.

[00:45:36] 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.

[00:46:03] 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.

[00:46:30] 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.

[00:46:59] 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 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.

[00:47:30] Ever. Who would have thought? Who would have thunk it? You know one thing that is perfect, though? Our advertisers? I knew you were going to guess correctly. 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's our sponsor, so I should probably explain that.

[00:47:56] 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. It seems like it'd be fairly easy to do. In fact, I probably should have done it while I was thinking about it. But this episode of Security Now brought to you by Zapier. I actually am always thinking about ways I can use Zapier to make my life easier.

[00:48:21] 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.

[00:48:50] 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 the right tools. You need Zapier.

[00:49:19] Zapier is how you break the hype cycle and put AI to work across your company. What is Zapier? 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. Have Zapier run Wireshark. Get the Wireshark information. Process it through Claude. Have Claude, and you can have all the scripting for Claude, what the prompt is and everything.

[00:49:49] Interpret it and generate an easy-to-use report so that you can figure out what your devices are talking to. You can 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.

[00:50:12] 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. 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, but they call them Zaps that you use all the time. I know I do. I have a whole library of them.

[00:50:39] Well, now 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 Zapier is for everyone.

[00:51:08] 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 slash security now. That's Z-A-P-I-E-R dot com slash security now. It's funny. It's funny.

[00:51:35] 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 slash security now. Try it for free. I think you'll like it. I got to warn you, you'll be hooked. On we go.

[00:52:04] Let's talk about scattered spiders, but don't be scared. There's no insects involved here. Just some evil people. Well, it's sad. Three days ago. Yeah, we were all hackers as teenagers, right? I know you were. I've said many times if I were in high school today, well, I mean, I have a strong sense of ethics. Yeah, you wouldn't be ransom wearing companies or anything.

[00:52:31] No, I had, as I mentioned once before, maybe at least once, I had a master key to the district, the entire school district, open to any door in the high school and any high school. Oh my God. But you didn't use it for evil? No. And the principal who had me in his office finally said, you know, you kids, because there

[00:52:56] was a small group of us, would be in real trouble, except we know when the janitor lost his master key ring. And 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, you know.

[00:53:23] If it had been my principal, he would have said, see, I've always said you were an underachiever, Laporte. No ambition at all. Never used that key once. 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 packing collective, which, you know, we've been talking about so

[00:53:48] much recently since it's not worth losing sight of the fact, 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

[00:54:12] 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.

[00:54:43] The 18 and 19 year olds were charged with conspiring to commit unauthorized acts under the 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 Baumgartner scheduled a further hearing for the 21st of November with a trial date set for June 8th of 2026.

[00:55:11] 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 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

[00:55:40] away with this. Recently arrested by the National Crime Agency and City of London police on the 16th of 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 31st last year, was carried out by members of cybercriminal group Scattered Spider.

[00:56:04] TFL said the hack cost it 39 million pounds 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.

[00:56:30] 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?

[00:56:59] 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 they messed up by doing that. Last Thursday, the day before, the European Union found that Facebook, Instagram and TikTok

[00:57:27] 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 TikTok could be fined an attention grabbing 6 percent, up to 6 percent of their total global revenue, which is some cash. And that will get their attention.

[00:57:56] The EU's press release explained what's going on. They wrote, today, the European Commission preliminarily found both TikTok 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

[00:58:24] 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 to challenge a decision that Meta has made. The Commission's preliminary findings show that Facebook, Instagram, and TikTok may have put

[00:58:54] 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.

[00:59:21] 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 European Commission speaking, neither Facebook nor Instagram, this is the EU, the European

[00:59:49] 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.

[01:00:14] 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.

[01:00:44] 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

[01:01:12] 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 honor that. Because, you know, that reduces the influx and the flood at the same time.

[01:01:41] If they don't, if they can 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.

[01:02:10] 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.

[01:02:34] Essentially, Facebook and Instagram don't want to, you know, spin up a big mechanism for doing what the DSA 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.

[01:03:04] 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

[01:03:34] 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 29th, tomorrow of 2025, as the delegated action on data access comes into force.

[01:04:03] 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.

[01:04:21] 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.

[01:04:45] Up to this point, the online world has been an 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?

[01:05:10] 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.

[01:05:38] We've been covering that throughout the life of this podcast. The legislatures finally grew tired of asking for voluntary change 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.

[01:06:03] 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.

[01:06:30] 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? Yeah, I agree. It's interesting.

[01:06:57] The only issue is whether the government is acting, who the government is acting 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's- Protectionism? Right. Yeah. That the EU's attack on Apple is at the behest of Spotify. Well, it is. Spotify complained.

[01:07:25] 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. And so as long as they're acting on our behalf, that's fine. 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.

[01:07:53] It was European advertisers who said, we don't like this. That's come up again, by the way. The EU is is now complaining about Apple's ad track with what 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 right. 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. Yes. It notifies you. Yeah. Yeah.

[01:08:23] So that's an example. I'm sure that that's advertisers have complained. And so it's protectionist. Because people, yes, 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. Right. Like 90 percent of people who see that say, no, don't track me. So I understand exactly what you mean, Leo, about who is to benefit. But it doesn't. It also doesn't matter. Right. Right.

[01:08:51] 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 again, I think that we've had this like Wild West attitude where really disruptive technologies have just come barreling in and no one said anything.

[01:09:18] It's interesting that like suddenly, I don't know what it is in the air, but this year in 2025, it's like, OK, the governments everywhere are saying we've had enough of this. We're going to we're going to 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, OK, you know, we're going to have age verification. You should you geeks figure out how to do that. Yeah. Not our problem.

[01:09:51] 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. That is the users of Teams clients.

[01:10:14] 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.

[01:10:39] 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 Teams 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.

[01:11:07] 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?

[01:11:24] Microsoft's 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.

[01:11:52] 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 are 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.

[01:12:18] 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.

[01:12:41] 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%. 95%. Almost everybody. We're good. We're good. Bring it on, baby. We can recover. We're ready.

[01:13:08] Turns out only 15% of those confident 95 were actually able to recover their data. 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? What the hell? Yes. And all their suppliers went bankrupt and yeah. It cost it. And it's the UK's economy. Like, like.

[01:13:40] So that's because now I understand the executives, the IT guys, the security guys at Jaguar were confident. We could, confident. We aren't going to have a, we could recover from anything. And they couldn't. They pushed the backup button and it went. But we have a sponsor for that, but we'll save that for a little later.

[01:14:04] 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.

[01:14:27] was that for the first time ever ransomware payment rates had seen a drop below 25%. But 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.

[01:14:57] It's dropping. That's interesting. 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.

[01:15:12] 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.

[01:15:40] Until today, the chance of being paid a ransom has fallen to less than one in four, as I said. No, 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.

[01:16:10] So that's part of the nonpayment 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.

[01:16:30] 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. Coveware's perspective on attacks is very interesting, illuminating and insightful. And they're the people who know because they're involved.

[01:17:00] They're like the tip of the spear in negotiating. And Leo, after our next break, since we're here at After Hour, we're going to look at a very interesting report from Coveware. Okay. I do think, though, that Coveware might have a little bit of a vested interest in this statistic. Like, see, we can help you not pay the ransomware because we'll negotiate with the bad guys, right? Could be.

[01:17:29] Although what I'm focusing on is the information they have about attacks, which is really interesting. That would be of great value. How the bad guys get in. 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.

[01:17:49] 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. One Password.

[01:18:19] I know you know the name One Password. They are, if not the most, I think they are the most popular password program in the world. If not the most, there's certainly in the top two or three. But they do more than just protect your credentials. 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.

[01:18:47] 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. Well, with a growing problem of SaaS, sprawl, and shadow IT, it's not hard to see why this is an issue for IT departments.

[01:19:16] Thankfully, there is a solution. One Password Extended Access Management. EAP and Trelica, which is One Password'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 One Password, inventories every app in use in your company. Every app, even apps you don't know about. Every app.

[01:19:43] 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've 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.

[01:20:09] And it will help you make sure that those approved apps are being used and unapproved apps aren't. You totally control it. You can manage shadow IT. It 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.

[01:20:36] It's just one of the ways that extended access management from 1Password helps teams strengthen compliance and security. Of course, 1Password is an award-winning password manager. It's 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.

[01:20:59] 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 at 1Password.com slash securitynow.

[01:21:26] That's 1Password.com slash securitynow. All lowercase. Thank you, 1Password, for supporting Steve Gibson and securitynow. 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.

[01:21:56] Anyway. Yeah. I mean, authentication has become everything. Job one. Let's talk about how hackers get into your system. I'm fascinated. Okay. So, 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.

[01:22:24] 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.

[01:22:53] 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.

[01:23:13] 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.

[01:23:36] 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.

[01:23:56] 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.

[01:24:22] 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.

[01:24:40] 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.

[01:25:07] 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, The initial access activity in Q3 reflected the continued evolution of attacker behavior more than any dramatic shift in tactics.

[01:25:36] The same foundational pillars, remote access, 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.

[01:25:59] 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.

[01:26:26] Credential-based intrusions through VPNs, cloud gateways, and SaaS integrations. That, of course, was the whole Salesforce mess. Continued to drive compromise, particularly in organizations navigating infrastructure migrations or complex authentication models.

[01:26:45] You just get tripped up over 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,

[01:27:16] 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.

[01:27:38] Campaigns that blurred these lines, such as those impersonating SaaS support teams or abusing help desk processes to gain OAuth authorization, again, the whole scattered spider fishing mess, demonstrated, you know, with Cloudflare, demonstrated how human trust can be engineered into a technical foothold.

[01:28:01] 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.

[01:28:18] 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.

[01:28:46] Technical remediation without procedural rigor still leaves gaps wide enough 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.

[01:29:05] 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 where patching lagged or migration hygiene fell short. Remember, there was an instance, I can't remember which, I think it was Cisco, where the people who were upgrading- It's always Cisco, by the way. Yeah, I know. I know. It's a safe bet.

[01:29:35] 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.

[01:29:59] Anyway, the report is so fascinating, as I've said, that 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 send the link on to your IT people or your C-suite people to get their attention. Because this Coveware group, they've got a great microscope into the way this is all happening.

[01:30:28] You could spend a whole show talking about these. I mean, this is just, I mean, it's endless. Yeah. Yeah. Garrett Smythe said, hello, Steven Leo. Hello. Hello, Garrett. 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.

[01:30:57] I was only a young buck when the show started. He said, friends, a toddler. So pretty much most of our audience. That's right. 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. But he says, if life ever slows down, which, okay, that's not going to happen.

[01:31:24] 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.

[01:31:54] 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.

[01:32:22] They're still as relevant today as they were back then. 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.

[01:32:51] I don't know why or how it will happen, but it will, but it will come someday. 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. So that's what I said when I was watching last night's World Series game between the Dodgers and the Blue and the Ajays. Someday there will be an end to this game.

[01:33:16] I know you're not a baseball fan, but you might be interested to know it went 18 innings, twice the normal number. And it didn't finish till after midnight California time after 3 a.m. East Coast time. That's a lot. Yes, that's a lot. Wow. I couldn't make it. I tried. And was it exciting? Yeah. I mean, if you like baseball, baseball is not inherently that exciting. I've been told that like, yeah, you have a lot of time to walk around and get a lot of time to have hot dogs. Yeah. Yeah.

[01:33:46] It's mostly about sitting in the sun, eating beer and drinking hot dogs or the other way around. Kevin Van Heren 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.

[01:34:10] 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.

[01:34:40] But I see changing my password manager password every five 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 one to three random characters to the end. This has the added benefit of slowly making your password longer as well.

[01:35:11] 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.

[01:35:34] With that, it would take 20 days to get back to your original password, which you probably forgot by that anyway. Signed, Kevin Van Heren. Kevin has a point about LastPass and that particular password manager not updating its password protection features. Remember the number of times that the password is hashed before it's used to generate the key.

[01:36:05] 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.

[01:36:28] 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.

[01:36:58] 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.

[01:37:29] 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 YouTube clients, which are leagues ahead of the official one, I might add. So I don't think, quote, and here she's quoting me. So technically, it's an application which accesses a repository.

[01:37:53] 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 Obtainium.

[01:38:22] 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. Yeah. It's been its user for more than a year now and could not be happier. D-Googled mobile OSs are more relevant than ever.

[01:38:50] However, they need more publicity from more sources. 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 club special. So you can watch me turn my hair out. I appreciate the corrections and clarifications. Having myself zero experience with F-Droid, I should have been more careful with my pontificating.

[01:39:19] I'm glad everyone heard what you were able to clarify and add. Many years ago, when I was experimenting with the discontinued Zio sleep tracking headband, I needed to sideload 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.

[01:39:46] So it sounds as though F-Droid is similarly installed, you know, just a simple sideloading. This does bring up the question of the legal status of F-Droid and the open source programs it catalogs.

[01:40:00] If Texas SB 2420 should survive to take effect on January 1st, you know, 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 to the beginning of the year to figure out what they want to do.

[01:40:26] 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 mess. 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.

[01:40:49] 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.

[01:41:06] 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.

[01:41:30] 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.

[01:41:49] Given the inherent difficulty in trusting 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.

[01:42:18] 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 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.

[01:42:46] 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 managers.

[01:43:09] I don't know if CJ is a 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.

[01:43:38] 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.

[01:44:08] 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.

[01:44:35] So this prevents us 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.

[01:44:57] 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.

[01:45:14] 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 has been given to an outside entity. So I guess my reply to CJ would be that I understand and can appreciate his or her points.

[01:45:35] 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.

[01:45:50] 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 and when we really need extra security. Well, changing the password kind of implies that it will somehow be discovered. Correct. Or brute force cracked.

[01:46:21] Exactly. But if your password is long, mine's, I don't know, 30 or 40 characters. Yep. It's not going to be brute force. It's not going to be brute force. No. And I'm not writing it down anywhere. I'm not. 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 mean, I guess I want to give some deference to somebody who is,

[01:46:50] insanely security conscious who wants to, like, over change their password. I would use the word paranoid. Okay. I'm not to, look, of course, it's easy with a password manager. Be my guest. Change it as often as you like. Like, the reason it's a bad advice in a corporation is what we've talked about, which is that people don't use password managers. They just add a number.

[01:47:20] 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. 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. Oh, that's a good point.

[01:47:47] If it's hashed on the browser, then that's a good thing. Right. 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 up from zero, essentially. If you don't change it, it's never being sent in the clear.

[01:48:15] 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're going to have a man in the middle attack. Yeah. 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.

[01:48:44] 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. And if you're worried, go to Have I Been Pwned every once in a while and use their password checker and see if your password's been discovered somehow magically. Yeah. If you need something to do, I don't know. I don't mean to dismiss it.

[01:49:13] CJ, of course, change it as often as you feel like it. 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. 95% 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.

[01:49:41] The rest of you, the 15% should be listening. This is what probably the 50. 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. The term is data resilience. Veeam keeps enterprise businesses running when digital disruptions like ransomware strike.

[01:50:10] 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?

[01:50:39] 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.

[01:51:09] Keep your business running at Veeam.com. That's V-E-E-A-M dot com. 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 Veeam. But if you're in the 85% who thought you were covered and you weren't, Veeam.com. That's all I can say.

[01:51:38] It's a solvable problem. There's no reason to suffer. All right. Back to the show, Steve. They just bought somebody. Somebody just bought them. Yeah. There's a, yeah, there's, I remember reading a story about Veeam. Well, I think maybe they got purchased, but they also purchased somebody in today's podcast. I mean, like in the content here. No. Maybe they bought. Oh, they did. They bought security with an eye. Yes.

[01:52:07] They did. You're right. I'm sorry. Nobody bought them. Veeam acquired or has assigned an agreement to acquire security AI, a data privacy management innovator. 1.7 billion dollars. There was somebody else. I don't know. There's somebody else. I don't think it was Coveware, but it was one of the, something that I was talking about. I saw that they had just been acquired by Veeam. I thought, oh, they're a sponsor. Yeah. Anyway, Nathan Ramsey said, hi, Steve. I believe today.

[01:52:33] Java voluntarily asked me if I wanted to remove it because I had not used it in six months. Yeah. Yeah. I love that. He said, I was so confused, then impressed. Yeah. He said, 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?

[01:53:02] 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.

[01:53:24] 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.

[01:53:52] 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.

[01:54:02] 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.

[01:54:31] 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 iOS asking if you'd like this app to keep tracking you. Apple's iOS recently notified me of some access permissions I had previously given to some app.

[01:55:00] 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's definitely worth it. By the way, you're right. Veeam owns Coveware. Ah, that's what it was. They bought them last year. Yeah.

[01:55:30] Thank you to Paul for finding that. They bought them in April of 2024. And Coveware runs independently. But, yeah, it just shows you. Veeam really has it. They're on it. Our sponsor is on it. Yep. Yep. David Benedict wrote, hi, Steve. Sorry, this is probably like the fifth or sixth email I've sent on this episode. You know, people like pause and then write email. Then they hit continue. Right. But if I don't send the email now, all caps,

[01:55:58] 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. 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.

[01:56:26] 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.

[01:56:54] 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.

[01:57:46] You know, we techies are being derided with a wave of their hands and statements like, well, those techie 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.

[01:58:13] 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.

[01:58:40] 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.

[01:59:01] 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.

[01:59:14] And it seems 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 the standards will emerge from.

[01:59:44] And it's a little dispiriting that 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, OK, 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.

[02:00:12] 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 sent them to me. He wrote Steve. Just a quick note to follow up on your coverage of the updated password verifiers in NIST SP800-63B. The following requirements apply to passwords. And they are.

[02:00:41] 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.

[02:01:11] OK, 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.

[02:01:33] 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. Wow.

[02:02:03] Oh, yeah. 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.

[02:02:31] Seven, verifiers shall not permit the subscriber to store a hint that is accessible to an unauthenticated claimant. Five, 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.

[02:02:58] 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. So, yeah. Anyway, those are- These all seem sensible. Yeah, except unicode. I- Well, I understand. I get it. But- You have to because there's foreign language speakers. Yeah, yeah.

[02:03:28] Unicode is a recipe for disaster. I understand what you're saying. Boy. But you have to. Yeah. Charles finishes saying, 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. Yeah. These all seem sensible, though.

[02:03:57] They seem like they're up to date. They're correct. I think they are 100% workable. I love it that they're requiring 15 characters. And they say you must allow a password longer than 64 because so many bank sites, you know. Oh, yeah. Based on weird backend technology, they're stuck at eight. Right. Yeah. Although I'm not crazy about if you're doing two-factor, it can be as short as eight. But I guess that makes sense.

[02:04:26] It's good. Yeah, it is. And thank you, Charles. Yeah. David Eckerd 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. Oh, good. We will. So, David? Yes. That's a great idea. I will say that it has definitely captivated a large portion of our listeners. And I agree that it would likely make a good twit short.

[02:04:54] Fortunately, our chief twit and company have all just heard your suggestion. And the ball is now in their court. I am sending it off right now. They may have already done that. I don't know. 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. Yeah.

[02:05:17] A frequent writer 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.

[02:05:44] 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, hmm, she's not here. And she locked her computer so I can't help her. At which point, her nearby coworkers immediately said, oh, her password is monkey123!

[02:06:11] 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 seem 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.

[02:06:38] Bad guys might try to use the same password on other accounts they can tie to the user. 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.

[02:07:06] So I thought, hmm, 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.

[02:07:33] Sincerely, Mike Cunningham, Spinrite owner, Club Twit member, watching Leo since ZDTV. Wow. Okay, so Michael, I appreciated 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.

[02:08:00] 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.

[02:08:27] 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.

[02:08:53] 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.

[02:09:22] This is why those NIST guidelines were finally changed. Harassing users for no good reason causes users to hate security. Exactly. And that's not good for anyone. Right. Bingo. Having people upset with and annoyed by their company's IT staff is not only bad politics, it's bad for actual security.

[02:09:49] 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.

[02:10:16] 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.

[02:10:40] 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? That's funny. NIST has just given you permission to be the good guy. Take it. Well done. Well done. That's very good.

[02:11:08] Put that on the refrigerator at work. We're time for our last break, Leo, and we're going to talk about the return of DNS cache poisoning. Oh, man. Is this a propeller hat or not? No. No. Okay, a little bit. A little bit. You know what that means. If Steve says a little bit, you might want to get your propeller hats ready, ladies and gentlemen.

[02:11:36] 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. See, AI, it's a double-edged sword.

[02:12:05] 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 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 all sorts of important data out to the cloud in some unknown repository. Even if you're using private AI, what data are you using for the training?

[02:12:34] 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 fight against. They're using powerful AI agents across all four attack phases. They're using them to discover the attack surface.

[02:12:58] 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 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.

[02:13:26] 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.

[02:13:56] 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 kind of does it all. Ask Stephen Harrison. He's CISO of MGM Resorts International. That's a name that should ring a bell.

[02:14:24] You may remember 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 Stephen 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.

[02:14:54] That's zero trust. Zero trust is a lot of trust. Oh, 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.

[02:15:22] And you can remain resilient even as the threats and risks evolve. Learn more at zscaler.com slash security. That's zscaler.com slash security. And we thank him so much for supporting the good work Steve is doing here at Security Now. Now, let's talk about DNS cash poisoning. I thought we were done with that. I thought it was over.

[02:15:49] 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.

[02:16:13] This was in 2008 that the internet's DNS resolvers were issuing easily predictable queries to upstream more authoritative DNS name servers.

[02:16:27] 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.

[02:16:53] The ancient system upon which the entire internet-dependent 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.

[02:17:18] Since every DNS query returns the remaining cache life of any cached domain, it's like every response tells you how much longer that will be in the cache.

[02:17:31] 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.

[02:17:54] 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.

[02:18:11] But before the upstream authoritative name server, the real one, the authentic one, has had a chance to reply, the attacker themselves supplies their own fraudulent answer to the waiting DNS resolver.

[02:18:28] 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.

[02:18:56] 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,

[02:19:25] 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,

[02:19:42] 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.

[02:20:13] This is why the whole industry went nuts in 2008 and basically created a secret synchronized replacement of all of the buggy DNS servers at the time, fixing them, 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 have at the time in 2008 have been so devastating.

[02:20:41] 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.

[02:21:06] UDP packets are issued from the resolver's 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.

[02:21:24] 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.

[02:21:45] 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 the same remote resolver were given three queries, they would have different ID numbers so that when the three replies came back,

[02:22:14] they could be assigned to the proper waiting outstanding queries. So since the operating systems tended to assign ports in upward consecutive order, they gave it like an outbound query, you know, port 30129, then 30130, 30131, 30132, just consecutive,

[02:22:40] all the way up until they hit 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.

[02:23:05] 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.

[02:23:31] 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?

[02:24:00] 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 16-bit ID was used. They know exactly where that resolver's counters are and the OS counter.

[02:24:26] 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 resolver's cache. This means that a fresh request for that domain's IP will need to be provided by an upstream authoritative name server.

[02:24:52] So the attacker first requests the IP of a domain whose name server they're monitoring. This tells them 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

[02:25:21] and the next successive query ID issued by the resolver's own query software. Then, immediately 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 server's reply.

[02:25:50] 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

[02:26:14] by asking a domain owner to place a specific text record into a domain zone. I've done that many times. That's how I get my certificates. Yep. I've done that many times. Yes. It's how we often... Yeah. Yep. It's like, put this text record in your DNS and then we'll verify you've proven ownership of the domain. And that's how DigiCert verifies my ownership of grc.com.

[02:26:43] 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 resolver's queries to be predictable.

[02:27:05] 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-bit and query IDs are 16-bit, this gives us 32 bits of potential entropy per query. Now, in this day and age, 32 bits isn't very much.

[02:27:34] 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.

[02:28:00] 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.

[02:28:25] 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 slash dns slash dns.htm, that's our spoofability tester. And it literally, it forces the user's resolvers to send GRC a huge number of queries.

[02:28:55] And GRC looks at the source ports and query IDs and charts them on all kinds of grids and scales 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.

[02:29:24] Ars Technica's senior security editor, Dan Gooden, explained the new worries in his piece just last Wednesday, writing,

[02:30:03] And 4780, And 4780 stem from a logic error and, get this, a weakness in generating pseudorandom numbers, respectively. Unbelievable. What year is it, Leo? They each carry a severity rating of 8.6.

[02:30:24] 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.

[02:30:39] The vulnerabilities can be exploited to cause, this is Dan writing, exploited to cause DNS resolvers located inside thousands of organizations to replace valid results for domain lookups with corrupted ones.

[02:30:55] The corrupted results would replace the IP addresses controlled by the domain name operator, for instance, 3.15.119.61 for arstechnica.com, with malicious ones controlled by the attacker. Patches for all three vulnerabilities became available Wednesday.

[02:32:10] Patches for all three vulnerabilities. Peace. Patches for all three vulnerabilities. Patches for all three vulnerabilities.

[02:32:39] 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.

[02:32:52] 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 pseudorandom number generator, the PRNG, that is used, it is possible for an attacker to predict the source port and query.

[02:33:22] That bind will use. Bind can be tricked into caching attacker responses if the spoofing is successful, unquote. And I say to that, unfrigging believable that in 2025 that could be true.

[02:33:40] 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.

[02:34:03] 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.

[02:34:22] 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 Dan finishes, the vulnerabilities nonetheless have the potential to cause harm in some organizations.

[02:34:50] 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 official CVE title for this is, Cash Poisoning Due to Weak PRNG. To which I say, really? What?

[02:35:17] First of all, one of the main topics of discussion throughout the early years of this podcast was the crucial need for high-quality random numbers for cryptography and Internet security in general.

[02:35:34] 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.

[02:35:54] 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.

[02:36:13] 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 pseudorandom number generator, being used by the Internet's most used DNS resolvers, bind and unbound, are weak.

[02:36:41] Well, you really have to shake your head. 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 an unconnected wristwatch or a sports app or something, if you have no access to the rest of the world, it's an embedded thing. It's your dishwasher, your toaster, who knows what.

[02:37:09] 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, it's understandable that they could have trouble generating anything that cannot be predicted.

[02:37:36] 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 lack of, their isolation and lack of having any contact with the world could hardly be any less true for any DNS resolver.

[02:38:01] 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.

[02:38:30] You never know when they're going to come in. So DNS resolvers are continually subjected to a virtual blizzard of entropy. The only way any DNS resolver could possibly be starved of sufficient entropy for collection and use and continually receding its pseudorandom number generator if its designers just really don't care.

[02:38:57] 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 it never had. Yes. No device on any busy network has any business having a weak pseudo-random number generator. It is just unconscionable.

[02:39:26] Now, the other CVE, 4778, whose title is Cash Poisoning Attacks with Unsolicited RRs. Those are resource records. That's interesting, since it suggests that there had been a means until this patch last Wednesday, which both Bind and Unbound were subjected to,

[02:39:49] where an attacker was able to supply unsolicited, which is to say unrequested, DNS replies, resource records, 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 unsolicited resource records could be abused by an attacker.

[02:40:16] 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 look any further. I don't want to know how it could possibly have been bad,

[02:40:40] because they had to try to not accept any additional entropy from the network they're connected to. They probably just used some library, right? Sadly. Sadly, yes. Yeah. They didn't want to write their own. Even TrueCrypt. Remember TrueCrypt back in the day? Yeah. When you were setting up a volume, it said, move your mouse around for a while. Right, right. And there it was. Brilliant.

[02:41:10] A source of unpredictable, no one could ever know how you moved your mouse, and your streaming position data in. And I talked about it. I called it entropy harvesting. It's the first component of the squirrel system I wrote. It harvested entropy from all different sources inside the computer. It's not hard. No. The crazy Intel chips have all these performance counters.

[02:41:37] Branch predictions missed. You know, I mean, how I'm feeling today. I mean, just all this stuff. 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. Yes. 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 use a random number generator.

[02:42:05] 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? So, um, we, we, we start with a, with a CPU that is predictable. Right. Right. Um, so, so if you determine it, if you determine it, it's entirely deterministic.

[02:42:34] So if, so any algorithm given a start, an initial starting state will always do the same thing. Yeah. Well, yeah, it will repeat, uh, hopefully in a long time. But while it's doing that, it may be, but it will be a predictable sequence. The whole sequence is predictable. And so the entire starts the sequence somewhere in the middle of the sequence.

[02:42:59] So, so today's good pseudo random number generators have a pool, what they call it, an entropy pool. And they're mixing this, 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.

[02:43:26] 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. What we're, we're, we're so far away from, uh, from a pseudo random number generator,

[02:43:54] generator being multiply this and add this to get the next number. Right. You know, those were simple minded pseudo random number. They weren't, they are pseudo random number generators, but they're really dumb. So there are, there are, uh, 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. Yeah. It's still deterministic and it can run out of entropy.

[02:44:24] So you need to be, you need to be constantly reseeding it with new entropy. And that keeps it from repeating. I get it. Exactly. And so it just keeps sending it off in different directions. And, and the idea is that, that, that, that the design keeps any short sequence from being predictable. And by the, by the time it might start to be predictable, it's gone off in a different direction.

[02:44:52] So you've receded the, the entropy before, um, it, it was predictable enough to, to, to, to start being useful. The sad thing is, uh, this whole problem with DNS cache poisoning was discovered by, as you mentioned, Dan Kaminsky in 2008, 17 years ago. Right. Uh, so, and what's really sad is Dan, of course, passed away, uh, in 2021.

[02:45:22] We talked to his mom, remember? Um, we interviewed his mom after he passed away. Uh, 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. Yeah. Uh, I were all, he and I were on stage together at one point for the, you had some great stories about him. Yeah. Yeah. And so it's very sad that it's back again, uh, posthumously, but, um, unbelievable.

[02:45:52] 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, well, we got people who like, just ask Dan Bernstein, he's still around. He'll tell you how to do a pseudo random number generators. It's confusing. There are three different Dan's there's Dan Kaminsky who discovered it. Dan Gooden, who did this fabulous writeup.

[02:46:17] He is the security reporter at Ars Technica and is universally great. Everything he writes. Fantastic. Uh, and then Dan Bernstein who knows how to write a pseudo random number generator. Yeah. Well, and, and, and he, he is the, the, the father of the, the primary elliptic crypt, uh, the, the elliptic curve that we're all using. Okay. Yeah. All right. I mean, the guy's really, you know, and he and I co-invented, what do we call it?

[02:46:46] It was a, it was an early DDoS, uh, thing. Uh, he had, he had come up with the idea. Oh, uh, uh, uh, sin cookies. Uh, I, I 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, I used it for windows and he had it over on Linux, I think, or Unix or something. Great. Anyway, crazy world.

[02:47:14] All right, Mr. Gibson, once again, you hit it out of the park, uh, and it didn't take you 18 innings to do it. Although it did take you two hours and 46 minutes, but that's, you know, that's not bad. That's not bad. It's a lot shorter than the way we roll these days. By the way, we did the math, uh, 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,049 shows discourage him, Leo. This is going to be discouraging.

[02:47:42] I had Patrick. The earlier ones are shorter. That's not going to help. It's, it will take you of nonstop listening. 77 days, 23 hours, two minutes and 21 seconds, not including this episode, but you already heard the other hand. On the other hand, when there's no new podcasts coming, what are you going to do? So you're going to turn back the clock. Yeah. Someday we'll be gone to them in reverse order though. You'll hurt yourself. So you need to, you need to start at the beginning.

[02:48:14] Thank you, Mr. G. Steve Gibson's at grc.com. There are many reasons to go there. Of course, his bread and butter spin, right? The world's best mass storage, maintenance, recovery, and performance enhancing utility version six, one, the latest version just came out. You can get a copy right there. Uh, 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.

[02:48:38] You can use like never 10 and decombobulator, shoot the messengers. I'm going way back now. Going way in control. Uh, and soon DNS, uh, the DNS benchmark pro. Um, 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, uh, for this show notes, which you want to get because he does the best show notes I've ever seen.

[02:49:07] I mean, it is how many pages, 18, 19 pages this week. It's quite a few. 23. 23. Okay. And there's links, there's illustrations is it is complete. It is everything you need to know about the show. We just, uh, did, but you can get that ahead of time. Uh, just by subscribing to the mailing list. Now here's what you do. You go to grc.com slash email. The main purpose of that page really was to, to whitelist your email address.

[02:49:34] So you can send Steve things like pictures of the week, like the, what was it? Control alt delete or, or, or comments or suggestions. Um, 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, um, you know, involuntarily subscribe you to anything, but if you want them, you can get that newsletter and you can get the

[02:50:03] 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, uh, benchmark pro. Uh, it's a good, that's a very low traffic email, uh, list and it's a good one to get on, uh, grc.com slash email. There's plenty of other things there, including this show. Steve has, uh, 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.

[02:50:32] 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, uh, 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'd like to read along while you listen or use those transcripts for searching, you can get those there.

[02:50:59] He also has a full fidelity 64 kilobit audio version. Uh, that's grc.com. The show notes are there too for download. If you want to just get it, uh, at any point, uh, after the fact. Now we also have copies of the show at our website, which is twit.tv slash 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. Uh, and then we also have the video because we shoot video of the show.

[02:51:26] 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. Uh, until we get that up on Tik TOK 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. Uh, I presume they are smart enough to play a YouTube video. Most people are, but you never know.

[02:51:55] Uh, 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, uh, 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. Uh, we thank our club members for making this possible. They support, uh, 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,

[02:52:22] twit.tv slash 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. Uh, you can also, and we do a lot of special events in there like our dungeons and dragons we did last week. Um, so join the club to that TV slash club to it. There are coop. There's a coupon on there right now for a 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.

[02:52:51] So don't wait, go there to get that. There's also two week free trial, a variety of other things. Twit.tv slash club to it. We do stream the show live. If you want the freshest version, uh, we do it, uh, every Tuesday, right after Mac break weekly. That's usually around one 30 Pacific four 30 Eastern. And now here comes the propeller head part of my day because we are on Pacific daylight

[02:53:17] time, but next week will be on Pacific standard time because we're setting our clocks back spring forward, fall back. That means it's going to still be one 30 PM Pacific four 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.

[02:53:48] UTC. Wouldn't UTC be universal time coordinated. 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.

[02:54:16] 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. You, we used to call it Greenwich meantime and see, that's the problem is no, is the French and 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?

[02:54:45] 1930 UTC. Yes. Cause we, cause we're going to set our clocks back in the, during the weekend. Well, you're not, they're going to set themselves back apparently. Well, all but that one in the microwave. Yeah. 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 got to wind them. You got to wind them, Leo. If you don't wind them after a couple of days, they just stop swinging. That's right.

[02:55:16] So our, our, our, our closing advice here is adopt the NIST guidelines and be invited to parties. I forgot the party part. And, and, and. Oh, you will be invited to parties. But if you don't. You'll be. That's right. You won't. That's right. Carrot in the stick, baby. Thank you, Steve. Have a great week. We'll see you next time. See you in November.