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.
