SANS Stormcast Wednesday Mar 12th: Microsoft Patch Tuesday; Apple Patch; Espressif ESP32 Statement

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

previous

next

Microsoft Patch Tuesday; Apple Patch; Espressif ESP32 Statement

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 Wednesday, March 12, 2025
 edition of the Sands and the Storm Center's Stormcast. My
 name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. Well, today we do have a Patch
 Tuesday, of course, but it's an interesting one. And I
 don't just want to call it the Microsoft Patch Tuesday. We
 got, and I'll leave this a little bit sort of as a
 cliffhanger for later, another company that released an
 interesting update today. Microsoft did release an
 update for actually less vulnerabilities than normal. A
 little bit more than 50 vulnerabilities were addressed
 in Microsoft's update. But what made it interesting again
 was six of these vulnerabilities, which may be
 a record, I haven't really looked back, are already being
 exploited. So let's talk a little bit about the already
 exploited vulnerabilities. Well, when we talk about these
 exploit vulnerabilities, they're heavy on file system
 issues. Now, none of the exploit vulnerabilities are
 critical. They're all important. The file system
 issues, there are three of them related to NTFS and one
 of them related to FAT. One of the NTFS vulnerabilities and
 one of the FAT vulnerabilities will lead to code execution.
 Microsoft labels them as remote code execution. So how
 would an exploit work here? In order to trigger the exploit,
 a corrupt file system has to be mounted to the victim's
 system. There are really two ways to do it. First of all,
 just trick the victim into opening a VHD file. VHD files
 would be these virtual hard drive files that would then
 take advantage of these vulnerabilities. But an
 attacker could also do it remotely if they have some
 kind of access to the system, some remote shell, something
 like this. And then they could upload that VHD file and mount
 it. So that's why they're classified as a remote code
 execution vulnerability. Exploitation is certainly not
 super easy and something that needs basically some
 additional tricks, which is why these vulnerabilities are
 only rated as important and not as critical. The other two
 vulnerabilities are security feature bypass in Microsoft
 Management Console. Typically, that means, well, some kind of
 warning that a file was downloaded or such is not
 being displayed properly. And then we have an elevation of
 bridge vulnerability in the Win32 kernel subsystem. So
 overall, these are, I think, sort of average
 vulnerabilities. But again, remember, they're already
 being exploited. But then let's talk a little bit about
 the critical vulnerabilities. There is one that I actually
 sort of rated as the most interesting vulnerability in
 this patch set. And that's code execution vulnerability
 in the Microsoft Windows DNS service. The reason I consider
 this interesting is, first of all, well, I like DNS and
 always think that DNS-related issues should get their
 attention. In this particular case, exploitation doesn't
 appear to be really that easy. It does require a dynamic DNS
 update record, which may or may not be enabled. It doesn't
 necessarily say in the advisory, but the advisory is
 pretty terse. Whether or not you need that enabled or
 whether just sending a packet, even if it's not enabled, will
 trigger a vulnerability. But my bet is if you don't have
 dynamic DNS updates enabled, then it probably won't work.
 Now, where you typically do have dynamic DNS updates
 enabled would be for some internal name server. The
 other issue here that Microsoft points out is that
 it's a timing vulnerability. And the attack has to be sent
 just at the right time. They, of course, don't tell us what
 that time is. But it's very likely that this depends on
 other DNS traffic. So it's not just when you're sending it,
 but also you have to know that some other update request or
 something like this has just been sent in order for you to
 trigger the vulnerability. Of course, an attacker could
 always just sort of flood the exploit and see if it works.
 But an exploit is likely not going to be sort of 100%
 reliable here. Other critical vulnerabilities being
 addressed are one in Microsoft Office and then one in the
 Windows subsystem for Linux. Not terribly exciting, but
 probably these are the ones that are actually among all of
 these vulnerabilities that you're going to see exploited.
 In particular, the Office vulnerability. And then we got
 the interesting bonus vulnerability. And that's this
 time Apple. Apple actually, in the afternoon, released an
 update for iOS, macOS, and visionOS fixing a single
 vulnerability, a webkit vulnerability that's already
 being exploited. This is actually a vulnerability state
 that they sort of addressed in iOS 17.2, but I guess didn't
 address it completely. So there's an additional fix for
 this issue. It only appears to be exploited so far in highly
 targeted attacks against iOS 17. Apply the patch.
 Definitely something that you want to take care of. But
 overall, probably not something we'll see sort of a
 public exploit for anytime soon. It would be triggered by
 the victim opening a web page. And then the malicious code
 would actually be able to break out of the Safari
 sandbox, which is a big deal and makes that worse than
 other Safari or webkit vulnerabilities. And then we
 got a statement from Expressive about the backdoors
 slash debug commands that were found in the ESP32 chipset.
 Well, they confirmed the commands exist. They also
 confirmed that these are debug commands. And they
 specifically state, and that was the part that I found a
 little bit difficult to read sort of between the lines in
 the original release about these vulnerabilities, that
 these commands are not executable via Bluetooth. So
 you have to already have access to chipset in order to
 use these commands. And as such, they don't really
 consider this vulnerability. I tend to agree with them. They
 will still release a patch in order to disable these debug
 commands because, well, a normal user just doesn't need
 them. And there is definitely sort of a small residual risk
 here that they could be used against the user. Well, that's
 it for today. So thanks for listening. Thanks for liking,
 subscribing. Did you know that Alexa also offers this podcast
 as part of its flash briefing? And if you ever run into
 anybody from SANS, well, tell them about how much you like
 this podcast. Thanks, and talk to you again tomorrow. Bye.