Hello and welcome to the Tuesday, February 11th, 2025
edition of the SANS Internet Storm Center's
Stormcast. My name is Johannes Ullrich and today I'm recording
from Jacksonville, Florida. Today we got a diary by Didier
with more details regarding that famous mark of the web
issue. As I indicated, there have been ongoing issues with
the mark of the web not properly propagating. If
you're decompressing files or other sort of multifile
compound formats like, for example, disk images. Didier
is talking specifically about 7-zip. 7-zip on Windows has a
specific setting that's actually disabled by default
to set the mark of the web for all extracted files if the
archive overall had this mark set. And again, this is an
issue that has to be taken care of on unpacking, on
decompression, not on compression. Kind of nice if
an attacker assembles an archive with the mark of web
being set for all the components. But again, the
archive was created by the attacker. So it's really up to
the defender as they are unpacking these archives to
properly set the mark of the web on all files being
extracted. So users will get the proper warning as they are
then attempting to open any of the files. And we got an
update from Apple for iOS and iPadOS. This particular update
fixes one single vulnerability, which already
indicates it's an important vulnerability. It's one that's
already being exploited in the wild. Apparently, this
vulnerability allows attackers to bypass USB-restricted mode.
What it refers to is that iOS devices and iPadOS devices, of
course, as well, will restrict data connections via USB to
devices that are specifically prior authorized that you have
connected to in the past. And also, this restriction will
automatically enable when the device is locked and if a
certain time of inactivity expired. So this can be
bypassed, which means that an attacker would be able to do
something like an evil mate attack or such by connecting a
malicious device to the iPhone, iPad, and then cause
code execution, data leakage, and such. So that's the
vulnerability being addressed here. It's already actively
being exploited again, which means if this is your threat
model that you're afraid of someone actually connecting to
your device while you're not close to it or such, then you
definitely should apply this update quickly. And Google's
security team released interesting proof of concept
exploit for some AMD CPUs. The problem here is that an
attacker who has root on a system is actually able to
update the microcode that's running on a particular CPU.
Now, this microcode is often updated during boot, but
should be static once the system is up and running. And
of course, there should be controls around what microcode
can be uploaded to a CPU. The interesting proof concept they
came up with was actually a modification to the random
number generator that would always create the identical
value. Be happy if a net hacker is doing just that
because at least that's easy to detect. But this is sort of
one of those fundamental supply chain issues. I've
spoken about random number generators years ago, I think
five or 10 years ago at RSA once, as if it's one of the
top threats at the time. The problem is it's very difficult
to verify that a random number generator is properly
functioning. And for example, in modifying the code that's
being used to create random numbers, an attacker could
break a large number of cryptographic protocols.
And CISA released an advisory that they're also seeing
active exploitation of a vulnerability in Trimple
Cityworks. This is geographic information system software
often used in local governments and such. So
definitely something that you need to keep an eye on if you
happen to use this software package. Luckily, I don't
believe it's used very widely, just sort of in these very
specific but critical areas. Let me get an interesting
update from Sucuri about what MageCard is up to. MageCard
attacks are typically referred to as attacks that modify
JavaScript, often on a supplier's website, in order
to then inject keystroke loggers into unsuspecting
websites. This new variety of the attack that Sucuri is
writing about here looks a little bit different. They're
taking advantage of JavaScript being used by Google
Analytics. Now, they did not compromise Google Analytics.
Instead, if a website uses Google Analytics, they're just
modifying the JavaScript on the page to include the
malicious payload. The problem here is that, of course,
administrators often just copy -paste the JavaScript for
Google Analytics. They're not really paying close attention
to what the JavaScript exactly does or looks like. And as a
result, these changes get then undetected. There's also an
interesting domain name they're using. And let me just
look it up here. It was something like
eurowebmonitertool.com. The reason I think they're using
this particular host name or domain name,
eurowebmonitertool.com, is back when I used Google
Analytics, one of the problems was that Google Analytics
itself is then pulling in all kinds of other JavaScript. And
some of that JavaScript is used to display the cookie
warnings for European users. And maybe they're sort of not
trying to fit in here with this pattern. Hey, just some
new random JavaScript being loaded to include that cookie
warning. Even administrator who pays a little bit
attention may be sort of used to this behavior from Google
Analytics and as a result, not follow up. Interesting new
development here. Definitely take a look for any
modification to the Google Analytics code that you may be
including in your site. Well, and this is it for today. So
thanks again for listening. Thanks for everybody who is
leaving recommendations in your favorite podcast app, is
rating this podcast, or just recommending it to their
friends and enemies. Thanks and talk to you again
tomorrow. Bye.
