SANS Stormcast Thursday, May 7th, 2026: .DE DNSEC Fail; PAN OS 0-Day Patched;

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9922.mp3

previous

.DE DNSEC Fail; PAN OS 0-Day Patched;

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Thursday, May 7th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich 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's no
 way it's DNS. And in the end, it was DNS. This good old DNS
 haiku again became true yesterday with the .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.
 You always complain that, you know, 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 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, you know, 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, DNSSEC 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 update, 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 the 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 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 Cloudflare's 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 that, 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 PanOS 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 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 there may
 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.