SANS Stormcast Friday, May 16th: Increase in Sonicwall Scans; RVTools Compromised?; RountPress

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

previous

Increase in Sonicwall Scans; RVTools Compromised?; RountPress

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