SANS Stormcast Thursday, May 15th: Google Open Redirects; Adobe, Ivanti, and Samsung patches

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

previous

Google Open Redirects; Adobe, Ivanti, and Samsung patches

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 Inn at Storm Center's
 Stormcast. My name is Johannes Ullrich and this episode
 brought to you by the Graduate Certificate Program in
 Incident Response is today recorded in Jacksonville,
 Florida. In today's diary, Jan is writing about how Google is
 aiding phishing attacks by providing open redirects. Now,
 these open redirects aren't provided intentionally, but
 more or less accidentally. In this particular case, the
 problem stems from links that Google offers from its maps
 pages to the hotel websites that are linked from the maps.
 This link actually at first looks kind of like they're
 doing the right thing. There are two parameters to the URL.
 There is a token and then the actual URL. Now, what often
 happens in these kind of cases is where the token provides
 some kind of cryptographic assurance that the URL is
 actually the URL that you would like to direct to.
 However, in this case, the token appears to be more
 encoding where the link came from and who may have clicked
 on it. So, once you have a valid token, it doesn't matter
 which one it is, you just may append any URL. It doesn't
 even have to be a valid hotel link to the URL here. And
 then, well, the victim will be redirected initially believing
 that they went to Google. And that's sort of really where
 the problem with open redirects comes in, that open
 redirects essentially borrow the trust that people do have
 in websites like Google. So, they're clicking on the link
 to Google, but are then immediately being redirected
 to a phishing page that may even attempt to impersonate
 Google in some cases. Google's response to this is, well,
 they don't really see this as a problem. Well, people just
 shouldn't trust Google. And if you don't trust Google, then
 there is no trust to steal and this attack should fail. I
 think that's solid advice. Don't trust Google. And that's
 probably the best defense you have at this point. Of course,
 for your own websites, again, to prevent these type of open
 redirects, you want to carefully allow list which
 URLs you direct to. And if you have millions of different
 URLs, like that's probably the problem that Google is running
 into here with all these hotel links, well, maybe add a
 cryptographic identifier that will then make sure that this
 particular link is actually authentic as it's being passed
 to whatever system you're using to do the actual
 redirect. And with yesterday's patch Tuesday, we also got
 again updates from Adobe. Adobe fixed, if I counted
 correctly, 13 different products. Now, the product
 that I'm always of interest in, aside from Acrobat, which
 is not patched this time around, is ColdFusion. For
 ColdFusion, we got updates that Adobe considers priority
 one. Now, the way Adobe does calculate this priority or
 considers the priority is that Debussy considers something
 likely to be exploited. And that's why I'm always focusing
 on ColdFusion. It's a relatively commonly used tool
 to create public websites. So anything like an
 authentication bypass or such, like in this case, or an
 arbitrary file read, it's possibly going to get
 exploited. And we have a number of different arbitrary
 file read, arbitrary code execution vulnerabilities
 being addressed in this update. So definitely get that
 patched. And about two weeks ago, we talked about active
 exploitation of a Samsung Magic Info 9 vulnerability.
 This is a con-management system that's often used to
 manage content on Samsung displays, like for
 advertisements and such. Well, back then there was some
 confusion whether or not this particular vulnerability was
 patched in August. Today, Samsung did release another
 update for this particular vulnerability. But if you read
 the actual note here from Samsung, other than assigning
 it a new CVE number, well, it's actually verbatim the
 same as they published last August. So no surprise that
 there is confusion about which patch actually was addressed
 by what update. But that's why you shouldn't really have
 these very brief and no details kind of vulnerability
 descriptions, because that's what gets people then
 confused. Another Ivanti vulnerability. Not 100% sure
 if I already covered this one. It's hard to track them all.
 Ivanti Neurons for ITSM suffers from a critical
 vulnerability. Now, this vulnerability is exploitable.
 Ivanti states that, well, you should really not allow access
 to the IS, to the web server behind Ivanti neurons. And
 they suggest that you limit access by IP addresses or by
 domain names. That at least will reduce the likelihood of
 a compromise. Of course, it doesn't fix the actual
 underlying vulnerability. That's fixed with this update.
 It was released on May 13th. And it's yet another
 authentication bypass vulnerability. CVSS base score
 of 9.8. And it does affect the on-premise version of the
 product in the cloud. Of course, Ivanti is going to
 patch it for you. Well, and this is it for today. So,
 thanks again for listening and talk to you again tomorrow.
 Bye.