Hello and welcome to the Tuesday December 16th, 2025 edition of the SANS Internet Storm Center's Stormcast. My name is Johannes Ullrich recording today from Jacksonville, Florida or virtually from Amsterdam, Netherlands. And this episode is brought to you by the SANS .edu graduate certificate program in cloud security. And of course, React to Shell is still in the news and I looked at what we have in current exploits in our honeypot. There was one attempt that sort of was the most visible one in our honeypots, meaning it hit the most different honeypots. Nothing fundamentally new here. It's of the usual malware distribution where they download a file, then mark it as executable. In this particular case, they actually kind of appear then to not launch the file if I'm reading the code correctly. So they may be missing a little piece here. And then use the standard ways to tuck away an exploit or a piece of malware like this, like slash temp slash def or slash def shm, which of course, the last one would be ephemeral and be deleted on each reboot. Nothing too terribly exciting otherwise with React to Shell. Yes, I saw the headline today that always means that exploitation pretty much has run its course. And the headline was that Iranian actors are now taking part in scanning for React to Shell, which of course, usually Iran, whenever they're mentioning news, it means that the exploit is old enough where you probably don't have to worry about finding a lot of new vulnerable systems that haven't been exploited yet. But last week, I talked about the new SAML vulnerability in Ruby, which actually wasn't new. It was just an incomplete patch to a prior vulnerability. We now have a great blog post by Portswigger talking about what went wrong in this particular case and why there are some fundamental problems with SAML that makes it really difficult to get it implemented correctly. One problem with Ruby in particular is that within their SAML library, they're using two different XML parsers. And those XML parsers so often don't quite agree sometimes in how they parse certain documents. Now, the other issue that they talk about in this blog post is that past SAML exploits often required a valid SAML signed message. And that can be somewhat tricky to obtain. After all, you're trying to basically break into a system where you don't necessarily have an account for it. Now, in the past, it was suggested that you could just basically steal the message from a valid user and then modify it. And again, because of the issues with the parsers, the modification would not be detected. What they're looking now into in this particular post is basically where any message that's signed by the SAML server with the secret key used to sign assertions can be used in order to then impersonate other users. In particular, what they're looking at here is that for example, some error messages are per standard digitally signed using that secret key. So error messages are usually not that hard to solicit from a server and can then be used as a basis to then create these fake SAML assertions. So big problem here is that XML as a standard is first of all, really difficult to implement and not really implemented consistently. across different libraries. Secondly, SAML then adds additional complexity to it, like how message are for example, normalized, they're talking about this a little bit, and how that then causes issues if that doesn't happen sort of uniform and consistently across different libraries. And yes, and then the standard and signature verification at all is quite complex for SAML and has a lot of openings here for vulnerabilities. So maybe not the last issue that we are running into with Ruby SAML. And if you are implementing SAML, definitely be careful, try to do as much verification of messages before you actually pass them to some of these SAML implementations. And Microsoft as part of its release health update, did state that there is an issue with the December 2025 update for Windows, which, well, was released last week. And the message queuing or MSMQ. Apparently you get messages like insufficient memory, insufficient disk space, even though you have plenty of memory and disk space. The message queuing essentially just fails. They acknowledge the error at this point, it appears to affect a Windows Server 2016 and 2019, as well as Windows 10 on the client side. But no patch or workaround mentioned yet, short of, of course, backing out the patch. Well, and this is it for today. So thanks again for listening. Thanks for liking. Thanks for subscribing. And thanks as always for leaving good reviews in your favorite podcast platform and talk to you again tomorrow. Bye.