SANS Stormcast Wednesday, July 9th, 2025: Microsoft Patches; Opposum Attack;

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

previous

Microsoft Patches; Opposum Attack;

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 Wednesday, July 9th, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and this episode brought to you by
 the SANS.edu graduate certificate program in cloud
 security is recorded in Jacksonville, Florida. Well,
 of course, today we have to start with Microsoft patch
 Tuesday. We got our July patches from Microsoft.
 Microsoft released a total of 139 patches. Now, 130 of those
 vulnerabilities are in Microsoft's own software. We
 had seven vulnerabilities in Git, interestingly, that were
 included in this update. And then two Chrome and with that
 Microsoft Edge related vulnerabilities that were
 actually already released a couple of days ago. Among the
 vulnerabilities that Microsoft patched, I think there are
 five that I would sort of consider noteworthy. I started
 out here with the Microsoft Office vulnerabilities. There
 are two vulnerabilities that are critical, that are remote
 code execution vulnerabilities, and where
 Microsoft considers exploitation more likely,
 meaning that these are not super complex exploits. The
 reason they are rated critical instead of important is that
 they don't require any user interaction. The user does not
 have to actually open the document. This is exploitable
 just via the preview feature. Then next, we do have a
 vulnerability in the Microsoft SQL Server. Actually, two
 vulnerabilities. The one is information disclosure
 vulnerability. What's interesting about this is
 that, first of all, it has already been made public. And
 to patch the vulnerability, you actually have to patch the
 OLLI database driver. Then the second SQL Server
 vulnerability, I consider kind of interesting, even though it
 hasn't been released yet. But it's a remote code execution
 vulnerability. And with that, it's, of course, critical. Not
 really sure how likely it is that something like this is
 being exploited, but Microsoft thinks it's less likely. But
 take it as an additional sort of motivation to make sure
 that your SQL servers are not exposed. And the last
 vulnerability here is a command or code injection
 vulnerability in SharePoint. We typically have cross-site
 scripting vulnerabilities in SharePoint. But this is an
 outright code injection vulnerability. So basically,
 arbitrary command execution vulnerability. However, an
 attacker first must be authenticated in order to
 exploit this vulnerability. So just a random user coming to
 your SharePoint site looking for some content is not going
 to be able to exploit this. I don't think there's sort of
 any big critical or must-patch -now vulnerability here in
 this set. So as usual, I would say just follow your patch
 procedure. Test these patches carefully before you actually
 release them to your users. But as always, make sure you
 get this done before next patch Tuesday. And before we
 talk about some of the other patches that were released
 today from companies other than Microsoft, let's first
 talk about a little new TLS issue that was released today.
 And, well, I at least want to mention it because often these
 TLS issues will cause quite a bit of press and such. So you
 kind of have an idea of what it's all about. They call it
 the opossum attack. And in this attack, in order to be
 vulnerable, the server has to use a very specific
 configuration. RFC 2817 is sort of specifying this. And
 what this configuration does is it allows HTTP and HTTPS
 connections on the same port, usually on port 80. In Apache,
 you can configure that by configuring the SL engine as
 optional versus as on, as you would do in a TLS-only
 scenario. So this is not a very common scenario. The more
 common option is where you have a web server listening on
 port 80 that will redirect users to port 443 to HTTPS
 instead. That's the safer configuration. And part of the
 problem here is that you basically allow HTTP and HTTPS
 connections on the same port. The way NetHacker would
 exploit this is by first sending a request to the
 server on port 80, basically just a plain HTTP request. The
 server, of course, will respond in this case with the
 101 status code, basically asking the client to resend
 that request via HTTPS. The next thing that happens now is
 that the actual client, the actual user, is connecting to
 the server. And one way this could potentially work here is
 that the NetHacker would just delay the request. So the
 NetHacker is not able here to decrypt any of the data. The
 TLS handshake then happens between the legitimate client,
 the legitimate server, and then again the attacker is
 delaying or blocking the first GET request. The server still
 has the response for the initial GET request. So it
 will now essentially respond with the wrong response. And
 the client is getting like a different page than they asked
 for. That's all it is. So there is no decryption
 involved. The main effect is that the user would get the
 wrong page in return, which could still cause quite a bit
 of problems. But it's only an issue if you're using this
 very specific configuration. And there appears to be no fix
 if you really want both HTTP and HTTPS to be on the same
 port and then use the 101 switch protocol, the upgrade
 headers, in order to switch between HTTP and HTTPS. And
 one company that also started in recent months to always
 release updates on the second Tuesday of the month is
 Ivanti. And this month in particular, interesting here,
 Endpoint Manager, they fixed three vulnerabilities. Two of
 these vulnerabilities deal with the improper use of
 encryption, which essentially allows users to decrypt each
 other's passwords. The third vulnerability is SQL injection
 vulnerability. Now, this one does require that the attacker
 is authenticated with admin privileges and then can read
 arbitrary data from the database. That could actually
 then, together with the first two vulnerabilities, be used
 then to retrieve the encrypted passwords and then decrypt
 them. Even administrators should not be able to decrypt
 or have access to users' passwords. Well, and this is
 it for today. So thanks for listening and hope to see you
 in the sea next week and talk to you again tomorrow. Bye.
 Bye.