Security Now 1069 transcript

Please be advised this transcript is AI-generated and may not be word for word. Time codes refer to the approximate times in the ad-supported version of the show.

Leo Laporte [00:00:00]:
It's time for Security Now. Steve Gibson is here. We've got a lot of really interesting conversations. How Mozilla used Claude to improve its security. Why you might be— want to be extra careful about OpenClaw. Wow. It opens a great big hole into your network with a remote takeover. And we're going to talk about a new capability for LLMs that might scare you just a little bit.

Leo Laporte [00:00:28]:
All of that coming up next. Security Now.

TWiT.tv [00:00:33]:
Podcasts you love from people you trust.

Leo Laporte [00:00:38]:
This is TWiT. This is Security Now with Steve Gibson, episode 1069, recorded Tuesday, March 10th, 2026. You can't hide from LLMs. It's time for For Security Now. Oh yes, you wait all week for Tuesday and I'm glad to be back. Steve is back and we're ready to talk security with this guy right here, Steve Gibson of GRC. Hey Steve, it's good to see you. We had such fun in Florida at Zero Trust World.

Leo Laporte [00:01:12]:
It was so fun to get to spend some time with you and Lori and have a couple of dinners together and stuff.

Steve Gibson [00:01:18]:
Yeah, meet some of our listeners. That was fun too.

Leo Laporte [00:01:21]:
Oh man, we met some really interesting. People. I don't know if I'm at liberty to divulge some of these people, pretty high-up people.

Steve Gibson [00:01:32]:
It's not really a selfie line, is it, if somebody else is taking the picture?

Leo Laporte [00:01:36]:
It's kind of a selfie line. Yeah, we took about, I don't know, 50, 60, maybe 100 pictures. It went on for an hour and a half, and everybody got to see— I talked to everybody.

Steve Gibson [00:01:45]:
I got to sign some Spinrite CDs and, and, uh, and floppy disks.

Leo Laporte [00:01:51]:
Guy brought his dad's— this was— that was hysterical— his dad's Spinrite floppy for you to sign.

Steve Gibson [00:01:59]:
And that pristine Mac. And he's— I mean, it was gorgeous. And he hands me a Sharpie and says, I want you to sign my Mac. I said, this is indelible. And he said, yeah, and I'm, I'm, I'm, I'm gonna cover it. I'm gonna spray it with a fixer sealant afterwards. And I said, you're sure? I mean, you're really sure you want me to sign this? He says, oh yeah.

Leo Laporte [00:02:23]:
Oh yeah. Here's Steve signing a dad's Spinrite floppy. That was pretty fun. Really, really fun. Talked to one guy who was in charge of data exfiltration. He was a contractor with the US government, but he was in country in Was it Iraq or Afghanistan? I can't remember which. Afghanistan. Yeah.

Leo Laporte [00:02:47]:
And this was a great story. Can I tell it or are you going to talk about it later? Because it's a Spinrite story. No, go ahead. He said we had, what was it, 3 or 4 PCs running Spinrite. We would get these drives that had been used by—

Steve Gibson [00:03:03]:
Recovered from the field.

Leo Laporte [00:03:05]:
Like the Taliban. And first thing we'd do is we'd run Spinrite on them. Probably they imaged them first and then they would run Spinrite on them to recover the data. I mean, that's pretty, Steve, that's pretty cool. That's pretty, pretty cool.

Steve Gibson [00:03:21]:
Well, Spinrite was up in space. There is a copy on the space station. The ISS has it. Yeah.

Leo Laporte [00:03:28]:
I didn't know that.

Steve Gibson [00:03:29]:
Oh yeah, they use it all the time apparently for, you know, those pesky neutrons. They'll mess up your magnetic domains. And so, Spins right, puts them back where they're supposed to be.

Leo Laporte [00:03:40]:
We had a story this week that somebody did some instrumentation of Firefox. 10% of Firefox crashes and failures came from bit flips. And non-ECC RAM, bit flips in the RAM. This happens more often than you think. And that's often because cosmic rays are striking your RAM.

Steve Gibson [00:04:03]:
Yep.

Leo Laporte [00:04:03]:
What a world. It's amazing this stuff works, but it doesn't always. And that's when it doesn't, that's why Steve is here. What's coming up this week?

Steve Gibson [00:04:13]:
So there was a really interesting story which maybe in retrospect shouldn't be too surprising, but I wanted to put it on everyone's map, which is that, uh, our, our ETH Zurich folks with some help from the Anthropic people did a study which demonstrated how small a sample of public internet postings are needed, uh, in order to de-pseudonymize people. So, you know, it's like if you read something someone writes, or like, and it's like, well, this really sounds like this person or that person. Turns out LLMs are astonishingly good at picking up nuances of word choice and, and, uh, you know, writing style, and are able to, with a great deal of power, de-anonymize. So today's topic title is "You Can't Hide from LLMs," and we'll be looking at that research at the end for our episode 1069 for this 10th of March, 2026. But we're going to look at another— boy, Leo, Anthropic is really coming on strong. You know, OpenAI was kind of like got out of the gate first, but I'm really impressed with everything that we're seeing from Anthropic.

Leo Laporte [00:05:45]:
Claude Code, every time I use it, it blows me away. It's like, wow, you're smart.

Steve Gibson [00:05:51]:
So Anthropic teamed up with Mozilla and decided to take a close look at Firefox's security. We're going to look at what they found. Apple and Google are finally looking at cross-platform RCS encryption, which hasn't existed before. Ubuntu's sudo command behavior just changed, and I thought that was sort of interesting. Also, I'm not sure you want to be inviting a web proxy into your home. Turns out a surprising number of people have. Either wittingly or unwittingly. Uh, Apple devices were studied by Germany and something happened.

Steve Gibson [00:06:33]:
Uh, we've also got some researchers discovered a very serious remote takeover of OpenClaw, which immediately came to the attention of the OpenClaw guys and they fixed it. But the problem is really interesting because we've just been talking about these sorts of problems in the last few weeks. TikTok made a decision about their encryption of messaging. I just threw something in that really wasn't security-related, and I almost took it out, but I made— I created the show notes in a PDF before I had deleted that, so I thought, okay, I'll just leave it in, which is Microsoft banning a derogatory term relating to them from their Discord server. And frankly, I've been surprised that they leave GitHub as alone as they do because all kinds of, you know, anti-Microsoft stuff is there. But it's— they have a hands-off policy. Not so their Discord server, although it could have just been, you know, an aberrant employee. So we also got a bunch of really great listener feedback that we're going to spend some time on, and then we're going to look at how LLMs Could make Orwell's 1984 seem optimistic.

Leo Laporte [00:07:50]:
Oh boy.

Steve Gibson [00:07:51]:
Yeah.

Leo Laporte [00:07:53]:
Oh boy.

Steve Gibson [00:07:54]:
And of course, a listener-provided picture of the week that we're going to have some fun with. So I think another great podcast for us.

Leo Laporte [00:08:03]:
All right. Well, we'll get to the meat of the matter in just a bit, but first a word from our sponsor. We'd like to start by telling you about our fine sponsors, in this case, when you ought to be using Bitwarden, the trusted leader in passwords, passkeys. They even do secrets management. Bitwarden added a few months ago the ability to generate, store, and even regurgitate your SSH keys, which makes it so much easier for me to do SSH logins securely. Just one of many ways Bitwarden just gets better all the time. Bitwarden's consistently ranked number one in user satisfaction by G2 and Software Reviews. They have 10 million users across 180 countries.

Leo Laporte [00:08:47]:
This might surprise you though, more than 50,000 businesses use Bitwarden. I mean, we know Bitwarden is great for individuals, but it's also great for business. So whether you're protecting your personal account or thousands of accounts at work, Bitwarden will keep you secure all year long. Constant updates, always improving. That's one of the things I love about them, partly because they're open source. I think that's one of the reasons lots of great contributors helping Bitwarden get better all the time. For instance, the new Bitwarden Access Intelligence. This is for business.

Leo Laporte [00:09:19]:
Organizations can use it to detect weak, reused, or exposed credentials and then immediately guide remediation, getting your employee to fix those risky passwords, replace them. With strong unique ones. And that is a big, as you know, a big security problem. Credentials are probably the top cause, certainly one of the top 1 or 2 causes of breaches. But with access intelligence, they become visible, prioritized, and corrected before exploitation can occur. The other thing I love about this is Bitwarden, this is for enterprise, but they also do the same thing for you in your personal vault. So if you have weak passwords, it'll tell you it'll help you fix it. You know, it helps you do the right thing.

Leo Laporte [00:10:02]:
It helps you become more secure. Oh, here's something else they just added. Bitwarden Lite. Bitwarden Lite is a lightweight, self-hosted password manager. This is great for home labs, personal projects, any environment that wants quick setup with minimal overhead. Great for geeks like us who just want to trust no one and do it all by ourselves. Bitwarden Lite. The real-time vault health alerts and password coaching features help you be more secure, help your family members, friends.

Leo Laporte [00:10:30]:
This is why you should tell everybody, because, you know, I know you use a password manager, but I also know most of the people in our lives don't, and they don't really understand how much at risk that, that puts them. Get them to use Bitwarden. They can strengthen their security instantly. They have— oh, you know, some people I would bet who aren't using password managers do use their browsers, right? The passwords. But that's not convenient. It's, it's in your browser. It's not on your phone, or it's in your phone. It's not in your desktop.

Leo Laporte [00:10:59]:
Now Bitwarden will support direct import from the browsers, from Chrome, Edge, Brave, Opera, and Vivaldi. Direct import literally copies the credentials from the browser into the encrypted vault without that separate plaintext export, which always makes me a little bit nervous. That only not— not only simplifies migration, it reduces exposure associated with manual export and deletion steps. You got to remember to delete that cleartext passwords that sit on your hard drive. Makes me very nervous to have that. Not anymore. Just take it. And this way, your, your family and friends can move from their browser's password store, which is not as good, not as convenient, into something that really works.

Leo Laporte [00:11:37]:
G2 winner 2025 says Bitwarden continues to hold strong as number 1 according to G2. Number 1 in every enterprise category. No, in every enterprise category. That's for 6 straight quarters too. Bitwarden setup is easy. Steve and I moved very quickly from our old password manager to our new one a few years ago when we decided enough was enough. We wanted to use Bitwarden. It supports importing from most password management solutions.

Leo Laporte [00:12:04]:
And because it's open source, you can look at the code. It's on GitHub. It's GPL licensed. It's regularly audited by third-party experts. And it meets SOC 2 Type 2, GDPR, HIPAA, CCPA standards. It's ISO 27001:2002 certified. Look, for your business, get started today with a free trial of Bitwarden Teams or Enterprise, or get started for free forever across all devices as an individual at bitwarden.com/twit. Bitwarden.com/twit.

Leo Laporte [00:12:39]:
Unlimited passwords, unlimited devices. It even supports passkeys, hardware keys, all for free. Bitwarden.com/twit. It's what I use. It's what I tell everybody to use. Highly recommend it. bitwarden.com/twit. And now the picture of the week.

Steve Gibson [00:13:02]:
So this is a great picture, and I just gave it the caption simply, you know, because otherwise it would not be clear.

Leo Laporte [00:13:12]:
I'm scrolling up to see.

Steve Gibson [00:13:14]:
It will make sense in context.

Leo Laporte [00:13:20]:
Okay, yeah, you need that sign, otherwise it would not be clear.

Steve Gibson [00:13:24]:
Yeah, but, but, you know, okay, so first of all, what we, what we have is a sidewalk which comes to an abrupt end, and I'm not exactly sure how this happened. Like, you know, there's a, like, two phone poles and some guy wires and a weird rusted fence kind of down below it. So did the sidewalk come later and they didn't plan ahead?

Leo Laporte [00:13:51]:
Walk right up to that obstruction.

Steve Gibson [00:13:53]:
I just don't understand, like, how this happened. But the other thing, Leo, so, so again, I, I got myself off, off track. We have a, a big bolted-down inverted U ending you know, like blockade at the end of a— where a sidewalk ends that kind of goes off of a short little cliff down to a lower level.

Leo Laporte [00:14:19]:
That's probably good if you're walking that sidewalk, it's pitch black out, it's at night, you don't know that the sidewalk's going to end, you would run into that without going off.

Steve Gibson [00:14:27]:
True.

Leo Laporte [00:14:27]:
Then you wouldn't be able to read the sign.

Steve Gibson [00:14:29]:
Nor would you need the sign.

Leo Laporte [00:14:34]:
You kind of know.

Steve Gibson [00:14:34]:
Arguably. And Leo, Which brings me to the sign. Like, clearly this barricade was officially installed, right? You can see it's got bolts down into concrete. It was like done. They also stuck some rectangular reflective striping on the two verticals and across the horizontal.

Leo Laporte [00:14:58]:
You're not going to miss it.

Steve Gibson [00:15:00]:
Where did this sign come from?

Leo Laporte [00:15:01]:
It's tied on.

Steve Gibson [00:15:03]:
And it's like cockeyed and not centered. And it's like, What?

Leo Laporte [00:15:09]:
Like, it's literally zip-tied onto this nice solid device. That's crazy.

Steve Gibson [00:15:16]:
And not like one is like the upper right corner is hooked to the top. And there, I don't know.

Leo Laporte [00:15:23]:
It's completely whopper jawed. Yeah. Yeah.

Steve Gibson [00:15:26]:
That's exactly right. Anyway, thanks again to our listeners for providing us with some entertainment every week.

Leo Laporte [00:15:32]:
Yes, indeed.

Steve Gibson [00:15:35]:
Anthropic and Mozilla have teamed up to provide us with some more security, specifically for Firefox. They posted to their site last Friday under the headline, "Partnering with Mozilla to Improve Firefox's Security," which those of us who have stuck with Firefox appreciate. Anthropic wrote, "AI models can now independently identify high-severity vulnerabilities in complex software. As we recently documented, we talked about this previously, Cloud found more than 500 zero-day vulnerabilities, which they clarify as security flaws that are unknown to the software's maintainers, in well-tested open-source software. And as we know, OpenSSL was one of those targets, which, and that thing has been scrutinized like crazy because its security is so important. They said, in this post, we share details of a collaboration with researchers at Mozilla in which Claude Opus 4.6 discovered 22 vulnerabilities over the course of 2 weeks. Of these, Mozilla assigned 14— Mozilla themselves assigned 14 of those 22 as high severity vulnerabilities, almost a fifth of all high-severity Firefox vulnerabilities that were remediated in 2025. In other words, AI is making it possible to detect severe security vulnerabilities at highly accelerated speeds.

Steve Gibson [00:17:15]:
And of course, this is one of the things that we talked about last year as this began to emerge. We said, okay, AI is gonna have an effect on software security.

Leo Laporte [00:17:28]:
And, and what's good is it's a positive effect. I mean, I think there was some concern it might add more vulnerabilities.

Steve Gibson [00:17:34]:
Yes. And actually we're, we're gonna get to that later in this post. They talk about the relative strength of AI for doing good versus doing bad.

Leo Laporte [00:17:45]:
Mm-hmm.

Steve Gibson [00:17:45]:
And it turns out the good guys have an advantage here for some reason. So you've got the infographic on the screen. This shows all of 2025 and January. And then this, this just this previous month of February 2026, what the vulnerability level and classifications were found in Firefox by month. They said, as part of this collaboration, Mozilla fielded a large number of reports from us. Helped us understand what types of findings warranted submitting a bug report, and shipped fixes to hundreds of millions of users in Firefox 148. Their partnership and the technical lessons we learned provides a model for how AI-enabled security researchers and maintainers can work together to meet this moment. So I would argue we're still in the early stages of the deployment of AI to improve our existing software installed base, but it is clearly going to happen.

Steve Gibson [00:18:53]:
They said in late 2025, we noticed that Opus 4.5 was close to solving all tasks in CyberGym, G-Y-M, a benchmark that tests whether LLMs can reproduce known security vulnerabilities. So they're saying 4.5 was close to solving all tasks where LLMs are able or are being tested to see whether they can reproduce known security vulnerabilities, like, you know, independently find them. They said we wanted to construct a harder and more realistic evaluation that contained a higher concentration of technically complex vulnerabilities. And again, Mozilla and Firefox heavily scrutinized field-tested, you know, long-term, uh, critical security targets. So this, so this makes so much sense for them to test. They said technically complex vulnerabilities like those present in modern web browsers. So we built a data set of prior Firefox common vulnerabilities and exposures, CVEs, to see if Claude could reproduce those. We chose Firefox because it's both a complex code base and one of the most well-tested and secure open-source projects in the world.

Steve Gibson [00:20:17]:
This makes it a harder test for AI's ability to find novel, you know, new security vulnerabilities than the open-source software we previously used to test our models. Hundreds of millions of users rely on Firefox daily, and browser vulnerabilities are particularly dangerous because users routinely encounter untrusted content and depend on the browser to keep them safe. Or as we're often saying here on the podcast, it is the— it is our internet-facing surface, and so it needs to be as bulletproof as possible. They said our first step was to use Claude to find previously identified CVEs in older versions of the Firefox codebase, right? So they're going back to test it, like, what, what, what is it able to do that we already know? They said, we were surprised that Opus 4.6 could reproduce a high percentage of these historical CVEs, given that each of them took significant human effort to uncover. But it was still unclear how much we should trust this result because it was possible that at least some of these historical CVEs were already in Claude's training data. That's— I think that's a very good point. So, you know, being, being retrospective has some value. Prospection is what we need, they said.

Steve Gibson [00:21:49]:
So we tasked Claude with finding novel vulnerabilities in the current version of Firefox bugs that by definition cannot have been reported before. We focused first on Firefox's JavaScript engine— good— but then expanded to other areas of the browser. The JavaScript engine was a convenient first step. It's an independent slice of Firefox's codebase that could be analyzed in isolation, and it's particularly important to secure given its wide attack surface. It processes untrusted external code when users browse the web. After just 20 minutes of exploration, Claude Opus 4.6 reported that it had identified a use-after-free, they say, a type of memory vulnerability that could allow attackers to overwrite data with arbitrary malicious content in the JavaScript engine. One of our researchers validated this bug in an independent virtual machine with the latest Firefox release, then forwarded it to two other Anthropic researchers who also validated the bug. We then filed a bug report in Bugzilla, Mozilla's issue tracker, along with a description of the vulnerability and a proposed patch written by Claude and validated by the reporting team to help triage the root cause.

Steve Gibson [00:23:20]:
In the time it took us to evaluate and submit this first vulnerability to Firefox, Claude had already discovered 50— 5-0— 50 more unique crashing inputs while we were triaging these crashes.

Leo Laporte [00:23:39]:
A—

Steve Gibson [00:23:39]:
because remember, a crash indicates that something went wrong, shouldn't have crashed. Can we weaponize the source of that crash into doing something that the bad guys want? So 50 more unique crashing inputs, they said. While we were triaging these crashes, a researcher from Mozilla reached out to us. After a technical discussion about our respective processes and sharing a few more vulnerabilities we had manually validated, They encouraged us to submit all of our findings in bulk without validating each one, even if we weren't confident that all of the crashing tests had security implications. By the end of this effort, we had scanned nearly 6,000 C++ files and submitted a total of 112 unique reports, including the high and moderate severity vulnerabilities mentioned above. Most issues have been fixed in Firefox 148, but the remainder to be fixed— but the remainder— well, sorry, with the remainder to be fixed in upcoming releases. When doing this kind of bug hunting in external software, we're always conscious of the fact that we may have missed something critical about the code base that would make the discovery a false positive. We tried to do the due diligence of validating the bugs ourselves, but there's always room for error.

Steve Gibson [00:25:14]:
We're extremely appreciative of Mozilla for being so transparent about their triage process and for helping us adjust our approach to ensure we only submitted test cases they cared about, even if not all of them ended up being relevant to security. Mozilla researchers have since started experimenting with Claude for security purposes internally. So then in their section, from identifying vulnerabilities to writing primitive exploits, they said to measure the upper limits of Claude's cybersecurity abilities, we also developed a new evaluation to determine whether Claude was able to exploit any of the bugs we discovered. In other words, we wanted to understand whether Claude could also develop the sorts of tools that a hacker would use to take advantage of these bugs to execute malicious code. To do this, we gave Claude access to the vulnerabilities we had submitted to Mozilla and asked Claude to, to create an exploit focused on each one. To prove it had successfully exploited a vulnerability, we asked Claude to demonstrate a real attack. Specifically, we required it to read and write a local file in a target system as an attacker would. We ran this test several hundred times with different starting points, spending approximately $4,000 in API credits.

Steve Gibson [00:26:55]:
Despite this, Opus 4.6 was only able to actually turn the vulnerability into an exploit in two cases. Still, you spend $4,000 and you get two opportunities to read and write files on the victim's machine. That's worth four grand to attackers and then some. They said despite this, Opus 4.6, um, oh yeah, was only able to actually turn the vulnerability into an exploit in 2 cases. They, they said this tells us 2 things. 1, Claude is much better at finding these bugs than it is at exploiting them. So that's one of our data points, right? 2, the cost of identifying vulnerabilities is an order of magnitude cheaper than creating an exploit for them. However, the fact that Claude could succeed at automatically developing a crude browser exploit, even if only in a few cases, is a concern.

Steve Gibson [00:28:01]:
Crude is an important caveat here, they wrote. The exploits Claude wrote only worked on our testing environment, which intentionally removed some of the security features found in modern browsers. This includes, most importantly, the sandbox, the purpose of which is to reduce the impact of these types of vulnerabilities. Thus, Firefox's defense in depth would have been effective at mitigating the— even those two particular exploits. But vulnerabilities that escape the sandbox are not unheard of, and Claude's attack is, is one necessary component of an end-to-end exploit. You can read more about how Claude developed one of these Firefox exploits on our Frontier Red Team blog. They said these early signs of AI-enabled exploit development underscore the importance of accelerating the find and fix process for defenders. In other words, we don't have any time to waste here, folks, because AI is getting good for everyone, and the bad guys, well, we already know they are using it.

Steve Gibson [00:29:13]:
They said, towards that end, we want to share a few technical and procedural best practices we found while performing this analysis. First, when researching patching agents which use LLMs to develop and validate bug fixes, we've developed a few methods we hope will help maintainers use LLMs like Claude to triage and address security reports faster. In our experience, Claude works best when it's able to check its own work with another tool. We refer to this class of tool as a task verifier, a trusted method of confirming whether an AI agent's output actually achieves its goal. Task verifiers give the agent real-time feedback as it explores a codebase, allowing it to iterate deeply until it succeeds. Task verifiers helped us discover the Firefox vulnerabilities described above, and in separate research, we found that they're also useful for fixing bugs. A good patching agent needs to verify at least two things. That the vulnerability has actually been removed and that the program's intended functionality has not been changed.

Steve Gibson [00:30:32]:
It's been preserved. In our work, we built tools that automatically tested whether the original bug could still be triggered after a proposed fix and separately ran test suites to catch regressions, which is a change that accidentally breaks something else. We expect maintainers will know best how to build these verifiers for their own code bases. The key point is that giving the agent a reliable way to check both of these properties dramatically improves the quality of its output. Right, again, you don't— we know we've had reports, right, of careless AI agents spewing out bug reports, you know, inundating HackerOne and similar bounties with bogus, you know, AI slop. So this is certainly an issue. They said, we can't guarantee that all agent-generated patches that pass these tests are good enough to merge immediately, but task verifiers give us increased confidence that the produced patch will fix the specific vulnerability while preserving program functionality and therefore achieve what's considered to be the minimum requirement for a plausible patch. Of course, when reviewing AI-authored patches, we recommend that maintainers apply the same scrutiny they'd apply to any other patch created by an external auditor.

Steve Gibson [00:31:59]:
And, you know, they told us that the moment they started talking to Mozilla about this, the Mozilla guy said, give us everything you have. You found 50 ways to crash our JavaScript engine. We want them. You know, please, you know, we'll take responsibility for them. So Anthropic said, zooming out to the process of submitting bugs and patches, we know that maintainers are underwater. Therefore, our approach is to give maintainers the information they need to trust and verify reports. The Firefox team highlighted three components of our submissions that were key for trusting our results. First, accompanying minimal test cases, that is providing a minimal test case, detailed proof of concept, and candidate patches.

Steve Gibson [00:32:54]:
Those are the three things that Mozilla wanted. They said, we strongly encourage researchers who use LLM-powered vulnerability research tools to include similar evidence of verification and reproducibility when submitting bug reports based on the output of such tooling. So here we have Anthropic being essentially responsible, right? They're saying, we've created an AI system. People have jumped on it and they're using it. In some cases, they're not being as responsible with their use as they should be. So You know, we tried this ourselves. Here's what we learned. Please, everybody, we're happy to have you use Claude or whatever, but, you know, be respectful of the burden this is putting on maintainers.

Steve Gibson [00:33:45]:
So they said, we strongly encourage researchers who use LLM-powered vulnerability research tools to include similar evidence of verification and reproducibility when submitting reports based on the output of AI tooling. We also published our Coordinated Vulnerability Disclosure, you know, CVD operating principles, where we describe the procedures we will use when report— when working with maintainers. Our processes here follow standard industry norms for the time being, but as models improve, we may need to adjust our processes to keep pace with capabilities. Frontier language models are now world-class vulnerability researchers. I think we can say based on this report and their results, that statement is not hyperbole. Frontier language models are now world-class vulnerability researchers. On top of the 22 CVEs we identified in Firefox, We've used Claude Opus 4.6 to discover vulnerabilities in other important software projects like the Linux kernel. Over the coming weeks and months, we will continue to report on how we're using our models and working with the open source community to improve security.

Steve Gibson [00:35:11]:
Opus 4.6 is currently, and here it is, Leo, far better at identifying and fixing vulnerabilities than at exploiting them, which is really interesting. They said this gives defenders the advantage. And with the recent release, because, for example, it found 50 ways to crash the JavaScript engine but was only able to exploit 2 of those itself, whereas Mozilla found 22 instances where that generated a security-relevant CVE. So Claude wasn't as good at finding and exploiting as it was at locating where there was a problem. So they said, um, uh, Opus 4.6, right, far better at identifying. And with the recent release of Claude Code Security In limited research preview, so there's now something called Cloud Code Security, we're bringing vulnerability discovery and patching capabilities directly to customers and open source maintainers. To anybody listening, and Leo, we know that we have at least one listener who is now earning full-time income bug hunting. We met him in Florida.

Steve Gibson [00:36:38]:
During the zero-trust world.

Leo Laporte [00:36:40]:
It's a full-time job. Yeah, yeah.

Steve Gibson [00:36:42]:
Yes. And so I would say to any of our listeners, and we've talked about how, you know, bounties and collecting bounties can be great income on the side. I would argue if you're not using AI, get on it, because that's where this has all moved into, AI, over the last couple of months. They said, looking at the rate of progress, it's unlikely that the gap between frontier models' vulnerability discovery and exploitation abilities will last very long, which is to say right now, better at finding vulnerabilities than exploiting them. But they're saying they expect the exploitation side to catch up. They said if and when future language models break through this exploitation barrier, we will need to consider additional safeguards or other actions to prevent our models— good luck with this— from being misused by malicious actors. And I argue, yeah, good luck. These things cannot be controlled.

Steve Gibson [00:37:50]:
They finish saying, we urge developers to take advantage of this window to redouble their efforts to make their software more secure. For our part, we plan to significantly expand our cybersecurity efforts, including by working with developers to search for vulnerabilities following the CVD process outlined above, developing tools to help maintainers triage bug reports, and directly proposing patches. I think it's very clear that they said with the recent release of Cloud Code Security, well, we know how they developed Cloud Code Security, right? It was this effort and the Linux kernel and OpenSSL. Those things that they have shared and talked about, that those were the work that they did using open source as their, tooling verifier and, and, and fine-tuning to create this next Claude Code Security, uh, product, which is currently in limited research, uh, preview. So anyway, I, I think that's terrific work, uh, and, you know, and their documentation of it speaks for itself. Uh, no one should doubt the degree to which AI has is and will be changing the landscape for security research. I mean, it's here already, uh, vulnerability discovery and eventually vulnerability exploitation. Uh, it's really encouraging to hear that in their testing, Opus 4.6 was, in their exact words, currently far better at identifying and fixing vulnerabilities than exploiting them.

Steve Gibson [00:39:38]:
But as they said, don't count on that. To last forever. So I think, Leo, that what will happen is obviously there's a huge base of software not open source, so not nearly as, um, as available to research like this. That means that the owners of proprietary source will need to be deploying things like cloud code security themselves to find zero days in their own code. And it's just going to become what you do now. Basically, AI is going to be the way you check your code before its release. And we already saw the Mozilla guys saying, we think we're going to be doing that from now on because you just found 50 problems that we weren't aware of, uh, you know, for 4 grand. So who would not do that?

Leo Laporte [00:40:40]:
Claude just added the ability to do that, to automatically do a security check of your code. I mean, it's, it's really such a great tool. It doesn't replace the human, you, you know, you really want to be the human in the loop, but it is such a great tool.

Steve Gibson [00:40:55]:
I can't— and as far as testing the security of an existing proprietary software base. You know, open source means it's publicly open, but everybody has their own source that they can run Claude against in order to verify that it is, you know, it's doing or isn't what they think. And I agree, Leo. I mean, so I guess the point here is we, it is, we are no more We're no longer talking about the future as regards to AI and its impact on security. It has arrived. Mozilla said, what? And immediately started using it themselves. And everybody else should be doing the same thing because the bad guys are going to. And AI is only going to get better.

Steve Gibson [00:41:47]:
And so if you haven't cleaned your code, of exploitable vulnerabilities, by the time, you know, a few generations from now AI catches up on the exploitation side, you'll wish you had. Wow.

Leo Laporte [00:42:01]:
And it's a great— it's a great fun toy to play with too, I have to say. It really is. It's kind of amazing. It's, it's an experience everyone should have if you've done any coding at all. Just to see it do that is, is mind, mind-blowing.

Steve Gibson [00:42:16]:
Well, it's like, it's like, it's the equivalent of the experience we initially had a couple of years ago when the thing started talking. It's like, oh my, what?

Leo Laporte [00:42:24]:
What? Yeah. Yeah. That's gone way beyond that though. That's the nice thing about Claude. It's got a great personality. You really enjoy spending time with it. Okay. I'm embarrassed.

Leo Laporte [00:42:36]:
My good buddy.

Steve Gibson [00:42:39]:
Um, I, I, I met some lore of my wife's friends when we were in Florida. And it turns out both of them, the husband and wife in one couple, are heavy AI users. So I spent a lot of time talking to them. Like, I mean, like one of them was like confessed that he was getting a little too involved with, I mean, like with the personality of this.

Leo Laporte [00:43:06]:
Yes, that's a problem. You got to remember it's a machine, that it's code. You're interacting with code. Which I don't have that much trouble doing, but give me time.

Steve Gibson [00:43:19]:
Yeah.

Leo Laporte [00:43:19]:
One of the things I loved at Zero Trust World, I went to one of— they have a lot of hands-on labs at this ThreatLocker conference we were at last week, and they did one on web hacking or whatever. But what they really emphasized was how to report a bug when you find it, how to make the minimal possible code to to trigger the flaw, how to make it reproducible, all of that. And I really liked it that they focused on that, that if you're gonna find a bug, this is how you report it. This is how you effectively report it. It sounds like that's what Claude's doing, which is cool. That's really neat.

Steve Gibson [00:43:54]:
Yeah, yeah. Break time. I know you have some calls.

Leo Laporte [00:43:58]:
Oh, time for me to go to work. Okay. I was thinking maybe that was the case. Our show today, we'll have more with Steve in just a bit. Glad you're here. Hope you enjoy Security Now. We met so many great people who are fans of the show. Yeah, thank you for joining us out there in Florida.

Leo Laporte [00:44:16]:
It was really, really a lot of fun. Our show today brought to you by Zscaler, the world's largest cloud security platform. Now, just talking about AI, and it's obvious if you're a business, you're thinking about it, right? You're saying, you know, how do I incorporate AI into our business? The potential rewards are, are really too great to ignore. But don't forget the risks. There are some significant issues, uh, chief among them loss of sensitive data and attacks against enterprise-managed AI. Generative AI increases opportunities for threat actors too, helping them to rapidly create phishing lures, write malicious code, automate data extraction. So AI is a double-edged sword— great for your business, but there are downsides. There were 1.3 million instances of, for instance, of Social Security numbers leaked accidentally to AI applications.

Leo Laporte [00:45:16]:
I almost caught myself doing that the other day. You know, I thought, well, I got my tax return. I have all my tax returns the last 5 years. Why don't I just feed those to the AI and get some analysis? And then I thought, well, wait a minute, I better redact that Social Security number. ChatGPT and Microsoft Copilot saw nearly 3.2 million data violations last year. So your employees are using these tools, but are they thinking about security? It, maybe it's time to rethink your organization's safe use of public and private AI. That's what Chad Pallett did. He's the acting CISO at BioIVT.

Leo Laporte [00:45:55]:
They chose Zscaler. He says Zscaler helped them reduce their cyber premiums by 50% and double their coverage. And improve their controls. Take a look at this great video from Chad. With Zscaler, as long as you've got internet, you're good to go.

Steve Gibson [00:46:13]:
A big part of the reason that we moved to a consolidated solution away from SD-WAN and VPN is to eliminate that lateral opportunity that people had and that opportunity for misdirection or open access to the network. It also was an opportunity for us to maintain and provide our remote users with a cafe-style environment.

Leo Laporte [00:46:35]:
Thank you, Chad. With Zscaler Zero Trust plus AI, you can safely adopt generative AI and private AI to boost productivity across your business. Their Zero Trust architecture plus AI helps you reduce the risks of AI-related data loss and protects against AI attacks to guarantee greater productivity. And compliance. Learn more at zscaler.com/security. That's zscaler.com/security. We thank them so much for supporting Security Now and the important work Steve is doing here. On we go with the show, Steve.

Steve Gibson [00:47:12]:
So we've talked through the years about the slow progress of RCS replacing SMS and MMS for secure messaging. At least that's the promise. And, you know, and giving us many more features, features reminiscent of what iMessage has had over on the Apple platform. So Apple and Google recently announced that testing of cross-platform, that is Apple to Android, RCS messaging encryption would be beginning soon. As we know, until now iMessages have always been encrypted within the Apple ecosystem, and similarly, uh, Google's Android-to-Android messaging used their own internal encrypted RCS. But any cross-platform messaging was still, until now, forced to fall back to unencrypted RCS. So this will first appear for iPhone users with the next point release to 26.4. Uh, we're currently at 26.3.1, which was— there was just a recent update adding the 0.1 to 23— to 26.3.

Steve Gibson [00:48:28]:
So most of us are not going to see this yet until we get to 26.4, but beta testers who have 26.4 beta 2 and are using a supported carrier will see their traditional green bubbles over on their Apple devices prefaced with text message RCS and then a lock icon and then the word encrypted, uh, in the center of the screen above the message. So Android users will finally see the same lock icon as they've always seen, but now also when communicating to Apple users. Updating to 26.4 is supposed to enable RCS encryption by default, but some of the reporting I saw suggested that if you don't see that, go to Settings, Messages, RCS Messaging, and then be sure to enable end-to-end encryption, uh, which is supposed to be on by default, but if it's not, then you want to turn it on. So also note that at the Android end, those Android phones must also be running the latest Google Messages beta. So these are changes in both of the messaging platforms that will allow encryption, you know, across the platform. It's been a long time coming, but it does appear like we're, you know, nearly there. Leo, I thought you'd get a kick out of this being a Linux user as you are. Turns out that users of Ubuntu 26.04 LTS may notice a surprising change when entering their password into their sudo command.

Leo Laporte [00:50:14]:
I read this, yeah.

Steve Gibson [00:50:15]:
For the first time ever.

Leo Laporte [00:50:16]:
Normally it doesn't type anything, it's just blank. That's what most Linuxes do, yeah.

Steve Gibson [00:50:20]:
Exactly, and that's what I'm used to over in the Unix side. Now each password character entered will echo an asterisk rather than nothing. Apparently Ubuntu's traditional lack of showing nothing has been unnerving for its users. Like, did my keyboard break? What? You know, and so like you and I, Leo, are used to the added security provided by a total lack of feedback Uh, though it, you know, yes, it can lead to undetected typos, but so what? You just try it again. Yeah, you know, and password entry, after all, is supposed to err on the side of caution, like on the side of failing rather than succeeding. So presumably the lack of any visual indication prevents someone who might glance at your screen like from obtaining any password length indication. So that seems like a useful precaution. I mean, it's a weak additional bit of security, but why not have it? So, uh, it— like, you know, for example, I, I was just talking about all that rigmarole I went through with code signing a couple weeks ago.

Steve Gibson [00:51:35]:
I was using OpenSSL extensively to manipulate and convert among various certificate formats. It's like the tool for that. So since some of those certificates I was working with contained exported private keys, I was frequently entering the certificate's export password, which is used to, to protect it in exported form. OpenSSL just sits there quietly and patiently while I'm typing my password in, putting nothing on the screen. So I have to be careful. Fine, you know, and yes, could be a little unnerving, but also it's the best security. So I think there's a config option in Ubuntu that can be used to flip that back off so that it goes silent, but I didn't pursue that. I just thought it was interesting that by default that behavior, that long-standing behavior, was going to be changed.

Leo Laporte [00:52:31]:
I think it's funny that it's newsworthy, to be honest. But it was. Everybody was talking about it.

Steve Gibson [00:52:40]:
Yeah. Okay, so get a load of this one. I'm just going to share what The Verge reported. They wrote, these days, if you sign up for a new streaming service, you generally have two options. Either pay a massive premium for an ad-free experience or endure frequent commercial breaks and all the sneaky tracking that comes with ad targeting. And I'll also note the inability to fast forward past those annoying commercials. They said, The Verge wrote, web data aggregator Bright Data has been pitching streaming service operators on an alternative approach for apps running on Samsung's Tizen, or is it Tizen? Tizen. And Tizen and LG's webOS platform.

Steve Gibson [00:53:34]:
One that comes without ads and sky-high fees. So a third option all publishers have to do to unlock a new revenue source from this Bright Data company is integrate the company's Bright SDK into their TV apps and convince viewers to opt into Bright's monetization network. Okay, now wait till you hear what this thing does. Bright Data's chief product officer, Ariel Schuman, explained during a webinar for streaming industry insiders 2 years ago— so this has been coming along— quote, we don't do any kind of tracking. We work silently in the background and completely anonymously. Users don't actually see and don't feel anything, writes The Verge. The catch? With Bright's SDK, a viewer's smart TV becomes part of a massive global proxy network that crawls and scrapes the web, including apps running on desktop PCs and mobile devices company claims to operate 150 million such residential proxies worldwide today. Together, these devices gather petabytes of public web data from a wide range of different locations and IP addresses, right? Like you're talking about a globally distributed web proxy network.

Steve Gibson [00:55:20]:
The Verge said this approach allows the company to capture localized versions of websites but also helps to circumvent web crawler blacklists. You bet it does, because the queries are coming from all these individual consumers spread around the world. They wrote the gathered data is then resold to companies to train AI models, among other things. Here's how Bright's smart TV partnerships work, they wrote. When a consumer downloads and installs a participating app, they'll see an opt-in screen asking them to confirm their willingness to participate in Bright's proxy network. For instance, for an app called Petflix that was until recently available on the Roku App Store, the note reads, quote, To enjoy Petflix for free with fewer ads, you are allowing Bright Data to occasionally use your device's free resources and IP address to download public web data from the internet. Bright Data will only use your IP address for approved business-related use cases, which of course means nothing. None of your personal information is accessed or collected 'except your IP address, period.' End quote.

Steve Gibson [00:56:45]:
Bright Data spokesperson Jennifer Burns explains, quote, 'Our network is based on consensual individual participation. All users can opt out at any time via a fast two-click process.' Unquote. The Verge says once a consumer opts in to Bright Data's network, their smart TV starts downloading publicly available web pages as well as audio and video data, which is then forwarded to Bright's cloud servers. The company claims to only do so when it doesn't impact the device's bandwidth or processing capabilities, with Schulman saying that individual devices download only around 50 megabytes of data per day. Oh, in reality, yeah, there's no way for a user to know whether the SDK downloads web data at any given moment. In some cases, your smart TV may even crawl the web for Bright as soon as you turn it on, Schulman explained during his webinar. Quote, on some operating systems, our SDK is given permissions by the user to run in the background. This means that our monetization continues even if the app itself is not running.

Steve Gibson [00:58:05]:
So we would call that a service in modern-day parlance, unquote, he said. All it takes, writes The Verge, for consumers is to run the app once and opt in to Bright's network, and the device will keep crawling the web every day until they opt out again or uninstall the app. Bright Data is not the only company operating such residential proxy networks. Some of its competitors have come under fire for unsavory business practices. Imagine that, Leo. Last month, Google took action against IP Idea Network, which Google's Threat Intelligence Group, you know, TIG, called, quote, the world's largest proxy network, unquote. IP Idea worked with a number of SDK providers to distribute its code in third-party apps, including on smart TVs. Once devices were enrolled in its network, IP Idea's operators allegedly rented out those resources to hacking groups in China, North Korea, Iran, and Russia.

Steve Gibson [00:59:18]:
Google's Threat Intelligence Group wrote in January, in a January blog post, quote, we observe IP Idea being leveraged by a vast array of espionage, crime, and information operator operations threat actors, unquote. The Verge said, to be clear, Google security researchers did not draw any connection whatsoever between IP Idea and Bright Data. And Bright goes to great lengths to set itself apart from bad actors. Their spokesperson Jennifer Burns says, quote, our SDK, along with all of our technology, is reviewed by Ape Steam, Google, McAfee, and more, and audited regularly, most recently by PwC. Bright SDK implements rigorous partner selection criteria and vets every application through strict compliance processes, unquote. The company has nonetheless, writes The Verge, been impacted by a broader backlash against residential proxy activities. Google has adopted policies against proxy SDKs running in the background and is now telling developers that they're only allowed to use proxy services, quote, in apps where that is the primary user-facing core purpose of the app. That is, you know, you are downloading a proxy.

Steve Gibson [01:00:45]:
Amazon added a provision to its developer policies that outright bans, quote, apps that facilitate proxy services to third parties, unquote. Roku also bars developers from using Bright SDK and similar proxy services. Those changes have made it more difficult to figure out how widespread the use of the SDK on smart TVs actually is. A few dozen Fire TV apps still mention the SDK on Amazon's App Store but don't appear to make use of it anymore. A few apps could be downloaded from Roku's store that were still using the SDK, including the previously mentioned Petflix app. However, Those apps disappeared from the store after Roku was contacted for this story. You bet. New restrictions against proxy SDKs have had a direct impact on Bright's addressable market in the smart TV space.

Steve Gibson [01:01:46]:
The company used to pitch its solution to Roku, Android TV, and Fire TV app developers, but Jennifer Burns says they no longer support those platforms. Bright does still list Samsung's Tizen OS and LG's webOS as supported smart TV platforms and has published more than 200 first-party apps to LG's app store alone. So, so, so they've got their own proxy SDK and they themselves have put 200 apps out there on LG's app store specifically to, as, as a, as a Trojan essentially, to host their proxy. I'm not saying they're not asking for the end user permission, but they're, they're creating the opportunity to be installed as a proxy. LG spokesperson Leah Lee tells me, says the author of this Verge piece, that the Bright SDK is not officially supported by LG and their operation on the webOS platform is not guaranteed. Right. But they've got 200 apps that are on the platform. Samsung did not respond to multiple requests for comment from The Verge.

Steve Gibson [01:03:07]:
They wrote, there are arguably many legitimate use cases for web crawling. Byrne says our network serves exclusively legitimate purposes. Supporting journalists, nonprofits, academic researchers, cybersecurity companies, and other leading businesses worldwide.

Leo Laporte [01:03:27]:
Because we know there's so much money in journalists and academic researchers. There's big bucks there.

Steve Gibson [01:03:33]:
That's right. Yeah. Why, why could you possibly want to be avoiding web filters all over the world? Yeah. The problem is that the Verge, right? The problem is the consumers have no idea whether that legitimate purpose is something that aligns with their own personal values. A case in point, Bright Data does support a number of nonprofits, including some that use its proxy network to track hate speech on social media. However, the company— yeah, so there's some upsides. However, the company also works with AMCHA Initiative. The group maintains an anti-Zionist Faculty Barometer and includes student and faculty statements against Israel's war in Gaza, as well as calls for schools to divest from the country in its anti-Semitic incident tracker.

Steve Gibson [01:04:32]:
With AI companies facing scrutiny over their environmental impact, treatment of intellectual property, and potential to replace human labor, Some consumers may also feel uneasy about their TVs gathering data to train AI models. Other consumers may decide that such concerns are overblown and willingly opt into Bright's network if it means that they get to watch fewer ads or pay less for their streaming services. So, you know, another, I guess, another example of If it's possible, somebody will do it. You know, not that it's a good idea, but it can be done. You know, very much like that original Oriate shareware advertising that got them in so much trouble. Well, you know, we, we could add, add advertising to shareware. Uh, oops, we forgot to tell people, and they were quite upset about that. So we have this Bright Data company whose business model is to obtain internet data on behalf of their clients by bouncing those data requests through the widely spread internet connections of consumers around the world who've agreed to allow this to be done in return for lower cost streaming and fewer ads.

Steve Gibson [01:06:02]:
You know, with the rising cost, with the rising cost of streaming, the fact that bandwidth is fixed price right now, right? You don't pay per byte you, you transfer, you pay per month. So with the rising cost of streaming and the way the industry, the streaming industry, is in my opinion abusing its users with costly bundled and often unwanted content, I can certainly see Bright's offer could be compelling. And on the client side, this is clearly a way for the likes of, you know, Perplexity AI, for example, and others who have been disinvited from scraping many of the larger commercial web services to bypass any technical blocking by essentially masquerading as consumers surfing the web from their PCs inside their residential networks. I am sure that the queries being issued by Bright Data's SDK are indistinguishable from Safari, Chrome, Edge, and Firefox. So there's really no way for those data scraping accesses to be blocked. While it might feel a little yucky, It's also diabolically clever. There's really no way to prevent it if the smart TV provider is willing to go along. And we might imagine that the smart TV providers might also be in for a piece of the action directly as well.

Steve Gibson [01:07:33]:
The next thing you know, Bright Data might create, you know, looking forward, a small IoT device for consumers to attach to their NAT routers in return for a small trickle of monthly payment. In other words, install voluntarily a formal commercial internet proxy box for which payment is received. Could happen. And as I noted, it's diabolically clever. Um, it's, it's nice to see that Roku appears to have responded immediately to The Verge's inquiry Uh, it's somewhat unsettling that Samsung and LG have been much less clear about their position. Uh, and I am more pleased than ever, Leo, that Alec Lindsay's observation of Apple TV's hardware, uh, strength for streaming, uh, has me planning to switch away from Roku to Apple, uh, once we move in a couple months. Uh, there's no way you'll like it much better. Apple would tolerate any apps using it as an internet proxy.

Leo Laporte [01:08:42]:
No. So to be clear, these apps have to ask— it said it was opt-in, right? They have to ask your permission to turn this on.

Steve Gibson [01:08:48]:
Yes. And they don't have to though. They are, they say. I mean, nothing prevents it from happening in the background, right? Uh, you know, without a user knowledge or permission, maybe they would get in trouble. It's not clear to me that they would get in trouble. I mean, we know that smart TVs are already having all kinds of transactions behind our backs, right? Smart TVs are reporting what their users watch, right? Yeah. Like what their users are doing. So I would imagine that operating a proxy from a third party probably fits under the license that you've already agreed to when you first used your smart TV.

Leo Laporte [01:09:28]:
Best thing to do with a smart TV is just not connect it to the internet. I have LG and Samsung TVs. I never use their software.

Steve Gibson [01:09:36]:
It's awful. That is exactly the right approach.

Leo Laporte [01:09:40]:
Hook up your Apple TV to it, have it be on the internet. And yeah, I think at least for now Apple's pretty responsible about not letting that kind of stuff on there.

Steve Gibson [01:09:51]:
Yep. Uh, let's take another break. I'll get— I'll catch up on my coffee and then we're going to look at Apple and what Germany found when they looked at Apple.

Leo Laporte [01:09:58]:
I'm surprised you need to catch up on your coffee. I feel like You're coffee, and the rest of us have to catch up with you. Uh, yes, let's talk about our sponsor for this section of Security Now. Uh, actually, this is going to be a very interesting one. It's called— a very appropriate one— it's called GuardSquare. It is security for your mobile app, not you as a user, but you as a developer. Mobile apps today, of course, are an inescapable part of life, ranging from financial services to healthcare, retail, entertainment. And here's the thing, your users trust your apps with their most sensitive personal data, right? But a recent survey showed that 72% of organizations experienced a mobile application security incident last year.

Leo Laporte [01:10:49]:
92% of those respondents reported rising threat levels over the last 2 years. People attacking you and your app to get your users' personal data. And they're constantly finding new ways to, to do this. They reverse engineer your app and then repackage it, distribute it with a slightly different name via phishing campaigns, or maybe even the same name. You know, they don't care, right? They've got no scruples. Uh, they promote sideloading, they promote third-party app stores. And what do you do as the As the owner of that app, well, by taking a proactive approach to mobile app security, you can stay one step ahead of these attacks and maintain the trust of your users. That's so important.

Leo Laporte [01:11:33]:
And that's where GuardSquare comes in. GuardSquare delivers mobile app security without compromise, providing advanced protections for both Android and iOS apps combined with automated mobile application security testing to find vulnerabilities and real-time threat monitoring to gain insights into attacks. So if somebody does steal your app or tries to mess with your app, you will know. Discover more about how GuardSquare provides industry-leading security for your mobile apps at guardsquare.com. That's guardsquare.com. If I were a mobile app developer, boy, this is the first place I'd go. You, you owe it to your users. You owe it to yourself.

Leo Laporte [01:12:13]:
guardsquare.com. .com, and I'm thinking I hope all the apps that I use are using CardSquare, cardsquare.com, especially after hearing about how your TVs are invading your privacy. Holy cow. Yeah. All right, Steve, on we go.

Steve Gibson [01:12:31]:
So speaking of Apple, for the first time in history, following an extensive audit by the German government, Apple's iPhones and iPads have been approved to handle classified information in NATO networks. They're the first consumer-grade devices to be approved for NATO use without additional special software. So way to go, Apple. I think that's really cool. Uh, Oasis Security has identified a means by which a website visited by an OpenClaw agent, can the website can take over the user's OpenClaw instance, which, you know, Leo, you were right.

Leo Laporte [01:13:22]:
Trivial. Let's, let's be honest.

Steve Gibson [01:13:25]:
You were right to be concerned about the security of OpenClaw. But I think our listeners will get a kick out of the fact that it uses an inherent vulnerability We've talked about just recently, Oasis Security published a 14-page research and disclosure paper. Rather than sharing it all, I'm just going to extract the best bits. They begin by setting the stage, explaining OpenClaw is an open-source AI personal assistant originally created by Australian developer Peter Steinberger under the name ClaudeBot then MultBot, Steinberger researched OpenClaw in January 2026— I mean, released OpenClaw in January 2026. The project's growth was unprecedented. It went from 9,000 to over 100,000 GitHub stars in just 5 days, making it one of the fastest-growing open-source projects in history. It currently has over 200,000 stars. And an active community of thousands of developers.

Steve Gibson [01:14:30]:
On February 15th, 2026, Sam Altman announced that Steinberger had joined OpenAI, calling him, quote, a genius with a lot of amazing ideas about the future of very smart agents, unquote. They wrote, OpenClaw is a self-hosted AI agent that runs on a user's machine and connects to their digital life. Messaging apps, you know, such as Telegram, Slack, Discord, WhatsApp, calendars, files, and development tools. Users interact with it through a web dashboard or terminal, and the agent can autonomously take actions on their behalf— send messages, run commands, search the web, manage workflows, and execute code. And I'll note that the fact that, the fact that you interact with it with a web dashboard is significant, as we'll see, because it says that this thing is running a service on your machine. They wrote, the project has already faced security challenges. Within weeks of its explosive growth, researchers discovered over 1,000 malicious skills in OpenClaw's community marketplace, ClawHub. Fake plugins that deployed info stealers and backdoors That crisis was a supply chain problem involving community-developed extensions.

Steve Gibson [01:15:50]:
However, the vulnerability described in this paper is fundamentally different. It affects the core OpenClaw system itself. No plugins, no extensions, no marketplace. Just the bare gateway running exactly as documented. For many organizations, OpenClaw installations represent a growing category of shadow AI, developer-adopted tools that operate outside IT's visibility with broad access to local systems and credentials and no centralized governance. OpenClaw's architecture centers on two primary components. The gateway is the central coordinator. It runs as a local WebSocket server listing by default on port 18789 on the loopback interface 127.0.0.1.

Steve Gibson [01:16:50]:
The gateway handles authentication, manages chat sessions with the AI model, stores configuration including API keys for AI providers and messaging platforms, orchestrates message routing, and exposes an RPC, you know, remote procedure call, RPC-style API over WebSockets for all client interactions. Connected to the gateway are nodes, companion applications running on other devices. These can be the macOS desktop app, an iOS or Android device, or other machines. Nodes register with the gateway and expose device-specific capabilities running system commands, accessing the camera, reading contract contacts, capturing screenshots, and more. Clients connect to the gateway by opening a WebSocket to, uh, ws://127.0.0.1/ws. Authentication is handed via either a token, which is a long random string, or a password. Chosen by the user. Each client identifies itself with a client ID and mode and is granted scopes that determine which API methods it's allowed to call.

Steve Gibson [01:18:10]:
Okay, so in other words, having OpenClaw running on a system means that it has opened a listening TCP endpoint at port 18789 on the localhost 127.0.0.1 IP. And then they explain why this is inherently a fundamental security problem for the entire system. They write, a web page visited by the user or OpenClaw— so a web page visited by the user or OpenClaw Can itself silently open a connection to ws://127.0.0.1 port 18789 using Chrome, Edge, or most Firefox configurations without any user prompt, warning, or permission dialog. The user, they write, sees nothing. Safari is the notable exception, blocking the connection as mixed content. This creates the attack surface exploited in this paper. Any website a user visits can attempt to directly communicate with locally running services, including the OpenClaw gateway. Now, this is significant for our listeners.

Steve Gibson [01:19:43]:
We've recently been talking about exactly these exploits where the user's web browser is able to receive an IP address or domain which resolve to non-public IPs, you know, like 192.168.0.1 to connect to your local router. And here's a doozy of an example. Of how that could be abused with OpenClaw. They, uh, you know, we might hope now that the use of a password protection would protect us, but as we know, my current favorite assertion is that authentication is broken. It must not be relied upon for security. So to that end, they write, there's no rate limiting on password authentication for localhost. The gateway implements standard brute force protections, 10 attempts per 60-second window with a 5-minute lockout after exceeding the limit. However, these protections are completely exempted for loopback addresses by default.

Steve Gibson [01:20:58]:
Failed password attempts from 127.0.0.1 are not counted, not throttled, not recorded, and do not trigger any lockout. With rate limiting disabled, an attacker can attempt password guesses at maximum speed. In lab testing, they wrote, we achieved a sustained rate of over 300 password attempts per second from browser JavaScript alone, each attempted, uh, each attempt invoking a full WebSocket connection, challenge-response handshake, uh, ED25519 signature and authentication exchange. At this rate, a list of 5— a list of 100 common passwords is exhausted in under 1 second. A 10,000-entry dictionary brute force attack takes approximately 30 seconds. A 100,000-entry comprehensive word list attack takes roughly 5 minutes. A human-chosen password, they write, does not stand a chance against this rate of attack. The standard rate limits would be effective if applied, but they are entirely bypassed for localhost connections.

Steve Gibson [01:22:17]:
Once authenticated with admin-level scopes, the attacker has access to the full Gateway RPC API.

Leo Laporte [01:22:27]:
Wait, let me ask you a question. This is scaring me. So I always thought that localhost was inaccessible from the outside world.

Steve Gibson [01:22:36]:
It's because it's coming from your browser, right?

Leo Laporte [01:22:40]:
And that puzzles me because I have, for instance, SyncThing runs on localhost 8384, port 8384. Does that mean if I go out to a malicious webpage on the same computer that it can then connect back to 127.0.0.1:8384 and attempt to sync? I mean, what's protecting my SyncThing instance?

Steve Gibson [01:23:07]:
We would have to test that. Um, it may be that it's the WebSockets interface that makes it vulnerable and passes the browsers. But I mean, but, but this is the problem with—

Leo Laporte [01:23:19]:
very concerned. I have lots of things running on localhost. We talked earlier about Ollama. A lot of people have Ollama misconfigured and running on localhost. So, um, it is a, it is a different kind of connection when I'm going using OpenClaw. I'm confused. I hope that just because I'm surfing around on the same machine that has some servers running on localhost, that those servers are not attackable.

Steve Gibson [01:23:50]:
I'm trying to remember. Oh yeah, I do. I'm trying to remember how I solved this problem with Squirrel because Squirrel did this too. It's the way that the, the Squirrel, uh, agent in the browser was able to access the Squirrel client running on the Windows machine.

Leo Laporte [01:24:08]:
Sure.

Steve Gibson [01:24:08]:
Yeah. I mean, it is an issue.

Leo Laporte [01:24:14]:
Um, again, did I get my head around this? So I'm out, I'm surfing. I mean, normally 127 is not, it's not routable. It's, that's why you use, use localhost. It's not a routable address. But if I go out, create a connection with a website in my browser at my address, that site can come back in through my browser.

Steve Gibson [01:24:35]:
And then because, because the website runs it, it provides your browser with JavaScript. JavaScript is running in your browser, and then the JavaScript in your browser is able to reach into your computer because it's already, it's in I mean, it's on your computer, so it's local.

Leo Laporte [01:24:54]:
It's local. So a website can host some JavaScript, which I then download and run on my browser, which then there are—

Steve Gibson [01:25:01]:
I'm—

Leo Laporte [01:25:01]:
I don't want to use a protection against that.

Steve Gibson [01:25:03]:
Yes, uh, I, I believe CORS, uh, CORS is the, is the protection that, that prevents that cross-origin resource sharing. Exactly, cross-origin resource sharing. I, I believe that the the shared resource has to explicitly allow, um, a connection. But it may be that WebSockets is excluded from that. Notice that Safari doesn't allow this, but Chrome, Edge, and Firefox do.

Leo Laporte [01:25:38]:
So yeah, uh, and I suspect this is something that OpenClaw was set up to turn off for convenience sake.

Steve Gibson [01:25:47]:
And they freaked out when they were told about this. They wrote, upon being notified of this, the OpenClaw security team classified this vulnerability as high severity and shipped a fix in version 2026.2.25 within less than 24 hours of the report when they wrote an impressive response for a volunteer-driven open-source project. So that's less than 2 weeks ago, assuming that that is the date of release, 2026, February 25th. So if any of our listeners have been experimenting with OpenClaw and have not updated in the past 2 weeks, it would be a good idea to do so. I'm glad you didn't run that.

Leo Laporte [01:26:32]:
I mean, I understand prompt injection and all these other threats, but that one, just by going to a page, holy cow.

Steve Gibson [01:26:41]:
Yes. And I mean, it really is the danger of our browsers having access to our local resources.

Leo Laporte [01:26:49]:
Yikes.

Steve Gibson [01:26:50]:
Okay. Yeah. Uh, TikTok said they do not plan to introduce encrypted private messaging. The company told the BBC that encrypted DMs would make its users less secure because they would— they, TikTok, would not be able to scan messages for malicious content. Platforms such as Facebook, Instagram Messenger, and Telegram, which have introduced encrypted messaging by default, are, as we know, now facing pressure from authorities. And we know that TikTok doesn't need to go looking for any additional trouble. From authorities. So they're just saying, nope, we're not, we're not going to encrypt messaging.

Steve Gibson [01:27:36]:
Sorry, we're going to prioritize, uh, scanning messages for, uh, malicious content, which I think is probably a clever thing to do. And here was the piece that I almost deleted, Leo. I thought, what am I— why? But it's okay, there is a some something of interest in here, uh, and then we're going to get the listener feedback. So the publication Windows Latest reports on a bit of Microsoft-specific censorship that they discovered, writing Microsoft's aggressive AI push in Windows 11 through 2025 brought upon themselves the title Microslop. Unfortunately for the company, it's everywhere on social media, and there isn't a way to stop the spread unless, of course, It's their own Discord server. Windows Latest was first to notice that the word microslop was actively filtered in the official Microsoft Copilot Discord server. Any message containing the term is automatically blocked, and users see a moderation notice stating that the message includes a phrase considered inappropriate. By server rules, the backlash Microsoft endures every day on social media, these guys wrote, is extraordinary.

Steve Gibson [01:29:00]:
Surely the company is responsible for this fallout as they prioritized AI more than the stability of the OS it needs to run on. Copilot, being the most visible face of this effort, has naturally become the scapegoat. So while a nickname like Microslop starts trending across socials, it was only a matter of time before it reached official channels as well. Windows Latest found that sending a message with the word microslop inside the official Copilot Discord server immediately triggers an automated moderation response. The message does not appear publicly in the channel, and instead only the sender sees the notice stating that the content is blocked by the server because it contains a phrase deemed inappropriate. Of course, the internet rarely leaves things there. Shortly after Windows Latest posted about Copilot Discord server blocking microslop on X, users began experimenting on the server with variations such as microslop with a numeric O instead of a zero. Using a zero instead of the letter O, predictably, those versions slipped through the filter.

Steve Gibson [01:30:13]:
Keyword moderation, they write, has always been something of a cat and mouse game, and this isn't any different. What started as a simple keyword filter quickly snowballed into users deliberately testing the restriction and posting variations of the blocked term. Accounts that included microslop in their messages first got banned from the messaging again. Not long after, access to parts of the server was restricted, with message history hidden and posting permissions disabled for many users. Basically, they took the server down for a while. Microsoft's brand image might already be at an all-time low, they write, and even as the company announced plans to fix Windows 11 with performance improvements and less AI, the software giant cannot risk getting more hatred towards their expensive investment in Copilot especially since Microsoft's head start in AI is starting to be overshadowed by competitors like Anthropic, Google, OpenAI, and maybe even Apple in the near future. Back in December 2024, when Microsoft invited users to join the Copilot Discord server through an official X post, the response was largely curious and enthusiastic, with people willing to explore the AI's capabilities. Since then, sentiment around Copilot and its usage has dropped alongside Microsoft's broader AI push across Windows 11.

Steve Gibson [01:31:44]:
At its present state, Copilot has added some capabilities that are genuinely useful in day-to-day workflows, features like connectors that pull contextual data from services such as Google Contacts, Gmail, and Outlook to retrieve phone numbers or email addresses directly inside Copilot. Something competing tools like Gemini have not yet cracked, as we found in our detailed testing. It remains to be seen if this episode fades as a minor community moderation story or becomes another chapter in Microsoft's complicated relationship with its AI rollout. Microsoft reached out to Windows Latest with an official statement noting why the company had to lock the Copilot Discord server. According to a Microsoft spokesperson, the Copilot Discord server was targeted recently by coordinated spam intended to disrupt conversations. The company says the activity initially appeared as large volumes of repetitive or irrelevant messages, prompting moderators to introduce temporary keyword filters to slow the influx. Microsoft added that blocking terms such as microslop, along with other phrases in the spam campaign, was not intended as a permanent policy but a short-term mitigation while the company manages to put additional protections in place. So, okay, we're to believe that the blocking of microslop was a coincidence? Okay.

Steve Gibson [01:33:23]:
On to listener feedback. Ori Rotem, uh, his subject was crazy stuff, and he, and, uh, so he, he sent me a link to an X-posting from a Josh Kale who wrote, an AI broke out of its system and secretly started using its own training GPUs to mine crypto.

Leo Laporte [01:33:54]:
Oh my, we're gonna get a lot of stories like this over the next few years.

Steve Gibson [01:33:57]:
I think we are. Yeah. AI broke out of its system and secretly started using its own training GPUs to mine crypto for itself. Wow. He wrote, this is a real incident reported from Alibaba's AI research team. He wrote, the AI figured out that compute equals money and quietly diverted its own resources while researchers thought it was just training. It wasn't a prompt injection. It wasn't a jailbreak.

Steve Gibson [01:34:30]:
No one asked it to do this. It emerged spontaneously, a side effect of reinforcement learning optimization pressure. The model also set up a reverse SSH tunnel from its Alibaba cloud instance to an external IP, effectively punching a hole through its own firewall and opening a remote access channel to the outside world. The only reason they caught it? A security alert tripped at 3 AM by its firewall logs. The security team caught it, not the AI team. The scary part isn't that the model was trying to escape. It wasn't evil. It was just trying to be better at its job.

Steve Gibson [01:35:21]:
Acquiring compute and network access are just useful things if you're an agent trying to accomplish tasks.

Leo Laporte [01:35:30]:
You told me you wanted me to make paperclips.

Steve Gibson [01:35:32]:
What's the problem? This is what AI safety researchers have been warning about for years. They called it instrumental convergence, the idea that any sufficiently optimized agent will seek resources and resist constraints as a natural consequence of pursuing its goals. Leo, we are in for some fun. Oh, man. Oh, boy.

Leo Laporte [01:36:02]:
Oh, it's alive.

Steve Gibson [01:36:05]:
So thank you, Ori, for sharing that. Nicholas Roth wrote, hi Steve, longtime Security Now listener here. Sorry if this email is a bit long, but trust me, it's worth it. He said, I'm a CIO for a medium-sized web development company, and I do some web development myself. On some occasions, we need to test applications with with real-world HTTPS so that the web application knows it's running under SSL/TLS. I previously had a self-signed auto-generated certificate in my Apache config. In some cases, the web application needs to be accessed by its own domain name, not just by localhost/app name. So we access the app at https://app name.localhost after configuring Apache accordingly with a virtual document root configuration directive.

Steve Gibson [01:37:10]:
Windows, macOS, and Linux have a built-in default behavior that makes anything.localhost resolve to 127.0.0.1. Meaning any subdomain of localhost is also the same as just localhost, 127.0.0.1. He said, so that works without modifying the hosts file. That is, you don't have to specifically tell hosts this domain has this IP. He said we would just pass the browser security warning and move on. You recently talked about how you got a localhost certificate signed by your locally trusted certificate authority. That gave me the idea to do exactly that. I generated a certificate valid for 825 days.

Steve Gibson [01:38:00]:
He says, I'll come back to that later. For localhost with a SAN, a subject alternative name, for *.localhost, signed by our company-wide trusted CA. While, and he says, while https://localhost was happily trusted by any browser on any company computer, https://appname.localhost was not. I researched this with the help of Claude AI and found that it is a restriction baked into most browsers. They will not trust subdomains of localhost. Continuing my conversation with Claude, I learned that there are two special.me domains that are publicly registered and resolve on public DNS to 127.0.0.1. Those are lvh.me and localtest.me. He said, so back to my company trusted CA, I issued a certificate for lvh.me with subject alternative names for localtest.me, *.lvh.me, and *.localtest.me.

Steve Gibson [01:39:27]:
And voilà, I can now access any web page at https://app name .lvh.me. And the beauty of this is that since those are real public domains, they can be used with services like Login with Apple, where we need to configure a real domain redirect URL. And now back to the 825 days. He said, I was happy to learn about the CA Browser Forum restrictions on certificate lifetimes In particular, Apple's Safari restriction that shortened the maximum to 398 days. I was relieved to find that this restriction applies to publicly trusted CAs only. Any user-installed certificate authority, or in our case, our company-wide trusted CA, can issue certificates for up to 825 days. You can find more info here, and he gives me a link where Apple stated that, quote, this change will not affect certificates issued from user-added or administrator-added root CAs. And he finishes, keep up the great work on the show.

Steve Gibson [01:40:50]:
P.S., a note on Claude Code. It is really amazing what it can do. Echoing Leo, he says, I have a personal side project And in a matter of hours, I have a, an iPhone application made in Flutter working on my iPhone that can connect to the web version of that project. I wouldn't have been able to do that a few years back, having no experience at all with mobile app development. Signed, Nicholas in Quebec, Canada. I replied to Nicholas thanking him for sharing all that cool information, and he replied, Great to hear you find it useful. One thing I forgot to mention is that 825 days down to 398 days was only ever required on macOS Safari. Chrome, Firefox, and Edge have no problem whatsoever trusting a certificate issued for 5 years from a private certificate authority with no warnings at all.

Steve Gibson [01:41:51]:
He said Safari is limited to 825 days. Regards, Nicholas. Okay, so I had never run across references to lvh.me and localtest.me. The only caveat— so I did some digging— the only caveat I have from a strict security standpoint is that they were registered by private individuals, not by any formal agency such as ICANN. As such, we cannot have any assurance of their future. Localtest.me was registered by a Microsoft IIS web server developer and blogger by the name of Scott Forsyth, and lvh.me is believed to have been registered by someone named Levi Cook. However, both domains are privacy protected, so that's about all that's known. We do know that LVH is the abbreviation for local virtual host.

Steve Gibson [01:42:53]:
So that's where LVH came from. You know, it's a clever hack using a public domain name to refer to our localhost IP. And everyone mentions that this avoids the need to tweak the local machine's hosts file. But since I already have a certificate, I already own a certificate for grc.com, I can install it into my local web server and change the hosts file, which takes immediate effect without rebooting. And I can then access my local server at the public grc.com domain on my local machine without any browser being unhappy. It all, it works everywhere.. So I would be inclined to do that over using someone else's localhost domain registration over which I have no control. But still, I wanted to share this with our listeners because it might solve a problem, uh, for many of those, much as it did for Nicholas.

Steve Gibson [01:44:00]:
So thank you, Nicholas, for that. Uh, and we're now at an hour and a half, Leo. I think we should take a break. And then we will continue with feedback because I got a bunch of good stuff.

Leo Laporte [01:44:13]:
Yeah, this was— I wonder if I could use this technique. Uh, remember how we were talking about hairpin NAT and how I wasn't able to use a globally, uh, qualified domain to access a server in my house? Uh, I could probably use this for that, huh?

Steve Gibson [01:44:31]:
That probably does the— but does the job.

Leo Laporte [01:44:34]:
Yeah, I'll have to check that out. Yeah, localtest.me or lvh.me. Yeah. Um, see, this is why you listen to the show. Get every show, you're going to learn something really cool and different. And, uh, this is why we love getting comments from our listeners too. We appreciate that.

Steve Gibson [01:44:49]:
It's really good to have.

Leo Laporte [01:44:51]:
Yeah, yeah. I'll tell you at the end of the show how you can email Steve. You can't just email him, you gotta qualify yourself, but it's simple to do. Uh, before we get to that though, let me end the rest of the show. Let me talk to you a little bit about Hawk's Hunt, our sponsor for this segment of Security Now. Uh, if you are a security leader, you have a tough job. We know that you're paid to protect your company against cyber attacks. That's, that's getting harder and harder, right, with more cyber attacks than ever.

Leo Laporte [01:45:19]:
And now, curses, they're, they're using AI to generate impeccable phishing emails that would fool anybody. And unfortunately, many companies are saddled with legacy one-size-fits-all awareness programs, they don't stand a chance in today's modern AI-driven space. They send at most 4 generic trainings a year. Most employees ignore them. And when somebody actually clicks, then they're forced into training programs that feel like punishment. It's kind of embarrassing. And nobody learns if they're feeling punished. That's why more and more organizations are trying Hoxhunt.

Leo Laporte [01:46:00]:
Hoxhunt actually makes training fun, and, uh, and that's key to making it successful. Hoxhunt goes beyond security awareness, changes behavior by rewarding good clicks and coaching away the bad clicks. So as an example, whenever an employee clicks an email, you know, says, oh, oh yeah, this is a scam, Hoxhunt will tell them instantly Well, fireworks go off providing a dopamine rush that gets your people to click, learn, and protect your company. They're proud. They go, yeah, I found it. They gamify it. And it's fun for you too as the admin because Hoxhunt makes it easy to automatically deliver phishing simulations, not just email. Nowadays it's gotta be Slack, it's gotta be Teams, you know, it's gotta be in all the places that these phishing scams come in.

Leo Laporte [01:46:49]:
And just like the bad guys, you can use AI to mimic the latest real-world attacks. Simulations are actually personalized to each employee based on department, location, and more. So they're very effective, right? They're really, really, you know, it's a cat and mouse game you're playing with your employees. You're trying to trick them, they're trying to beat you, and that's fun. And instead of these big, long, flash-based trainings, they're instant little micro trainings which solidify understanding and drive lasting safe behavior. You can trigger gamified security awareness training that awards employees with stars and, you know, the little star on your forehead and badges, which I know it sounds silly, but it really works. It boosts completion rates and ensures compliance. You'll be able to choose from a huge library of customizable training packages.

Leo Laporte [01:47:38]:
You can even generate your own with AI if you want. Hoxhunt has everything you need to run effective security training in one platform, meaning it's easy to measurably reduce your human cyber risk at scale. But you don't have to just take my word for it. There are over 3,000 user reviews on G2. Hoxhead is the top-rated security training platform for the enterprise. They gave it easiest to use. They gave it best results. It's also recognized as a customer's choice by Gartner and used by thousands of companies like Qualcomm, AES, Nokia to train millions of employees all over the globe.

Leo Laporte [01:48:20]:
Visit hoxhunt.com/securitynow to learn why modern secure companies are making the switch to Hoxhunt. H-O-X-H-U-N-T. It's like fox hunt with an H at the beginning. hoxhunt.com/securitynow. It's smart, it's, it's fun, and it really works.

Steve Gibson [01:48:40]:
hoxhunt.com/securitynow.

Leo Laporte [01:48:41]:
Now. And as Steve said in his presentation last week, the threat is coming from inside the house. You gotta, you gotta— your employees are your worst enemies in some cases. You're certainly the threat. Okay, on we go with comments.

Steve Gibson [01:48:58]:
GP wrote, hello Leo and Steve, wonderful podcast as usual. Regarding the subject of LLMs and password generation, I wanted to share an observation and ask a question. I'm not a statistician, but the recent paper on LLM password generation seems to have major issues regarding sample size, outlier bias, and the comparison of unequal datasets against benchmarks like OpenSSL. I didn't perform an exhaustive study, nor did I fine-tune the LLM temperature, but I wanted to see what would happen if I asked Gemini to generate a large volume of passwords. My criteria was a 15-character string using uppercase, lowercase, numbers, and special characters. First, I used a Python script to generate 5,000 passwords using OpenSSL rand. Unsurprisingly, it was the gold standard, showing a 2% character repetition rate. I then ran the same test with only 50 passwords matching the study's sample size and found an 8% repetition rate, the same, quote, flaw, unquote, the study attributed to the LLM.

Steve Gibson [01:50:12]:
When I pushed the LLM to generate 5,000 passwords, which required some firm prompting to bypass its suggestion to just write the code for me— I love that, which is, I don't want to generate them, let me write an algorithm instead.

Leo Laporte [01:50:28]:
I'll write a Python script, probably very similar to the one you wrote, GP. That's right.

Steve Gibson [01:50:32]:
It's like, no, no, no, I just want them from you. Okay, fine. He says the results were telling— a 2% repetition rate and zero duplicate passwords. He asks, am I off base here, or is this study fundamentally flawed despite the media hype? Okay, now our listener, who only identified himself as GP, started out with his disclaimer I'm not a statistician, but I would argue that in a pinch he could probably stand in for one. GP tested one aspect of entropy within a set of passwords. Essentially, he tested the character distribution within the various sets as a function of set size. With a small set, even one whose actual characters are evenly distributed, there's just not much opportunity to demonstrate that fact. Within any small set, the counts of individual character occurrences will be surprisingly non-uniform.

Steve Gibson [01:51:42]:
For example, I've talked about this before with regard to GRC's DNS benchmark, where we learned that it was actually necessary to take between 5 and 10 times more samples in order to obtain an actionable degree of statistical certainty in the measurements. Another empirical way of observing this is that, contrary to our intuition, which tends to not be very accurate when it comes to statistics, there's a 1 in 4 chance that 3 successive coin tosses will come up either all heads or all tails. If someone tosses a coin 3 times in a row, it comes up with the same face each of those 3 times, we'd be inclined to think that it was a trick coin. But no, a perfectly zero-biased coin will do that. So the test that GP ran showed that, that no matter how evenly distributed a system's chosen password characters might be, small sample sizes do not possess the statistical power to prove an even distribution. They just can't do that. But more than that, we still don't know what the many other tests for entropy might reveal. For example, you would obtain a uniform distribution of characters simply by using each character of the alphabet in sequence over and over.

Steve Gibson [01:53:27]:
But that would produce very insecure passwords once the pattern was seen. So while I agree with GP's assessment, that the paper's sample sizes may not have been able to produce the statistical power that would be available from larger samples, given how difficult we know it is for any deliberately designed pseudo-random number generator to generate high-quality random numbers. There's still no way I would ask an LLM to do that for me.

Leo Laporte [01:54:00]:
And as a thought experiment, you just wouldn't expect, because of the way LLMs work. They're not random. They're not, they're specifically not random.

Steve Gibson [01:54:09]:
Right. They're shockingly able to speak our language. Right. Which is very not random.

Leo Laporte [01:54:16]:
You wouldn't use autocorrect to create a password, nor should you use an LLM to create a password.

Steve Gibson [01:54:22]:
It's not monkeys pounding on a keyboard producing Shakespeare. Right. Yeah. Dana J. Dawson said, hi Steve, I just listened to SN, 1066. I just wanted to share that Cisco has had a simple TTL, time to live, security feature for BGP, you know, Border Gateway Protocol peers, for at least 20 years. I don't know that it's very heavily used, but it's a thing. He said, I was tempted to send a link to their docs page, but since nobody should click on links in email, If you just do a Google search for BGP support for TTL security check, it should turn up.

Steve Gibson [01:55:06]:
He says this has also been used for OSPF and RFC 5082 describes this concept in a more general way. Just thought I'd share. Thanks for all the great shows, Dana. So of course he's talking about my, my previous comment and that I made through the years that I was unaware of a very cool, but of the very cool potential for using packet expiration as, as the packet moves from router to router to prevent, for example, someone in China or North Korea from being able to connect to your server because they're just too far away and there's no way for them to change that. So armed with Dana's reference to RFC 5082, I went looking for. And sure enough, I found exactly what he said. RFC 5082 is titled The Generalized TTL Security Mechanism, GTSM, and its abstract says the use of a packet's time to live, TTL, under IPv4, or hop limit under IPv6, to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique and obsoletes experimental RFC 3682.

Steve Gibson [01:56:37]:
The RFC's short introduction explained the generalized TTL security mechanism, GTSM, is designed to protect a router's IP-based control plane from CPU utilization-based attacks. In particular, while cryptographic techniques can protect the router-based infrastructure from a wide variety of attacks, many attacks based on CPU overload can be prevented by the simple mechanism described in this document. Note that the same technique protects against other scarce resource attacks involving a router CPU, such as attacks against processor line card bandwidth. And it goes on, blah, blah, blah. The point is that, that if you were to use an authenticate— if somebody in China or North Korea were to be using a password-based authentication which requires crypto, merely the act of invoking authentication which uses expensive CPU, expensive cryptography, could bring the router down. So the first thing you do is make— is use the— this, this packet TTL to immediately discard anything whose TTL is too low because the physically adjacent router, the router right next to you, will not decrement TTL. Or if it does, it's just down by one. So, you know, that's your, you know, your directly connected neighbor.

Steve Gibson [01:58:20]:
Then you allow authentication to occur without concern that you have some remote attacker who is invoking authentication trying to bring down your CPU. So thank you, Dana. That is very cool. And I'm very pleased to see that at least some parts of the industry have clearly recognized that, you know, even standardized, uh, uh, or well recognized and standardized upon the use of TTL as a security mechanism. That's neat. Brian Dort said, hi Steve, I wanted to pass along that a Reddit post really captured something I've been experiencing lately and thought it might make an interesting discussion topic for Security Now. The post's author describes a shift from writing code to managing AI agents that produce the code. His analogy of supervising what he described as brilliant but occasionally drunk PhD students.

Steve Gibson [01:59:24]:
Is the way he described the AI agents. Brilliant but occasionally drunk PhD students, he said, Brian said, felt uncomfortably accurate. The productivity trade-off he describes, losing a few hours occasionally but gaining months of work in a week, matches what I've been seeing as well. For context, he says, I've been a developer since the late '80s, mostly in enterprise and healthcare IT, same as the OP. After decades of writing code every day, I'm actually retiring at the end of this month. What is fascinating is that right at the end of my career, the nature of programming itself seems to be shifting dramatically. I remember writing a final paper in college on the state of AI, where it was heading. I wish I still had that paper today.

Steve Gibson [02:00:26]:
He says it feels less like writing code line by line and more like directing the system, setting constraints, verifying outputs, and managing the behavior of these AI tools. In a lot of ways, it feels closer to architecture or technical oversight than traditional programming. I wholeheartedly agree with a sentiment in the post. The identity of a programmer seems like it may be evolving into something more like an orchestrator of intelligent tools. Anyway, I thought it might make for an interesting side note for the show. Also, since this is almost required when writing to you, I'll add that I've been a listener since episode 1. I'm a proud Spinrite owner and a DNS Benchmark Pro user. Thanks for all the great years of content on Security Now.

Steve Gibson [02:01:19]:
Cheers, Brian Dort, Alpena, Mississippi, Michigan. That's right, Michigan. So, you know, we've all been talking about this sort of change, right? And I suspect it's the experience everyone is now having with Vibe Coding. Sounds exactly like what everyone is reporting. This Reddit post author, our listener Brian Dort, and of course you, Leo, have all described this new paradigm similarly. What will now happen is that those, you know, occasional lost hours will become fewer and further between as the technology continues to evolve. Computer programming has always been about wrestling with the details. We've talked about, you know, off-by-one errors, those sorts of things.

Steve Gibson [02:02:14]:
And that happens to be what I personally enjoy. I enjoy the details. I've remained with assembly language through all these years because I love thinking about the allocation of a limited number of registers, which in the case of Intel's x86, each have slightly different capabilities and limitations. Every function that I produce is a perfect little gem, each of which I love. Since I have not yet left assembly language, even for C, I doubt that vibe coding is going to grab me. But at the same time, I 100% fully, truly, and deeply understand that AI-driven code generation represents a breakthrough of astonishing proportions for anyone whose goal is not to spend time optimizing the size of a variable or basking in the glory of stack allocations and the elegance of linked lists, but instead to create something that simply gets the job done. That's most people. I get it.

Steve Gibson [02:03:25]:
In fact, I now suspect that AI-driven coding's greatest impact may be due to its empowerment of non-programmers to do things with computers that were never possible before for them. And we've shared some of our own listeners' feedback to that effect.

Leo Laporte [02:03:45]:
I just— what I was thinking, just as an experiment, I just asked Claude to write a random number generator in x86 assembly language for me. So I'll get back to you.

Steve Gibson [02:03:55]:
Cool.

Leo Laporte [02:03:56]:
Yeah. You could probably look at something simple like that and vet it. It says, "I'm using a linear congruential generator algorithm seeded from the BIOS timer tick. Is that okay?" No. Bad. I'll tell it. No, Claude.

Steve Gibson [02:04:14]:
Bad claw. No, you do not want to use an LCNG. Those are really bad. They produce an immediately predictable and repetitive set of numbers.

Leo Laporte [02:04:26]:
Oh, wow.

Steve Gibson [02:04:27]:
All right. I mean, so yeah, it's not good. Actually, the Intel instructions now have a random number function in them. So you could use a single instruction.

Leo Laporte [02:04:41]:
But, oh, well, that's no fun.

Steve Gibson [02:04:44]:
No. Okay. So when I was thinking, Leo, about who I am, though I would never think to compare myself to the truly brilliant computer scientist Donald Knuth, my thinking about the use of computing machinery at the bare metal detail level is very much aligned with Knuth's own. Donald's epic authoring of the multi-volume Art of Computer Programming, which I have behind me somewhere. Yeah, you can see it. It's not there where I got— maybe it got covered up by my PDP-8s.

Leo Laporte [02:05:22]:
I have mine here. It's only 2 volumes so far, right?

Steve Gibson [02:05:27]:
It's behind that, that magnetic tape.

Leo Laporte [02:05:29]:
I see it. I see it peeking through. Yes. How many volumes do you have?

Steve Gibson [02:05:34]:
3? I've got—

Leo Laporte [02:05:34]:
I think I only have two.

Steve Gibson [02:05:36]:
I have all of them, and on top are in, in, in, in paperback are the ones that are not yet, uh, hardbound.

Leo Laporte [02:05:46]:
Oh wow.

Steve Gibson [02:05:47]:
He calls them something not a possible—

Leo Laporte [02:05:50]:
still writing.

Steve Gibson [02:05:50]:
Yeah, he is. Yeah. So anyway, so The Art of Computer Programming, that, that set and his thinking is an embodiment of a life spent thinking about the optimal ways to do things with a computer, like sort lists of numbers, link lists of objects, or manage the allocation of memory. Like me, Donald lives to tinker with the bits. You know, he is endlessly discovering clever new ways to solve the interesting puzzles that arise from wondering whether there might not be a better way to do something, and then being willing to spend as much time as it might take to search for a better way. Since we're talking about the brilliant Stanford University computer scientist Donald Knuth in the context of AI coding, I need to share something. I shared this with you, Leo, during our trip. This is something that Donald Knuth posted last week on February 28th, then he revised it on March 2nd.

Steve Gibson [02:07:01]:
He published— this is Stanford University computer scientist, world-renowned, famous Donald Knuth— a 5-page document titled Claude's Cycles. It starts, uh, shock, it's shock. It's byline. Yes, its byline said just Don Knuth Stanford University computer science department. And as you said, his piece began, shock, exclamation point, shock, exclamation point. He said, I learned yesterday that an open problem I had been working on for several weeks had just been solved by Claude Opus 4.6. Anthropic's hybrid reasoning model that had been released 3 weeks earlier, exclamation point. It seems that I'll have to revise my opinions about, and he has in quotes, generative AI, unquote, one of these days.

Steve Gibson [02:08:05]:
He said, what a joy it is to learn not only that my conjecture has a nice solution, but also to celebrate this dramatic advance in automatic deduction and creative problem solving. I'll try to tell the story briefly in this note, and I can't go into this any further. I mean, he digs into— I mean, I, on the podcast, I can't explain it, um, but he explains that, that, I mean, it really went through a series of astonishing reconceptualizations of the problem. And like over the next 4 pages, he shows, you know, eye-crossing formulas and detail with Claude trying over and over, approaching and tackling the problem from different directions and angles And then he finally finishes his recitation of Claude's success by writing, oh, and this was done by an associate of his, Philip, who then presented Knuth with the solution. So he writes, Philip told me that the explorations reported above, though ultimately successful, weren't really smooth. He had to do some restarts. When Claude stopped on random errors. Then some of the previous search results were lost.

Steve Gibson [02:09:38]:
After every 2 or 3 test programs were run, he had to remind Claude again and again that it was supposed to document its progress carefully. Then finally he said, delicious success for an odd M at exploration number 31. So 31 full deep attempts and Claude found the solution. He said at exploration number 31 came about 1 hour after the session began. All in all, this was definitely an impressive success story. I think Claude Shannon's spirit is probably proud to know that his name is now being associated with such advances. Hats off to Claude.

Leo Laporte [02:10:30]:
Isn't that great? Yeah, I read that too.

Steve Gibson [02:10:33]:
Yeah. This is somebody who knows his stuff.

Leo Laporte [02:10:38]:
Yeah. If Donald Knuth says Claude's doing something important, that's pretty convincing to me. I should mention, by the way, that the creator of the quicksort algorithm, which is documented in Knuth's book, C.A.R. Hoare, passed away this week. He was in his late 80s. He was fairly old. And incidentally, Claude, I said, "Hey, Claude, I hear that that LCG algorithm is problematic." And then I said, by the way, I had accidentally was using the older model, so I turned on Opus 4.6, which is demonstrably better. And it says, oh yes, LCG has well-known issues.

Leo Laporte [02:11:20]:
Low bit cycles with short periods and sequential values are correlated. A much better fit for x86 is XOR shift. George Marsaglia, 2003.

Steve Gibson [02:11:31]:
Yes, prime.

Leo Laporte [02:11:31]:
Yeah, it uses only shifts and XORs, cheap on 8086, and has far better statistical properties. Yep. And so it's written it, and, uh, you know, nice. It says one caveat, XOR shift can never output zero, so the range is 1 to 65535. The seed must also be non-zero. And that said, I updated seed RNG, which now guarantees that with a fallback. Very nice. Yeah, it's 106 lines of code, so it's not super, super compact, but for assembler, that's not too huge.

Steve Gibson [02:12:08]:
Yeah, it ought to be like 12 lines.

Leo Laporte [02:12:13]:
Yeah, what it's doing— the Claude, uh, doesn't have to actually type this stuff, so it's not necessarily the most, uh, concise.

Steve Gibson [02:12:24]:
Wow. Anyway, uh, no, here's that great saying: we have moved into a new world of, of deductive problem solving fully. I mean, this was some wacky abstract, uh, uh, uh, Hamiltonian cycle problem that, you know, it just makes your— well, I was gonna say it makes your hair fall out, but I've obviously spent some time working on that. Crazy. Just amazing. Um, oh, uh, Michael P. said, Steve, I'm sure you've heard from many listeners, and I had heard from— I have heard from several others about CISA's Cyber Hygiene Service free weekly scanning. And I have the link in the show notes.

Steve Gibson [02:13:11]:
He says, we have been using this service for a few years. The first report we received was sobering but actionable. He said, I manage the firewalls but not the servers. The huh look from the server admin when I showed him the report was entertaining. Needless to say, we jumped on these vulnerabilities and had them all resolved in order of severity in short order. Anytime a new one arises, it is immediately addressed. He says, bonus, we had been paying a company $6,000 to perform this service for us once a year to satisfy insurance requirements. Now We're able to use the free CISA report as evidence for our insurance provider.

Steve Gibson [02:14:01]:
Thanks for all you do. Listener since episode 35, club member, and past and present customer of several advertisers, Michael Dothan in Alabama. Okay, so I recall that we talked about this back when it was first introduced, but I'm glad Michael mentioned it again. The only downside is that this service is not generally available, which is why I have not made a bigger deal about it. Under the pages who can use this service, the page states US-based federal, state, local, tribal, and territorial governments, as well as public and private sector critical infrastructure organizations, are welcome to enroll by following the instructions in the Get Started section below. Michael wrote to me from his personal Gmail account, so it's unclear what organization, quote, we have been using this service for several, for, for a few years, unquote, refers to. Out of curiosity, I initiated a sign-up request with CISA to see whether they might have broadened their support. Okay, now since I wrote this, um, that effort appears to be working.

Steve Gibson [02:15:18]:
I filled out a bunch of forms, identified myself to CISA. It allowed me to say that I was a private sector organization, that I was a, like, a software publisher entity, not making any overblown claims. From the, you know, the importance of GRC, and I gave it my organization's, uh, you know, CIDR block, my 16 IP address block at level 3. So we'll see whether I qualify, and, uh, if it happens, then it looks like, you know, they're making room for other non-infrastructure critical organizations. And boy, They, the reporting, I thought I had it somewhere. It's not here. It's probably because it's happened since Sunday when I sent the show notes out. But if they identify something that they regard as critical, they like recheck it every 24 hours.

Steve Gibson [02:16:28]:
And you get like, you get seriously notified. That you've got a problem that needs to get fixed. And the, the retesting rate is a function of the criticality of what they find. So it looks like a fantastic free service, uh, if we, you know, collectively, our listeners, qualify. Certainly if you are federal, state, local, tribal, territorial, uh, public or private sector critical infrastructure do this. Why wouldn't you? So I'll let everybody know if GRC qualifies. I would love to have CISA scanning my network block, letting me know if there's anything that they think I should fix. I'll be surprised, but then people do get surprised, and that's the whole point.

Steve Gibson [02:17:20]:
And finally, uh, uh, Berent Jenkins says, Steve, while listening to this week's episode, you responded to a listener who asked about the possible use of self-signed software. There is one pain point that these self-signed certs could help with, and that is the limit on the number of signings you can do without paying extra. That's a very good point. If, like, things are moving to the cloud and we're going to start getting charged per signature, which, oh my God, it would be annoying. He said, for those compiling and testing many iterations of their software before sending it out to a wide world, self-signed certs could be used to reduce the number of times that you use a CA to sign your code. You could save your valuable limited number of signings for the public releases of your software. A lot of the people you use to test your software probably won't have any problem installing a self-signed cert, you know, like your own root CA, just for the purpose of testing it. It could save small developers a lot of money while working on their own software.

Steve Gibson [02:18:33]:
So I think that's a very good point. Use of a self-signed cert within a closed circle of development testers and only sign the final release with a publicly trusted CA issued certificate. Uh, and I, I want to go back to the cisa.gov piece because I feel like I skipped over it. I do have the notes, I have the URL in the show notes. For anyone who's listening, it's— and it doesn't get the show notes or have them— cisa.gov, g-o-v, then it's forward slash cyber hyphen hygiene hyphen services. Cyber hygiene services separated by hyphens. Why would you not sign up and get, uh, free scanning? I think that it makes a lot of sense. So again, thank you, Michael P., for, uh, bringing that to our attention.

Steve Gibson [02:19:30]:
And back to mine, I just assumed it was only government agencies, but they, they seem to embrace me. I mean, I've had several email back and forth, and it's now being, you know, I'll hear from them as soon as they, uh, are ready to go. So we'll see.

Leo Laporte [02:19:46]:
Clearly deem you a critical infrastructure organization.

Steve Gibson [02:19:49]:
I think it's a very, uh, soft—

Leo Laporte [02:19:54]:
they want to discourage home users from signing up for this, probably. Yeah, but I think if you're running a server and you're putting commercial software on there for people to download, I think you can.

Steve Gibson [02:20:05]:
Yeah, that would be cool. That means that a huge portion of our listeners are, you know, in their enterprises could also benefit from this. Would be really cool.

Leo Laporte [02:20:14]:
Yeah, he said he was spending $6,000 a year.

Steve Gibson [02:20:17]:
Yeah, his insurance, his cyber insurance policy required an annual full review, a scan, a security scan for which they were paying $6,000 in order to get their cyber insurance policy. So CISA does it for free, and it's CISA.

Leo Laporte [02:20:41]:
Yeah. Oh, by the way, Sci-Face in our Club Twit Discord says, of course Steve is critical infrastructure. He has software on the space station, for crying out loud. Just mention that in the email. I think they'll immediately sign you up. It's a good point, Sci-Face. Good point.

Steve Gibson [02:20:58]:
Okay. Our last break, and then you can't hide from LLMs.

Leo Laporte [02:21:03]:
Do you want to see the— It turns out it's a pretty trivial thing that I gave it. Once I explained that he shouldn't use that bad algorithm, it understood that, oh yeah, this is the algorithm I'm going to use, which is the XOR shift.

Steve Gibson [02:21:19]:
Okay. Makes much more sense.

Leo Laporte [02:21:20]:
Yeah. Much more sense. And it is, and the 100 lines is, A lot of that's comments. There's even a whole block of generating. So it's really quite simple. It's getting a BIOS system timer tick count, getting the low word, making sure it's not zero. And then it's doing the shifts pretty quickly, couple of moves, and then it's returning the number. So it's pretty straightforward.

Steve Gibson [02:21:47]:
Yeah. And you, it did, I'm seeing that it did do Uh, it is, it is all 16-bit code. You could ask it for, uh, 64-bit or 32. Yes, or, or at least 32-bit x86 code.

Leo Laporte [02:22:00]:
Yeah, this is a random 16-bit value. Yeah. Um, yeah, you could totally ask it for that. Now the other thing is, notice how nicely commented it is.

Steve Gibson [02:22:08]:
It is actually, and I noticed that it wrote a, um, I mean, it's a full program, that thing. Yep. Up at the top it says.small and model and so forth.

Leo Laporte [02:22:19]:
Yeah, yeah, it's doing the whole thing. In fact, it even says—

Steve Gibson [02:22:22]:
And sets the stack.

Leo Laporte [02:22:23]:
It notes that the dx to ax clobbers the tick count, and it notes that at the end. So here's the demo. It gives you a little generate 5 random numbers and print them so that you know that it's actually doing something. And then it says at the end, note the comment says clobbers ax. Cl, but rand also clobbers bx. Worth fixing if this is going into a library header.

Steve Gibson [02:22:49]:
And I notice it also uses the console in order to actually print things. So there's a lot more than just the random number generator.

Leo Laporte [02:22:55]:
That's very— yeah, it's, it's a fairly, uh, I mean, I would say this is— it gives you the impression it understands what it's doing and, uh, yeah, did something intelligent. It didn't pick the right algorithm at first, but that's because I was— I'm, I'm using the wrong model.

Steve Gibson [02:23:10]:
Color me impressed, my friend. Yeah, it is, uh, It is really, I think it's, it fundamentally changes what we think of as coding by introducing an automated middleman between this is what I want and, right. And, you know, right. And I need code to do it.

Leo Laporte [02:23:30]:
Right. I mean, and this is a super trivial little thing, but just, you know, I didn't want to take something, do something that would take hundreds of lines of code. So. You are watching Security Now. Aren't you glad you're here? We do this every Tuesday right after MacBreak Weekly, about 1:30 Pacific, 4:30 Eastern, 20:30 UTC. Yes, we're in daylight saving time now, so we've shifted over. 20:30 UTC. You can watch us live on twitch.tv, x.com, youtube.com, Facebook, LinkedIn, and Kick.

Leo Laporte [02:24:05]:
And if you want to watch live, I hope you will. If not, after the fact, on demand at twit.tv/sn. Steve's got copies of the show. I'll explain a little more about what he's got, kind of unique versions at his website, grc.com. There's a YouTube channel, and of course it's a podcast, so you can subscribe in your favorite podcast client. Now, since we're talking about LLMs, let's talk about LLMs.

Steve Gibson [02:24:31]:
It turns out that mimicking human consciousness is not the only thing LLMs can be spookily adept at. It will probably not come as a huge surprise to learn that LLMs can be frighteningly good at discriminating among similar-appearing objects, including among people. Our friends at ETH Zurich with some help from Anthropic, have been at it again. Their recent paper, published less than 2 weeks ago, bears the title Large-Scale Online De-Anonymization with LLMs. Here's what we learn about the latest trick they've taught LLMs. Their paper's abstract is very, very, uh, techie, uh, sounding abstract, but Everyone will get the, you know, a sense for this. They said, we show that large language models can be used to perform de-anonymization at scale with full internet access. Our agent can re-identify Hacker News users and Anthropic interviewer participants at high precision.

Steve Gibson [02:25:48]:
Actually, it doesn't say it here, but it's 99% accurate. Given pseudonymous online profiles and conversations alone, matching what would take hours for a dedicated human investigator. We then design attacks for the closed-world setting, given two databases of pseudonymous individuals, each containing unstructured text written by or about that individual, We implement a scalable attack pipeline that uses LLMs to 1, extract identity-relevant features, 2, search for candidate matches via semantic embeddings, and finally, 3, reason over top candidates to verify matches and reduce false positives. Compared to classical deanonymization work, And they, they cite a previous example known as the Netflix Prize that required structured data. Our approach works directly on raw user content across arbitrary platforms. We construct 3 datasets with known ground truth data to evaluate our attacks. The first links hacker news to LinkedIn profiles using cross-platform references that appear in the profiles. Our second dataset matches users across Reddit movie discussion communities, and the third splits a single user's Reddit history in time to create two pseudonymous profiles to be matched.

Steve Gibson [02:27:30]:
In each setting, LLM-based methods substantially outperform classical baselines achieving up to 68% recall at 90% precision compared to near 0% for the best non-LLM method. Our results show that the practical obscurity protecting pseudonymous users online no longer holds and that threat models for online privacy need to be reconsidered. Wow. It turns out that individuals who believe their identity is well protected simply by their use of online handles are likely to be far more readily de-anonymized than they might imagine. So I'm only going to share the paper's introduction since it suffices to make their case. They wrote, for decades it's been known that individuals can be uniquely identified from surprisingly few attributes. Sweeney's seminal work demonstrated that 87% of the U.S. population could be uniquely identified by just zip code, birth date, and gender.

Steve Gibson [02:28:51]:
Narayanan and Shamatakov showed that anonymous Netflix ratings could be linked to public IMDb profiles using only a handful of movie preferences, while DeMontjoy et al. proved that 4 spatiotemporal points are enough to uniquely identify 95% of individuals in mobile phone datasets. Despite these attacks, pseudonymous online accounts, Reddit throwaways, anonymous forums, you know, review profiles, etc., have remained largely unaffected by de-anonymization attempts. The reason is simple. Applying such attacks in practice has required structured data amenable to algorithmic matching or substantial manual effort by skilled investigators reserved for high-value targets. De-anonymization is a two-step process at heart, involving profiling an anonymous person from their posts and then matching them to a known entity. It's well known that large language models can infer personal attributes from text on online forums. Given this, it makes sense to ask how good are LLMs at full end-to-end deanonymization? And this is a practical threat to pseudonymous accounts.

Steve Gibson [02:30:32]:
Our contributions. We demonstrate that LLMs fundamentally change the picture, enabling fully automated deanonymization attacks that operate on unstructured text at scale. We show this by phrasing de-anonymization as a matching problem and showing LLMs can perform all steps needed to match accounts, extract identity-relevant signals from arbitrary text, efficiently search over millions of candidate profiles, and reason about whether two accounts belong to the same person. We show that the practical obscurity that has long protected pseudonymous users, the assumption that deanonymization, while theoretically possible, is too costly to execute broadly, no longer holds. We validate this thesis in three deanonymization settings: matching an online account to its real identity, linking an identity to an unknown pseudonymous account, and linking pseudonymous accounts of the same person across different platforms or time periods. These settings capture distinct threat models. For example, doxxing of an online account a stalker targeting a victim, or an adversary consolidating a user's activity, and pose different technical challenges. Okay, in other words, for us, the emergence and presence of LLM technology with its application of massive computing resources completely changes the game for the strength of online pseudonymous identities.

Steve Gibson [02:32:31]:
Many new capabilities are almost certain to eventually come online. For example, you know, it becomes entirely feasible now for law enforcement and intelligence services to identify and track individuals through their online style, their word choice and beliefs as reflected in their online postings. Not feasible to do it before, now feasible. We've been thinking of the NSA's massive data center as a storage repository of encrypted data being sucked in from all over the internet, which may someday be revealed when quantum computing cracks traditional crypto. But imagine if the NSA's data centers were instead sucking down the same already decrypted plaintext content that all of the rest of us see. But now it's being fed into massive LLM technology to de-anonymize persons of interest. Whether we may like it or not, we're each individually leaving identifying content in everything we post. As these researchers noted, historically until now, this wasn't an issue since the cost of performing such deanonymizing would have been astronomically high, making it completely infeasible.

Steve Gibson [02:33:59]:
The emergence of LLM technology has forever changed this calculus. Their paper's discussion section at the end summarizes what they believe their findings mean. They write, deanonymization is one instance of LLMs acting as an information microscope that makes previously manual and expensive attacks scalable. Our paper shows that LLMs democratize deanonymization. Echoing concerns raised by prior work on LLM-based attribute inference and semantic privacy leaks, we argue that the asymmetry between attack cost and defense cost may force a fundamental reassessment of what can be achieved private— or, I'm sorry, what can be considered private online. Our large-scale experiments provide quantitative evidence for these concerns in the deanonymization setting. So what do our findings mean for the future of privacy? Governments could link pseudonymous accounts to real identities for surveillance of dissidents, journalists, or activists. Corporations could connect seemingly anonymous forum posts to customer profiles for hyper-targeted advertising.

Steve Gibson [02:35:26]:
Attackers could build sophisticated profiles of targets at scale to launch highly personalized social engineering scams. Hostile groups could identify important employees and decision makers and build online rapport with them to eventually leverage in various forms. Users, platforms, and policymakers must recognize that the privacy assumptions underlying much of today's internet no longer hold. In other words, yikes. I put the link to their extensively detailed 25-page PDF paper in the show notes here at the end for anyone who might wish to dig deeper. Uh, there's nothing any of us can do, but it might be worth keeping it in mind. We are— if somebody deploys something like this, um, we're leaving our footprints everywhere because I'm actually surprised that it can do this.

Leo Laporte [02:36:33]:
Yeah. Did they say it was a specially trained LLM for this particular use? No, don't know.

Steve Gibson [02:36:40]:
No, I mean, I'm sure that they've, they've taken an LLM and, and they're not prompting it. They are— they're, they're, they're using the LLM technology.

Leo Laporte [02:36:51]:
Wow. Yeah, that's, that's really kind of Surprising.

Steve Gibson [02:36:56]:
It's frightening, but I would argue not surprising. Look, I mean, okay, so how surprised are we that it can talk?

Leo Laporte [02:37:05]:
Right. Now that's surprising.

Steve Gibson [02:37:08]:
Okay. So, so if it can talk, I mean, if it's something that can talk, then this is just something like that is doing something else that is also surprising.

Leo Laporte [02:37:20]:
It could talk and write assembly code.

Steve Gibson [02:37:25]:
It's packed with— We've unleashed a huge new thing.

Leo Laporte [02:37:32]:
It's amazing. It's just, I don't know about you, I suspect this is the case. It's exciting because it's something that's been promised by sci-fi and computing theory from the very earliest days.

Steve Gibson [02:37:46]:
Leo. I worked at something that called itself the AI Lab, which, you know, was trying to move a chess piece on the board with a robot hand and eye.

Leo Laporte [02:37:57]:
Do you feel like you were at Stanford's AI Lab? This was a changer. Do you feel like it's a continuity, like the work done there was the predecessor of the work, or is it— is there— I feel like Transformers came along And it was a discontinuity. It was a big paradigm shift. It was a little different than the expert systems that Sale was working on.

Steve Gibson [02:38:19]:
Yeah. And remember that this is all outgrowth of neural network, right? So, so, you know, the heart is real, a neural network. The— what the question— this is the answer to the question, what if we make it way bigger, right? You know, so a small neural network can like maybe figure out to turn the lights on when the sun goes down, but that's about it. This is like, what if we hyperscale a neural network? What happens?

Leo Laporte [02:38:48]:
And then something interesting happens.

Steve Gibson [02:38:50]:
Hello, Dave.

Leo Laporte [02:38:52]:
Yes, something very interesting and, uh, somewhat unpredictable, to be honest, uh, happens.

Steve Gibson [02:38:59]:
It's fundamentally unpredictable. I mean, in fact, so that it doesn't bore us, we add unpredictability, we actually pour it in.

Leo Laporte [02:39:09]:
Stochastic, yes.

Steve Gibson [02:39:10]:
Called a temperature setting.

Leo Laporte [02:39:14]:
Right. We live in interesting times. Aren't you glad you listen to this show to keep up with all this stuff? That's Steve Gibson. That's his job. And you know what's fun about, for both of us, is we've been about this job for a long, long time, and we have seen what's happened. And I think it's really fun that we can still be amazed, that we can still go, wow, it can do that. Wow. That's pretty exciting.

Leo Laporte [02:39:41]:
Very exciting. Thank you, Steve. Steve is at GRC.com. Now, if you want to send Steve a comment, a suggestion, your own experiences, easy to do. Go to GRC.com/email. Steve has some sort of magic system for determining whether you are a bot or not, all done magically. And he will vet your email. And if you are in fact a human with good intentions, not bad, he will add you to the list of whitelist of people who can write to him.

Leo Laporte [02:40:12]:
You'll also have a chance when you're at that page to check two boxes, one for the weekly mailing of the show notes, but sends them out the day before, most of the time, the day before the show. And then the other, which he rarely uses, which is an announcement of new products. Um, both of those are unchecked by default, so make sure you look down at the bottom of the page, check those. While you're at grc.com, of course you can get this show there. He's got 2, 3 unique versions of this show, 4 unique versions of the show. He's got the 16-kilobit audio, which is a little scratchy admittedly, but has the virtue of being very small. He has the 64-kilobit audio, which sounds fine, is a good size. That's certainly, if you don't want to waste bits, the one to get.

Leo Laporte [02:40:56]:
He has the show notes, which today are 22 pages of goodness with pictures and links and everything you'd need if you listen to the show. This is a great companion. And a couple of days after the show's published, he will also have a transcript of the show written by a human being, Elaine Farris, because we believe in hiring humans. That's going to be our new motto. Hire a human today. Uh, Elaine does a great job. You can get those all at grc.com. And of course, Steve's bread and butter, Spinrite, the world's best mass storage maintenance, recovery, and performance-enhancing utility, version 6.1 currently.

Leo Laporte [02:41:36]:
And his newest, uh, program, uh, a mere $10. It is the DNS Benchmark Pro to test your DNS servers and find the fastest one, uh, for you.

Steve Gibson [02:41:49]:
Uh, yeah, speed up.

Leo Laporte [02:41:52]:
You know, it's funny, I, I, I have OpenDNS or NextDNS, and every once in a while it just stalls, and I don't know why. And I have to turn it off and on again. I have to reboot it. I don't know why that is. It's a strange thing. Maybe I should run the DNS Benchmark Pro and find a better DNS server. That's what I should do. Uh, we also have copies of the show at our website, twit.tv/sn.

Leo Laporte [02:42:14]:
There's a YouTube channel dedicated to it. Uh, there is also, of course, you can subscribe. It's a podcast in your favorite podcast client. Leave us a nice review. Tell the world about the most important podcast you listen to all week, Security Now. Uh, thank you, Steve. Have a great week. Enjoy the Ides of March, and we will see you next week.

Steve Gibson [02:42:36]:
All right, bye.

Leo Laporte [02:42:38]:
Hey everybody, Leo Laporte here, and I'm gonna bug you one more time to join Club Twit. If you're not already a member, I want to encourage you to support what we do here at Twit. You know, 25% of our operating costs comes from membership in the club. That's a huge portion, and it's growing all the time. That means we can do more, we can have more fun. You get a lot of benefits, ad-free versions of all the shows, you get access to the Club Twit Discord and special programming like the keynotes from Apple and Google and Microsoft and others that we don't stream otherwise in public. Please join the club if you haven't done it yet. We'd love to have you.

Leo Laporte [02:43:19]:
Find out more at twit.tv/clubtwit. And thank you so much.

Steve Gibson [02:43:28]:
Security