← Security Now (Audio)
Security Now (Audio)
SN 1071: Bucketsquatting - Meta and TikTok's Tracking Pixels
02:47:44
Meta and TikTok's Tracking Pixels
Loading summary
Transcript148 lines
- [00:00]
A
Coming up on Security Now. Steve Gibson is here and I am filling in for Leo Laporte. Kick off the show with H and R Block's tax software. Well, it's doing something pretty wild and Steve has a suggested fix for it. We also talk about what happens when Breathalyzer firmware needs to be calibrated. Plus, Russians want Telegram and WhatsApp to return to Russia. And very important, we finally learn what bucket squatting means and what can be done to fix it. All of that plus so much more. Coming up, Security now
- [00:40]
B
podcasts you love from people you trust.
- [00:45]
A
This is Twit. This is security now. Episode 10002071 with Steve Gibson and me, Micah Sargent. Recorded Tuesday, March 24, 2026. Bucket squatting. It's time for Security Now. And if you're hearing this voice and going, that's not Leo Laporte. Well, good for you. You've got a good ear for voices. I am Micah Sargent. Leo Laporte is not here with us this week. He'll be back, don't you worry. But until then, I am excited to be joined by the ed, ever knowledgeable Steve Gibson. Hello, Steve.
- [01:26]
B
Micah, great to be with you again. Leo told us last week that he that the RSA conference is going on in San Francisco and so he and Lisa are there shaking hands with past and present and maybe even future advertisers for absolutely security related things. So glad to have you filling in for him.
- [01:49]
A
It's always a pleasure to get to join you.
- [01:51]
B
Well, yeah, and you know, once upon a time when we had Father Robert, he was our, our backstop for Leo. And now we got you. So that's great.
- [02:01]
A
Yeah, good to be here. Now. Go ahead, go.
- [02:06]
B
I was just gonna say this. Security now episode 1071 for March 24, 2026. Two days as it happens before my 71st birthday. So wow. I will be. Yeah, I feel great. So good.
- [02:24]
A
Happy early birthday and I'm glad you feel good.
- [02:28]
B
Security now, episode 2000 before very much longer. Today's episode is titled Bucket Squatting for. And this has nothing to do with like something you have to do when you're camping. This is about an interesting problem that Amazon has had for years which it turns out represents a surprisingly serious security vulnerability which we're going to cover in detail. But wow, there's a bunch of other really cool things that have happened in the last week. It turns out that H and R blocks Tax software, their. I think it's that, I think they call it the, the Enterprise 2025 tax stuff is doing something that is so very wrong. Also, a cyber attack has hit a company called Intoxiblock, which provide breathalyzers to enable the ignition systems on automobiles whose drivers need to prove their sobriety before driving. That's an interesting story. We've also got Firefox now as of today. We should be at Firefox 149 as of today offering a free built in VPN. Also, TikTok and Meta's tracking pixels turn out to be doing much more than we believed. Russian citizens are begging to get their instant messaging back, which, you know, Telegram, WhatsApp and so forth, which the Russian government have said no, no messaging for you. We've also got the lack of wisdom of connecting your crypto wallet to an unknown service. Yet another. And what would a Security now podcast be if we didn't have a Cisco CVSS of 10.0? Yes, you're just getting them confused at this point because there's so many of them. But Cisco's not alone. Ubiquiti also had a 10.0 CVSS critical flaw that needs to get patched. We've got some interesting listener feedback. And then what is exactly bucket squatting and what can be done to prevent it? So, you know, maybe we have some things to talk about this week. I don't know.
- [04:56]
A
Sounds like it. Sounds like there might be a few things to talk about. I'm looking forward to learning about bucket squatting, I'll tell you that. You know, it's a good exercise move. Surely works on the thighs.
- [05:10]
B
That's true. Strengthen those whatevers.
- [05:13]
A
Yeah, exactly, the whatevers. But as you all know, this is the time where after our wonderful summary of what's to come, we take a moment to cut to an ad break. And Leo will be here for you for that.
- [05:31]
B
Hi, Leo.
- [05:32]
C
Hi, Micah. Hi, Steve. Sorry I couldn't be here. I'm at RSA right now. Having a great time, I'm sure. But I did want to come back and tell you about our sponsor for this episode of Security Now, Hawks Hunt. Actually, I'm meeting with them at RSA in just a little bit as a security leader. You've been there. The eye rolls during training. You're making us do this. The one size fits all phishing simulations that your employees spot a mile away. They don't learn anything from that. And that report button, that gets ignored more often than not. Your programs are running, but it's not changing employee behavior. And isn't that what it's all about? Meanwhile, AI is making real attacks more Convincing by the day. And leadership is starting to ask the question you don't have a clear answer to. Is this actually working? Well, Hoxhunt is built to answer that. Hawks Hunt empowers your employees to spot and stop phishing attacks. It drives measurable behavior change and it does it in a fun way through personalized gamified micro training. No more eye rolls. It's just engaging and fun and it's how people learn. It's powered by AI and behavioral science. And you'll love it as an admin because Hox Hunt does all the heavy lifting. The simulations run automatically. And not just email these days. Gotta be everywhere. They run an email and slack in teams. It's like real phishing attacks, personalized to each employee based on role, location and behavior. Every simulation uses AI to mirror those real world attacks, meaning employees are tested on what's actually getting through, not outdated templates they recognize immediately. No messages from Nigerian princes. They know better than that. Now, gamified training keeps engagement high without feeling punitive. Your employees will love it and you'll love it too. And because every interaction generates a coaching moment, you're not just tracking completion. You're building behavioral indicators that tell a real story. You get reporting rates, repeat clicker reduction, and time to report the kind of metrics that hold up. But when the leadership asks the hard questions, you could say, yeah, got it right here. You don't have to take my word for it. With over 3,500 verified reviews on G2, Hoxhunt is the top rated security training platform, recognized for best results and easiest to use. It's also recognized as a customer's choice by Gartner. And thousands of companies use Hoxhunt, Qualcomm, Docusign, Nokia. They trust Hoxhunt to train millions of employees worldwide. Visit hawkshunt.com securitynow today to learn why modern secure companies are making the switch to Hawkshunt. That's hoxhunt.com securitynow now back to the show.
- [08:26]
A
All right, thank you, Leo for that. Let us get into the show the good stuff.
- [08:33]
B
So last week I showed this picture, same picture that we have here, but with a different caption. I thought this picture was so bizarre that I would just put it out to our listeners to say, give me an idea for a caption. And so that was a caption contest. Last week I got flooded with a huge range of very fun and creative bits of feedback. I settled on one which I like because clearly what we're seeing here with this insane Communications, telephone pole, a power pole, whatever the hell it is.
- [09:22]
A
It's beautiful.
- [09:24]
B
This. This demonstrates, like, what, 50 years of accumulation. Clearly, this did not happen in a day. Right? It used to be initially, when that pole was erected and the first lines were run to it. I'm sure down there in the core, buried deeply, is what was there originally beautiful. Probably made sense. You could take a look at it and see what was going on, everything. It was perfect. Then, like, oh, but wait a minute. We need to add another trunk line. So, okay, tack that onto the side and. And wire it in. And then who knows how many decades pass and you end up with what could, you know, affectionately be called a rat's nest of wires? So I gave this.
- [10:15]
A
It's a rat king's nest. Do you know what a rat king is?
- [10:18]
B
Yeah, yeah, I gave. And there's some poor worker guy up there on the top, like, trying to add just one more wire. I just need one more wire to Dale. Anyway, so I gave this thing the caption. A contemporary visualization of the Microsoft Windows code base.
- [10:38]
A
This is the caption you added?
- [10:40]
B
Yes, that's my cap. That.
- [10:42]
A
It's for beautiful Steve. I read that and I thought, yes, yes.
- [10:47]
B
Oh, I think that. And I mean, that's what we see with Windows, right? I mean, and in all fairness, it's not just Windows. It's any old code base that has been evolving over time where you can't really throw away the old code because it's working and things depend upon it being the way it is. So we're just going to add to it. We're going to, you know. You know, and we've got, you know, Windows now has multiple APIs. I hear Paul Thorat talking about how, you know, oh, nobody codes to that API anymore. Well, of course I do, but not, you know, other normal coders. So, anyway, I thought this was a great caption. It's a variation on an idea that I got from one of our listeners. So thank you for that and thank you, everyone, for sharing your ideas. Okay, so this first goodie is where we're going to spend some time this morning because. Or this podcast, because there's a lot here to unpack and I really think our listeners are going to find this interesting. The first mention of this goes to a listener. A credit for the first mention. Jack Christiansen, who first pointed me at this. Since then, the Hacker News and other security outlets have picked up on this and shared it. Just. Jack provided a. A note with. Included a link to the original Y combinator posting Whose Chinese author? A guy named Yifan Liu Y a F a N last last name Lu Lu Yifan Liu. He appears to know his way around TLS and web servers, as we will see. So here's what Yifan posted to Y Combinator last week. He said just a he said psa but we know that stands for Public Service announcement for folks here in the US because tax season is coming up and some of you may be using it's business not enterprise HR block business 2025 he said I discovered that the software give Get a load of this folks. He I discovered he wrote that the software installs a root CA named WK ATX Server Host 2024 so a root certificate authority WK Space ATX Space Server Host Space 2024 with an expiration in 2049 yes, 23 years from now.
- [13:44]
A
Wow.
- [13:45]
B
He said. Into your local machine's trusted root certificate store. They also helpfully include the private key to this certificate in a. DLL file. He says this certificate does not identify itself as as H and R block anywhere and does not get uninstalled when you uninstall the software. He said, I've been able to successfully use this root CA +MITM proxy which is a software package man in the middle proxy to manipulate TLS traffic on a brand new virtual machine on the same network with a DNS spoofing attack. And he gives us then a link in his posting to a YouTube video and I've got the link in the show notes for anyone who's interested. He said to test if your machine is vulnerable visit this page. And now we have a URL to a host on his domain. It's HTTPs hr as in you know, h r block hr backdoor.y-a f a n l u.com so this is a a TLS a secure HTTPs secure connection to a web server on his domain that is carrying a certificate he made using this root CA that was installed in everyone's machine who has H R Block Business 2025 thanks to the fact that they also provided the private key for this root certificate which you shouldn't, which should never be there anyway. He says go to this URL and if you do not get any warning or error message from your browser then you have the backdoor installed. Okay, now it's not really a backdoor I understand, but I think that's a popular term. It's frightening and scary as we'll see. I don't get how this is a back door, but okay, just not A good door, you know, maybe a side door. He said if your browser does does complain, you can choose to visit the page anyway for more details on the vulnerability. And I did and I'll tell you about what I found in a second. So he says, is it negligence or a real back door? It's impossible to tell and since the private key is out there, anyone can use it. So the point is moot. There's no legitimate reason and boy do I agree. And as we'll see, I'm going to demonstrate how we don't need this why they need to install a wild card root CA under a different name when I contacted them and I'll be sharing the timeline of that later when I contacted them about it, their statement includes, quote, similar findings and have been identified through internal security assessments, unquote. He said, meaning they know about this issue but have not fixed it. He said, I would not trust H and R Block software at this point. If you did not get the. If you did not get bit by this. Congratulations. He said, see this post as a reminder to audit your trusted root CA store. The that is in other words, take this post as a reminder to go take a look and see what cruft things may have installed behind your back for their own purposes. Because unfortunately, as this demonstrates, that can happen and it's not good. Okay, so let's reverse engineer this to figure out what's going on here. First, let's Again, I want to be very clear that having H and R Block install its own root certificate into the certificate authority root store of every single person who installs their tax preparation software and then, I mean that's bad enough, but then even worse to leave it there forever with an expiration date in the year 2049. And you know Micah, I do think the podcast will probably not last that long. So we're not going to be here to celebrate the expiration of the H and R Block root certificate. So this will remain valid for the next 23 years. Doing that on by on H and R Block's part is the height of hubris and irresponsibility.
- [19:05]
A
I mean, I don't, I don't want to spoiler. So if, if you are going to talk about this, then you can just say that it'll be a spoiler. But I know that when it comes to the practically minded, particularly those in the security world, perhaps the motivation is not as important as the impact. But I would love to know, do you have any thoughts about why. What's the why make this choice of a certificate that doesn't. Is it just pure laziness? You talk about hubris and irresponsibility here. That just seems like. Well, one would say that's a choice. I mean, they made a choice.
- [19:45]
B
Yeah. And in fact I'm going to explain.
- [19:48]
A
Okay, good.
- [19:49]
B
The dangers and then I'm going to explain the reason for it and, and then we're going to show how it could, the same thing could be achieved in a completely secure fashion. So I've, I had a lot of fun with this because we've never did, we've never in the 21 years of the podcast haven't seen this and, and, and gone into it. So it's a great opportunity to get ready folks. Really dig in. Yes. Okay, so remember that the way all this works is that a root certificate has signed itself and has declared itself to be a certificate authority certificate. Certificates are, have a whole bunch of things they can be labeled and they can also contain constraints on their own behavior, that is constraints that they broadcast on what things they can be used for. So this is an unconstrained certificate authority certificate, which is the most port, most potent form of certificate you could have. So just as with any root, you know, certificate authority certificate, the purpose of that certificate, that self signed certificate is to verify the signature of any other certificate that, that it might have signed using its matching private key. It contains the public key. So its private key signs something which the root certificates public key can be used to verify. So it can verify, but it can't itself sign. That's the beautiful, the, the, the beauty of this public key, you know, division of labor between private and public keys. So the CA's private key consequently like, like, like for Digicert, right? They're a ca. Their private key is the most prized protected and safeguarded piece of information anywhere. Since any certificate which that super secret protected private key signs will be trusted anywhere that it's matching CA certificate containing its matching public key is installed. Okay, so keeping the private key secret is like so important. Did H and R Block at least keep its installed CA certificate private key secret? Well, no. Refon told us. No, not even a little bit. This intrepid researcher discovered the CA certificates never to be disclosed. Matching private key sitting comfortably in a DLL that was included as part of this software's installation. We can be certain that this is true since this researcher used the matching Cas private key which he found in the DLL to create and sign his own standard TLS web certificate. Just like a CA would Like a certificate authority, like DigiCert did when GRC got its most recent certificate. That's what what it does. So he created a a TLS web certificate using the private key that he found in the DLL in order to create that backdoor yifanlu.com website which anybody who installed the H R Block software can now go to because their machine, their browsers will all trust this certificate that he made for himself. When I went there, since I didn't install this H R Block software, Firefox freaked out, as it should warned me that the site was attempting to use an untrusted certificate signed by an unknown issuer and that I should proceed no further. I put the dialog box in the show notes it says so this is from Firefox. Someone could be trying to impersonate the site and you should not continue. Websites prove their identity via certificates, writes Firefox. Firefox does not trust HR backdoor.yifanlu.com because its certificate issuer is unknown. Meaning to my computer Firefox said the certificate is self signed or the server is not sending the correct intermediate certificates. And so then we we get the error code SEC error security error unknown issuer and you you have a link. Then you can click on View Certificate and see the certificate where we we see that everything that Yifan Lu has told us is true. So this is all exactly what we would want and expect from any browser and it's what we should receive. Because as I said, I never made the mistake of installing H and R blocks 2025 tax prep software. But what's significant is that anyone who has ever previously installed HR blocks, you know business 2025 tax prep software from now and for the next 23 years while their purposefully installed CA root certificate remains valid, would not and does not receive any warning or notification at all. Their web browser simply opens that page without complaining. Yifa News, you know self cert created page because the signer of Yifan's demo test site certificate will then will now be known and trusted by their PC. Because once upon a time, maybe recently, maybe up to 23 years in the future, they had installed HR Blocks software. Okay, so so far this is all just happy demonstration test land, right? The reason Yifan has raised the alarm is that the inherent dangers extend far beyond testing since in addition to installing an untrusted an untrustworthy certificate authority cert into every PC root store as I said, and he's proven H and R Block thoughtfully provided their CRs matching private key. Consequently Anyone anywhere in the world can generate their own TLS web certificates or code signing certificates, any kind of certificate, because there's no constraint on the use of this that will be trusted without question by any previous user of H and R Block's tax preparation software. And for the next 23 years, for example, nothing prevents someone from signing a TTLs certificate for www.google.com or update.Microsoft.com or any other web domain they might choose if traffic can then be rerouted to that maliciously named and now fully trusted server. Anyone who had previously installed the H and R Block tax preparation software could be fully spoofed. Their browser would go to web pages at those URLs, they would see matching trusted certificates and be fully spoofed. Now, presumably H and R Block has digitally signed their software, but any of their users who had previously installed their tax preparation software would also now be completely spoofable. Their customers PCs would download and blindly trust any subsequent software from any source that was signed with a certificate that had been issued with their private key. The code signing certificate could say H and R Block, or it could say Microsoft Corporation or anything else that fit the malicious need of the moment. Yifan also said in his original Y Combinator posting, he said, quote, I've been able to successfully use this root CA and MITM proxy to manipulate TLS traffic on a brand new virtual machine on the same network with a DNS spoofing attack. So let's look at that. We've talked a lot about so called middle boxes through the years. Many corporations use them to allow deliberate mitm, you know, man in the middle interception in order to examine 100% of the traffic that's passing into and out of their networks. They want to protect their employees inside their protected perimeter from anything malicious cruising in to their network under the protection of TLS encryption. And they'd like to prevent corporate trade secrets from being sent out through their network either inadvertently or deliberately thanks to the same TLS encryption. So to accomplish this, every PC operating inside their corporate network environment must contain the root certificate for that middle box. In other words, a CA root certificate for that middle box. And we hope that it's matching, you know, well protected inside the matching private key is not extractable. So having all PCs in the enterprise containing that middle box's root certificate and with it having the matching private key, which it's careful never to let anybody else get, that allows the middle box to synthesize fake trusted remote website certificates on the fly. So here's how that Works say that someone inside the enterprise attempts to go to chat GPT.com the middle box will intercept that connection attempt and it itself will go to chatgpt.com on behalf of the user to obtain Chat GPT's TLS certificate as if it were a user connecting. It will duplicate many of the details of Chat GPT certificate, but it will sign that new cloned certificate with its own internal private key and it will then return that cloned certificate to the enterprise user who will believe they've connected directly and privately to to chat GPT. Their browser will show www.OpenAI or chat GPT.com or whatever the URL is. However, they've actually connected to their enterprise's middle box which is masquerading as Chat GPT, which it can do because their PC contains that root CA for the middle box. Therefore middle box created certificates are trusted inherently. Now all of this may seem like a lot to go through, but it's the only thing that allows the enterprise to monitor the TLS encrypted communications of its employees to prevent them from, for example, uploading the company's 10 year product planning in order to ask ChatGPT it thinks about those plans. Those should not leave the enterprise, so somebody needs to guard those communications. Yifan's point about the installation of a root SE certificate and man in the middle proxy is that for reasons that are not at all clear, H and R Block has thereby by doing what they've done, they've given themselves all of the same privileges and capabilities as any enterprise middlebox on their customers computers. The question is what?
- [33:24]
A
Too much power?
- [33:25]
B
Yes. They could intercept all of their customers communications to any other website. Oh my God.
- [33:35]
A
Why would you want that?
- [33:37]
B
Yes Level. Why would you want the responsibility of having that responsibility?
- [33:42]
A
Yeah. Thank you.
- [33:44]
B
The only reason H and R Block would need to include the private key that matches the CA root certificate they installed into their users machines would be if they needed to create and sign TLS certificates on the fly that would be trusted by that user's machine. I don't see any other possible need for the private key being locally present as it is. So again why, why is it H and R Block have given themselves the capability for for wholesale local machine invasive traffic interception and decryption. And there doesn't appear to be any reason why tax preparation software would need anything like this. And even if we trust H and R Block and assume that they must have some justifiable basis for having given themselves this capability on every one of their customers machines that have installed their software. As Yifan himself demonstrated, they will also have given anyone else, anyone else like him, this researcher who is aware of this, the same privileges. Since the CA root cert is installed and its matching private key is sitting in a DLL for anyone to extract and use. I mentioned at the top that we were going to reverse engineer this in an attempt to understand what's going on. I haven't seen this H and R block software and I don't, I, I, I don't want to let it anywhere near my machines, right? So I have not watched it work. But the only reason I can see that they would do this would be if their software installs and runs a local web server in their user's machine. This would allow them to have a fully web browser based user interface and a, a, a UI free headless web server that encapsulates all of their tax preparation logic. In other words, we, we go to Google Docs in order to use Google's document application, it would be possible to instead go to H and R block software server with our browser running on our machine to use their tax prep application delivered to us by a server running locally. So clicking for example, some sort of little startup app would invoke the Windows shell to launch the user's default web browser with a URL like 127001 colon and then like some port number 1234 or some custom port number, whatever they wanted to use, you know. Or they might have also tweaked the user's hosts file to map a more friendly looking domain name like hr block hyphen tax hyphen prep.com mapping that to 127001 IP. That way users would see something comforting in their web browser's URL address bar. But none of that actually explains why they couldn't then just install a root CA and a certificate for that. There's no need to make it up on the fly. I, I mean I'm kind of like I'm giving them the benefit of every possible excuse here. Okay, so now the user clicks on the startup app which launches their web browser, which accesses their locally running web server. That built in local web server needs to present their browser with a TLS certificate that matches the address they've accessed. Again, 127001 or hrblocktaxprep.com or whatever, whatever the case that certificate needs to be trusted by the browser. This means that it must have been signed by the private key that matches the root CA certificate that HR Block planted into every user's PC since the root's subject name, the root, that root certificate, subject name, as Yifan told us, is WK Space, ATX Space, Server Host Space 2024. Okay, it seems unlikely that it would be, you know, used directly as the server's end certificate. That would be a weird string for users to see in their browser's URL bar. It's more likely that the installation process, or perhaps, you know, the. Maybe the first time you run the system that it would create the built in web server certificate which it would have, which it would then have signed using the root Cas private key, which we know is sitting in a DLL. And this is exactly as I said, what Yifan Lu did when he created his test site. Once all this was done, the built in web server would offer the user's browser this custom minted TLS certificate and it would use that certificate's private key, which it must. The web server would have that key to verify its valid ownership of the certificate it provided to the browser. The point I want to make here is that any web server that's accepting and terminating TLS connections does need to have the private key that matches the public key in the certificate which it provides to the web browser. But that should never be the private key for the CA root certificate. No one does that. Right there is the. The only thing the root signs is another certificate which is then presented to the web browser itself is never used. Thus you never need its private key to be around. Okay, so when all this was like revealed when, when Yifan found all this, he did the right thing and reported his astonishment and concerns to H and R Block. The timeline of his interactions with them was on March 10th. So today's what, the 24th? So two weeks ago today, on the 10th, he disclosed to H R Block through their responsible disclosure policy. Two days later, on March 12, he was asked to quote, please provide more details about how an attacker would realistically exploit this in practice, unquote and quote, share the video proof of concept from start to end, unquote. Three days later he'd. On the 15th, he did that. He wrote, provided H R Block with details and a proof of concept video and told them the deadline for their response is March 20th due to US tax season coming up on the 20th, he received the following statement back from a H and R Block. After review with the program team, we're closing this report as out of scope. The reported issue involves an executable application that falls outside our defined program scope. And similar findings have been identified through internal security assessments. Okay, what? So like yeah, we know. Like really somebody actually explained this to you and you're like eh, that's how it's supposed to work. Okay, okay. So this is obviously pretty much a head buried in the sand response. They deserve to receive full scrutiny over this very wrong headed design of their system. And I hope they receive that. There can be no doubt that the use of their tax preparation software leaves an uninvited unwanted, an unconstrained root Certificate with a 23 year lifetime remaining and its known private key sitting in the root store of every customer of their tax preparation software. And it persists even after their software has been uninstalled. Okay, now the one thing we've not examined is what I would do I, Steve Gibson, if, if I were told, you know, or if I were contracted with to do this in a secure fashion. So Micah, let's take a break and then we're going to look at that how to do this right.
- [43:52]
A
I am looking forward to hearing how we can do it right after seeing how you can do it. So, so wrong. But let's take a break. Leo Laporte joining us for the next sponsor.
- [44:04]
C
Hi guys, real quick, this episode of Security now brought to you by Guard Square. Mobile apps today. Well, you just listen to the show. You know, they've become an inescapable part of life. We use them all the time, ranging from financial services to healthcare, retail, entertainment. And of course users trust mobile apps with their sensitive personal data. But a recent survey showed that 72% of organizations experienced a mobile application security incident last year. And 92% of respondents reported rising threat levels over the last two years. Doesn't take a survey to know that right now, if you're an app developer, you gotta remember your users are trusting you and attackers want your user's personal data. So they're constantly finding new ways to, to attack your mobile app. This is one really awful thing they do. They reverse engineer it. Easy now using AI, they'll repackage it. They'll distribute your app modified via phishing campaigns, via sideloading by third party app stores, any means necessary. And then your users get compromised. And who they blame? They blame you. But by taking a proactive approach to mobile app security, you can stay one step ahead of these attacks and maintain the trust of your users. That's where Guard Square comes in. Guard Square delivers mobile app security without compromise, providing advanced protections for both Android and iOS apps combined with automated mobile application security testing to find Vulnerabilities and real time threat monitoring to gain insight into attacks. You're not helpless anymore. Discover more about how Guard Square provides industry leading security for for your mobile apps@guard square.com that's guard square.com we thank him so much for support and security now. And now back to Mike and Steve guys.
- [46:00]
A
Thank you very much Leo for that. We are joined once again by Steve Gibson as we continue on with understanding what we would do if tasked with fixing things for each and every.
- [46:14]
B
Okay, so if I. So first of all let me reiterate that I'm sort of, I'm like trying to give these guys every benefit of the doubt. I don't understand why they've done this. The only real reason that I can imagine is actually traffic interception. They would need this to act like, you know, in order to act like a middle box to intercept encrypted communications maybe. And again, I've not seen the software. Maybe they set themselves up and then their app says okay, now go to IRS.com go to your bank's website, go. I mean like maybe there are remote cloud based sources of information which it asks you to look at and while intercepting your communication so that it can suck that stuff in and incorporate it into your tax preparation. I don't know. I mean it's like that's like the only thing I can imagine now. Still horrible. I mean you don't want a, a proxy that's able to intercept all of your TLS connections installed on your machine, let alone left behind after you've uninstalled it. But that's the only thing I can imagine. And also if all they wanted was to be able to run a local web server that your browser trusts, then they would need to install a their own root cert and the web browser would then have a certificate that that root cert has signed. But there would never be the root search private key because it wouldn't be necessary. And the only thing that certificate would do would would be to run a local web browser. You know, web app developers do this all the time. They run a local web server on their machine. It's not a big deal. So H and R Block could have done that. If that's that, that's all they would have needed to do and it could have been safe. But say that for some reason they did need to deploy this on the fly. Even that could be done securely. And here's how. If I wish to deploy a product that included a built in web server that a user's Modern fully secured web browser could interact with without raising any warnings about insecure connections, lack of trust, self signed certificates and so on. It's possible. So HR Block, are you listening? Upon installation, the installing software would first generate a state of the art standard 4096 bit public private key pair. They would not ship that with the product. In other words, this thing the H and R Block did was they provided a public key in a, in a root CA and the private key bundled into bound into the dll. So they shipped those statically, which means anyone who gets a copy of one has what they need for all H R Block users. Which is where the problem is. No, instead generate it on the fly. Generate your own 4096 bit public key pair on the fly so that no two installations ever share the same keys. The public key half would be contained within a. To your point, a short lived root certificate, you know, having a lifetime of the expected duration of the product's use, maybe 90 or 120 days for tax preparation software. Micah, as you pointed out, there's no reason for it to live any longer.
- [50:34]
A
Yeah, because people are going to reinstall it again the next if they uninstall or something. The theory is they're going to install it again and use it again next year.
- [50:43]
B
And you since it's able to make a certificate, if it did expire, it could just make a new one. Yeah, even it itself could just bump this along forward. You know, always installing a few months worth of root CA that will gracefully properly expire after a few months. You'd like to have the uninstaller remove it because you don't want to just have this, all this crap accumulating in, in your, your users root stores. But okay. In addition it should tightly constrain the use of the certificate so that it can only ever be used to sign a TLS end certificate. Those are constraints that could be added to the ca. They didn't do that either. Okay, next it generates a second 4k bit public private key pair. It uses this second key pair to create the web server's local site certificate. So that's for that's going to be that, that's the certificate for the server that the server will send to the browser, to the, to the user's local browser. And it would name it something like, you know, HR Block Local Host. That would be a safe name. Local Host is reserved for the local host as a sort of a local host pseudo domain. So HR Block Local Host which would mean that certificate could never be misused in any useful fashion. It would only ever be able to serve and encrypt and authenticate TLS connections. In order for this local site certificate to be trusted on that local machine, it needs to be signed by the root certificates private key, that first one that was made, you know, the one belonging to the just created local root ca. And then here's what's crucial and cool. Immediately after that Root Cas private key was used to sign the local site certificate, that private key is securely overwritten and deleted. The point is that private key is never written to non volatile storage. So it is now permanently gone. And the locally installed root certificate can never be abused because its matching private key which is required for its abuse no longer exists. It was just, it was ephemeral, it was transient. It's gone. Since its private key was only ever needed once to sign the local certificate to prove that certificate's validity, it should never be retained. The installation then in my system would, in my solution would add an entry to the system's hosts file which maps hr block localhost to 127001. Now we have a certificate named hr block localhost with a unique public and private key pair that will only ever be trusted by, by a similarly unique root CA which will itself expire a few months after it was created. Any local browser can now be directed to some unique port I guess 80 if it's free. But you, you might want to do you know, 8888 just to, for the sake of being out there somewhere. So you know, HR block local host Colonial 8888 and now you're able to access the built in web server in order to view the a the HR block UI in a server client relationship. And lastly on its way out the software's uninstaller should remove the short lived root CA certificate after it shuts down the local web server and and deletes all of the products files. So as we've just seen in this example it is if you really needed to do this for some reason I don't see even why you have to because you could just, you know, give somebody a set of static certs that would only be useful for local, for HR block local host. But if you, even if you needed, if you wanted every instance to be unique and I can see a benefit there, it can be done in a way that does not open any security holes. But that's not what H and R Block has done through very poor security design. Sloppiness and as you said, apparently not caring. You know, they've Left behind a 23 year lifetime completely unconstrained CA root certificate, meaning it can sign TLS web certificates, it can sign code, it can be used for any malicious purpose you can imagine left behind in the root store of every one of their users with its matching key statically embedded in a shipping DLL so that it's known to the world. This makes you wish that our industry's software liability protections were not as virtually non existent as they currently are. I mean I'm sure somewhere in a, the, in the, in the license agreement that all users click on not reading because you can't, you know, 25 pages of legalese, you know, it says, you know, you know you are by using the software you agree to hold as harmless of any damage that may arise. You know, even if we'd been informed beforehand that such damage could occur. The license agreements all say that. And so it's like we can do anything we want to your computer.
- [56:59]
A
That's so frustrating to me. And that because I was going to say, you know, I'm always, I'm always curious he reached or this person reached out to H and R block. Each and our block had to know that if this was coming from truly a security researcher that this was going to be made public as opposed to it just being some, you know, I would imagine that if you just heard from some random person that did not, you know, put themselves forth as a security researcher at all, they might go oh we can bury this or this won't matter. But to say basically we don't care to someone who is going to disclose that. That's the stuff where I'm like, I want to meet every person involved in every part of these decisions and just hear what they're thinking is because what is their thinking and why would they that this is not a big deal when you're showing us how it can quickly become a big deal and that the responsibility there is is vast. But as you pointed out it with the right agreements in place, they don't need to care, do they?
- [58:07]
B
No.
- [58:08]
A
It's frustrating.
- [58:10]
B
Now speaking of frustrating, the company known as Intoxalock. Got to love the name. Provides court court mandated automotive breathalyzer facilities. Oh. That are installed into the automobiles of people who a court has come to the determination should be required to provide proof of their alcoholic sobriety through a quick built in breathalyzer breath sample every single time they get behind the wheel and wish to drive their car. Now since Alcoholic breathalyzer technology is tricky and can be a bit flaky. It requires periodic calibration for reliable operation by an authorized calibration facility. And the calibration facilities, it turns out, are all tied back to the mothership in the cloud that tracks and reports on all of this. Now, that whole system generally works pretty well, but it turns out only so long as a cyber attack does not render Intoxalock's entire periodic calibration and reporting infrastructure inoperative. This is exactly what befell Intoxalock Saturday before last on March 14th. So today is the 24th. A full 10 days later, their calibration system remains offline. It's down. The trouble that's now facing a gradually growing number of drivers who need to prove their sobriety to their cars is that the system's firmware has been designed to enforce a zero tolerance policy in general, no recalibration when. If you don't get a recalibration when it's needed, you don't get to drive and you cannot now recalibrate. As a result, as the recalibration system outage stretches on day after day, an increasing number of drivers are unable to use their automobiles. In some cases, Intoxalock is apparently, and this is on a state by state basis, apparently able to offer a 10 day calibration extension. But that appears, as I said, to be limited by state. A posting on their service status page explains it writes, effective immediately, service centers will be able to give your device a 10 day extension while our systems are being restored. Tennessee customers have a service date extension through Tuesday, March 24th. That's today at this time, this extension is not available in Michigan or Washington. Wow. We're actively working toward a resolution and will notify you as soon as anything changes. So here we have an interesting case of people's physical lives being meaningfully impacted by a cyber event. Since the calibration and reporting system sounds like it's very data based based, I would not be. Yeah, I would not be surprised to learn that Intoxalock, although this hasn't been publicly disclosed, had fallen victim to a generic ransomware attack which encrypted all of their systems. And in this case, consider the fact that the data that may also have been exfiltrated.
- [62:25]
C
Wow.
- [62:26]
B
Yeah.
- [62:27]
A
A list of all the people. Oh my goodness, yes.
- [62:33]
B
All of the people. Extra personal, extra private and extra sensitive. You know, involving the identities and the habits, the drinking habits and the drinking and driving habits of US drivers who have been under court mandated driving restrictions. That's not the sort of data anyone wish to have floating around the Internet I would argue. You know it makes a Social Security number look tame by comparison.
- [63:04]
A
Yeah, this is a huge blackmail target. I yeah honestly I was going to make some silly joke about I wonder how many executives didn't get to work on time that day. And then you said what you said and I thought actually it gave me goosebumps. This is horrible. This is awful. This is terrible.
- [63:23]
B
Yeah, it's not. Not good. And they're, they apparently are the go to company for. For this service. I was looking to see where what their status page says today because this was support.
- [63:42]
A
It also made me wonder why you're looking for that. It also made me wonder if the calibration narrative is pushed by that company so that they can continue to make money even after those breathalyzers are installed. And of course that's just you know, supposition but it is a very interesting thing to be one of the main companies providing what ends up being sort of a government mandated device needing to have these regular check ins.
- [64:15]
B
Yeah and the good news is they have got their systems back up at I went to intoxalock.com status and I'm getting a green bar systems restored services and installations resuming. So and it's got lots of instructions for people who are inconvenienced and, and and there's a mobile app and and so forth so note if you received a service date extension in Tennessee during the temporary pause please return to the service center today on March 24th. Failure to do so may result in an extension or full restart of the interlock program, whatever that means. So anyway the good news is looks like they paid ransom or they restored from backups we don't really know but they are back up. But if nothing else this demonstrates that we are cre. We are the. Our cyber world is increasingly interacting with the physical world and you know here cause people a lot of inconvenience especially
- [65:28]
A
when you've got all of your eggs in one basket or and as you
- [65:32]
B
said even with the system restored if they did, if this was a cyber attack and they exfiltrated all their database data as you said now there's serious extortion opportunities for anybody important who's you know, cares about keeping their past problems with drinking and driving private.
- [65:52]
A
Yeah, that's mortifying.
- [65:56]
B
Okay, so exactly one week ago last Tuesday the 17th Mozilla posted some welcome news under their heading More reasons to love Firefox. I don't need any more reasons. I Love Firefox, but okay, they wrote what's new now and what's coming soon. They, they, they start their post off rather generically by writing Firefox is for people who make their own choices online. Apparently they're saying, you know, Chrome people are sheep. I don't know from what stays private they wrote to the tools that help get things done. That commitment to choice shows up throughout the Firefox experience. The AI controls is just the latest example, meaning you can turn them off, making it possible to turn generative AI features off on or customize them feature by feature. Over the coming weeks, we'll be rolling out a series of updates that build on that expect more control where it matters, better protections in the background, and a few new tools that make everyday browsing better. You may even spot a fresh face of Firefox along the way. Okay, then they, you know, they talk about the ability to turn off any generative AI. A new feature coming in the next Firefox 149, which will allow side by side page display and the ability to write and attach notes to tabs. Okay, yeah, I'm not sure about the whole AI thing. The side by side webpage thing sounds as though it might come in handy for me for podcast production, since I'm often flipping back and forth between Google Docs where I author the page and the source information. So that would be cool. But the forthcoming new feature that caught my eye and which I felt sure would interest our listeners was Firefox 149, which drops today on March 24. Its new free built in VPN, they wrote. A free built in VPN is coming to Firefox. Free VPNs can sometimes mean sketchy arrangements that end up compromising your privacy. And I've often said, you know, don't trust a free VPN from some sketchy provider. Certainly Mozilla is not that they said, but ours is built is built from our data principles and commitment to be the world's most trusted browser. It routes your browser traffic through a proxy to hide your IP address and location while you browse, giving you stronger protection and protection online. With no extra downloads, users will have 50 gigabytes of data monthly in the US, France, Germany and UK to start available in Firefox 149 starting March 24. In other words, as I said today, now we know that there's been something of a gold rush to VPN services driven by the increasing use of IP based geolocation to limit underage access to age restricted Internet content. And services since Firefox's desktop. Unfortunately, its desktop presence continues to slip in terms of market share. It's down from 6.3 last year, down now just down to 4.2% desktop Share this year. So Mozilla may be hoping that the presence of a built in free VPN service will help. It is worth noting also that it has not escaped, unfortunately the the awareness of legislators that people are rushing to use VPNs in order to get around a state based location age restriction. And there actually has been some conversation about legislation to prohibit VPN use, which, you know, good luck with that. I mean it's like, hey, you know those TCP connections, they're pesky. I think we better outlaw tcp.
- [70:34]
A
Oh Lord, could you imagine?
- [70:35]
B
No. Come on guys. Where? Where does it stop? One place I know it doesn't stop is with our advertisers and Micah. Beautiful. A great place for us to take a break for a sponsor.
- [70:53]
A
I love that. What a great segue. Leo. Take it away.
- [70:56]
C
Hey guys. This episode of Security now brought to you by outSystems. The number one AI development platform. OutSystems helps businesses bridge the enterprise gap to their agentic future. Where the constraints of the past give way to unlimited capacity and scale. Outsystems enables businesses of all sizes to build agents that actually do work things like take actions, make decisions and integrate with data. More than just answering questions, OutSystems provides the only AI development platform that's unified, agile and enterprise proven. Let me explain. Unified because you build, run and govern apps and agents all in one platform. Outsystems Agile because you now can innovate at the speed of AI and importantly without compromising quality or control. It's enterprise proven because it's trusted by enterprises for some of the most important mission critical AI applications and durable innovation. Outsystems. It's the secret weapon behind the world's most successful companies. And this isn't just for small apps. These are for massive, in many cases massive, complex systems that are running banks, insurance companies, government services, out systems. Even helps companies with aging IT environments bridge the gap to the AI future. Without a rip and replace nightmare, it almost feels like you could do anything. Outsystems. It provides the safest and fastest way for an enterprise to go from we need an AI strategy to yeah, we have a functioning AI application. Stop wondering how AI will change your business and start building the agents that will lead it. Visit outsystems.com TWIT to see how the world's most Innovative enterprises use outsystems to build, deploy and manage AI apps and agents quickly and cost effectively without compromising reliability and security. That's O U T S Y-S T E M S.com TWiT to book a demo outsystems.com TWiT we thank them so much for supporting the good work Steve does here at Security. Now, now back to the show.
- [73:11]
A
Indeed we are back to the show. Take it away, Steve.
- [73:14]
B
Okay, so I just learned how far tracking pixels and we now need to put that in air quotes because they are so much more. They're easy to miss because much like cookies, the code which their presence on any web page allows to run is completely hidden from us. I mean, it's not that you can't get it, but it's not easy to see. Last Wednesday the 18th, the security researchers at JSCrambler shared what they had recently learned about what TikTok and Meta are both now doing. Their headline was beyond analytics, the Silent Collection of commercial intelligence by TikTok and meta ad Pixels. Okay, and as we're going to see this writing, Jay Scrambler's writing is targeted at web merchants who are voluntarily putting these insidious tracking pixels onto their sites. Because, you know, this is not something that, that happens without the site provider's knowledge. This is something that they, you know, said, oh yeah, you know, we're, we, we, we want the analytics or we want the, whatever we're getting in return. So every page that we serve will have a reference to some JavaScript back at meta or at TikTok or wherever, basically causing the user's web browser to, to, to pull in that resource and invoke whatever the script is. So here's what they explain. They wrote TikTok and Meta's tracking pixels are quietly harvesting personal data, granular checkout interactions, and detailed commerce intelligence from the users of the websites that implement them. The collection is going to far beyond what ad attribution requires, creating serious privacy compliance risks and competitive disadvantages for the businesses involved. Jay Scrambler conducted a runtime analysis of the ad pixels used by TikTok and meta on actual websites, revealing that their default behavior requires immediate attention from every organization that employs them. The analysis focused on large companies in the retail, hospitality and healthcare sectors. However, it's worth noting that most businesses with an online presence use these tracking pixels on their websites as well. Okay, now I'm, I'm sure I don't need to tell our listeners that this is not something I, you know, with GRC would ever consider doing? I'm annoyed that I've given Google any presence at all. But that little search box, you know that little search box is that that's a pro visitor feature. Other than that, you know, GRC may be ancient appearing, but it's also completely devoid of all modern web analytics. Because I just, I would rather protect my users privacy. What's so insidious about this is that when a company says, okay, yes, we'll make a query to your ad server to pull in your ad pixel, they have no control over what it does once it gets there. That's the key point. It's very much like software that goes out and downloads some other software to enhance itself. That if that if the behavior of that augmented software changes, then the overall product changes after the fact. Yeah, anyway. Jay Scrambler continues writing Tracking pixels were once just a small snippet of code on a web page to confirm an ad impression of or log a visit. Almost all websites use them to track user behavior, measure ad performance, and optimize marketing efforts. These pixels let businesses see which ads drive traffic, conversations or sales, and provide data to retarget users who showed interest but might not have completed a purchase. What many website owners likely don't realize is that TikTok and Meta's pixels now go far beyond those traditional tracking tags. They collect user emails, phone numbers, and addresses, turning seemingly anonymous browsing data into persistent, identifiable, identifiable user profiles. TikTok's Pixel, they write, creates three different data records for each user interaction. A primary event record of what the user did, such as viewing a product or adding to a cart, a metadata record, and a performance record, all connected using the same session id. When personal information like an email or phone number appears On a page, TikTok's identity module processes it, normalizes it, and converts it into an SHA256 style hashed identifier before sending it out. Meta takes a similar approach, hashing a wide range of fields, including first and last names, locations, and external identifiers. The hashes are deterministic, meaning they produce the same output for the same input each time. And because the hash is built from predictable data like emails and phone numbers, it's easy to re identify them by matching those hashes against existing hash data, meaning that if metadata I mean if meta has your email address and hashes it, they get the same hash. If they get if they have your phone number and hash it, they get the same hash. So when those hashes later pop up out on the web, they know it's you there's no mystery there. It's not you are not anonymized and they write. It effectively eliminates anonymization, allowing platforms to recover original user data and build long term behavioral profiles without the user's knowledge. In practice, this is like a candidate input matching process where emails or phone numbers are compiled or generated, hashed and then compared against the target hashes to find matches. Identity resolution is only part of the problem. Jscrambler's research, they wrote, found that TikTok and Meta's ad pixels match methodically harvest detailed product level intelligence and entire customer journeys from merchant websites. Meta and TikTok's requests routinely include product names, unit prices, quantities, currency and total cart values. They also logged specific checkout actions such as add to cart or add payment info. In other words, stuff that is none of their business. Meta's telemetry even records the structure of checkout forms and buttons, providing insight into how a merchant's site is built. Wow.
- [81:44]
A
Are they making this data available to the people whose sites they're on?
- [81:50]
B
That's wild.
- [81:51]
A
This is, this is not a trade.
- [81:53]
B
It's total intrusive for Meta's benefit. And maybe they're selling it. Yeah, I mean it's data that they are aggregating. So I'll just interrupt to note that, you know, you might be thinking, if you might be thinking that none of this is any of Meta's effing business, I would agree with you wholeheartedly. It is so wrong and intrusive. They do it simply because they can. They can because it's hidden, because web browsers will run by default any JavaScript they're given and because there's no one looking, there's no one to stop them. Jscrambler continues but well, and I'll note also Medic can say, oh, but we hash the data, we anonymize it. No you don't. You're not throwing in a random token with the hash because if you did, it wouldn't be useful to you. It would then be purely random noise. So they said merchants are unlikely to be aware of the extent to which their websites share data with these tracking pixels. While they might know that pixels collect basic conversion information, much of the detailed product level checkout stage and structural form data is automatically captured or passed through integrations like Shopify with little visibility. While businesses might think they're enabling only standard tracking, in reality they are feeding third party platforms with a deep continuous view of their product catalog, pricing and customer behavior that could potentially benefit larger rivals. The implications from a privacy compliance and sensitive data exposure standpoint should be very concerning from any or for any organization using these pixels. Jscrambler found TikTok pixels capturing sensitive data even before a user had the opportunity to make a consent choice and in some cases even after a user had clicked reject all we observed TikTok capturing physical addresses entered into store locator fields at major French and German retailers and transmitting the data back to their servers. Metaspixel includes a feature called Automatic Events, which is enabled by default. The feature automatically scans page elements and captures information such as checkout interactions and and visible payment card details, including the last digits, expiration date and cardholder name.
- [85:00]
A
Why? I mean, I know why, but I just.
- [85:04]
B
You full spying?
- [85:07]
A
Yeah, it's absolutely full spying. And to do it without any regard of Just like they're not even having to explain themselves because as you've pointed out, no one's paying attention to this.
- [85:18]
B
Yep, since this they write since this is the default behavior and not opt in merchants may not be aware that the pixel is collecting this information. The pixel I love calling. It's like calling it a pixel makes it. Oh look, it's a little.
- [85:34]
A
Yeah, exactly.
- [85:38]
B
On separate sites, Meta captured recipients, full names and delivery addresses when users selected address Options during checkout. TikTok's Pixel was observed exhibiting similar behavior, harvesting sensitive user data during the checkout process. This included partial payment card details and other personal data provided by the customer. Both TikTok and Meta's pixel code can load and begin transmitting data. Hear it Again. Again. Both TikTok and Meta's pixel code can begin. I'm sorry. Can load and begin transmitting data before the website's consent management system has time to block it, meaning information can leave the browser before the user's choice is applied even more. That's right.
- [86:40]
A
Right. They're coming.
- [86:41]
B
We asked the user. They said no, but oops, it was too late.
- [86:45]
A
Yeah.
- [86:46]
B
Even more concerning is that data may be transmitted in clear text, occasionally within the request URL itself, exposing sensitive information to browser histories, server logs, intermediaries and debugging tools. This vulnerable, so it wasn't even well done with like a privacy first approach. They said this vulnerability stems not only from the pixel's data collection methods, but also from misconfigurations during its implementation or from issues with the website's underlying architecture. Consequently, the attack surface is significantly broader than a surface level analysis would suggest. The behaviors jscrambler documented put websites in direct conflict with gdpr, CCPA, and other major Privacy regulations. The potential violation triggers include consent failures, inadvertent personal data transmission, and financial or address data exposed in logs that outlast the original request. In addition, the exposure of partial cardholder data and address information increases the risk for identity theft and secondary data breaches. From a competitive standpoint, merchants need to understand that the pixels they implement. Pixels. I mean, calling it a pixel is so wrong.
- [88:19]
A
Yep, I agree.
- [88:20]
B
The pixels they implement are not passive measurement tools. They are instead active data collection systems that feed proprietary commercial intelligence, such as pricing, product mix conversions, and customer behavior directly into the same global advertising platforms that every other merchant on those platforms, including rivals, relies on. Larger rivals with bigger ad budgets could benefit because the more data the platform collects from all merchants, the better its targeting becomes. Often better targeting favors those with the most budget to spend on ads because there's more ads available for choosing. To manage these risks, they write, organizations need to do considerably more than just review a pixel's documentation. This involves auditing actual pixel configurations, meaning work and implement implementing continuous monitoring to catch scope creep. Meaning the pixel used to be a cute little thing that only targeted ads, but that was 10 years ago. Now you're downloading a whole suite of spying intelligence where in that cute little pixels JavaScript they. They finish where a third party script begins collecting more data than originally intended. Exactly. So. Wow.
- [90:02]
A
Jeez Louise, that's. Yeah. So that's again, frustrating.
- [90:06]
B
It's, it's. It's commerce, you know, getting away with everything it can. And of course, why wouldn't they? You know, we're talking meta. They're an aggressive commercial organization and they've, you know, convinced the whole world to put their cute little tracking pixels everywhere. Yikes. Okay, as we know, no one is an island. Unfortunately, that's a problem if you don't get any messages. I suppose we should not be surprised that Russia's increasingly stringent and pervasive Internet stranglehold is choking their own local companies. Russia's private sector is desperately asking their government to lift the recently imposed total bans on Telegram, WhatsApp, and other foreign messaging platforms. It seems that not everything needed to conduct business in Russia can be found within Mother Russia and that Russian entities need to conduct and work with foreign partners. And unfortunately, Russia is saying, no, we don't want you to be using know they've got their own. I can't remember now what it's called. They. They did a native Russian messaging app, which of course no one wants to use because we know that Russia is spying on it. So Nobody outside Russia wants to have anything to do with some Russia spyware. Who knows what it does once it gets into their machines. Another bit of news. I saw this blurb, a security news summary, and I thought, okay, well that's interesting. Let me share it first, then I'll tell everyone what what I thought. The security news blurb was titled Open Claw Fishing Campaign and it just said threat actors are spamming GitHub issues and tagging other developers with fake promises of Open Claw tokens. The plan is to lure the devs to phishing sites where they're asked to connect their crypto wallets but are getting their accounts emptied. Okay, so that's all we know. I don't ever want to see anyone hurt, of course. Really, I don't. Ever. But anyone who would naively connect their crypto wallet containing any amount of crypto which they're not entirely prepared to be separated from in the next moment, especially if they consider themselves to be savvy enough to be a developer, they would have a difficult time extracting much sympathy from me, even though I never want them to be hurt. I mean, really, you know, you sometimes
- [93:24]
A
need an object lesson, and someone who's making those mistakes needs perhaps an object.
- [93:30]
B
And I just hope it's not too expensive a a lesson. I, I would certainly be sorry that if anyone were scammed, but I would not be very surprised. So our takeaway here is please, please always be careful. You know, especially anytime you're connecting any wallet to any sort of automated system which you cannot be 100 certain of. You know, really like set up a secondary wallet, transfer a little bit of working money there, and then, you know, use that if you must connect it to something, but you know, not your wallet where you actually store any useful amount of money. Since we previously touched upon Cisco's very bad 10.0 CVE 2026 20127, which was that widely exploited authentication zero day discovered while being exploited in Cisco's Catalyst SDWAN Enterprise product line. Really, anyone could be forgiven for confusing that one with Cisco's CVE 2026 201. 31. So not 27. No, 31, which is another, wait for it, CVSS 10.0 Critical Vulnerability in Cisco's systems. As I said at the top of the show, what would the Security now podcast be without a brand new shiny Cisco CVSS Critical 10.0? The NIST NVD the national vulnerability database, says of the new one 31 they write a vulnerability in the web based management interface. Who would have guessed of Cisco Secure Firewall Management center apparently not. That secure software could allow an unauthenticated remote attacker to execute arbitrary Java code as root on an affected device. In other words, there you go, Cisco 10.0. They wrote this vulnerability is due to insecure deserialization of a user supplied Java byte stream. An attacker could exploit this vulnerability by sending a crafted serialized Java object to the web based management interface of an affected device. A successful exploit could allow the attacker to execute arbitrary code on the device and elevate privileges to root. That's right. Unfortunately, most of the world that's not listening to this podcast has not caught up to the many continuing demonstrations that authentication does not work. If authentication did work, then unauthenticated hackers and attackers would not and could not be continuously breaking into supposedly protected systems in ways that bypass their authentication controls. Right? I mean, one plus one equals two. Not to mention, oh, I don't know, allowing them to execute their arbitrary Java code as root on breached devices. And so what happens to enterprises who solely rely upon Cisco's broken authentication promises to protect their perimeters? Last Wednesday the 18th, Amazon's threat intelligence posted their observation under the headline Amazon Threat Intelligence Teams Identify Interlock Ransomware Campaign Targeting Enterprise Firewalls. Gee, which enterprise firewall do you think that could be? Amazon's Threat Hunters wrote, quote, Amazon Threat Intelligence has identified an active interlock ransomware campaign exploiting CVE2026 201 31, a critical vulnerability in Cisco Secure Firewall Management center software that could allow an unauthenticated remote attacker to execute arbitrary Java code as root on an affected device, which was disclosed by Cisco on March 4, 2026. Now that's an important date. March 4, 2026 disclosure means patch available on March 4, 2026, they wrote they Amazon After Cisco's disclosure, Amazon Threat Intelligence began research into this vulnerability using Amazon's MAD POTS global sensor network, a system of honeypot servers that attract and monitor criminal cyber activity while looking for any current or past exploits of this vulnerability. Our research found that Interlock was exploiting this vulnerability 36 days before its public disclosure beginning January 26, 2026. This wasn't they write. This wasn't just another vulnerability exploit. Interlock had a zero day in their hands, giving them a five week head start to compromise organizations before defenders even knew to look. Upon making this discovery, we shared our findings with Cisco to help support their investigation and protect customers. Okay, so just so that everyone is clear about the timing of this, again, Amazon discovered exploitation of this zero day dating back as far as January 26th. And Cisco's announcement and patch wasn't made available until March 4th. So for at least 36 days or a little more than five weeks, only the bad guys knew of this. And even fully patched and up to date Cisco Secure firewalls and the enterprises behind them were being compromised and falling victim to this interlocked ransomware and campaign. Through no fault of theirs, those they were fully patched and updated. Amazon explained what they found writing a misconfigured infrastructure server, essentially a poorly secured staging area used by the attackers. They actually found an in an a misconfigured infrastructure server of the attackers exposed. They wrote Interlock's complete operational toolkit. This rare mistake provided Amazon's security teams with visibility into the ransomware group's multi staged attack chain. Custom remote access trojans, backdoor programs that give attackers control of compromised systems. Reconnaissance scripts meaning automated tools for mapping victim networks and evasion techniques. In other words, Amazon has honeypots. The bad guys infected a honeypot. Amazon was able to use the infection to track backwards up into the attacker's infrastructure which they found improperly set up. So they were able to get in.
- [101:59]
A
Now hold what if. Maybe I'm writing a movie now, but what if that was just a reverse honeypot and it points Amazon down the wrong route when they found all this
- [102:10]
B
data that could be possible. Although what they worked from was Cisco's fresh disclosure so so they had evidence that that system was attacking their honeypot. You back as many as 36 days earlier using information that was not public. So nobody knew how how, how it could be used to to get into their customers machines. Let's we're at an hour and a half in, let's take a break and then I'm going to finish up with what Amazon tells us about this interesting and unfortunately all too common Cisco vulnerability.
- [102:57]
A
I will say the magic words to summon Leo laporte. Bippity boppity Laporte.
- [103:05]
C
This episode of Security now brought to you by Zscaler, the world's largest cloud security platform. You know we talk about this all the time. The potential rewards of AI are far too great for any company to ignore. But so are the risks, right? Loss of sensitive data attacks against enterprise managed AI, generative AI increases opportunities for threat actors, helping them to rapidly create phishing lures, write malicious code and automate data extraction. Did you know there were 1.3 million instances of Social Security numbers leaked to AI applications last year? ChatGPT and Microsoft Copilot saw nearly 3.2 million data violations. Yikes. It's time to rethink your organization's safe use of public and private AI. And if, if you want to know more, just check out with Siva. The director of Security and Infrastructure at Zwara says about using Zscaler to prevent AI attacks.
- [104:03]
B
Watch. With Zscaler, being in line in a
- [104:06]
A
security protection strategy helps us monitor all the traffic.
- [104:11]
B
So even if a bad actor were to use AI because we have tight security framework around our endpoint, helps us proactively prevent that activity from happening. AI is tremendous in terms of its
- [104:22]
A
opportunities, but it also brings in challenges.
- [104:24]
B
We're confident that Zscaler is going to help us ensure that we're not slowed down by security challenges, but continue to
- [104:30]
A
take advantage of all the advancements.
- [104:34]
C
Thank you, Siva. With Zscaler Zero Trust plus AI, you can safely adopt generative AI and private AI to boost productivity across the business. Their Zero Trust architecture plus AI helps you reduce the risks of AI related data loss and protects against AI attacks to guarantee greater productivity and compliance. Learn more@zscaler.com security that's Zscaler.com security. We thank him so much for supporting security. Now, now I see Steve's all caffeinated, so let's get back to the show.
- [105:09]
A
Let's do it.
- [105:10]
B
How did he know?
- [105:13]
A
That's a big cup.
- [105:17]
B
Okay, so just to finish on Amazon's threat intelligence, they wrote AWS infrastructure and customer workloads on AWS were not observed to be involved in this campaign, meaning Cisco customers, not Amazon customers. They said this advisory shares comprehensive technical analysis and indicators of compromise to help organizations identify potential compromise and defend against Interlock's operations. Right. I mean this was going on for 36 days. Anybody who the bad guys could find who had this firewall may well have been compromised. So you know, a true problem. They said Amazon threat intelligence identified threat activity potentially related to this CVE 20131 beginning January 26th. Observed activity involved HTTP requests to a specific path in the affected software. Request bodies contained Java code execution attempts and two embedded URLs, one used to deliver configuration data supporting the exploit and another design to confirm successful exploitation by causing a vulnerable target to perform an HTTP put request and upload a generated file. So that was the the compromised system sending stuff back up to the bad guys infrastructure. They said multiple variations of these URLs were observed during across different exploit attempts to advance the investigation and obtain additional threat intelligence. We performed the expected so they were pretending to be infected we performed. We Amazon the expected HTTP put request with the anticipated file content. Essentially, we pretended to be a successfully compromised system. This successfully prompted Interlock to proceed to the next stage, issuing commands to fetch and execute a malicious ELF binary a Linux executable file from a remote server. So that suggests that the Cisco firewall is Linux based. And so this was downloading Linux malware into and to be run by the Cisco firewall. They said. When analysts retrieved the binary, they discovered the same host, that is the hacker controlled server, is used for distributing Interlock's entire operational toolkit. The exposed infrastructure organized artifacts into separate paths corresponding to individual targets, with the same paths used for both downloading tools to compromised hosts and uploading operational artifacts back to the staging server. And if they were able to look around in there, they may have seen all the uploads from all the infected systems. No one's talking about how many systems were infected, but my guess is Amazon knows and Cisco probably knows and hopefully is not happy about it. They said the ELF binary and associated artifacts are attributable to the Interlock ransomware family based on convergent technical and operational indicators. The embedded ransom note, the ransom note and the Tor negotiation portal are consistent with Interlock's established branding and infrastructure. The ransom notes invocation of multiple data protection regulations. Oh, you gotta love that. You are in you. We just attacked you and infected you and now we've exfiltrated your data, which puts you in violation of various data protection regulations.
- [109:07]
A
Congratulations.
- [109:09]
B
Oh, by the way, yes, congratulations. So they said the ransom notes invocation of multiple data protection regulations reflects Interlock's documented practice of citing regulatory exposure to pressure victims, essentially threatening organizations not just with data encryption and exfiltration, but with regulatory fines and compliance violations. Wow.
- [109:40]
A
It's clever. It's clever.
- [109:42]
B
They're bold. The campaign Specific organization identifier embedded in the note aligns with Interlock's per victim tracking model. Interlock has historically targeted specific sectors where operational disruption creates maximum pressure for payment. Education represents the largest share of their activity, followed by engineering, architecture and construction firms, manufacturing and industrial organizations, healthcare providers, and government and public sector entities. Amazon's posting then goes into very interesting and rich detail. It's certainly relevant to anyone who may have fallen victim to this, or anyone who might worry that they may have. But what matters most is the way Amazon's Threat Intelligence Group concludes. They write the real story here isn't just about one vulnerability or one ransomware group. It's about the fundamental challenge Zero Day exploits pose to every security model. When attackers exploit vulnerabilities before patches exist, even the most diligent patching programs cannot protect you during that critical window. This is precisely why defense in depth is essential. Layered security controls provide protection when any single control fails or hasn't yet been deployed. Rapid patching remains foundational in vulnerability management. But defense in depth requires organizations, I'm sorry, helps organizations not to be defenseless during the window between exploit and patch. Right? So there you have it. The point Amazon is making is that if there is no defense in depth, if everything relies upon that single point which could fail, and we see, keeps failing, an organization security perimeter could be breached even if they did absolutely nothing wrong during that at least five week interval, any fully patched and fully up to date Cisco firewall could have been successfully breached through no fault of their IT managing staff. Unfortunately, this is not what we normally see. We are usually, we're usually noting that lax and lazy and inattentive IT was at fault, at least at fault for not keeping their equipment up to date. Right? Like if patch was available months ago and they still hadn't got around to updating. But not so this time. As Amazon reminds us, defense in depth is needed because it's never safe to depend entirely upon any single security control. Anytime any management portal is exposed to the entire global Internet where access is controlled by some form of authentication, the security of the entire organization now rests upon that single point which could fail. And that state of affairs would be acceptable if nothing more could be done, right? If there was, if you, if like if we've done everything and there, there's, we, we still have a single point of failure. If nothing more could be done, then okay, I guess that's the best we can do. But it is almost always the case that additional parallel protections could be erected so that for example, almost, almost no one is even able to see that possibly vulnerable authentication interface. No one in China, no one in North Korea, no one in Iran, no one in Russia can even get to, because there's port filtering that blocks their access to that authentication interface. Unless you really need everybody in the world to be able to guess your password, don't give them the opportunity.
- [114:23]
A
So then arguably it, you said in this case the. It did everything right, but it seems like you are also arguing that they didn't. Because doing everything right would also mean that you have security and depth, right?
- [114:39]
B
Yeah, so that's a very good point. What I meant was it was key at least keeping everything patched. But this demonstrates that even keeping everything patched is really no longer enough. You need other layers. And if somebody had other layers, although you wouldn't want to be lax on patching, at least being latched on. Lax on patching, like being a few weeks or months late, well, you wouldn't get infected because bad guys couldn't even, couldn't even attempt to infect your system. So really, you know, we would, you know, the, the, the jargon that I've been using most recently, that, that, that I used at Zero Trust World and, and before was really bringing stronger meaning to least privilege. You want least privilege to apply? It is a privilege if someone in China has the opportunity to guess your password. Why, why have you given Chinese attackers the, the privilege of doing that? They shouldn't even be able to see that you have a management interface. You know, they should be blocked by simple IP based filtering. And it's so easy to do. But everyone says, oh, look, Cisco, you know, they have a, you know, we, oh, we got security. No, you need. Your security needs security.
- [116:13]
A
I like that. That's, that's a shirt for security. Now your security needs security.
- [116:18]
B
Your security needs security. Okay, so finally, before we talk about listener feedback, I just did want to mention that Cisco's not alone. Last Wednesday and then updated on Saturday, Ubiquity released a security update to Patcher Critical. Also one of the rare. I, you know, it used to be that CVSS 10.0 were, were rare, right? Nobody had them. Like the worst you would see was a 9.8 and we would joke about, oh, you got to try real hard to get up to a 10.0. Well, unfortunately, Cisco has put the lie to that because they're getting them all the time now. In this case, so did ubiquiti. A CVSS 10.0 was discovered in its Unifi Internet gateway and WI FI management application. The flaw enabled a path traversal exploit that could allow threat actors to access the device's configuration files as never good and take over unified gateways that way. So Ubiquiti Unifi users are advised to update. I know we've got a bunch of Ubiquiti users and unifi users. Leo is a big proponent, so everybody should update. Okay, Some listener feedback. Vern Mastel. He said his, his email had the subject clocks cursive encoding with AI. And he wrote, steve, we already have many children who cannot tell time on an analog clock. Many school systems began phasing out cursive writing a decade or more ago. In another generation, the ability to read and write cursive will fall into the category of arcane skills understood and practiced by only grizzled old professors in dusty, cluttered offices. He said. For decades we've been teaching students how to code. With advances in AI, it seems clear that this too will cease. Why bother when you can have an AI bang out apps in minutes? It seems likely that that in the near future old school style programming will also become an arcane skill known and understood by only a few. I have to agree. I I think we're we're very clearly seeing that actually writing code will change into managing its authorship by, you know, AI devices. That clearly seems to be where we're headed. And I remind everyone what we have today is not what we're going to have tomorrow. It's going to be getting way, way better. Jeffrey Ko wrote Hey Steve, since it's getting close to tax time, I thought you might enjoy seeing the IRS version of the click fix exploit. And he said I blurred out the script. He said, I'm a long time listener Every episode Spin Right Owner Regards, Jeffrey Jeffrey D Co so and he he attached in his email a picture of an Internal Revenue Service Department of the treasury sent from Austin, Texas with their zip code. It's letter number 1058 and it says Final notice, Notice of Intent to levy and Notice of your right to a hearing addressee. Jeffrey and then there's we we have a case ID and it says you must respond within seven parens numeral seven calendar days. Your account has been selected for AN office examination. Colonel Revenue Code Section 7602 authorizes the IRS to require you to appear and provide records. We've identified a mismatch between the income on your tax return and data received from payers oh 1099 that you didn't report. That's never good. To resolve this matter, you must appear at an IRS location. Receipt of this notice must be acknowledged using the secure method below so we can schedule your appointment. Non acknowledgement will be deemed Failure to respond. This notice does not contain clickable links. Acknowledgement may only be made via the secure method indicated. And now we have the increasingly familiar and unfortunately, increasingly successful Click Fix variant. It says in a separate box call out. It says acknowledgment required. Step 1 Hold the windows and R keys together to open run. Step 2 Type or paste the acknowledgment code from the box below into the open field. Step 3 Press enter. We will then assign your appointment and then it provides in in a you know the down below acknowledgment code which starts out reading powershell space quote and then we have something that Jeffrey blurred out, then we have forward slash irs and then a space vertical bar space iex and then a close quote. So again, as we know this succeeds because so few people actually understand how Windows works. They're users who basically follow scripts of various forms. And this latest trend of click fix to me is truly frightening. We've learned and previously reported that more than half I think it was 52% of all exploits combined are now attributable to this single category of click fix related social engineering attacks, more than half of all successful attacks. And even before we had this number it was clear just looking at them that these attacks which leverage the the user's lack of true understanding of how their PCs operate would turn out to be devastating. So Jeffrey, thanks for sharing that. Jim Housley wrote listening to SN 1070 from March 17th so that's last week you were talking about properly signed malware and you commented about how the certificate had to be in an hsm, you know, hardware security module. He said. However, in the previous two or three weeks when you were talking about the current options for you to get a new certificate, you mentioned that signing in the cloud was becoming an option and seemed to be preferred by the cas with cloud based signing. Isn't it possible to share or steal access to the cloud account to use someone else's certificate? Longtime listener since episode one Spin Right Owner thanks Jim. In a word, yes, you are 100% correct Jim. Once code signing is moved into the cloud then we introduce the whole new specter of remote network authentication into the code signing domain and huh. Has there ever been any trouble with authenticating who people are over a network? Yeah, I believe I'd prefer to take responsibility for my own code signing certificate that's password protected in a hardware module which resides inside a closed server, inside a locked rack, inside a locked cage that's under 247 surveillance using a triple locked building with biometric pin and badge reader and ever prowling security. That's where mine is and it has never suffered a break in. So I think old school physical security is a little better than allowing, you know, foreigner foreign attackers from states we don't trust, free roam and access trying to impersonate us and get our code signed. I think Jim is exactly right. And finally Michael wrote Hey Steve, you're not alone in your love of coding. Like you, I absolutely love writing my own code and solving problems myself. I don't care if I'm not as fast as AI as long as I am fast enough to achieve my own goals. And like you, I'm writing professional software. It's not just a hobby. And like you, I'm a one man team and my own boss. Consider this analogy. Many fishermen buy their poles and lures at Walmart, which is fine, but there exists a small subset of fishermen who make their own lures. And I bet you would, Micah, because you're a craftsperson.
- [125:57]
A
I was going to say. Ooh, this sounds fun.
- [126:00]
B
Who make.
- [126:01]
A
Who.
- [126:01]
B
Who make their own lures because they're craftsmen who love the craft. And the experienced ones produce much better lures than the machine assembled ones available at Walmart. I suspect your code is the same, and I'd much rather buy software like Spinrite from you, which I know you had, which I know has had your full attention and 30 years of maturation, then ask Claude to write a cheap knockoff, just like I'd much rather write my own software, you know, make my own lures, essentially, then cheat myself out of the joy of coding. That said, I do use Gemini to do the things I do not enjoy, like writing regular expressions, but even then it makes mistakes that I often need to correct. Anyway. You keep on coding and know that you're not alone. Longtime listener and huge fan, Michael. And I like Michael's fishing lure analogy a lot. Yeah, it. I think it clearly articulates the craftsmanship aspect of coding, which anyone who codes, you know, because they love it just for its own sake, would understand. So for me, AI producing code does not represent a worry or competition. You know, I've never been interested in coding in a production environment. I love that. Many more people than ever before are now finding themselves able to get their PCs to do things they never could before because AI is able to create code for them, which does what they want. You know, to me, that's the greatest innovation so far on the AI coding front. And I'm sure that we, as I've said, we've only seen the tip of the iceberg. We've got lots more to come in in upcoming years. Okay, and Micah, that brings us to our final break before we talk about bucket squatting. What it is, what it means, and I don't know, I don't think you want to squat over a bucket.
- [128:28]
A
No, no. In fact, ever since the introduction of plumbing and the toilet, I don't need a bucket anymore anyway. Well, let me take a moment. We continue on with the show to tell you about Club TWiT at TWiT TV Club TWiT. That is where you can go to sign up. $10 a month, $120 a year gets you access to the club. You can also use that QR code up in the top corner there. When you join the club you gain access to some pretty awesome benefits. You get every single one of our shows ad free. Just the content. You also gain access to our special feeds. We have feeds that you will enjoy, including our feed that has our kind of behind the scenes before the show. After the show we have a feed that has our live coverage of tech news events. We also have a feed that has our special club Twitch shows like what was alluded to a couple of times here. My crafting corner we have Stacey's Book Club. We have so many good things there in the club. And if that's not enough, well can I also invite you to join our Discord, a fun place to go to chat with your fellow Club Twitt members and those of us here at Discord. Excuse me, those of us here at Twit, we would love to have you. So head to Twitt TV Club Twit to check it out. Can't wait to welcome you into the fold.
- [129:46]
B
Zootopia 2 has come home to Disney. Let's go get ready for a new case. We're the greatest partners of all time. New friends Gary the Snake and your
- [129:54]
A
last name the Snake Dream Team. Pick new habitats.
- [129:57]
B
Zootopia has a secret reptile population. You can watch watch the record breaking phenomenon at home. Zootopia 2 now available on Disney Plus. Rated PG. Right now you can get Disney plus and Hulu for just 4.99amonth for three months with a special limited time offer. Ends March 24. After three months, Plan Auto renews at 12.99amonth. Terms apply.
- [130:18]
C
Are you stuck staring at your W2? Are tax refund worries holding you back? You probably have fomu the fear of messing up the fix. Using TurboTax on Intuit credit Karma, they find every credit and deduction to help you get every refund dollar you deserve or your money back. It's time to overcome your fear of messing up and get your taxes done right. Start filing today in the Credit Karma app.
- [130:47]
B
Whether you bond over streaming binge worthy videos, watching sports recaps, video gaming or by unplugging altogether, the 2026 Lincoln Nautilus Hybrid helps keep you connected throughout your journey. Learn more@lincoln.com available. Connectivity, features and functionality vary by model. Package pricing, trials and term lengths vary by model Video streaming and games are only available while parked.
- [131:12]
A
All right, back from the break. I've got my bucket. My, my legs are ready. Tell us all about it. Okay.
- [131:22]
B
A little over a year ago, back in February 2025. So 13 months ago, Watchtower Labs posted a troubling narrative that documented the degree to which the security of significant parts of the Internet have not been thoroughly thought through before being implemented. And it's not only new tech like, you know, the open source repositories that bad guys are constantly attacking and poisoning, or some AI that can be subverted. The greater lesson the past 21 years of this podcast has taught over and over is that not only is security difficult, but we keep discovering that it's even more difficult than we thought. Or as we just recently noted, security needs to be more secure. One thing to fully appreciate is that only a portion of security failures result from bugs. Just as many failures are the result of inattention, oversight and poor design, or what I often lump into the label of policy as opposed to mistakes. So this suggests that even after AI being used to improve our security has matured, as I'm sure it will, and it's able to help us far more strongly eliminate traditional exploitable bugs, that will not be the end of our security woes, since even the misapplication of flawless technology can still result in serious consequences. So I don't see security as a, as an issue being resolved by AI. So this brings us back to Watchtower labs exploration from February 2025. It's a perfect teaching example of a system's poor design's unintended consequences. Watchtower's posting February before last was given the headline 8 million requests later we made the solar winds supply chain attack look amateur. So here's what they wrote back then. They said, surprise, surprise, we've done it again. We've demonstrated an ability to compromise significantly sensitive networks, including governments, militaries, space agencies, cybersecurity companies, supply chains, software development systems and environments, and more. In November 2024 we decided they wrote to demonstrate the scenario of a significant Internet wide supply chain attack caused by abandoned infrastructure. I'll just pause to note that we've looked at problems with abandoned infrastructure before where something has all been set up and is going to. It's. It's for whatever reason, you know, been left behind. Pieces of it maybe have been taken away, but some pieces remain and those end up being targets of abuse. So they said. This time, however, we dropped our obsession with expired domains, which of course is, is an example we've looked at before and instead shifted our focus to Amazon's S3 buckets, thus bucket squatting, they said. It's important to note that although we focused on Amazon S3 for this endeavor, this research challenge, approach and theme is cloud provider agnostic and applicable to any managed storage solution. Amazon's S3 just happened to be the first storage solution we examined, and we're certain the same challenge would apply to any customer organization usage in any storage solution provided by a cloud provider. The TLDR is that we ended up discovering around 150Amazon S3 buckets that had been used across commercial and open source software products, governments and infrastructure deployment and update pipelines before they were abandoned. 153Amazon S3 buckets that were used before being abandoned, they said. So we registered those abandoned buckets to see what would happen. The question was how many people might be attempting to request software updates from S3 buckets that appear to have been abandoned months or even years before. Wow. At the huh. At the start of this, we had no idea how this would turn out. The research panned out progressively with S3 buckets registered as they were discovered. It went rather quickly from aha, we could put our logo on this website to dot mil. We should probably speak to someone about that. Oh my God, they said. After spending around $400 as in only $400 on S3 Cloud Trail and Cloud watch logs querying, we had some results worth talking about. When creating these S3 buckets, we enabled logging, allowing us to track who requested files from each S3 bucket via the source IP address and what they requested, the file name, the path, and the name of the S3 bucket itself. Collectively, these S3 buckets received more than 8 million.
- [137:42]
A
Are you kidding me?
- [137:44]
B
8 million HTTP requests over a two month period for all sorts of things. Those making the queries for whatever it was that used to be there were requesting all sorts of things, software updates, pre compiled unsigned Windows, Linux, Mac OS binaries, virtual machine images, JavaScript files, cloud formation templates, SSL, VPN server configurations and credentials, and more. Had we been maliciously inclined, we could have responded to each of these 8 million requests with something malicious like a nefarious software update, a cloud formation template that gave us access to an AWS environment, virtual machine images backdoored with remote access tooling binaries that deployed Remote access tooling, scary ransomware or such, and so forth to give us access to the requesting system or network that the requesting system was within, and in some cases mil. They wrote these many millions of incoming Give me this file Requests came from the networks of organizations based on DNS WHOIS lookups that included government networks in the USA, including NASA, numerous laboratories, state governments, etc. The UK, Poland, Australia, South Korea, Turkey, Taiwan, Chile and more. Then there were military networks and the Networks of Fortune 500, Fortune 100, a payment card network, a major industrial product company, global and regional banks and financial services organizations, universities around the world, Instant messenger software companies, cybersecurity technology companies, casinos, and more. We want to take this opportunity to give our sincere thanks, they wrote, to the entities who engaged with us when we realized what we'd stumbled into, including the UK's NCSC who helped with introductions to the correct teams for us to speak to AWS, who took those around 150s three buckets off our hands to Sinkhole, a major unnamed SSL VPN appliance vendor who worked with us very quickly and directly to take relevant S3 buckets off our hands, and CISA who very quickly remediated an example that affected CISA.gov Wow. Yeah. AWS's agreement to sinkhole the identified S3 buckets means that the release of this research does not increase the risk exposed to any party. The same issues discussed in this research could not be recreated against the same specific S3 buckets thanks to the sink holding performed by the AWS team. We believe that in the wrong hands, the research we performed could have led to supply chain attacks that outscaled and out impacted anything we as an industry have seen so far. As an industry, we spend a lot of time trying to solve issues like securing the supply chain in as many complex ways as possible while still completely failing to cover something as simple as make sure you don't take candy from strangers, unquote. Okay, so what? So their posting then delves into the specific details about each of these many extremely embarrassing and potentially explosive exposures. To best understand how the industry got into this mess, we need to talk a bit about Amazon's somewhat astonishing AWS S3 bucket naming. First of all, a so called bucket is nothing special. It's just Amazon's name for a cloud based directory that can hold files. The name S3 itself, you know, stands. You know, that's three S's right? Stands for simple storage service. That's what S3 stands for. Simple Storage Service. And simple is exactly what it is. The simplicity of Amazon's Simple Storage service likely accounts for much of its, you know, early success and popularity, but it may also have contributed to the service's Very spotty security record. I mean, there's been lots of problems with exposed AW AWS S3 buckets in the past. What's perhaps most shocking about Amazon's S3 bucket naming is that access to any S3 storage bucket is via an HTTP URL that ends with the standard web domain s3.amazonaws.com and surprisingly, that ending can be prefixed with anything that looks like a valid World Wide Web domain name having between three and 63 characters, because that's exactly what it is. For example, I have an Amazon bucket named GRC. That's right, the bucket's name is GRC, which means that the bucket's full name is GRC.s3.amazonaws.com and that bucket can be accessed by anyone, anywhere in the world, at any time. And if that seems like a terrifying thing, you'd be correct to think that the only thing that even begins to make this system safe is access controls. So, of course I have extremely strong access control security policies set on that bucket so that only I am able to work with it. But we've seen many examples where someone mistakenly, though presumably at some point for some purpose, deliberately allowed global read or read write access to one of their S3 buckets, and disaster soon followed.
- [144:56]
A
That shouldn't even be an option, right? Like, why would anyone ever want.
- [145:01]
B
Well read write. I would agree, although you might want people to be able to put information up, like to. To submit things to you. And certainly if you were, for example, a certain SSL VPN appliance vendor, you might want to have your appliance querying that S3 bucket by name, whatever name you've given it, to pull down updates or security configuration improvements or something. So you're basically using it like a globally accessible cdn, a content delivery network. So actually that's how many people use it. So, okay, as a consequence, I have a bunch of S3 buckets with many wonderful, simple and fun names. Since I got there early and I grabbed them, assignment of S3 bucket names could not be any simpler. It's as simple, you know, as first come, first serve. Like Twitter handles were back in the day. If you attempted to create a bucket which is always by name, that effort will succeed if that name is not currently assigned to anyone else's bucket. So I have grc, and that name is exclusively mine until I delete it. And as long as I have it, no one else can have it. In computing, we, you know, we call this, this is known as a global namespace, a Single shared naming space where every name must be unique. So this means that everyone in the world shares the same naming space. There's only one Amazon S3 namespace that that everyone shares to name any and all of the S3 buckets they may have created and governed by whatever access controls its owner may have configured. Any S3 bucket is accessible by its name simply by appending S3Amazon AWS.com to the end of it. For the sake of thoroughness, I'll add that S3 bucket names must be between 3 and 63 characters total. They must always be lowercase alpha from A through z or a numeric digit digits 0 through 9. You can also have dots and hyphens. So just like domain names, they must. They. They also must begin and end with a letter or a number, meaning they, they cannot begin and end with dashes and they cannot contain a pair of adjacent dots. There must also be, I mean there are also a bunch of specially reserved prefixes and suffixes that Amazon has, but like for things like puny code and things. So in order to use a large, a larger spelling Alphabet. But overall, anything that anyone wishes to use will be valid within those guidelines. And notice that I, I keep saying that any bucket that isn't currently in use by someone. The point here, and this is where things get somewhat sticky, is that buckets that are no longer needed by their owner can be deleted. Two things occur when that happens. Whatever content they may have contained will be deleted and the bucket's name, which will then no longer be in use by its original owner, will be released and returned to the available bucket pool and become available for use by anyone who wishes to have it by name. So now we see what these Watchtower guys did. They created some form of directed brute force Amazon S3 bucket scanner, which they used to search for named buckets that once existed, but which were then deleted by their original creators. The problem was that many widespread automated tools, software update systems, antiviral templates, virtual machine images, even executable program downloaders continued in their attempts to access those previously the content within those previously deleted buckets. So when these researchers discovered and recreated one of these previously deleted buckets and began logging the failed file access attempts, they were able to quickly learn what resource something, somewhere was attempting to obtain from that bucket. The danger of this is obvious and truly horrifying. Given that they could see that the see what it was that was being requested, they could readily choose to return whatever malicious content of that form they might wish. Since these requests were being made over TCP connections. The true IP address of the entities making the requests could be determined. They wrote, remember, they wrote these many millions of incoming, give me this file. Requests came from the networks of organizations that included, you know, government networks in the USA, NASA laboratories, state governments, etc. The UK, Poland, Australia, South Korea, Turkey, Taiwan, Chile and more. You know, on and on. Universities, instant messaging software companies, cybersecurity technology companies, casinos and more, credit card processing companies, you know, you name it. So this is not the result, and this is the key. This is not the result of a bug. This was the result of a fundamentally poor system design. Amazon should never have allowed bucket names to be recycled and reused. And in fact, right now they ought to take any which were ever in use. Yep. And, and sinkhole them. Just take them offline. And really, when you think about it, bucket names are really just vanity. Right? They're like.
- [152:05]
A
That's what I was thinking. Yeah, it doesn't matter.
- [152:08]
B
They're like license plates. All you really need is something random and unique that's yours. It doesn't mean need to be your name, your initials, or some cutesy expression. But when users are given a choice, they'll tend to create bucket names that are meaningful to them. And that likely means they could be guessed by someone else. You know, anybody could guess. I might have grc. Well, I do. So, yeah, and I'll admit it, I'd rather have GRC than 09.2d 76.30b 5f, you know, much sexier. But since S3 buckets are almost always accessed by automation, names were really never even necessary. They were just for fun. But that fun comes at a cost. Since Amazon chose to give us control over our bucket names, they should have appreciated the inherent problem with reuse and made them single use from the start, once taken, can never be used again. Okay, I have grc, and that should be it forever. But it probably won't be unless they change their policy, which, after all, they could. At any time, my use of grc, those three initials will eventually end because I will eventually end, you know, whether I do it deliberately or not. I'll cancel my long standing AWS account or it'll be canceled posthumously. At that time, the account's data will be deleted and the grc bucket. The bucket name grc, you know, will be recycled back into the available pool, ready to be used again by someone. I have only ever used S3 as an off premises encrypted storage archive. The danger for me has never been present. You know, there's nothing for anybody to ask for. But the guys at Watchtower discovered that many S3 users are using once used in other words, or I meant once used, their S3 buckets as a form of CDN to deliver quite sensitive files. Both Microsoft Azure and Google Cloud have long provided protections against the inherently dangerous practice of recycling bucket names within a single global namespace, which enables this form of bucket squatting, as it's appropriately been called. But Amazon has been slow to come around. You know, change is always difficult, but the good news is, and the reason this we're talking about this today, is that last Thursday, at long last, that finally changed. Amazon's announcement carried the headline Introducing Account Regional namespaces for Amazon S3 general purpose buckets and they wrote the following short it's just quick, they said Today we're announcing a new feature of Amazon simple storage service. Amazon S3 you can use to create general purpose buckets in your own account Regional Namespace Simplifying bucket creation and management as your data storage needs grow in size and scope, you can create general purpose bucket names across multiple AWS regions with assurance that your desired bucket names will always be available for you to use. And that last phrase with assurance that your desired bucket names will always be available for you to use, reminded me of another aspect of the single global namespace problem, which is that no one owns anything about any not yet created bucket names. You know the Amazon S3 namespace is flat, as I said, not hierarchical. If I own the domain as I do GRC.com then I also automatically own all subdomains and host names of GRC.com www.grc.com and forums.grc.com and noodles.grc.com they're all automatically mine. We would say that everything under GRC.com is mine. What? But you know, under only applies because the domain name system is an inherently hierarchical namespace. There's no under in any flat namespace such as S3 has always used. So, for example, you know that that say that an organization had the practice of saving their annual archives into a series of buckets named ACME Enterprises Archive 2024, then the next year ACME Enterprises Archive 2025 and so on, where the year obviously is incremented successively. If some begrudging exit employee, you know where we're going wished to cause their ex employer Acme Enterprises some grief, nothing prevents them the ex employee from opening an Amazon S3 account, which is cost nothing, and creating the bucket ACME Enterprises Archive 2026 now at the end of this year, when Acme Enterprises went to create their succeeding years archive bucket, that attempt would fail because someone else had beaten them to it. Having a single global namespace shared by every S3 user may have once seemed simple and maybe even fun. But there's a better way. So Amazon's addition of what they're now calling account regional namespaces is a long needed addition. Their announcement continues to explain this writing with this feature, you can predictably name and create general purpose buckets in your own account regional namespace by appending your account's unique suffix in your registered bucket name. For example, the bucket named our bucket hyphen 123-45-6789012 hyphen us hyphen east1 hyphen an okay not particularly sexy, but okay that would exist in an account regional namespace. They said our bucket is the bucket name prefix specified. Then we add the account regional suffix to the requested bucket name, which is that hyphen 123-45-6789012 hyphen us east1 an if another account tries to create buckets using this account suffix and lord, why would they their requests will be automatically rejected. So that's the good news. You get protection against somebody trying to create a bucket with your specific account number suffix. They finished saying your security teams can use AWS Identity and access management policies and AWS Organization Service control policies to enforce that your employees are only able to create buckets in their account regional namespace. This will help teams adopt the account regional namespace across your organization. Okay, so I would argue that the implementation of this is something of a kludge. The total length of the bucket name prefix plus the regional account suffix is 63 characters. So they've really only done two things. First, any bucket created while this new policy is enabled must end in the proper account Number REGIONAL SUFFUS. Second, that account number regional suffix is now reserved for employees using that account number. So no one else can create a bucket which uses that suffix. And I guess a third thing they've done is they've allowed you to set policies upper management the IT overlords can set policies that require all new buckets created to use this account regional namespace suffix so they finally address this problem. Notice that it is incumbent on the organization to turn this on, right? This doesn't do anything retrospectively retroactively. All of that is still a problem. That is non regional suffix buckets presumably still exist and work, but only newly ones created. So this is just enforcing a New bucket creation policy, bucket creation naming policy on future bucket creation. So unless Amazon also decides to prohibit the recycling of previous bucket names and they ought to just take, they ought to immediately, you know, blacklist any that have been abandoned. Right now they're still doing nothing to prevent bucket squatting on earlier buckets, which these guys may not have found. They had to do some sort of brute force scanning to find all of these buckets. They, there are probably other buckets that still exist that have not been found. So, you know, the good news is if organizations adopt and enable this enforcement account number, regional suffix, bucket naming, then at least going forward the problem will have been prevented. And that is bucket squatting.
- [163:03]
A
That is far more terrifying than I thought it was going to be. Based on the name, I will say that that's pretty prevalent across the web. And the fact that.
- [163:15]
B
Frightening. Yeah. How widespread this is.
- [163:19]
A
There's a, there's a level of creativity among security researchers that I really find to be quite incredible when sometimes you'll be talking about these different exploits and ideas and I think about the thinking required to get to that end point. Right. And it's, you know, despite being on its face, a more practical, more sort of scientific approach, there's a lot of creativity that's involved in the work that you all do. And I think that that's something that really stands out to me at these times because I just. Yeah, you have to think about the different tools that we use that are out there and then go, as you like to say, what could possibly go wrong? And that list can be hundreds of thousands of things and you just highlight the one. Oh yeah, let's check this, let's see if that worked. This is just a cool thing to think of, but it's a terrifying outcome whenever it comes out to be true. Right.
- [164:24]
B
Yeah, yeah, yeah. We're, we're, we're still just on one hand. I think we're, we're dragging legacy design and policy forward. And it's, it's also the case that, I mean, because AWS was created once after the Internet was mature, we already, I mean, you know, as a cloud based service, yet these guys didn't stop to think, well, what if somebody uses automated agents to pull code from buckets and like, like firewalls or SSL VPN appliances that are, they're checking for new firmware and then they go out of business or they decide we don't like this bucket, we're going to move that in house. But there's all this equipment out there that is still pulling from a bucket which has been abandoned. But some bad guy could then register and have and provide their own download for all this equipment to download. I mean, this is a. This is a real problem.
- [165:29]
A
Yeah, they actually proved it to be a real problem. Yes, that's. That's terrifying. I'm glad that it's, you know, again, we're shining a light on it. That's the first step and it's the
- [165:40]
B
good guys who are finding it and not the bad guys because it could be exploited. Unfortunately, there appear to be no, no lack of problems that the bad guys are finding and exploiting too.
- [165:52]
A
There are always so many things on that list that we talked about earlier. So, Steve, I'm glad that you have your eye on the prize and that others out there are paying attention as well. This has been security. Now the show publishes every Tuesday. Twitter TV SN is where you go to find the show heading there gives you access to the audio and video versions of the show. You can of course, check out GRC.com where you will find all sorts of good things. It's also where you can go to make sure, sure that you are part of the email subscriptions and to send Steve email as well. And of course, it's the place where you can go to get spin. Right. Steve's bread and butter. Plus the DNS benchmark. That's available now, right?
- [166:52]
B
Yeah. Has been for months. Yep, the DNS benchmark.
- [166:55]
A
Wonderful.
- [166:55]
B
Now available.
- [166:57]
A
Wonderful, wonderful. Steve, thank you so much for another great episode. If I'm forgetting anything, now's your time to tell us.
- [167:07]
B
You got it, you got it.
- [167:09]
A
Wonderful, wonderful.
- [167:09]
B
Thanks for doing a great job at your end.
- [167:12]
A
Thank you. Yeah, it's always a pleasure to get to join you on the show. Leo will be back next week, everyone, don't worry. But thank you.
- [167:18]
B
He does. He does have some travel planned for later this year. So we're going to be seeing more of you.
- [167:23]
A
Yes, indeed. And I'll be right here ready for it. All right, I think that does it for this week. So goodbye, Steve, and goodbye, listeners.
- [167:34]
B
Thanks, buddy. Bye.
- [167:36]
A
Thank you very much. Hey, I'm Micah Sargent, host of Tech News Weekly and several other shows on the network. If you're looking for a smarter way to advertise in 2026, look no further because Twitter is where tech decision makers listen and ROI never ends. Our audience isn't just passionate about technology either. They actually work in it. Over 90% of our listeners are IT professionals, developers, engineers and business leaders who shape the products and the decisions that move tech forward at their companies. Here at Twit, we produce an array of trusted tech shows. These include the latest news and hands on advice featuring authentic embedded host Read ads delivered by Leo Laporte and yours truly. Now our partners see real results because our listeners actually trust us and then take action. And that's because of authenticity. When I'm talking about how I like a product or a service, it's because I actually do. And our listeners know that. And here's something we're super proud of. 88% of our listeners say they've made a purchase because of a Twit ad. So if you're ready to reach the most intelligent audience in tech with that purchasing power to back it up, let's talk. We'd love to help your brand grow. Email PartnerWIT TV or visit TWiT TV Advertise
- [169:02]
B
Security now Foreign. To see your brand on tv, Roku Ads Manager makes it easy to launch targeted ad campaigns in minutes, track results in real time, and drive on screen purchases with just a click of the Roku remote.
- [169:22]
A
Get a $500 match on your first $500 spent with code ROKU500@ads.roku.com that's code
- [169:29]
B
R O K U500.COM terms apply.