SANS Stormcast Tuesday, December 16th, 2025: Current React2Shell Example; SAML woes; MSMQ issues after patch;

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/9740.mp3

previous

Current React2Shell Example; SAML woes; MSMQ issues after patch;

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 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.