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.
