Hello and welcome to the Wednesday, February 19th, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ulrich and today I'm recording from
Jacksonville, Florida. Well, today we got Russ McRebeck,
our handler after a hiatus. And the first diary really
addresses a topic that I've covered a couple times here.
And that's, well, malicious machine learning models. When
you're downloading a machine learning model from a site
like HackingFace, well, you're typically downloading a pickle
file. The problem with pickle files is they are Python code.
So as you're instantiating the model, you're potentially
execute Python code, which could be malicious, which
could execute operating system commands and all kinds of evil
things that attackers like to do to your system. This could
even happen if you're using the torch load command. The
PyTorch module. Torch load may also instantiate models unless
you specifically only have the weights only parameters set
that will only load weights for the model, not to complete
any Python code or so that's potentially being added to the
model. Now, to help you with this task to figure out if a
particular machine learning model that you downloaded is
malicious or not, Russ introduces a tool called
ModelScan. ModelScan does well what you would expect it to do
based on the name. It will scan your machine learning
model and tell you if there is any suspect code in this
machine learning model. Well, Russ has sort of a quick run
-through of that model scan tool with a benign and a
malicious model. In the malicious case here, it
recognizes that there are some operating system commands that
are going to be executed and it will alert you of that.
There are different ratings for the finding is fine. It
includes, of course, there will probably be a little bit
of cat and mouse game going on over the next month, years,
whatever. Between the tool and the attackers trying to look
for evasion techniques and to detect evasion techniques. But
it looks like a very solid tool. It comes with gibber
notebooks and all the good stuff that you kind of need in
order to run an experiment with the tool. So, we do have
two new vulnerabilities in OpenSSH. The vulnerabilities
were found by Qualys and were just patched. One of the
vulnerabilities, the one that's really more interesting
here, allows for an attacker to impersonate a server. The
attacker needs to have a machine in the middle position
in order to conduct the attack. But, of course, that's
kind of not the type of attack that you want to protect
yourself from via the proper key identification from the
server. You're only vulnerable to this attack if you have the
verify host key DNS feature enabled. It's usually
disabled. However, apparently in FreeBSD, it's sometimes
enabled by default. The vulnerability itself is over
10 years old. And, well, as a result, pretty much any SSH
server client that you would find out there right now is
vulnerable. Now, a little bit about that verify host key DNS
feature. The idea is that you publish an SSH fingerprint of
the key via DNS. This has to be DNSSEC protected. But SSH
here does not deal with errors properly. If there is a memory
allocation error during the parsing of the record of the
key, then the key is accepted. And that then leads to no
warning being displayed as the user connects to the
potentially malicious host. So, a couple of things you
want to do here is, number one, of course, keep SSH
updated. This is one of the critical things that you have.
I just yesterday talked about how SSH may be the one thing
that you enable, like, you know, on your parameter. And
then check if this verify host key DNS feature is enabled.
Most networks don't even publish any SSH fingerprint
records via DNS. If you don't publish these records, then
definitely disable it because there's nothing really to
verify here. The second part to this, of course, is if you
do publish those records, again, make sure that you're
up to date. Also, double check for odd errors and such that
you may see in your logs that would potentially indicate an
exploit attempt here. The second vulnerability, as I
said, is a denial of service vulnerability. So, nothing
really all that outrageous here necessarily. Not good,
but definitely less important than the impersonation of a
server. We've got a couple other smaller issues,
vulnerabilities. First of all, Juniper released some patches.
Not necessarily a small problem, but not a lot of
details here. And that's an out-of-cycle bulletin, meaning
that is not one of their regular bulletins. They
prioritize this bulletin. It affects a wide range of their
devices, and it's an authentication bypass. They
call it an alternate path or channel vulnerability that the
router is exposed to here. And yes, CVS score in the 9.8
range for this vulnerability. So, definitely prioritize
updating.
Dell also published a fix for an authentication
vulnerability. This one affects the bias of a wide
range of systems. However, in order to exploit this, you
already have to have authenticated using a more
privileged account. So, not all that critical. And, well,
bias updates are always painful. So, nothing that you
have to do right now. The list of vulnerable systems is long.
I would suspect it's pretty much all of Dell's system that
may be vulnerable to this. Well, and that's it for today.
Thanks for subscribing. Thanks for listening. Thanks for
recommending this podcast. And talk to you again tomorrow.
Bye.
