Transcript of Episode #1030

Internet Foreground Radiation Description: An exploited iOS iMessage vulnerability Apple denies? The NPM repository is under siege with no end in sight. Were Comcast and Digital Realty compromised? Don't ask them. Matthew Green agrees: XChat does not offer true security. We may know how Russia is convicting Telegram users. Microsoft finally decides to block two insane Outlook file types. 40,000 openly available video cameras are online. Who owns them? Running SpinRite on encrypted drives. An LLM describes Steve's evolution on Microsoft security. What do we know about the bots that are scanning the Internet? High quality  (64 kbps) mp3 audio file URL: http://media.GRC.com/sn/SN-1030.mp3 Quarter size (16 kbps) mp3 audio file URL: http://media.GRC.com/sn/sn-1030-lq.mp3

SHOW TEASE: It's time for Security Now!. Steve Gibson is here. Apple denies it, but there's clearly an exploited iOS Message vulnerability. A good reason not to use Telegram ever, ever, ever. And Steve's evolving opinion of Microsoft security. I think you can guess which direction it's headed. All that and more coming up next on Security Now!.

Leo Laporte: This is Security Now! with Steve Gibson, Episode 1030, recorded Tuesday, June 17th, 2025: Internet Foreground Radiation. It's time for Security Now!. I know you wait all week for Tuesday to come around. Steve Gibson is here, the man in charge of Security Now!, our expert. I shall give you the Klingon salute.

Steve Gibson: Oh, that's good.

Leo: Yesterday I went - our wonderful little coffee shop in town which has really become a community center, good friend of mine runs it, has a game night on Monday nights. And I brought my chess set down. I thought, oh, this will be fun. Maybe I'll get somebody to play chess with me. And I set it all up, put the clock there. Nobody was playing. But there was a guy across from me setting up his Star Trek 3D holochess that plugs in, and the things light up and stuff. And I said - I came over, I said, "Hey. I've got to play some." He said, "Well, I don't know the rules, and I seem to have lost the booklet." So I asked ChatGPT. ChatGPT knew the rules.

Steve: Oh, of course.

Leo: Fortunately, the proprietor had also saved the booklet. What ChatGPT said is, since there are no canonical Star Trek rules for holochess, people have made them up over time.

Steve: I was going to ask whether, you know, did I miss that episode? Because, you know, they always were moving them around.

Leo: Yeah. You knew they were playing.

Steve: Yeah.

Leo: But here's the photo of Chris and Peggy and me playing...

Steve: Oh, good.

Leo: ...Star Trek holochess. And it had sound effects, and the pieces light up and stuff. And the rules are so complicated that you get a card that you hold so you know - there's a piece called a Ghhhk, I guess that's how you pronounce G-H-H-H-K. Anyway, it was a lot of fun. We played to a draw.

Steve: I think Klingon was actually a fully realized language; wasn't it.

Leo: I think there's some Klingon names in this thing.

Steve: Yeah, you can actually speak Klingon.

Leo: Oh, yeah. There's people who - yeah. Apparently Shakespeare has been translated to Klingon.

Steve: It is a fully realized language.

Leo: Yeah.

Steve: So, yes, because before computers we didn't have enough to keep us busy. Unlike the case now.

Leo: Anyway, it was a lot of fun. And there's a name for it, too, which I can't remember off the top of my head.

Steve: It's not "gherk."

Leo: No. It's something almost equally silly, like "gajeet" or something. But anyway, yeah.

Steve: And as an accomplished chess player, Leo, was it actually a useful game, or just...

Leo: No, no, chess is so much better. If I could have just gotten anybody to play chess with me, I would have been - it's called Dejarik. It's not - did I say Star Trek? It's Star Wars.

Steve: Oh. Oh, oh. And that does look like the board...

Leo: Yes, this is the one they were playing on the Millennium Falcon.

Steve: Yes, yes. The board...

Leo: I apologize.

Steve: Yeah, okay.

Leo: I get them confused.

Steve: No, no, you don't.

Leo: I do.

Steve: No, you don't.

Leo: And it's not good, yeah.

Steve: You can't do podcasts if you confuse Star Trek and Star Wars.

Leo: I know. They're going to take away my geek credentials. Ohhh.

Steve: That's, I'm sorry, that's not okay.

Leo: What's coming up on Security Now!?, as I sit in shame.

Steve: So we're going to talk about - I had fun with the title because for 20 years I've been talking about a term that I coined, "Internet Background Radiation."

Leo: Yes.

Steve: Today's podcast is titled "Internet Foreground Radiation."

Leo: What?

Steve: And we're going to find out what that's all about. But we're also going to look at an exploited iOS iMessage vulnerability which Apple is denying. Do we trust them? Are they saving face? We don't know. The NPM Repository is under siege with no apparent end in sight. Two pieces of news there, not good. Were Comcast and Digital Realty compromised? You know, don't ask them. They'll say no, not here. But evidence and even some serious agencies suggest otherwise. Matthew Green has agreed that XChat does not offer true security. We touched on that last week. I said I might dig deeper into it. I don't have to because Matthew did for us. We may know how Russia is convicting users of Telegram, and it's not by decrypting their messages.

Leo: Uh-oh.

Steve: Interestingly enough. Microsoft finally decides to block two insane Outlook file types, and I'm going to deliberately control my language because we have young listeners of this podcast.

Leo: Good.

Steve: But, boy.

Leo: Wow. I know you want to.

Steve: Ugh. It turns out, just as we were doing the podcast last week, Leo, you ran across the news that 40,000 video cameras were online on the Internet. I've got the details to follow that up and, interestingly enough, where they are and who owns them. Also there was a question about running SpinRite on encrypted drives that I'm going to cover briefly. And then, oh, a listener also sent the result of their dumping all of Elaine's transcripts into an LLM, and then asking it how my opinion of Microsoft security has evolved over time.

Leo: Oh, boy.

Steve: And what do we know about the bots that are scanning the Internet to create Internet Foreground Radiation. So, and, oh, a Picture of the Week that is - I sent the show notes out about 24 hours ago, yesterday afternoon. This one generated more LOLs than is common. I am going to have to describe before we explain this what it means to refactor code because...

Leo: Oh, I know that well, so...

Steve: I know you do. And I also have had to do so from time to time.

Leo: Once or twice, yes.

Steve: But anyway, we have a great Picture of the Week.

Leo: Can't wait. I have not looked at it. We will see it together in just a minute or two on this episode of Security Now!. Can't wait. Always look forward to this. Go ahead, have a little sip of java. There's a lot of work ahead of you, Steve. All right. I'm ready for the Picture of the Week. Set me up.

Steve: Okay. If you're willing to wait for our listeners...

Leo: Of course.

Steve: I was going to say you could jump ahead if you didn't read it out loud. Okay.

Leo: I'll wait.

Steve: So what I need to explain, for those who are not coders, is what the process of refactoring a code base is. And it really comes from - it came from math, where, for example, if you have the number 30, there are a bunch of factors of 30.

Leo: Right, right.

Steve: You know, 2, 5, 10, 15, 30.

Leo: Two times 5 times 3, yeah, yeah, yeah, yeah.

Steve: So there are different, the point is there are different ways to break that 30 down into its factors. But one of the things that happens with code is you start off with kind of an idea of what you're going to do, and you say, okay, I'm going to put these things in this file, and the things for the user interface, they're going to go over here. And things for the database go in the database file. And everything sort of starts off right. And then, you know, reality hits. You know, it's time for version 1.5. And some guy says, well, but AI, now, we need an AI. It's like, ooh, crap, where do I put that? So you kind of stick it in somewhere just to get it working because the boss says you've got to ship this yesterday, what's taking you so long. And a few years go by, and the point is that code notoriously does not evolve well. It just kind of - it gets stuff hung on it like barnacles and strange fungus and, you know, it just - it's not good. And so it gets to a point, typically, where at some point you say, okay, wait. We're having a hard time maintaining this because it just doesn't make any sense anymore. And so we need to refactor it. It basically means sort of just saying, okay, hold on. This thing over here should really go over there. And this one function ended up with so many arguments that nobody knows what it does anymore. So let's break this up into multiple smaller pieces, each which has a clearer task. I mean, sort of it's like a rethinking of something big and complex. Okay. So with that background, the title I gave this perfect snippet from Twitter, or X, was "A perfect summation of where we are today with AI."

Leo: All right. Now, I have not seen this. I'm going to scroll up here.

Steve: And you should read it to yourself.

Leo: "Claude 4 just refactored my entire codebase in one call. 25 tool invocations, 3,000+ new lines, 12 brand new files. It modularized everything. Broke up monoliths. Cleaned up spaghetti. None of it worked. But, boy, was it beautiful." Yeah. Yeah. I've seen that happen, actually. Yeah.

Steve: Oh. This is just great. So anyway, so this guy, Vas is his handle on Twitter, or his name, his actual handle's a lot longer, he dumped some massive codebase into Claude 4 and said, "Fix this." And, oh, it was so impressive. Of course, it broke his code completely.

Leo: Yes.

Steve: He says: "But oh, my god, it's just so pretty now."

Leo: But made it much worse. Yeah.

Steve: Doesn't work. Doesn't work. But wow. If it did, that would be great. Anyway, yes. Where we are today with our AI. Okay. So the mobile threat hunting security firm iVerify posted the news of their discovery under their headline: "iVerify Uncovers Evidence of Zero-Click" - which, you know, is the worst kind - "Mobile Exploitation in the U.S." And at that point it's like, okay. That seems kind of generic. It could be whatever. Then we find out, they wrote: "Throughout late 2024" - so quite recently - "and early 2025, iVerify detected anomalous activity on iPhones belonging to individuals affiliated with political campaigns, media organizations, AI companies, and governments operating in the United States and the European Union. "Specifically, we detected exceedingly rare crashes typically associated with sophisticated zero-click attacks via iMessage, an exploitation technique previously unobserved in any systematic way in the United States. Subsequent forensic examination of several of these devices ultimately revealed a previously unknown vulnerability in the 'imagent'" - I-M-A-G-E-N-T process, you know, image agent, so they just crunched it together - "process which, owing to its relative position in the operating system and its functionality, would provide attackers a primitive for further exploitation. This vulnerability was patched by Apple in iOS 18.3. We've dubbed this vulnerability NICKNAME because it's taking advantage of an apparent flaw in iMessage's Nickname functionality." They said: "In the course of our investigation, we discovered evidence suggesting - but not definitively proving - this vulnerability was exploited in targeted attacks as recently as March of this year. Specifically, we learned that Apple sent Threat Notifications to at least one device belonging to a senior government official in the EU on which we saw the highly anomalous crashes." So some correlation there. We don't know about causation. "Likewise, one device demonstrated behavior frequently associated with successful exploitation, specifically the creation and deletion of iMessage attachments in bulk within a matter of seconds on several occasions after an anomalous crash." Again, that's not normal. "We only observed these crashes on devices belonging to extremely high-value targets, and these crashes constituted only .0001% of the crash log telemetry taken from a sample across 50,000 iPhones." They said: "While this evidence does not definitively prove exploitation, it is nonetheless difficult to ignore and merits a public discussion, particularly in light of Signalgate. Our findings suggest it doesn't matter what channel is being used to communicate if the device itself is compromised." And of course that's what we've been saying all along; right? You know, you may have a - even with Signal, if you've got a compromise in the device, it's before it's encrypted and after it's decrypted on the device. "Our findings suggest it doesn't matter what channel is being used to communicate if the device itself is compromised. Attackers have access to all conversations, regardless of whether those happen over Signal, Gmail, or any secure application. This is why it's crucial that organizations on the front lines of digital conflict - including the U.S. government - adapt their mobile security models to face modern threats. "Our findings have been vetted by multiple, independent third parties, including iOS security experts such as Patrick Wardle from the Objective-By-The-Sea foundation, who have confidence in our conclusion that mobile compromise is real, not academic or hypothetical, and that it's happening here in the United States." So what exactly are those findings? "So far, we've observed six devices total that we believe were targeted for exploitation by this threat actor, four of which demonstrated clear signatures associated with NICKNAME, and two which demonstrated clear signs of successful exploitation. Interestingly, all of the victims had either previously been targeted by the Chinese Communist Party (CCP), meaning they were confirmed to have also been targeted by Salt Typhoon; they were engaging in business pursuits counter to or of particular interest to the CCP; or they had engaged in some sort of activism against the CCP. We don't have enough evidence," they wrote, "to make clear attribution or a full view of an exploit chain, but the circumstantial evidence could indicate the CCP." So how does it work? "iPhones allow you to set a nickname or avatar for numbers in your contact list. The vulnerability is likely triggered by sending repeated, rapid-fire nickname updates to iMessage, which results in a use-after-free memory corruption." And of course we've just in the last few months, we've extensively looked at the idea of, well, of what is Use After Free and how a race condition could cause something, you know, that has been freed to get used before the access to it has completely disappeared. They wrote: "This makes NICKNAME a good candidate for a primitive to pivot off as part of a longer exploit chain. We believe this vulnerability correlates with successful iPhone exploitation, due to four concurrent factors: First, the extreme rarity of these specific crash patterns (<0.001% of all crash logs). Second, their exclusive appearance on devices belonging to high-value targets. Third, similarity to crash patterns seen in previously known spyware attacks. And, finally, evidence of successful exploitation, including the receipt of at least one Apple Threat Notification proximal to the observed behavior and evidence of 'cleaning' behavior." So is it still active? "Differential analysis reveals the vulnerability was patched in the iOS 18.3.1 release; however, NICKNAME could be one link in a larger exploit chain. It's possible that there are other elements of the exploit chain that are still active, which is why we're only speaking about the link in the chain that has definitively been patched. We provide a full technical analysis and look forward to sharing any additional material findings when our investigation concludes." I've got a link in the show notes to their full technical report, which is extremely thorough. And it's important to disclose that Apple is actively contesting this, although, boy, I mean, the evidence surely does point at this. Axios reported: "Apple has fixed the flaw which was present in iOS versions through 18.1.1 but disputes that it was ever used to hack devices." Ivan Krstic, head of Apple Security Engineering and Architecture, said in a statement: "We've thoroughly analyzed the information provided by iVerify, and strongly disagree with the claims of a targeted attack against our users." Krstic added: "Apple confirmed the underlying Nickname bug, but said its own field data from iPhones points to it being a 'conventional software bug that we identified and fixed in iOS 18.3.'" He said: "iVerify has not responded with meaningful technical evidence supporting their claims, and we are not currently aware of any credible indication that the bug points to an exploitation attempt or active attack. We are constantly working to stay ahead of new and emerging threats, and will continue to work tirelessly to protect our users." Okay. So the results are, at best, ambiguous. On the iVerify side, you know, if it walks like a duck and quacks like a duck - which this flaw certainly did - then it really would be reasonable to conclude that it's probably a duck. But as we have observed and talked about long ago, back when Kaspersky discovered some of their iPhones containing very similar malware, the very fact that iPhones have been so tightly locked down actively thwarts the type of post-exploitation forensic analysis that would allow third parties like iVerify to be able to dig more deeply and to help put pressure on and kind of keep Apple honest if, indeed, they were not already being. You know, I mean, Apple certainly doesn't want this to be true. Boy, but the circumstantial evidence, which is circumstantial because it's the only evidence you can get, because these iPhones are so well protected. The trouble is that the stakes in all this, as we know, have been raised to such a high level. iVerify referred to Signalgate in their posting, reminding us of the threat that high-level classified military operations planning was now known to have been conducted on non-secured civilian smartphone hardware. They didn't identify who these people were that were attacked, but they were explicit about saying "individuals in the U.S." Very high-value targets in the United States. They ended their disclosure with an important reminder, iVerify did. They wrote: "iVerify recommends that high-risk users keep their phones updated and turn on Apple's Lockdown Mode, which is designed to guard against spyware. iVerify's COO Rocky Cole said that it's likely that Lockdown Mode would have prevented these potential infections." And so that's just a reminder about that, given, you know, that all of the evidence continues to show - just consider last month's Pwn2Own competition against fully patched systems - that we do not, still do not currently have the technology or capability to perfectly secure our devices; you know? So having a bifurcated feature set where fewer features can be offered optionally to obtain greater security makes all kinds of sense. It's like Microsoft disabling their Edge browser's JIT (Just In Time) JavaScript compiler after observing that 80% of their Chromium-based browser's security problems were being discovered in the Just In Time compiler. And with computers having become so fast today, the Just In Time compiler optimization is way less necessary than it once was. So, you know, as we recall, they did some experiments where they experimentally turned it off in Edge, and nobody noticed. And so they thought, well, let's just leave it off because we have a much more secure browser with it that way. So anyway, no one's ever going to know. There was some reporting, I think it was last week or the week before, where somebody that I was referring to had made the comment that, while we don't get details from Apple, they do keep fixing things and rebooting our phones and - oh, it was about the whole jailbreak, the evolution in jailbreaking and how it was now much less feasible to, like, certainly not as a hobby, you know, offering you jailbreaking services. Those days are gone. But the point being, you know, Apple is still releasing supercritical important updates. They don't tell us why or how or what, but they're happening. So...

Leo: It feels like also if you really are a high-risk subject, you shouldn't be using a consumer-grade smartphone to begin with. Right?

Steve: Yes. Yeah. Yeah. As we covered at the time, it was - I think it was Obama who was very upset that...

Leo: They took away his Blackberry.

Steve: His Blackberry, where he's saying, hey.

Leo: But that's what, you know, that's what our security agencies do is they create hardened devices for this purpose.

Steve: Yeah, and they're much less fun to use, I'm sure.

Leo: Yeah, yeah, of course they are.

Steve: Yeah. It's just they don't have all the bells and whistles and goodies because every extra goodie is one more opportunity for exploitation, as we well know. Okay. So I got two quick bits that should serve to remind us, and that's just why I'm doing this, that the open source library system is more or less under constant attack. Which is, you know, Leo, where we say "why we can't have nice things" because, really? Gosh. Okay. So the Node JavaScript Package Manager (NPM), its facility description reads, just to remind everybody: "Relied upon by more than 17 million developers worldwide, npm is committed to making JavaScript development elegant, productive, and safe. The free npm Registry has become the center of JavaScript code sharing and, with more than two million packages, the largest software registry in the world. Our other tools and services take the Registry, and the work you do around it, to the next level." Great.

Leo: And of course Claude code is installed, as are many tools, through npm.

Steve: Right.

Leo: So if you're doing vibe coding, you're probably using npm.

Steve: And, I mean, the concept of a huge repository of useful libraries, where you can say, ooh, I need a regex parser, grab it from here. Oh, I need a background log writer. Oh, grab it from there. And, you know, you piece together a package using the well-intentioned and hopefully proven work of many other authors in order to glue together solutions much more easily. Unfortunately, its openness is also its challenge. The first piece of news that caused me to pause here was: "Eighty-four malicious npm packages were discovered and taken down last week." The advisory said: "Check out the GitHub security advisory portal for more details. This also includes two packages spotted by Socket that would wipe production systems."

Leo: So almost as well as an AI can.

Steve: So, nasty. Yeah. Almost as bad as asking AI to refactor our code, please. Gee, it used to work. I hope there's an undo on this. The second piece of news was a threat actor has compromised 16 npm libraries from the GlueStack UI framework. The attacker compromised a GlueStack admin's account, adding a remote access trojan to the libraries, and pushed updates on Friday. The affected packages are extremely popular and have almost one - get this, Leo - one million weekly downloads.

Leo: Oh, geez.

Steve: Aikido Security says the attacker is the same threat actor behind another supply chain attack on the rand-user-agent package last month.

Leo: Oh, we talked about that, yeah.

Steve: Yeah. And I have a snippet from Aikido Security's posting in the show notes. They note "Active NPM Supply Chain Attack - 1 Million weekly downloads." They wrote: "Today, we uncovered a rapidly evolving supply chain attack targeting GlueStack packages on NPM. More than 15 packages compromised so far. Nearly, again, 1 million weekly downloads. Malware includes a full-featured Remote Access Trojan." Lovely abbreviation is RAT, of course. "The latest package was compromised just one hour ago," before their one-hour previous, you know, before their posting. "The same threat actor behind the rand-user-agent attack is now targeting UI-focused packages like @react-native-aria/button, and @gluestack-ui/utils, and more. The malware gives attackers the ability to run shell commands, upload files, persist access, even after updates. This could have a massive impact, particularly for mobile developers using React Native. So developers, check your dependencies now. Security teams: Review access logs for anything suspicious." They finished: "We're tracking this live, so we will give updates." So, you know, this is another PSA. In this case it's a programmer service announcement, reminding and cautioning all of our listeners who may be availing themselves of the true value - I mean, this is the problem is this stuff is really valuable, so there's a strong interest in going there and using it - the true value of shared open libraries to nonetheless always remain vigilant and aware that not everyone who places code there is motivated by altruism.

Leo: Are there - silly question - libraries like this for assembly language? Any assembly language package repositories?

Steve: In the old - it's funny because there's never been a market, believe it or not, Leo. There were, in the early days, there were a couple assembly language libraries.

Leo: Like macro libraries or something.

Steve: Yeah. And, you know, the floppy disk and later a CD bound into the back cover, you know, so - and it was like, you know, it was like some well-meaning programmer sat down and wrote a toolkit. Here's a bunch of things to put text on the screen, here's a bunch of sorting routines, you know, this and that. Just sort of a hodgepodge. But after selling two copies, the publisher decided...

Leo: Not no more.

Steve: ...[crosstalk] both? Okay.

Leo: You know, that's one of the reasons I like Common Lisp. There's nobody messing with the common lisp package libraries. There's a good one called Quicklisp. There's a new one called Ultralisp. But I don't think attacks - it's not a target-rich environment, shall we say.

Steve: No. It's why I kept my realtor on Windows 98 for so long.

Leo: Exactly, yeah.

Steve: Because she was worried about viruses. And I said, Judy, you have different DNA in your computer. Viruses don't know, they look at that and ago, where am I?

Leo: They don't care. I don't want this person. Eww.

Steve: Time for a break? I'm going to wet my whistle, and then we're going to look at what happened with Comcast and Digital Realty. I didn't realize, I didn't know about Digital Realty. They're a massive datacenter provider, like it turns out that AWS and Google and those guys, they subcontract their space.

Leo: That's a good business. Think about it.

Steve: And, oh. Yeah.

Leo: You want to make money, don't be a gold miner, be the guys who make the picks and shovels.

Steve: Yeah. So I was scanning reports of a possible undisclosed breach of Comcast and the major data center enterprise Digital Realty, when I encountered this comment: "Inside two major U.S. telecom operators, incident response staff" - Leo, are you sitting down? - "incident response staff have been instructed by outside counsel not to look for signs of Salt Typhoon."

Leo: As a Comcast user, we're using it right now, I'm a little disturbed. Perturbed.

Steve: "Inside two major U.S. telecom operators, incident response staff have been instructed by outside counsel not to look for signs of Salt Typhoon."

Leo: What?

Steve: Said one of the people, "declining to name the firms because the matter is sensitive."

Leo: Because you wouldn't want to find it.

Steve: Gee, you think? So that's what has evolved from the intersection of big business, cybersecurity, and legal accountability. The reporting is from NextGov's cybersecurity reporter. The headline of the story was "U.S. agencies assessed Chinese telecom hackers likely hit data center and residential Internet providers." Now, this headline teases us with the phrase "U.S. agencies," which begs the question, which U.S. agencies made this assessment? To that end, the reporting says: "Two U.S. security agencies listed mass media provider Comcast and data center giant Digital Realty among companies likely ensnared by a Chinese hacking group previously found inside major U.S. and global telecom operators, according to three people familiar with the matter." So triple-sourced reporting. And guess who those two U.S. security agencies are? "The National Security Agency" - yes, our NSA, they wrote - "made the determination that Comcast had likely been impacted by the group known as Salt Typhoon, according to two of the three people. The Cybersecurity and Infrastructure Security Agency" - our illustrious CISA - "cataloged Digital Realty as being potentially compromised, the third person said. The people spoke on the condition of anonymity to discuss the matter's sensitivity. "Salt Typhoon breached major telecom carriers in a global, multi-year espionage campaign uncovered last year. Over time, news trickled out about the scope and scale of the incident, which was first reported by The Wall Street Journal. The hacking unit is part of a broader syndicate of state-backed groups tied to different military and intelligence arms of China's central government. The 'Typhoon' moniker comes from a Microsoft naming convention for Beijing-linked cyber actors. "Such intrusions, especially into a data center environment, could give the hackers a potentially far deeper foothold into infrastructure supporting the world's information service providers than previously known." This is what was really creepy about this. I hadn't really considered that data centers offer a different view than telecom providers. They wrote: "The agencies' assessments have not been previously reported. There's uncertainty among officials about who was impacted by Salt Typhoon. Various agencies across the U.S. government are in possession of lists of confirmed or potential victims, but it's not clear if the tallies are consistent with each other, adding to confusion about who may have been accessed, targeted, or marked for investigation. CISA, for instance, is in possession of a list of both telecom and information technology companies, but an FBI tabulation shows different entities." And here it comes. They wrote: "Making investigations into the breach more complicated is that multiple telecom providers have invoked legal strategies to protect themselves from disclosing compromise by the hackers." And this is what I quoted that caught my - that just brought me up short. "Inside two major U.S. telecom operators, incident response staff have been instructed by outside counsel not to look for signs of Salt Typhoon, said one of the people, declining to name the firms because the matter is sensitive."

Leo: Yeah, bad [crosstalk].

Steve: So yes, now we have deliberate and internally formalized "heads buried in the sand" strategies in place because employees, after all, may be deposed under oath. I hope that any cross-examining counsel has the presence of mind to ask whether they were ever instructed by anyone to avoid looking for signs of external intrusion, not just are they aware of any signs of external intrusion. The article continues: "One of the sources said that having been assessed as likely victims" - oh, and I should just mention it might be that the external counsel knows that counsel, that cross-examining counsel might ask them just that. Were you ever instructed not to look? And that when you think about it, saying yes, I was instructed not to look, is probably less damaging than looking and finding. That is, it's like better to say, yeah, my bosses told me don't look. So oops, I don't know. It's probably better not to know. I mean, even to admit that you were told not to look, than it is to be able to, you know, than if you did look and then had to say, yeah, and I did find evidence that we were compromised. Think about it. That's probably more damaging. So what a world. "One of the sources," they wrote, "said that having been assessed as likely victims, CISA representatives should have contacted Digital Realty and Comcast multiple times since December. It's not clear whether consistent back-and-forth communications were established. CISA tends to initiate outreach to potential victims when it's believed their networks are compromised, according to another person familiar with the cyber defense agency's notification process." Now, of course, a new concern this year is that CISA has recently suffered a significant and controversial reduction in personnel as a result of the job cuts enacted by DOGE. In the same way that it's impossible to prove a negative, it can be challenging to justify the presence of staff whose job is to prevent trouble. Right? Like, well, they're here to prevent trouble. Of course, this is the problem, it's a familiar problem, it's one that corporate CISOs also face, but on a government agency scale in the case of CISA. You know, someone challenges: "What are all those people doing over there?" to which the reply is "Well, they're keeping an eye on things." Which is then followed by the difficult-to-defend challenge: "So, why do we need so many of them?"

Leo: Right.

Steve: You know, I don't know. So as all of our listeners will appreciate, CISA, as we've often said on this podcast, has been doing a surprisingly tremendous job since it really got rolling a few years ago. I've often commented that I've been surprised by how proactive and effective it has been, especially considering that it's a government agency. So I hope, I sincerely hope these cutbacks will not compromise that. It's probably impossible to accurately gauge since we cannot know how things would have been with a significantly smaller CISA. We'll just need to watch and see. The reporting continues, writing: "A Comcast spokesperson told Nextgov: 'We've worked with law enforcement and government agencies and have closely monitored our network. [So this is Comcast speaking.] We have found no evidence that Salt Typhoon has impacted our enterprise network.' An intrusion into either provider could carry significant national security risks. Comcast," they write, "facilitates Internet access for millions of users and businesses, while Digital Realty hosts troves of physical infrastructure used by telecom operators, cloud providers, and governments to route global web traffic. "A CISA spokesperson said: 'As a policy, we do not comment on individual entities.' The NSA, for their part, declined to comment, and the FBI did not respond to a request for comment. Digital Realty did not return multiple requests for comment. "Nextgov reported in December that hundreds of organizations were notified" - hundreds of organizations were notified - "of potential Salt Typhoon compromise. Last month, CyberScoop reported that CISA and the FBI devised a coordinated notification campaign to alert affected companies and help them deter the hacks, sometimes providing new data to them on an hourly basis. The FBI concurred with other agency assessments that the Salt Typhoon attacks, broadly speaking, are the most egregious national security breach in U.S. history by a nation-state hacking group. "Marc Rogers, a seasoned telecommunications cybersecurity expert said: 'A breach of Comcast and Digital Realty would confirm what many of us in the cybersecurity industry already suspected, that the Salt campaign was broader than just telcos, and we have low confidence the attackers have been evicted.' "Nextgov obtained an internal CISA list of communications sector hardware and software products found to have been exploited by China-linked hacking groups. Of several listed, one of those vulnerabilities, first discovered in 2018, was found in MikroTik routers, and some of the software flaws exploited by Salt Typhoon were first disclosed in 2018," same year as the MikroTik router flaws. "Marc Rogers said: 'Something that isn't being talked about enough is that the initial way in which these attackers used were simple flaws like eight-year-old vulnerabilities and credential theft. Instead of talking about 'ripping and replacing,' we should be looking at why we aren't simply patching and maintaining our existing critical infrastructure.' "Eric Hanselman, the chief technology, media, and telecommunications research analyst at S&P Global Market Intelligence explained that: 'Chinese access into datacenter and colocation firms would provide the hackers with a different target set compared to messaging services operated by traditional carriers.' [This is him speaking.] 'The additional risk created would be their gaining the ability to monitor intra-service and intra-application communications traffic that does not normally traverse the Internet backbone. That could include storage traffic moving from colocation environments into cloud or traffic moving from hosted environments into on-premises infrastructure. That traffic might have less robust protections, as it's not traversing the open Internet.'" In other words, it might all be behind firewalls. So where we trust everybody inside behind the firewall. "Digital Realty," writes Nextgov, "has over 300 data centers" - this was a surprise to me. "Digital Realty across 25 countries and 50 metropolitan areas, according to a company marketing webpage. They list Amazon Web Services, Google Cloud, IBM, Microsoft, and Nvidia among their clients. The company is considered one of the largest data center colocation providers in the world, housing the physical systems where cloud and telecom networks exchange data, and they're believed to have been compromised. "Eric Hanselman said: 'We can reasonably assume that these attackers already have sufficient access into Internet infrastructure and are looking to expand the depth with which they can monitor other activities that are taking place within data center environments.' Comcast's broadband and cable customer base is around 51 million, while its total wireless customer count totals about 8.1 million, according to recent earnings data. "It's widely believed that Salt Typhoon has still not been excised from telecom systems, despite public statements from companies saying otherwise." On the other hand, they've been told not to look too closely. "On Thursday," they write, "well-known Republican Senator Josh Hawley said in a Senate Homeland Security Committee hearing that the hackers are still inside. He said: 'If a foreign actor chose to concentrate on any member of the audience here we were told behind closed doors, of course but what we were told is that foreign actors basically have unlimited access to our voice messages and our telephone calls.' "President Donald Trump, Vice President JD Vance, and a range of U.S. officials had their calls and texts directly targeted by Salt Typhoon hacks. The cyber spies accessed providers' 'lawful intercept' systems, used to comply with government orders requiring access to communications metadata for law enforcement investigations." Wow. And remember that, as we previously saw, Salt Typhoon's apparent way into these major telecom backbone providers was not rocket science nor advanced Pwn2Own-style elite hacking. It was simply that someone somewhere within telecoms' sprawling and largely out-of-control infrastructure, somewhere there were older, unpatched systems still online with known vulnerabilities. The reporting says: "A spokesperson for the House China Select Committee said in an email: 'If these reports are accurate, they point to yet another serious and deeply concerning example of the Chinese Communist Party targeting America's digital infrastructure,' and noted that 'the panel has repeatedly warned about the CCP's efforts to exploit access points into our communications networks, and this apparent breach reinforces the urgent need to harden our defenses.' "In March, the House's Homeland Security Committee chair Republican Representative Mark Green of Tennessee sent a request to DHS asking the agency to transmit internal documents about Salt Typhoon and another Chinese hacking unit, Volt Typhoon. Green said in a statement to Nextgov: 'Every new detail that emerges surrounding the Salt Typhoon intrusions teaches us the lengths Chinese-backed hackers will go to undermine the integrity of our critical infrastructure, our U.S. sovereignty, and the privacy of Americans.' Green said this in reference to recent testimony from DHS Secretary Kristi Noem saying CISA is lacking detailed information about the telecom hacks." Okay. It's difficult not to wonder whether some additional manpower at CISA might help. Green added: "My colleagues and I on the committee share this concern, which is why we sent a letter in March to examine the previous administration's response to the Volt and Salt Typhoon intrusions." Now, I was about to comment on that, that is, that they were sending a letter about the previous administration's responses, when I saw that Nextgov's reporting had already done so. They wrote: "The Cyber Safety Review Board a DHS body that was dismissed at the start of the Trump administration was in the middle of investigating the Chinese telecom hacks. Lawmakers have called for it to be reinstated. CISA has also been mired in budget plans to slash significant parts of its workforce and operations." So I hope that CISA will be able to recover and rebuild whatever effectiveness it may have lost. It seems pretty clear that, unfortunately, private industry is unwilling to expend the cost and effort required to fully secure its own business operations. You know, they'd rather have their attorney say, oh, don't tell anybody, but we'd like you not to look too closely because you could be put under oath and cross-examined, and we would rather have to say "We were told not to look" than "We looked and found evidence of Chinese intrusion into our enterprise." When the public depends upon the security of those operations, there is, clearly, a legitimate need for oversight, for regulation - which can only come from the government - and for accountability, that apparently needs to be imposed by the government. So let's hope we get that. Matthew Green, our illustrious cryptographer, says, well, he concurs. I mentioned briefly in passing last week that someone named Matthew Garrett had looked at the encryption mechanisms underlying X's supposedly new, all new, remember, rewritten in Rust, end-to-end encrypted XChat DM (Direct Message) facility and had decided that it was no better than the old one. He shared Elon's declaration about how it was written in Rust, and unfortunately it turns out it's still written in C and C++. Since then, Matthew Garrett's posting came to the attention of another Matthew. This Matthew was none other than the renowned Johns Hopkins University Cryptographer, Matthew Green. This Matthew is well known to this podcast, so this Matthew's posting last week titled "A bit more on Twitter/X's new encrypted messaging" is of interest. Matthew's post is longer than we need, and I've included a link to the entire thing in the show notes. So I'm just going to share his relatively short bullet-pointed introduction and summary. It'll really tell us as much as we need. So he wrote, Matthew Green posted: "Matthew Garrett has a nice post about Twitter (uh, X)'s new end-to-end encryption messaging protocol, which is now called XChat. The TL;DR of Matthew's post is that from a cryptographic perspective, XChat is not great. The details are all contained within Matthew's post," Matthew Green writes, "but here's a quick TL;DR [from Matthew Green]. "First, there's no forward secrecy. Unlike Signal protocol, which uses a double-ratchet to continuously update the user's secret keys, the XChat cryptography just encrypts each message under a recipient's long-term public key. The actual encryption mechanism is based on an encryption scheme from libsodium. "Second," and here it is, "user private keys are stored at X. XChat stores user private keys at its own servers. To obtain your private keys, you first log into X's key-storage system using a password such as a PIN. This is needed to support stateless clients like web browsers, and in fairness," he writes, "it's not dissimilar to what Meta has done with its encryption for Facebook Messenger and Instagram. Of course, those services use Hardware Security Modules. "And third," he says, " X's key storage is based on 'Juicebox.' To implement their secret-storage system, XChat uses a protocol called Juicebox. Juicebox 'shards' your key material across three servers, so that in principle the loss or compromise of any one server won't hurt you." Okay. So, and we've talked about key sharing schemes in the past where a key is broken up into pieces so that no one person has the entire key, and you need some number of individuals to all come together in order to reassemble the original key. This sounds like what Juicebox is doing. So our Matthew Green writes: "Matthew's post correctly identifies that the major vulnerability in X's system is this key storage approach. If decryption keys live in three non-HSM servers that are all under X's control, then X could probably obtain anyone's key and decrypt their messages. X could do this for their own internal purposes, for example, because," he writes, "their famously chill owner got angry at some user. Or they could do it because a warrant or subpoena compels them to. If we judge XChat as an end-to-end encryption scheme, this seems like a pretty game-over type of vulnerability." And he says: "So in a sense, everything comes down to the security of Juicebox and the specific deployment choices that X made. Since Matthew wrote his post," writes Matthew Green, "I've learned a bit more about both of these. In this post I'd like to go on a slightly deeper dive into the Juicebox portion of X's system. This will hopefully shed some light on what X is up to, and why you should not use XChat." So the bottom line is that Matthew Green concurs with Matthew Garrett, which is to say that no one should consider any encrypted messaging system to be securely end-to-end encrypted when such a system externally stores on its users' behalf their private keys. Now, a perfect example is Apple's currently controversial Advanced Data Protection. What it explicitly does is give its users discretionary control over whether or not a copy of their private key is also retained by Apple. Allowing that enables additional features, but it also enables Apple to similarly respond to court ordered subpoenas. In the case of Advanced Data Protection, if that's not what you want, and if you're not in the United Kingdom, and all of your devices are running Apple OSes that support ADP - iOS or iPadOS 16.2 or later in the case of iPhone and iPad - then you can turn that on, and a new private key Apple has never seen will be created and shared only among your iDevices. So no one should confuse Apple's state-of-the-art encryption technology, and for that matter Signal's, with what Elon is peddling. I'm not suggesting that anyone necessarily needs end-to-end encrypted DMs on X. But everyone should be aware that they're not really available there to the same degree they are elsewhere. Nor, for that matter, are they available on Facebook Messenger or Instagram, which as Matthew Green notes similarly stores its users' private keys in their own data centers in order to enable the features that are necessary. Leo, we're at an hour in. I want to talk about what we learned about Telegram. Let's take our third break.

Leo: Indeed we shall. Thank you, Steve. Back to the show.

Steve: I am so jealous of that top-level domain. But...

Leo: Isn't that great, .security? How much?

Steve: It's insanely expensive.

Leo: Yeah, of course.

Steve: I think it's like $25,000 a year.

Leo: Oh, that's nothing, dude.

Steve: Crazy. Isn't that like...

Leo: What would you do? GRC.security?

Steve: I don't know. No, I don't really want it. I love GRC.com.

Leo: Dot com is pretty darn good. You know, those three level TLDs are even more expensive.

Steve: Yeah. Oh, I get offers all the time.

Leo: I'm sure, yeah.

Steve: Okay. So I also recently mentioned that Telegram's encrypted privacy had recently been called into some question when Russian citizens who were supporting Ukraine - oh, naughty Russians - were being arrested and convicted by Russia's FSB. It turns out that the culprit might not be any weakness in Telegram's, yeah, it's a little questionable encryption, but it's probably good enough. It could instead be a compromise of its network infrastructure. In other words, there may be some leakage of messaging metadata. And we've talked about metadata a lot. We know that it can be notoriously difficult to prevent metadata leakage. You know, it's why we've gone to the all the lengths of creating the TOR network. And turns out you couple with the fact that Telegram's network infrastructure appears to be directly under Russia's control, that's a problem for privacy. So this could explain how people are getting in trouble for who they contact without needing to see inside their messages. I'm not going to spend any more time on this because this brings us to another of those, you know, I wouldn't use Telegram in any event if you really care about privacy. But apparently it is worth nothing that Telegram's networking infrastructure is entirely under the control of at least Russia sympathizers. I've got a link to extremely detailed coverage of this in the show notes for anyone who wants more. The report is titled "Telegram, the FSB, and the Man in the Middle: The technical infrastructure that underpins Telegram is controlled by a man whose companies have collaborated with Russian intelligence services." So again, who you connect with can be just as damning as what you say during that connection, especially if you're in Russia, and you're connecting to a Telegram contact that supports the Ukraine, apparently. So don't do that. Okay, Leo, here's where I need to control my language. BleepingComputer...

Leo: I want to hear what this AI figured out about your opinion about Microsoft.

Steve: Oh. Oh, yeah, we're going to get there.

Leo: Yeah.

Steve: BleepingComputer brings us the news that starting in July, so next month, starting next month, sometime next month, Microsoft Outlook will be blocking two additional file types. BleepingComputer reported: "Microsoft announced it will expand the list of blocked attachments in Outlook Web and the New Outlook for Windows starting next month. The company said in a Microsoft 365 Message Center update that Outlook will block .library-ms and .search-ms file types beginning in July. "Microsoft said: 'As part of our ongoing efforts to enhance security in Outlook Web and the New Outlook for Windows, we're updating the default list of blocked file types in OwaMailboxPolicy. Starting in early July 2025, the .library-ms and .search-ms file types will be added to the BlockedFileTypes list. Windows Library files (.library-ms), which define virtual collections of folders and files in the Windows file system, were used earlier this year in phishing attacks targeting government entities and private companies to exploit a Windows vulnerability (CVE-2025-24054) that exposes NT LAN Manager hashes.'" Okay. Now let me just pause here for a moment to say that, if I didn't know that we have many young people listening to this podcast with their parents while they're on their way to school in the morning, as well as many other settings, and that those parents have grown to trust me to keep the colorfulness of my language under control for those young ears, at this point I would loudly expand upon the well-known abbreviation WTF. Why in the world Microsoft would have EVER, by default, EVER considered allowing ANY email client - which inherently, think about it, inherently presents as large an attack surface as any web browser, and which is being constantly bombarded with unwanted and potentially malicious content, to handle .library-ms files which, we are now told, define virtual collections of folders and files? I've been in this business, as have you, Leo, since long before it was a business, and I've never seen a .library-ms file. How is it that this is a file type that all Outlook users' clients should have ever been able to open? And how can that possibly be addressing the need that anyone has in email? It's just utterly unbelievable to me, as it should be equally unbelievable to anyone trained in the practice of cybersecurity. How many times have we talked about the security benefit that flows from first blocking everything by default, and then only allowing selected known safe and needed content through any security perimeter? Email is a security perimeter. This is unbelievable. I'm so surprised by this because any rational security-aware design would never be permitting the reception and handling of, by default, any wacky file type somebody at Microsoft might come up with in the future. Which is apparently what happened here because that file type didn't exist in the past.

Leo: Ah.

Steve: Okay.

Leo: That's why they didn't block it. Okay.

Steve: But they shouldn't be - it shouldn't be, unless we know it's bad, we're going to let it through.

Leo: You're saying it should be a whitelist, not a blacklist.

Steve: Yes.

Leo: Yeah.

Steve: It's a security perimeter. Email is getting bombarded with all kinds of crap. Okay. Take a deep breath, Steve. So what about this other file type? BleepingComputer tells us: "The .search-ms URI protocol handler has also been exploited in phishing and malware attacks" - get this - "since at least June of 2022."

Leo: Oh, that's a long time. That's three years.

Steve: When Hacker House - yes. When Hacker House co-founder and security researcher Matthew Hickey found that it could be used to automatically launch Windows Search windows on recipients' devices to trick them into launching malware when chained with a Windows Support Diagnostic Tool (MSDT) remote code execution vulnerability (CVE-2022-30190). Well, isn't that just peachy? What year was that? Oh, yeah, 2022. So it only took Microsoft, what, three years to finally announce that next month - not this month, no. Next month they plan to start blocking this other unneeded and clearly abuse-prone file extension. BleepingComputer reports that in Microsoft's announcement, Microsoft wrote: "The newly blocked file types are rarely used" - except by hackers and malware and bad guys who just love using them - "so most organizations," they say, "will not be affected by the change. However, if your users are sending and receiving affected attachments" - yeah, like when did anyone ever get a .search-ms attachment in email - "they will report that they are no longer able to open or download them in Outlook Web or the New Outlook for Windows." Apparently the old Outlook for Windows is screwed, you're still going to get those.

Leo: Oh, my.

Steve: "No action is required if your organization does not rely on these file types." If your organization does rely on these file types, you've got a different set of problems. "The update will automatically apply to all OWA Mailbox policies in your organization. If your organization needs to allow these files, you can add them back to the AllowedFileTypes property of your users' OwaMailboxPolicy objects before the rollout." Why not just have that always been that way? If your organization needs one of these wacky, no one has ever heard of them file types, then turn them on for your people and good luck to you, rather than exposing the rest of the world to this nonsense. BleepingComputer then explains: "You can find the complete list of blocked Outlook attachments" - apparently very short list - "on Microsoft's documentation website. Enterprise users with a Microsoft Exchange Server account can ask Exchange Server administrators to adjust security settings for their mailboxes to accept attachments blocked by Outlook if they can't be shared as an archive, using a different extension, or using OneDrive or SharePoint. This move is part of a much broader effort" - apparently which Microsoft has just initiated - "to remove or secure and turn off Office and Windows features that have been abused and exploited to infect Microsoft customers with malware." Well, what a concept.

Leo: I'm shocked.

Steve: We'll see what AI thinks about this rant. "It started in 2018 when Microsoft expanded support for its Antimalware Scan Interface (AMSI) to Office 365 client apps" - apparently they haven't had anybody looking at this ever since 2018. Somebody woke up and said, ooh, look, let's add some more stuff to the AMSI - "to block attacks using Office VBA macros. Since then, the company began blocking VBA Office macros by default" - another great jump, a leap for security - "disabled Excel 4.0 XLM macros" - remember covering that, yay - "introduced XLM macro protection" - we even gave it a nice name - "and started blocking untrusted XLL add-ins by default." Because what could an untrusted LLM do? Wow. "Microsoft also announced in May 2024 that it would" - so a year ago - "it would kill off VBScript and disable all ActiveX controls in Windows versions." Boy, you know, I don't know. Again, it is truly, I mean, really inexplicable that Microsoft has been so utterly lame about the security of their email clients on the desktop and in the cloud. The only rational explanation is this was all originally put in place by engineers who had zero training in security. Hubris is the only explanation for a policy of "allow everything to run by default." It is the exact equivalent of having an "allow all" firewall policy and believing that it could ever be secure to only block the dangerous ports. Nobody does that. Haven't for a long time. Microsoft's just beginning to wake up to this and say, oh, look, three years ago people began exploiting the .search-ms extension which nobody has ever needed or uses, but which Microsoft says, oh, look, let's open that. My god. Okay.

Leo: Take a deep breath. I mean, yeah, I can't think of any reason. I mean, one thing would be that engineers say, well, you should just be able to send anything you want. Why wouldn't, I mean...

Steve: Yeah, what could possibly go wrong? All of our code is perfect. We never have any flaws. Just ignore those 125 critical updates that we had last month.

Leo: Every Tuesday, every month, yes.

Steve: And the next 150 that we've got planned for this coming month. Really, those are just exceptions. Besides, none of those were .search-ms so, you know, wouldn't have been - this wouldn't have helped anyway. It's unbelievable. I mean, again, that all should be turned off. And if, for some bizarre reason, some enterprise has to send, I don't even - virtual folders and directories through email? What?

Leo: Not through email. Never.

Steve: No. I mean, that's what this does, dot whatever that was. It's unbelievable.

Leo: Okay.

Steve: I'm just, I'm looking forward, Leo, to October, when they stop messing with Windows 10 and just will leave it alone. And then it'll have a chance to settle down, and then we can just keep using that. That'll be good. Okay. I don't need any more coffee, that's for sure. As we were recording last week's podcast, Leo, you encountered the news of 40,000 cameras having been found online. Now, this raised a bunch of questions, the first of which was probably what sort of exploit might have been needed to hack into and compromise such a huge inventory of Internet-connected cameras? And the answer, it turns out, is none. All 40,000 of these video cameras are simply online and wide open, viewable by anyone, anywhere, anytime. The news of this came from Bitsight, an Internet scanning company that offers to keep an eye on the IPs and ports of its own clients to let them know when anything like this might be happening to them. In Bitsight's report they wrote: "Welcome to 2025" - where Microsoft is still getting around - no. "Welcome to 2025, where thousands of Internet-connected cameras meant to protect us are actually putting us at risk. In our latest research at Bitsight TRACE, we found over 40,000 exposed cameras streaming live on the Internet. No passwords. No protections. Just out there. We first raised the alarm in 2023; and, based on this latest study, the situation has not gotten any better. "These cameras, intended for security or convenience, have inadvertently become public windows into sensitive spaces, often without their owners' knowledge. No matter the reason why one individual or organization needs this kind of device, the fact that anyone can buy one, plug it in, and start streaming with minimal setup is likely why this is still an ongoing threat. And it doesn't take elite hacking to access these cameras; in most cases, a regular web browser and a curious mind are all it takes, meaning that 40,000 figure is probably just the tip of the iceberg." Okay. For their key takeaways they wrote: "Bitsight TRACE has found more than 40,000 security cameras openly accessible on the Internet, allowing anyone to view their live footage. The United States and Japan rank first and second for camera exposure. Most times, all that an attacker needs to spy on homes or even large organizations is just a web browser and the right IP address. We detected conversations on the dark web where bad actors are discussing exposed cameras. We scanned the entire Internet for exposed HTTP-based and RTSP-based cameras. The United States leads the charge with roughly 14,000 exposed online cameras, followed by Japan, Austria, Czechia, and South Korea. Given the high prevalence of exposed cameras in the United States, we also analyzed their distribution across each state." I grabbed the heat map, both of the world and of the U.S. And what's curious is that the U.S. map is not at all uniform. It shows that a huge preponderance of open cameras are located in California and in Texas. Like way more than any other two states. You know, it would be interesting actually to determine why. I have no idea. As I said, the distribution is extremely non-uniform. Bitsight noted that: "Not all online cameras are bad. Some people stream beaches or birdhouses on purpose. But here's where things get problematic," they said. "Residential cameras watching front doors, backyards, and living rooms; office cameras disclosing whiteboards and screens full of confidential information; factory cameras showing manufacturing secrets; even public transportation cameras streaming passengers' movements. By leveraging the intelligence gathered by our awesome Cyber Threat Intelligence colleagues, we dug into dark forums where people openly discuss tools and tactics to find and abuse the content being exposed by these cameras. Some even sell access." They said: "This isn't hypothetical. It's happening right now." Then they finish their synopsis with a section titled "What should I do to protect myself or my company?" Their advice is what any long-time listener of this podcast would echo. They wrote: "If you have a security camera at home or manage surveillance cameras for your company, then taking the right precautions can make the difference between keeping your footage private and unintentionally broadcasting it to the world. Here are some simple but essential guidelines to ensure your cameras are secured. First, check if your camera is accessible from the Internet. Try accessing it from a device outside your home network. If you can reach it remotely without logging in through a secure app or VPN, it's exposed. "Second, change default usernames and passwords. Many cameras come with weak or publicly known default credentials. Set a strong, unique password. Third, disable remote access if you do not need it. If you only use your camera on your home network, there is no reason to allow outside connections. Fourth, keep its firmware up to date. Manufacturers often release security updates that fix known vulnerabilities. Regularly check for updates and install them. "Additionally," they wrote, "if you manage security cameras in your organization, restrict access with firewalls and VPNs. Ensure that only authorized personnel can access camera feeds using a VPN or firewall rules that block access from untrusted sources. And finally, monitor for unusual activity. Set up alerts for unexpected login attempts." It really would be interesting, I think, to follow up and track down a large set of those cameras to determine whether they are likely being deliberately shared publicly, or may be inadvertently exposing, like, views of the physical world to a global audience that should not have access to it. The idea, you know, of a corporate camera aimed at a conference room's whiteboard is terrifying. You know, I mean, maybe they just think it's a security camera and don't realize that some configuration misstep, you know, allowed this thing to go out over the Internet. But clearly the consequences could be devastating. Leo, we're an hour and a half in. Let's take a break, and then I'm going to talk briefly about using SpinRite on an encrypted drive, share some feedback, and then we're going to start talking about Internet Foreground Radiation.

Leo: All right. I hope you're enjoying the show so far. I certainly am. And we thank Steve for doing such a good job putting this all together.

Steve: My tech support guy, Greg, forwarded an interesting question about SpinRite which bears sharing because its answer is not always intuitive and sometimes results in some confusion, as it did when it was recently posted over in GRC's web forums. Lee Garrison sent the email through Greg: "Hi, Steve. I need to run SpinRite 6.1 on a 3TB partition which is encrypted with VeraCrypt for the purpose of locating and fixing bad sectors on this encrypted partition. The drive is a Western Digital 4TB hard disk drive" - meaning a spinner - "which also has the rest of the drive space occupied with an unencrypted partition. My question is, should I first decrypt this partition with VeraCrypt before running SpinRite on it, or should I leave it encrypted while running SpinRite on it? We've been discussing this problem over on your GRC Forums under the 'Running SpinRite' topic, but with varying opinions persisting." Yes, Leo. Leo's raising his hand. Yes? I don't have your audio.

Leo: I didn't turn on my microphone, so you didn't hear my "Oh, oh. Mr. Gibson. Oh." It doesn't matter. Am I right? It doesn't matter.

Steve: Correct. Correct. Correct.

Leo: All right.

Steve: I went over to the forum to see what the dialogue had been over there since he referred to that. And it was as Lee had asked. The answer, as you said, Leo, is that SpinRite has no problem running on drives that have been encrypted with VeraCrypt, TrueCrypt, BitLocker, or any other form of encryption. Since SpinRite 6.1 is seeing the drive as nothing more than opaque blocks of data, it doesn't care whether the data might be encrypted or not. Now, what's interesting is that SpinRite has this Real Time Monitor screen which presents a cool "window" that allows its user to "see" the data that's passing by as SpinRite is working on it. And one of the cool things that SpinRite's users notice is that they often see their own recognizable data flashing past that window while SpinRite is running on their drive. But that's an example of what encryption would change. When SpinRite is running on an encrypted drive or partition, that Real Time Monitor window will never reveal any of its user's recognizable data. Everything will just look like monitor static. It will be digital noise because, as we know, the result of high quality encryption is data that is indistinguishable from completely random noise. So by all means, Lee, run SpinRite over that encrypted partition, and any damaged sectors that SpinRite is able to recover will result in recovered files once that encrypted partition is remounted and viewed through its decryption. Okay. Some other feedback. Jason Egan wrote: "Steve, I wanted to send along my thanks to you for reminding me of the Tower of Hanoi puzzle. I had forgotten how much I'd enjoyed it as a child. I picked one up for my children, who are eight and 10, for Father's Day, and" - Leo is showing it to us on camera - "and they are hooked."

Leo: It's so great.

Steve: He said: "It makes me proud." He said: "Thanks for not only bringing us timely and informative security news, but also for interesting and fun things like this. I appreciate what you do every week. Jason."

Leo: I did the same thing because I told you I grew up with one of these.

Steve: Yup.

Leo: And I just couldn't resist going out and buying one.

Steve: Yup.

Leo: They're not expensive, and they're a lot of fun.

Steve: Yeah. And that's a nice one. Different colored wood discs.

Leo: Yeah, so you kind of know the even and odd. It makes it a little easier to...

Steve: Nice.

Leo: ...yeah, to spot it. And it all folds up and goes into this [crosstalk].

Steve: Yeah, very cool.

Leo: So you can put it away.

Steve: I was wondering if the pegs are, like, attached to the lid enough so that you're able to move the discs around?

Leo: Yeah, they do [crosstalk]. You have to really jam them in so they don't - but, yeah.

Steve: Nice.

Leo: They do come out so you can put it all in the box.

Steve: Nice.

Leo: Yeah, I love this. It was nothing. It was on Amazon. It was nothing. And just a great memory for me.

Steve: Yeah. As I said last week, there are pages of those, and many of them are those really nice-looking blue ones with their own little box. So Jason, thank you for your note. I very much appreciate it, and all the feedback our listeners take the time to send every week. And it's interesting, a surprising number of our listeners mention that the podcast also makes them laugh.

Leo: Oh, good.

Steve: I assume that's mostly thanks to the Picture of the Week.

Leo: And not our silliness.

Steve: Yeah, we do encounter things in the security space that are so absurd as to be ridiculous and funny. So anyway, when it's occasionally possible to both inform and entertain, well, that's a win. Brian Tillman wrote: "What I'm curious about is how a newspaper can claim that its LLM's users" - only he's referring to an article we talked about last week - "how a newspaper can claim" - I think it New York Times that was leading a group of newspapers that were suing, I don't remember who it was - "that an LLM's users are reading data that's supposed to be behind a paywall."

Leo: OpenAI [crosstalk].

Steve: "If there's a paywall in place, how are the LLMs gaining access to that material?"

Leo: Oh, same way I do.

Steve: "Doesn't seem like a very good paywall to me."

Leo: No, it's not.

Steve: And I think that's a really good point.

Leo: You just turn off JavaScript.

Steve: Yeah. Many sites, like coding forums, will have huge historical depth of code that could be plumbed once. So once an LLM got in there and sucked out all of its content, you know, it's game over for that site. The information has escaped. But the point of a news site is that it's news. So to Brian's point, although it may not have been clear several years ago, today's LLMs have learned that they must legally abide by robots exclusion rules and not traverse into any sites that have explicitly banned their entry or put up a paywall.

Leo: That's key. I want to hear that.

Steve: And I would be pretty sure that's no longer happening.

Leo: Yeah. Well, depends on the LLM. Some of them are very aggressive in ignoring.

Steve: And I did just see something, and I haven't had a chance to follow up. I mean, it was like literally during one of our commercial breaks. Someone sent something about how LLMs are getting clever about, like, being - LLMs are being used by hackers to get around these things.

Leo: Yeah. Cloudflare has complained about it. They said, you know, that most, many, many of these spiders don't adhere to robots.txt. But I think more and more that's going to make them liable in courts. That's going to be the real problem.

Steve: Right. If you put up a clear specification saying, you know, AI not welcome here, and then there is evidence that AI got trained here, you've got a good case.

Leo: That's terrible, yeah.

Steve: Yeah. Okay. So Ze'ev said: "Hi, Steve and Leo. My name is Ze'ev." He has Z-E-'-E-V, so I'll go with...

Leo: Ze'ev, actually, I think.

Steve: You think it's, what, Ze'ev?

Leo: Yeah.

Steve: Okay, Ze'ev.

Leo: Unless he's Hawaiian.

Steve: Oh.

Leo: I don't think that's where he's from.

Steve: "And I'm a longtime listener of the Security Now! podcast. Your show is fantastic, and I'm glad to hear that there's no definitive end date in sight."

Leo: Yay.

Steve: He said: "Recently, like many others, I've become interested in AI. As part of a hackathon at work, I explored the LlamaIndex Python library, which can be used, among other things, to easily create a Retrieval-Augmented Generation," which he calls a RAG system. "That immediately made me think of the incredible podcast transcripts that Elaine Farris has created for your show. I realized it might be an interesting opportunity to use AI to gain insights from this amazing trove of data. I ended up writing a simple Python program, around 130 lines of code, that lets you run a query or prompt to get an answer based on the transcripts."

Leo: Awesome.

Steve: "After some experimentation, I found that indexing and querying the transcripts by year yields the best results." He said: "Below are a few examples of prompts I tried, and the responses I got from the LLM." He also said: "The code is available on GitHub here," and he gives us a link. I've got it in the show notes for anyone who wants to go there, github.com/zeev-b/sn. And he said: "Thank you for all the work you put into the podcast. It's been an invaluable source of knowledge and entertainment over the years. Best regards, Ze'ev."

Leo: This is cool. Now, you could do this also with Notebook LLM if you have all the transcripts downloaded. Just give them to Google's Notebook LLM and do the same thing. In fact, I did it with just a handful of them, a few months' worth, and made a little show. And it sounds just like our shows. Two very nice AI voices.

Steve: Okay. So Ze'ev shared his query and the LLM's reply about our most recommended science fiction reading material and our most recommended television shows. But his third query, as I mentioned at the top...

Leo: I can't wait.

Steve: ...and the LLM's response was the most interesting to me and, I figured, would also be interesting to our listeners. What Ze'ev asked his transcript-trained LLM was: "How has Steve's opinion on Microsoft security changed over the years?" And the LLM's reply was: "Steve's opinion of Microsoft security has evolved significantly over the years, reflecting a complex interplay of recognition of improvements, growing skepticism, and critical concerns about the company's practices. "In the early years, particularly around 2015, Steve acknowledged Microsoft's efforts in managing security, noting that the company had developed defenses against constant attacks and was not frequently in the news for major breaches. He appreciated the improvements in security, but remained cautious about privacy implications, especially with Windows 10's design. "By 2016, his perspective began to shift toward a more critical stance, particularly regarding Microsoft's handling of updates and the promotion of Windows 10. He expressed concerns about the alignment of Microsoft's interests with those of its users and highlighted issues such as the lack of transparency in updates and potential security risks associated with third-party antivirus software. "In subsequent years, Steve recognized improvements in built-in security measures, particularly with Windows Defender; but he also emphasized the ongoing challenges in cybersecurity landscape. By 2018, he began to advocate for the use of built-in security solutions over third-party options, acknowledging the complexities of maintaining security in a rapidly evolving environment. "However, as time progressed, his concerns deepened. By 2019 and into 2020, he expressed frustration with Microsoft's inconsistent handling of vulnerabilities and updates, particularly regarding support for older operating systems. He highlighted the need for users to be proactive about security and criticized Microsoft's approach to updates, which he felt often led to significant vulnerabilities. "By 2021 and 2022, Steve's skepticism intensified, as he noted a perceived negligence on Microsoft's part in addressing known security issues promptly. He pointed out that the company seemed to prioritize other aspects over security, leading to a growing concern about the effectiveness of their measures. "In 2023, his criticism became more pronounced, focusing on Microsoft's reliance on updates and the prevalence of known vulnerabilities in their products. He expressed frustration with the company's failure to address these issues proactively and questioned the ethics of their approach to forcing upgrades. "By 2024, Steve's opinion had crystallized into a broader skepticism about Microsoft's commitment to security, particularly in light of high-profile security failures and a corporate culture that seemed to deprioritize security investments. He criticized the company's reactive approach to vulnerabilities and argued for the inclusion of essential security features in base products rather than as a paid add-on. "As of 2025, Steve's view reflects a recognition of the inherent complexities in securing Microsoft's systems, acknowledging that while improvements have been made, the legacy nature of their software creates ongoing vulnerabilities. He advocates for additional protective measures when using their products, emphasizing the need for caution and accountability in Microsoft's security practices. "Overall, Steve's evolving opinion illustrates a journey from cautious optimism to critical skepticism, highlighting the need for significant changes in how Microsoft approaches security to better protect its users."

Leo: I think that was fairly accurate. Do you think?

Steve: Yes. I mean, you know, it has that kind of vanilla feel.

Leo: Yeah, that AI thing, yeah.

Steve: That AI gives things. But you cannot argue that to give something, just a bunch of text - and, I mean, we are living through a truly astonishing revolution where we are witnessing the emergence of a technology that's able to take transcripts of 20 years of my rambling and turn them into that. Which, while, yeah, a little pablum-ish, still, you know, it's amazing that it even is able to say this. I'm astonished.

Leo: Yeah, yeah. It is amazing. Notebook LM will do the same thing. In fact, we're going to talk to the folks from Notebook LM on IM...

Steve: Tomorrow.

Leo: Yeah. Oh, you know more than I do.

Steve: Cool.

Leo: Yeah.

Steve: Cool. Okay, just for the sake of not breaking up this final piece...

Leo: Okay.

Steve: ...on Internet Foreground Radiation, let's take our last break, and then we're going to look at what is going on with proactive bot scanning in the foreground across the Internet. And it is very rare that we encounter something fundamental that we have never talked about in 20 years of this podcast.

Leo: Well, I am in the Neil Sedaka camp on this one. "Breaking Up Is Hard to Do." So let's get the ad out of the way, and then Internet Foreground Radiation with Mr. Steven "Tiberius" Gibson, who apparently knows the difference between Star Trek Holochess and Star Wars Holochess, even though, as far as I can tell, they do look the same. Am I wrong? I think they do look the same.

Steve: Star Trek's, actually, they had three-dimensional chess.

Leo: Oh, that's right. It was three-dimensional.

Steve: And they had weird little 3x3 and 4x4 boards, and Spock would move things around.

Leo: Yeah, that's right.

Steve: No one ever explained it.

Leo: Yeah. There is - and you can get those chessboards, too, and make up your own rules. All right. Let's talk about Foreground Radiation. You're the guy, at least as far as I know, coined "Internet Background Radiation."

Steve: That's my term, yup. Okay. So as I mentioned at the top of the show, today's podcast title "Internet Foreground Radiation" is a play on the term "Internet Background Radiation," which I coined 26 years ago, back in 1999...

Leo: Holy cow, wow.

Steve: ...while developing GRC's ShieldsUP! facility. Which, by the way, Paul Thurrott was the first person to discover and write about.

Leo: Really. Oh, that's awesome. It's a small world.

Steve: And that came because I was observing all the random packet crap and noise that would occasionally flow into any Internet IP address. Now, Wikipedia reminds us that: "Cosmic background radiation is an electromagnetic radiation that fills all space. The origin of this radiation depends on the region of the spectrum that's observed. One component is the cosmic microwave background. This component is redshifted photons that have freely streamed from an epoch when the Universe became transparent for the first time to radiation. Its discovery and detailed observations of its properties are considered one of the major confirmations of the Big Bang." Now, fortunately, unlike the cosmic background radiation which will presumably never die, the original designers of the Internet had the foresight to place a "time to live" counter into every single packet that moves across the Internet. And the very first thing that every Internet router does when it receives an incoming packet is to decrement that packet's remaining "time to live." If the packet's time to live was "1" and is decremented to "0," that signals that the packet has been alive long enough, and that if it was ever going to reach its destination it should have by now, and that for the sake of the greater good of the Internet, it must now be put to rest. Sorry, packet. When this occurs, well-behaved Internet routers will see where that packet came from from its source IP address and will send back an ICMP "time exceeded" message to inform its sender that the packet it sent to whatever destination IP never, for whatever reason, reached its destination. My point here is that, unlike true cosmic background radiation, Internet packets are strictly not allowed to wander around the Internet forever, aimlessly. And what this in turn means is that all Internet background radiation has a deliberate source somewhere, and that any time a packet is received, someone somewhere deliberately formed it and dropped it onto the Internet. Now, that said, that "someone somewhere" could be some cranky old and forgotten NT server in a locked and forgotten closet that became infected with Code Red or Nimda worms back in 2001. Those were the good old days, where Code Red, for example, was a flash worm that successfully infected more than 350,000 Microsoft IIS web servers within a few hours of its launch onto the Internet. So if any skeptics might be wondering whether things have gotten better through the intervening years, the answer is certainly yes. We do seem to be well past the point of flash worms taking down the Internet.

Leo: Thank god.

Steve: Yeah.

Leo: Geez. I forgot all about that.

Steve: Yeah. But the presence, still, the presence of any monoculture should always make a prudent person nervous, since mistakes can always happen. My point is that, even today, even though Internet packets will never persist on the Internet, true Internet Background Radiation being emitted from dusty servers in lonely locked closets may still exist. So the reason I named today's podcast "Internet FOREGROUND Radiation" is that there's something else going on that an Internet security firm has been observing. The distinction I wanted to make is that, whereas "Internet BACKGROUND Radiation," much like the cosmic background radiation, lacks deliberate intention, there is now separate Internet Foreground Radiation, behind which a great deal of deliberate intention lies. So who's generating THAT radiation, and why? Last week, the firm HUMAN Security posted the results of their long-running research under the heading: "Opportunity Makes the Thief: How Web Scanner Bots Target New Websites for Cyber Attacks." And I have in the show notes a link to their full research paper. Since what they found is not something that I think has ever been known before, or appreciated before, I thought it would be worth sharing and taking a closer look at. They introduce this subject by writing: "When a new website goes live, it's not people who visit first. It's bots. Automated tools probe new domains within minutes, long before any customer or legitimate user arrives. These bots vary widely in intent. Some are benign - search engine crawlers indexing your pages, or commercial security scanners checking for vulnerability with permission - but many are malicious. Among the most pernicious are web scanner bots, which quickly examine websites for weaknesses and exploit them immediately, turning reconnaissance and attack into a single automated sequence, carried out at scale. "HUMAN Security's Satori Threat Intelligence team monitors bot activity across our customer network and in dedicated research environments. One such environment is a honeypot, a web server we intentionally set up to attract only bot traffic. By observing the requests hitting this fresh, otherwise unpublicized website, we are able to gain insight into the types of bots that target a website from its inception onwards. One early finding in this experiment was that web scanners consistently dominate early traffic to new sites, and continue to probe the sites day after day, long after other bot types began to appear. This persistence underscores why scanner activity is a security concern for the full lifespan of any web property. "This blog post examines the threat of these web scanner bots and shares our recent research findings on several active scanner campaigns including the Mozi.a botnet, a Mirai-variant called Jaws, and the 'Romanian Distillery' scanner. Web scanner bots are an escalating cyberthreat. These bots are often the very first visitors to any new website, probing for security weaknesses long before any human users arrive. On a newly launched site observed by HUMAN Security, scanners made up an average of 70% of all bot traffic in the first days, meaning web scanners, scanning the entire site. And on some days 100% of detected bot visitors were from scanners. "Botnet-driven scanning operations are growing more complex. The 'Romanian Distillery' operation is a prime example. Once focused solely on harvesting SMTP credentials, it now probes for PHP services, .env files, and misconfigurations across a distributed /24 subnet. Its scan patterns follow doubling revisit intervals and reveal a coordinated infrastructure designed for scale. In some cases, such scanners don't stop at discovery. They attempt SQL injection or deploy malware immediately after identifying a weakness. "Traditional defenses struggle to catch web scanners. Many of these scanner bots evade simple security measures. They may rotate through networks of infected devices using other botnets to distribute their scans, hide their true identity by omitting or faking their user-agent strings, and rapidly change tactics to avoid signature-based detection. Legacy security tools that rely on known malicious IP lists or obvious signatures often miss these stealthy probes. "Web scanners, also known as website vulnerability scanners, are automated tools designed to identify security weaknesses in web applications, websites, and APIs. They systematically probe and inspect websites for misconfigurations, exposed files, default credentials, or known vulnerable software. If a new website is still being configured or lacks proper protections, scanners will attempt to find and exploit any flaw they can, before the site's owners have a chance to secure it." Okay. So the first and crucial takeaway would be to never assume that any security can be added after any portion of a new site goes live. Never assume that since it hasn't been advertised or announced in any way publicly, that it might be at all safe to place anything online that hasn't already been fully hardened. Essentially, the entire Internet has become a loaded and cocked mousetrap, ready to spring and capture at the slightest provocation. This is where my favorite of all tricks - IP-based filtering - can come in handy. It is so simple and is so absolutely robust as a security solution. If you wish to create some true external exposure, simply first block all access, then selectively allow the IPs through that you know you can trust. But never open the floodgates until you are fully prepared to be deeply attacked because that will immediately happen. They wrote: "Not all scanners are bad, though. There are 'good' scanners run by security companies or researchers to help site owners by identifying vulnerabilities so they can be fixed, before the 'bad' scanners can get to them. But both good and bad scanners impose load on your site; and the bad ones, if not blocked, will certainly attempt to leverage any weakness they find. Scanners don't just visit once. They constantly and persistently re-scan sites over time, since new vulnerabilities might appear with site updates or as new exploits are discovered." Okay. So it's always fun to run across, as I said, something we've never touched on or talked about on this podcast. Given that this is our 1030th podcast, we've logged many thousands of hours discussing and covering pretty much anything and everything that's happened over the past 20 years. So it's not often that we encounter something we've never discussed before. But today is one such rare day because the ubiquitous shift to TLS HTTPS website connections, which increasingly require the use of SNI - which we were just talking about, server name indication - to be specified and provided by the connecting client in its first TLS handshake packet, means that knowing the IP address of a site, or having a site's IP address simply by scanning them all, is no longer sufficient to successfully establish a completed handshake to a site's servers. That's new. We've never mentioned this before. Think about that for a second. From the birth of the Internet, it has been possible to simply scan the Internet's 32-bit IPv4 space for web servers and to establish connections to them. But that all changed once the likes of Cloudflare and other CDNs came along. As a result of IPv4 space depletion and the economic fact that IP sharing is inherently far less expensive since it also allows for infrastructure sharing, today more than 90% of today's websites are now sharing IP addresses, leaving fewer than 10% of all sites sitting on a single dedicated IP address. This means that more than 90% of the Internet's websites have migrated behind proxies that are only able to disambiguate website destinations by examining the incoming client's SNI extension field, in the TLS handshake, the Client Hello packet. This even applies to a modest facility like mine. GRC's .sc shortcut server, our mail, dev, SQRL, GitLab servers and others all share the same IP. So it's not possible to reach any of them simply by their IP because we don't know which server to send it to. It's necessary for anyone who wishes to connect to any server behind that IP to somehow also first know which domain name they expect to find at which IP address. So, as I said, that's not an observation that's ever come from this podcast before. The bad news is, I wish this presented a bigger problem for web scanners than it does. The guys at HUMAN Security explain that scanners' response to this has been to solve it. They wrote: "To ensure that their scanners manage to get first in line for any new website, threat actors take advantage of feeds and services that announce new websites or domains coming online. For example, threat actors monitor Newly Registered Domain (NRD) feeds, which are lists of recently registered, updated, or dropped domains, such as WHOIS databases and domain drop lists. Such NRD feeds are re-purposed from policy feeds intended to increase corporate security to threat intelligence and monitoring feeds against the websites themselves. "Threat actors also monitor certificate transparency logs, such as CertStream, which publicly log new TLS certificates. For scanners, a new domain registration or certificate issuance indicates a new website that could be scanned. Once the large-scale SEO crawlers index the new website, scanners may also monitor the search engines' new listings, and the scale of scanners will increase even further." One thing that hadn't occurred to me until just now as I was reading this and paying attention to it, is that wildcard certs are an interesting hack here. If a wildcard cert is issued that just says, for example, *.grc.com, that doesn't indicate what the sites' hostnames are. And there's no indication of that from a wildcard certificate. So there's a little bit of obscurity there. I wouldn't rely on it, but still it's there. So for the purposes of this research, these guys are interested in identifying and, where possible, disambiguating and classifying the range of bots that are probing their honeypots. We know this doesn't matter for the sake of security, since for security it's necessary to simply be equally secure for anyone who might come knocking. But what these guys found was intriguing and revealing. Under the heading of "Identifying Web Scanner Bot Traffic" they wrote: "Some scanners openly identify themselves in the user-agent string" - which, okay, that's interesting - "which is the part of an HTTP request that might say, for example, 'Mozilla/5.0 (compatible; ScannerXYZ/1.0)' and then it goes on. So this is identifying itself as a scanner." And they say: "Security teams can easily filter or block those known scanners. But many malicious scanners, naturally, deliberately mask their identity or use misleading user-agents to obfuscate their true nature. "In these cases, identifying them requires analyzing their behavior and deploying antibot mechanisms to intercept their activity. You know, like maybe a ridiculously number of page requests per second. You can say, wait a minute, this is not a person. On the other hand, you wouldn't want to block a search engine, and this thing might be declaring itself to be Google, you know, a Google spider. So there you'd have to know if it corresponded, if the source IP corresponded with a legitimate known Google IP address." Anyway, they wrote: "Some user-agents we observed suggest the presence of outdated or anachronistic systems including the BeOS, legacy Linux kernels, and even Windows 3.1 Internet Explorer versions. Obviously, no real users are surfing the web on Windows 3.1 today, so this was a dead giveaway of automated activity." And not very smart activity. "These impossibly old user-agents likely came from a public user-agent database that the attackers grabbed for obfuscation purposes, a fun and benign find that should never hit any of your web servers if you have a decent bot mitigation solution deployed." And Leo, you put that on the screen a second ago. And they show some of these ridiculous user-agent strings. I particularly like the Mozilla/1.22 (compatible; MSIE 5.01; PalmOS 3.0)...

Leo: I remember that one.

Steve: EudoraWeb 2.1.

Leo: Eudora.

Steve: Yes, PalmOS 3.0. Now, my refrigerator could use that, but nothing else. And then Eudora Web 2.1, wow.

Leo: That's hysterical.

Steve: Anyway, so I would be inclined to agree with their assumption about the likely source of those bogus bot user-agent strings. Where else are you going to get them, from some old historical list somewhere.

Leo: AI. Yeah.

Steve: Under the heading "Reconnaissance and Probing the Target," they explain what these scanners tend to do once they locate a new candidate target. They write: "Before scanners are even deployed, operators conduct manual reconnaissance to identify likely entry points - directories, configuration files, endpoints, and services that may exist at newly launched sites. They then craft scanners" - so they're talking about the operators who design what the behavior of the bots will be. So they design this behavior, then they turn the bots loose. So they said: "They then craft scanners with predefined paths and exploitation logic, tuned to probe and attack if those elements are present and identified. Once launched against a site, the scanner rapidly tests for these known targets. It attempts to enumerate directories, pages, API endpoints, and exposed resources, executing preset payloads or exploits where applicable. "One of the most common methods to launch scanners is using 'Dirbust,' a dictionary-based attack against web servers that automates the process of discovering hidden files and directories on a website. This tool scans through predefined lists of potential directory and file names (/admin, /config.php, /backup.zip, et cetera) in hopes of getting lucky in finding unprotected sensitive files or admin interfaces." Now, here again, having been a website admin myself for the past 25 years, it can sometimes be tempting to imagine that it might be possible to just briefly do something that's not entirely secure, under the assumption that, you know, just for a few minutes nobody will notice. All I can say is that on today's Internet, doing anything like that is risky at best. I've always had better things to do than wonder and worry about what percentage of GRC's inbound connection traffic has malicious intent. But, for example, I have seen ample evidence of tools like that "Dirbust" they mention in the logs that I sometimes briefly enable when I'm trying to track down some specific behavior. The only way to be safe is to assume that everything is malicious and be prepared for that. GRC's servers do not log website activity specifically because the signal-to-ratio is so low that there's virtually no signal among all of the noise. That's the reality of today's web for sites that have been around for the last 25 years. It really has become a nasty jungle out there. It's sad it's happened, but it has. They wrote: "Using the scanner traffic from our research, we mapped the most targeted path types targeted by scanners. This mapping shows that scanners have particular favorites when it comes to these initial probes. The two most targeted types of files by far were environment configuration (.env) files and repositories for code secrets. In fact, about one-third of all scanning attempts in our study were after .env files, and another one-third were looking for Git repository data, such as .git folders or leftover export files." They wrote: "This is no surprise. Environment (.env) files often contain API keys, database passwords, and other secrets that would be a jackpot for an attacker, and Git-related files might expose source code or credentials that enable a deeper compromise. The potential exploitation from each of these path types is listed in the table below, and the most targeted paths are shown in the chart." And I've got a big pie chart here. It is rather astonishing mostly to see how, again, non-uniform this stuff is. So, I mean, here's a hint. If you wanted to immediately increase the security of your website, and you don't use .env files, or Git secret files, simply set up a trap so that any query to those file extensions on your site blacklists that source IP for some length of time. I mean, again, no legitimate user who is clicking on a URL to access a page on your site for a site that doesn't use those file types is going to query that. So you're better off without them going any further. So, astonishingly, fully 33.6% of web server file type requests which they observed were for .env files. 33.6%. And the effectively equal 33.5% were for Git secrets.

Leo: So these are clearly malicious spiders.

Steve: Yes. No other - yes.

Leo: There's no other reason.

Steve: No other reason for anything to probe that. You know, period. So there's two thirds of the probes right off the bat you're able to identify as malicious intent. Next up at 23.4% were common PHP files. So collectively, just those three account for a whopping 90.5% of all website probes. This leaves 4.3% for unprotected config files, 2.9% for YML files, and 1.1% for Python mail sender files. They offered a table that explained why different file types were being searched for. As I mentioned, the .env files typically store API secrets, tokens, and other sensitive information that can be used by attackers to pivot and attack. The Git secrets are used to gain access to victims' repositories, leading to cross-organization compromise. Of course Common PHP, if you left your php config out, that might allow them to do recon, identify versions of PHP and other installed frameworks. Even WordPress, popular PHP CMS files. As we know, WordPress has a long history of vulnerabilities. Attackers try to find fresh versions that are still using default credentials or endpoints that provide additional fingerprinting, such as plugin versions. So these can be further then scanned for vulnerabilities and exploited if they're found lacking the latest security patches. So, you know, a wealth of information just from scouring and looking for things. And we know, we know how many unintentionally exposed files exist on the Internet that make this sort of scanning worth doing. I mean, unfortunately there is a payoff. You just don't want it to pay off on your site. They wrap up the topic of reconnaissance and probing by adding: "Beyond those, scanners also commonly seek out various configuration and backup files (for example, .yml or .yaml configs, old .bak or .zip backups of the site, or files like config.php that might reveal database connection information)." Ooh, that's true. "They probe for known software-specific files. For instance, requesting a URL ending in wp-config.php could indicate the site uses WordPress and reveal its config if not secured, or hitting /server-status on a web server could reveal internal information if that page is not locked down. Scanners will even check for well-known vulnerable services. One example is scanning for Outlook Web Access and Exchange server paths on sites, since unpatched Exchange servers are high-value targets that could lead to a broader organizational breach. "Essentially, during the probing phase, scanner bots test the site against a predefined list of files, directories, and endpoints that should never be exposed. Every directory listing, config file, or version disclosure it finds constitutes 'loot' that can be used in the next phase of the attack. This process is highly automated and aggressive: the scanner might attempt hundreds of different URLs on your site in rapid succession, far more exhaustive and faster than any human could manage. That behavior pattern is often a telltale sign that the traffic is a scanner bot." So when you stop to think about it, there's only one reason any of this exists, and any of this is worth the time and trouble on the part of the attackers. All of this technology we're using today contains a very long legacy of being insecure by default. That's what this is about; right? You have to be proactive. You have to take measures not to expose these things. I mean, it is really a sad state of affairs that we have developed in a world which is insecure by default. You know, although this characteristic is beginning to disappear, historically it has been entirely possible and was even once acceptable to choose NOT to use any password at all when setting up a new operating system or device. UNIX and Linux once allowed the ROOT user's password to be null. Today we all recognize this as beyond bad, but we all probably also remember a time when perhaps we did that ourselves. In the future, the option to skip a password won't exist. No one will believe it was even ever possible, and they'll understand that doing so in the future would be insane. So once upon a time, though, it was not so insane. But that, you know, that approach of having no or low security has been now entirely upended, thanks to the Internet's steadily growing foreground radiation.

Leo: I remember a time when no one locked their doors, and children would play out in the street with absolutely no fear at all. Times have changed, Steve.

Steve: Used to be a friendly neighborhood.

Leo: Used to be a nice place back here. Yeah. Got to have a password for your root user. Gotta. Just seems sensible.

Copyright (c) 2014 by Steve Gibson and Leo Laporte. SOME RIGHTS RESERVED This work is licensed for the good of the Internet Community under the Creative Commons License v2.5. See the following Web page for details: http://creativecommons.org/licenses/by-nc-sa/2.5/

Gibson Research Corporation is owned and operated by Steve Gibson.  The contents of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP, NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.

Last Edit: Jun 24, 2025 at 09:15 (17.87 days ago)

Viewed 9 times per day