← SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
SANS Stormcast Tuesday, March 3rd, 2026: Finding URLs in ZIPs in RTFs; Merkle Tree Certificates; Taming Agentic Browsers
00:08:10
SANS Stormcast Tuesday, March 3rd, 2026: Finding URLs in ZIPs in RTFs; Merkle Tree Certificates; Taming Agentic Browsers
Loading summary
Transcript1 lines
- [00:05]
A
Hello and welcome to the Tuesday, March 3, 2026 edition of the SANS Internet Storm Center's Stormcast. My name is Johannes Ulrich, recording today from Jacksonville, Florida, and this episode is brought to you by the Sans Edu Graduate Certificate Program in Purple Teams operation. When attackers are attempting to obfuscate what they're doing, they often take advantage of comp document formats where they're trying to sort of wrap one document into another document type. And then of course, it becomes more difficult to figure out the actual malicious part. Didi has a quick diary up on how to use his tools in order to analyze one particular type of these documents. And that's a zip file inside an rtf. Yes, that's legal, that's perfectly fine. And of course a particular type of zip file would be a Word document, because these Docx formats, well, they're really just compressed zip files. So the DDA is walking you here through a particular example and showing how to not only extract this sort of mess of convoluted documents, but Also then extract URLs, for example, which of course could lead you to then additional exploit attempts or malicious documents. One commenter pointed out that the document that Didier here happened to use in the blog post was actually also covered by Akamai a week or so ago because it was one of the documents attempting to exploit a Microsoft vulnerability that was patched in February. So a relatively recent vulnerability was being exploited using this particular document. And, well, the voyage to finally end up with quantum safe Internet is continuing. And the next challenge here is certificates. There are two interesting blog posts that are sort of released to each other, one by Cloudflare, one by Google, about how to solve this particular challenge. I'll link to the Cloudflare one. I like that a little bit better in its explanation, but there's nothing really different. So there's nothing wrong with the Google one. If you have seen that one. It's a little bit arbitrary here to just pick Cloudflare, but either way. So what's the problem here? The problem is that if we are using quantum safe certificate certificates, we also have to include, well, the certificate and then of course, any signatures that were created using quantum safe algorithms. The problem here is that these certificates and signatures are about 20 times as big as normal certificates. So, well, what are we going to do about this? And what this would end up with is we're like these client hello, message and certificate messages would basically span multiple packets that often kind of creates an issue with middle boxes and such. So have to somehow compress what's going on here and the solution that they came up with here is Merkle Tree Certificates. Instead of actually sending the entire certificate as part of sort of the TLS handshake, we're just sending essentially proofs that these certificates exist and that's these Merkle Tree certificates. Interesting solution. A little bit too complex too explain here as part of the podcast. That's why I'm going to link to these blog posts that have this in more detail how this all exactly works. Now the reason you have this from Cloudflare and from Google is that Google of course is going to implement that in Google Chrome and Cloudflare is going to implement that in their proxy architecture. They're actually saying that already 50% of the connection that they're proxying here are taking advantage of some quantum safe encryption algorithms. But that's really just the traffic encryption, it's not affecting the certificates. They're going to start implementing this about a year from now. So no rush here. Nothing that you have to do at this point. Similarly, like the future versions of Google Chrome will be able to support it. As with any other sort of TLS change, they try to remain backwards compatible. So you still have the old old fashioned certificates and such to go by. So really at this point, nothing you have to do. But of course as always, that's why they're going to roll it out slowly. There's always a chance that there is something breaking. Like for example, when they sort of initially offered quantum safe algorithms in Google Chrome, they had some issues sort of with these multiple packets and handshake and such of a TLS 1.3. They had some issues like this as well. And that's, you know, what they're looking for. And that's why they sort going to roll it out slowly to well, not break anything big right from the get go. The reason why quantum encryption and quantum signatures are so important for the certificates is also that well based on the current algorithms, if you have the public key in the certificate, you could derive the secret key. Now one reason why you kind of want to start quantum cryptography early is this sort of, you know, store and decrypt threat where an attacker store data and then later, once quantum computing becomes available, decrypt the traffic for the certificates, that threat is less of a problem because while the certificates are relatively short lived on, sort of that timescale we are talking about here. So you know, these days the longest certificate is about 13 months. So with that it's probably not going to happen that we have quantum cryptography or quantum computing break certificates within the next year. That's why this is less of a problem, and we have more time implementing this than some of the other use cases of quantum safe cryptography. And Palo Alto did publish a blog with some details regarding a vulnerability that was recently patched in Chrome. The problem here is, well, the new trend of gentic browsing and the Gemini panel that Google added to Chrome. So the Gemini panel gives you access basically to Google's Gemini AI. And the problem here is that if a browser extension has access to that Gemini panel, which they usually have, because it's really just a URL they're accessing here, well, they by extension and also get access to anything that Gemini can do, which includes in this case, accessing camera and microphone. So typically when you're installing an extension in Google Chrome that wants to access the camera or the microphone, you get a warning you wouldn't get this in this particular case because the extension itself never accesses the microphone or camera. It just does so via Gemini. And that was the vulnerability back then. Relatively easy to exploit. And I hope, well, as always, that you keep your browser up to date. But the reason I really mention this is because I think that's a little bit sort of a more generic issue with some of these AI tools that basically extend the capability of the browser and how these extended capabilities are then exposed to things like extensions. Well, and that's it for today. So thanks for listening, thanks for liking, thanks for leaving comments about this podcast and talk to you again tomorrow. Bye.