SANS Stormcast Feb 11th 2025: 7zip and MoW; Apple 0-Day Fix; AMD Microcode Overwrite; Trimble CityWorks 0-Day; MageCart Update

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

previous

next

7zip and MoW; Apple 0-Day Fix; AMD Microcode Overwrite; Trimble CityWorks 0-Day; MageCart Update

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