Hello and welcome to the SANS and its Storm Center's
Stormcast. My name is Johannes Ullrich and today I'm recording
from Jacksonville, Florida. And today's episode is brought
to you by the SANS.edu Graduate Certificate in
Penetration Testing and Ethical Hacking. In Diaries
today we have a Ghi talk, well yet again, about the 2021
sonic wall vulnerabilities that are still being
exploited. And while there is qualitatively nothing really
new here, it's still the same URLs being hit. Well, the
quantity substantially changed. It changed by an
order of magnitude. Now, there is one particular network, so
if that sticks out here, and that's 141.98.80. This
particular network belongs to Globalhost. Globalhost appears
to be, well, one of those low -cost hosting providers. And,
of course, they're often being used to then just rent a
couple cheap machines and start these scans. Of course,
with low-cost often also comes low support and an inability
to sort of react to abuse complaints. Still have to
notify them and, well, see if maybe we get a response from
them. And Google released an update to Google Chrome. We
are now up to version 136. This update fixes two
vulnerabilities that were detected externally. And a
number, and there's obviously various fixes from internal
audits. Now, what is kind of interesting here is that one
of the flaws is already being exploited in the wild. So,
upgrade as usual. Google Chrome usually does a
reasonable good job in upgrading itself. I always
recommend at least restart Google Chrome once a day. That
way, you usually make sure that the update is actually
being applied. And to make things more exciting, the
vulnerability was actually made public with details on X
10 days ago by S. Lancer here, the X account. The
vulnerability resolves around link headers being sent for
sub-resource requests and the refer policy here being not
correctly applied to these link headers. As a result,
it's possible that URL parameters are leaking. Now, a
couple of things about this. First of all, you shouldn't
really have any confidential data on URLs, but sometimes
that's not easy to avoid. Secondly, the refer policy.
Its intent is that the refer header does not include
additional details that you are afraid could leak, like
URL parameters. But that's not properly or not applied as
expected in this particular case. So, the end result is
leakage of URL parameters. Now, earlier this week, I
talked about backdoor versions of the RVTools software.
Again, this is a well -respected and non-malicious,
usually, tool to get dashboards and performance
data from VMware environments. Now, there's a new article
here from Cerro Day Labs, which does make it sound like
it wasn't actually, as reported earlier, malicious
ads directing people to, like, a completely unrelated RVTools
site that then delivered the malicious version. But that
the malicious version actually came from the original RVTools
site. At least that's how I read this article here at
CerroDayLabs.net. They're not specifically stating where
they got the compromised version from, but they're not
saying that anybody followed any ads or anything like this.
And they do point out that RVTools should better secure
their distribution point for their software. So, I'll leave
it up to you to figure out what exactly happened here.
But definitely be careful with RVTools, whether or not it
came from the original RVTools installation site or some
other site. You may have gotten a malicious version
over the last couple of weeks. And ESET is reporting that
they are seeing a number of cross-site scripting
vulnerabilities being exploited in webmail systems,
in particular by threat actors linked to Russia. I've said it
before, but writing a webmail system is one of the most
difficult things you could possibly do. You have to
render the HTML that you receive from the email inside
the actual web app that makes up the webmail system. There
are some tricks that many sites are using, like, for
example, iframes and such to keep things a little bit
isolated. But still, it remains difficult to do it all
right. Well, so no surprise that we keep seeing
vulnerabilities like cross -site scripting in systems
like that. Your best bet is to keep things patched carefully.
And, of course, maybe try not to use a webmail system. But I
realize that this is not always an option. A particular
target here appear to be webmail servers run by various
government entities and the like. And, of course, they
often, for political legal reasons, aren't allowed to use
some of the major U.S.-based cloud providers that may also
offer webmail systems. But instead, they run their own,
like Zympra, Horton, similar systems that are quite popular
in that space. Well, and this is it for today. So, thanks
again for listening. And thanks for liking and
recommending this podcast. And reviews and any feedback,
comments are always very welcome. So, thanks and talk
to you again on Monday. Bye.
