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.
