SANS Stormcast Friday Mar 21st: New Data Feeds; SEO Spam; Veeam Deserialization; IBM AIX RCE;

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

previous

next

New Data Feeds; SEO Spam; Veeam Deserialization; IBM AIX RCE;

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

New Discussions closed for all Podcasts older than two(2) weeks
Please send your comments to our Contact Form

Podcast Transcript

 Hello and welcome to the Friday, March 21st, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. Well, today I wrote a little bit of
 mixed diary. First of all, just introducing that we
 reorganized some of our data feeds a little bit. We have
 some more or less static reports that we recreate once
 an hour, once a day, depending on the report. And they may be
 more efficient for you if you want to use our data. Instead
 of querying, for example, our API for individual IP
 addresses, you can download here, for example, our Threat
 Intel feed that lists all of the IP addresses for which we
 had recently activity. And then some labels going with
 that IP address. That sort of should speed things up and, of
 course, also takes a little bit of load off our API if
 you're using this. In addition, sort of a little
 incident here, I called it. It's something that we have
 seen in the past but haven't seen for a while. And
 yesterday we got yet another email from sort of a search
 engine optimization scam. That's at least sort of where
 I put it. The email itself basically claims that a link
 that we have in a podcast episode is no longer active.
 And they give you a new URL to replace that link with. Well,
 the problem is that, first of all, the email didn't come
 from the organization that actually owned this particular
 webpage. It happened to be the Electronic Frontier
 Foundation. And they're going sort of now after these
 popular links with these scams. And then, of course,
 the new link they offered, it had the same content as the
 original page. Basically, just copy-pasted that. But it also
 was part of one of those essay writing websites. So not
 really what I would consider a legitimate business. And they
 essentially just try to drive click-throughs, advertisement
 to their page. That's really what it's all about. It's a
 little scam. So if you run a blog or something like this,
 you may also get some of these emails. Just be careful before
 you update any links. Make sure the old one is actually
 gone. Like in this case, the old one was still perfectly
 fine. And then that the new content is actually related to
 the original owner of the content. Well, lately I
 started referring to Veeam, sort of a friend of the show,
 because they always are good for new vulnerability stories.
 The other company that is often mentioned then as well
 is watchTowr. Because they then, of course, take these
 vulnerabilities and tell us everything that went wrong. I
 sort of really like the watchTowr approach here. It's
 maybe a little bit sort of, I don't know, my dark heart
 here. Like to make fun of stuff like this. Particularly
 if it's large companies that probably should do better. But
 either way, let's talk a little bit about what happened
 here. It's another deserialization vulnerability.
 Deserialization vulnerabilities have been
 quite common. They usually affect software written like
 in .NET, Java, most of all. Can happen in any object
 -oriented language. But typically it more happens in
 Java, .NET because it does happen in enterprise systems
 that often accept arbitrary objects. And the reason
 deserialization exists is that objects aren't just data.
 They're data and code. And if you deserialize the wrong
 object, well, then you end up with arbitrary code execution.
 So there are two ways to avoid deserialization, very
 simplistically speaking. One is, hey, let's set up an allow
 list of safe objects that we actually want to deserialize.
 The other object and or the other method is what Veeam
 did. Well, let's just find a list of all the bad objects
 and then set up a list of all those bad objects and just not
 allow them. So the block list approach. And anybody who has
 done anything in security probably realizes that it's
 really hard to impossible to get the block list approach.
 Right. And that's exactly what's going on here with
 Veeam. I don't know enough about the product to
 understand why they can't do an allow list here. Like
 another example where this happened was like WebLogic,
 for example. They did a similar thing with block
 lists. Didn't really work very well. But WebLogic is
 middleware that has to accept all kinds of objects. Really
 difficult for them to sort of come up with an allow list.
 For a backup system like Veeam, I would hope there is a
 better way of doing it. But again, I'm not that familiar
 with Veeam to really speak to the difficulties that they
 encountered in doing anything like, you know, reasonably
 safe here. Anyway, keep patching Veeam and there will
 be probably more just to learn a little bit from what
 happened with WebLogic or other software like this.
 Desetialization vulnerabilities don't always
 happen as the object is instantiated. They can happen
 on the destructor. They can happen when there are
 exceptions being triggered. And usually attackers, once
 they're done finding all the bad objects that are causing
 code execution on instantiation, and once that
 block list is reasonably good, well, they look for these
 other methods to then, you know, again, exploit it. So
 there's probably a number of additional vulnerabilities
 coming here. And we also have two critical vulnerabilities
 in IBM's AIX operating system. They both affect NIM. NIM is
 short for the network installation management. It
 allows essentially to set up the systems over the network.
 So it does allow for remote code execution, but should ask
 for authentication. The problem is that in this
 particular case, due to this vulnerability that hasn't
 really been specified in any additional detail, well, these
 code execution can happen without any authentication.
 And then we have the latest way to steal NTLM hashes. This
 time it's via library-ms files. Well, the vulnerability
 was recently patched, but now there is a very trivial proof
 -of-concept exploit showing how to exploit this
 vulnerability. I read the other day that the problem
 with these NTLM hash leaks is that this is really sort of
 how the operating system Windows was designed to work,
 to basically just automatically authenticate.
 And that's really sort of being abused here. And that's
 why we keep having, you know, basically any place where a
 remote URL could be used as a file name, which also is
 pretty much anywhere where a file name could be used. Well,
 you have a potential for NTLM leakage. So the real fix again
 here is block outbound port 445 at least. And then also,
 you know, disable NTLM hashes as much as possible. Well, and
 this is it for today. So thanks for listening. And
 thanks, Chris Mosby here for leaving a nice Spotify
 comment. So if you haven't done so yet, haven't had a
 comment on Apple Podcasts for a while, for example, if
 you're using that to subscribe to this podcast. And with
 that, well, I'm probably off to the dog park then
 reprocessing this podcast. Hopefully I won't forget about
 it and you'll be able to listen on it on Friday
 morning. And that's it. Thanks and talk to you again on
 Monday. Bye.