← SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
SANS Stormcast Thursday, May 7th, 2026: .DE DNSEC Fail; PAN OS 0-Day Patched;
00:06:04
SANS Stormcast Thursday, May 7th, 2026: .DE DNSEC Fail; PAN OS 0-Day Patched;
Loading summary
Transcript1 lines
- [00:05]
A
Hello and welcome to the Thursday, May 7, 2026 edition of the sans Internet Stormz Stormcast. My name is Johannes Ulrich and today I'm recording from Jacksonville, Florida and this episode is brought to you by the SANS Edu Undergraduate Certificate Program in Cybersecurity Fundamentals. Well, it's not DNS. There is no way it's DNS. And in the end it was dn. Good old DNS. Haiku again became true yesterday with the dot DE the German country top level domain. Apparently what happened here was a DNSSEC issue. Dnssec, as I have often said, is one of those protocols that, well, they actually let the security people develop the protocol. They always complain that protocols aren't secure enough because security people never sort of get a say in the development until it's too late. Well, dnssec I think is sort of an example where it went the other way around. And as a result it's a pretty complex protocol. Lots of moving parts, lots of things that can go wrong and then, well, in the sense of good security, if it goes wrong, it usually just stops working. So it's one of those fail closed kind of systems. And that's kind of what happened here with the DE Zone. The problem apparently was key rotation. Like with all cryptographic systems, you need to rotate your keys ever so often, which then also means that you need to change signatures. Well, dynasec has a mechanism for this where you first basically make a new key live, you advertise a new key and the old key remains valid and also remains accessible. But then you start updating signatures. Apparently something here went wrong. They haven't really released any details yet as to what went wrong. Whether they made the key live too late or whether they signed the new data too early with a new key that's really not available yet. What exactly happened here? But the end result was that if you try to go to a.de website for several hours last night, well, you couldn't resolve it. Now cloudflare took an interesting step in disabling the DNSSEC validation on its server. So they basically then flipped the fail open kind of switch here and decided that, well, DNSSEC is not really important enough that you rather want to go to the website and take the risk of maybe have some DNSSEC information or DNS information spoofed. Interesting event. And certainly here also cloudflares behavior, which is reasonable, it's understandable. But of course, you know, kind of tells you that one of the big problems with DNSSEC is that it easily results in denial of service. And yes there are threats with spoofing of DNS responses, but they're in some ways a lesser issue. And then well back to sort of our normal diet of vulnerable enterprise security devices that are already being exploited. This time it's Palo Alto's Pan OS that is vulnerable. It affects the user ID authentication portal, which makes this particular buffer overflow vulnerability specifically serious because, well, you go to the user ID authentication portal when you're not yet authenticated. So this is a pre authication buffer for overflow vulnerability that does allow for the execution of arbitrary code. They're rating it with a severity of 9.3 on the CVSS scale. Patches are available, but Palo Alto also states that this vulnerability has already been exploited in, as usual, some limited targeted attacks. So if you must expose your user ID authentication portal to the public and maybe be good reasons for it, after all it is the authentication part of your enterprise sort of security stack here. Well, in that case definitely patch quickly assume compromise at this point and well consult with Palo Alto for any details like indicators of compromise or other help that they may be willing to provide you. And then we also got the monthly patches for Android from Google. Interestingly, only one critical vulnerability here listed no other vulnerabilities at all. And if you wonder if that's because, well, Google took care of all the other vulnerabilities now, and we are left only with one vulnerability a month. Google actually stated a month or so ago that they're only going to list vulnerabilities that they consider, well, critical enough to be made known. So there may be other patches that are included in this update that are not publicly announced like this. Also, Android 13 as of two months ago has officially reached sort of its end of life, so you'll no longer get any patches for Android 13 or any details on whether or not some of these vulnerabilities apply to Android 13. Well, and that's it for today. Thanks for listening, thanks for liking, thanks for any comments and as always, talk to you again tomorrow. Bye.