
Google's login page accepts a vulnerable GET parameter - ivank
https://www.aidanwoods.com/blog/faulty-login-pages
======
f-
One important consideration here is that the phishing attack as described here
could be pulled off even if the targeted site did not support redirects - and
in general, it would be exploitable without any identifiable fault on the part
of the "vulnerable" web app.

This property is an artifact of how browsers work, and it's not something
that's likely to change soon. Basically, if you visit evil.com, evil.com can
always load accounts.some-trusted-domain.com in a new window, give you enough
time to examine the address bar and confirm that it's legit - and then
sneakily navigate that window to a phishy location that looks the same as our
legit login prompt, but is controlled by the attacker.

(The evil site can also detect certain events, such as navigation, and deliver
the payload only at that point.)

For my whimsical demo for Chrome and Firefox (dating back to 2011!), see:
[http://lcamtuf.coredump.cx/switch/](http://lcamtuf.coredump.cx/switch/)

(Disclaimer: I kinda wrote a book about this stuff. Also, I work for Google.)

~~~
bennofs
I agree that you cannot 100% prevent phishing, but I think that the case
presented here is slightly different: the "evil URL" is only contained in a
_parameter_ to an request to another URL. I don't think that the typical users
will look at the things that come after the `?` in the URL, especially since
those can be url-encoded an thus just look like garbage.

------
mangeletti
Steps:

    
    
        1. Send email that looks
           like it's from AdWords,
           claiming the user's CC
           needs to be updated
    
        2. User logs into Google
           after verifying URL is
           in fact google.com
    
        3. Google literally sends
           trusting user to attack
           site... to enter their
           credit card number
    

How is this not a serious vulnerability?

~~~
dsacco
First of all, open redirection is not a _serious_ vulnerability. Serious
vulnerabilities include remote code execution, SQL injection and cross-slide
scripting (depending on the context). Serious vulnerabilities can be used to
compromise user accounts without their interaction. Vulnerability severity is
always a bit of a touchy subject, but calling open redirection _serious_ is
either hyperbolic or report-padding for security consultants.

Second, this vulnerability cannot be used to compromise user accounts or data,
let alone with or without their interaction. It is a social engineering attack
that could work, yes, but the Google Vulnerability Rewards Program is
specifically designed to reward researchers for reporting technical security
vulnerabilities, not those leveraged through social engineering.

Third, this is a rabbit hole. Google's core functionality is redirecting users
to third party websites. You can just as easily send someone a link to a
Google redirector that occurs in the browser when you click on a search
result. It's not feasible to prevent this, and it's not feasible to prevent
social engineering in general.

Bug bounty programs require a hard line somewhere in order to function. In
order for an attack to be acceptable, it must have a clearly demonstrable
foundation in a software implementation failure. It must be clearly defined as
a logic error, not an error in human reasoning. The only cases where open
redirection and social engineering are eligible are those where they are
simply peripheral - an actual technical vulnerability that allows these
attacks to scale far beyond manual means (an example might be a technical
failure in Facebook's linkshim service).

I am disappointed in seeing that this story has risen to the top of the HN
front page, because I believe there isn't a single security engineer here that
would agree this is a technical vulnerability that should be eligible for a
reward.

~~~
mangeletti
> Serious vulnerabilities include remote code execution...

I just meant "serious" in the general sense of the word, like the way that a
bullet would in the stomach is serious, even though one in the head is more
serious.

> Google's core functionality is redirecting users to third party websites

I'm pretty sure that Google's core functionality is ads, which don't require
the user to actually be actually visiting pages Google.

Pertaining using Google for social auth, the user is actually expecting to go
back to the site they just came from, whereas when they login to update their
credit card they're logging in to stay on Google, which means that a page that
looks exactly like Google...

How long this functionality remains on the site will be a better indicator. My
guess is not long, esp after the publicity.

~~~
dsacco
_> > I just meant "serious" in the general sense of the word, like the way
that a bullet would in the leg is serious, even though one in the head is more
serious."_

To continue your analogy more accurately, open redirection is not a gunshot
wound, it's a cold.

~~~
parent5446
I don't know about a cold. Maybe the flu, since elderly and children are more
at risk. ;)

~~~
xori
Really, people. Are we seriously doing this...

------
Manishearth
Google seems to consider such issues about security UX being severely
affected, where _expectations_ are involved, to not be vulnerabilities.

This is one of them. "theoretically", it is not a vulnerability, since the
actual integrity of the security model is not compromised. However, the UX
changes. A user who checks for the green lock in https urls may not check that
a "wrong password" page reached via the google login page is on a different
domain because they don't expect it to be. Given the existence of google oauth
login, I do agree that this isn't really a good expectation, but I suspect
that many folks have it (and it's easy to add "login successful, redirecting
to <site>" for non-whitelisted endpoints). It's certainly something to improve
upon, even if you don't give out a bounty or w/e.

I reported a vulnerability of a similar kind months ago, which was similarly
classified as not a vulnerability. When Chrome receives an invalid certificate
which is invalid due to multiple reasons, it does not show all the reasons or
prioritize. This means that if I have a self-signed certificate that also
expired half an hour ago, chrome just tells me that it is an expired
certificate. The integrity of the security model hasn't been affected here --
the warning is still shown, the user still has to manually click through. But
the user may be _much more likely to_. Recently-expired certificates are
relatively common, and seem like a reasonable thing to bypass. Of course, you
should always check the cert details and cert tree before bypassing (unless
you don't want to login or don't care about things being MITMd on that site),
but not everyone understands the cert trees, and not everyone will do this.

Of course, it's up to them to not consider security UX fails as
vulnerabilities, and UX is pretty hard to get right anyway (Google has some
awesome folks working on security ux though!).

~~~
flukus
> A user who checks for the green lock in https urls may not check that a
> "wrong password" page reached via the google login page is on a different
> domain because they don't expect it to be.

I wonder if you could use that new fangled css that changes the tab color to
red, then the red unlocked icon looks like part of the error page styling.

~~~
kuschku
Or just use lets encrypt to get a certificate for accountsgoogle.com ?

That ensures basically no one will notice a difference.

------
pwinnski
Since Google has decided that
[https://www.google.com/amp/[any_domain_here]](https://www.google.com/amp/\[any_domain_here\])
isn't a vulnerability, then I don't see how combining that with a google login
is a vulnerability.

OP talks about having the continue page prompt for password, but how is that
any different from creating a fake Google password prompt page now? That page
would not be on [https://accounts.google.com/](https://accounts.google.com/),
and it would not have my personal info displayed, so why would I enter my
password? Just because the last thing I did was log into Google? Is that
supposed to "put me in the mood"?

If I'm on page A, and I click a link that prompts me for my google
credentials, I've either _expected_ that, so I check to make sure it's Google,
or I haven't, so I close that tab. If I enter my username and password, or
just my password, and then end up at page B, and it prompts me for my password
again, it certainly doesn't know my username like the real Google password
prompt page did. It looks different, and raises all sorts of flags.

Alternatively, if I'm on page A, and I click on a link that sends me to page B
directly, where I'm prompted to enter my username and password, I don't. Why
would I? It's not google.com, etc.

There's just no way that this seems like any more of a vulnerability than the
open redirector already is.

~~~
2bitencryption
I'm on the sign-in page for Google.

I check out the URL, it's google.com. The padlock is there.

I sign in. Whoops, must have typed my password in wrong. It happens sometimes.
So I type it in correctly.

...I just got phished.

The problem is that the behavior of this exploit mimics almost EXACTLY the
expected behavior. The warning flags to even an educated user are not clear at
all. It would be so easy to fall for this.

~~~
jrockway
Your profile picture would go away on the second page though, which might be
unusual.

I recommend installing this extension, however:
[https://chrome.google.com/webstore/detail/password-
alert/noo...](https://chrome.google.com/webstore/detail/password-
alert/noondiphcddnnabmjcihcjfbhfklnnep?hl=en)

~~~
kuschku
Which might be unusual, unless you add an error message, as in this example:

[https://cdn.kuschku.de/ServiceLogin/video.mp4](https://cdn.kuschku.de/ServiceLogin/video.mp4)

~~~
pwinnski
I lack the patience to create a video (kudos!), but I'm still not seeing how
this is any more of a vulnerability than just sending someone to that page in
the first place? It's not on a google.com URL, which seems immediately
obviously to me.

It might help that I _always_ enter my password via command-\, never typing
it. So even if I was _really_ not paying _any_ attention, and didn't realize
the domain had completely changed, and that my username had disappeared (which
still seems unlikely), command-\ wouldn't fill in my credentials, because it's
not google.com.

That last page is phishing, for sure. And it's going to fool some number of
people, for sure. I'm struggling to think of how that's something Google
should do something about though.

~~~
kuschku
Google obviously thinks it shouldn’t happen – that’s why they have a whitelist
in the first place.

This is just a simple whitelist bypass.

But the issue is: How do you check the page you are on is the correct one?

You might check everything the first time, but after that?

------
cstrat
The simple fix would be for google to show their own page after successfully
logging in. On this page they would tell the user they are about to be
forwarded to another page external to google.

~~~
danielsamuels
That wouldn't solve this problem given that the page they're redirecting to
_is_ a Google page, the continue check enforces that.

------
flashman
Signing in on this page will download PuTTY, for example:
[https://accounts.google.com/ServiceLogin?service=mail&contin...](https://accounts.google.com/ServiceLogin?service=mail&continue=https://www.google.com/amp/is.gd/CoBrwD)

------
libber
A non-vulnerability like this is a good example of how easy it is to get press
for $important_company + security.

Top of hackernews at the moment and fingers crossed there wont be a wave of
articles about this in the coming days from tech press who don't fully
understand the issue but know clicks when they see them.

~~~
mixedCase
A non-vulnerability? I understand how you could call it non-serious if you
don't work on user-oriented code or think all users have perfect periferic
vision all the time. But how do you explain the purpose for the check that
fails any non-google domain then?

------
PuffinBlue
I can appreciate their stance on phishing but being able to automatically
execute an arbitrary file download that appears to come from Google as part of
the login process strikes me as a bad thing, no?

~~~
im4w1l
> automatically _execute_ an arbitrary file download

Your phrasing could easily be misread. A downloaded program would _not_
automatically run.

~~~
euyyn
And in modern browsers/OS not even after you click on them, until you clear a
"yes, I know this is risky" dialog.

------
grrowl
It feels like you should phish one of the Google Security Team to really get
the point home.

------
TomAnthony
This has been this way for several years now.

I have notes on a Google attack I discovered ~2 years ago that includes an
open redirect as a critical part. It allows running arbitrary JS on
authenticated users on the click of a link.

However, there is one small part of the attack (one character!) which prevents
it working so I've never reported it. Interesting that there is such a debate
here, as I thought open redirects were generally accepted as out of scope for
most bug bounties.

~~~
kuschku
Well, maybe there should be social engineering bounties then.

For things like this, or when you can engineer their support to gove you
access to their systems.

------
amq
If any URL can be passed, and this is not a vulnerability, why validate the
argument at all for google.com.*?

------
milankragujevic
Couldn't they just sign the URL with a hash and call it a day? For example,
have a parameter continue be "something" and hash be
sha256("something"+someRandomStringThatOnlyGoogleKnows)... And on the server
check if sha256(continue+random) == hash.

------
gyey
I have noticed that a redirect to any site on sites.google.com also works
seamlessly on mobile. The amp pages are not working for me and I get an error
page, but as someone mentioned they probably don't work on mobile and only on
desktop.

------
belovedeagle
Frankly, I don't see any reason why Google isn't right here. This
"vulnerability" can only be exploited by appending another one, fishing. It's
reasonable to say, "If AB is a vulnerability only if B is a vulnerability,
then A is not a vulnerability". That you can't solve fishing [as a service
owner, without also owning the browser] is unfortunate but irrelevant.

~~~
kuschku
Try this variant:

(link removed, see video below)

And tell me your parents/grandparents/etc will not mistake that for the real
thing.

(you can enter whatever you want into the phishing form, it will just take you
back to this post – but someone with less morals could do entirely different
things)

EDIT: Video for mobile users (this page doesn’t work on mobile):
[https://cdn.kuschku.de/ServiceLogin/video.mp4](https://cdn.kuschku.de/ServiceLogin/video.mp4)

~~~
woliveirajr
Perfect example. Everything that I can see in my cell looks right, including
informations from the green padlock, just opening (and understanding! ) the
whole URL would make one NOT enter the password.

~~~
kuschku
And that’s the thing, thanks to Let’s Encrypt, the padlock on the fake site
also stays, everything looks normal.

If you now also register something like accountsgoogle.com or a similar page,
people likely wouldn’t even notice.

This is like it’s made for phishing.

------
tamana
The boilerplate FOAD email they send when they decide to end the conversation
is dripping with smart.

Exclamation points! Bummer!

------
cyberferret
That is quite an incredible security flaw. I also appreciate the irony of
using a Google service to exploit Google's login itself.

It's akin to that scene in "Terminator 2" when the T-800 walks into a gun
shop, asks to see all the top shelf guns, then loads up and shoots the shop
owner before walking out...

~~~
zachrose
That was Terminator 1 though.

~~~
ikeboy
Was it really Terminator 1 before any other films came out, though?

~~~
zachrose
No but it became Terminator 1 retroactively, much in the same way that Kyle
Reese retroactively become John Connor's father.

------
sigjuice
I guess this should not matter to someone like me who never logs on to google
in a web browser? I just use gmail via IMAP.

~~~
sigjuice
I guess I am wrong. Looks like I do have to go through some sort of Google
login page when I set up my email for the first time
[https://imgur.com/a/Vlj09](https://imgur.com/a/Vlj09)

~~~
niftich
This changed sometime in 2014. You used to be able to use IMAP authtype
'simple', but in April 2014, Google released a rather vague blog post [1]
about how they're going to deprecate something; please move to OAuth 2.0.

The Thunderbird team's bug tracker has some context [2] where they had to move
quickly to add functionality to Thunderbird to support the SASL XOAUTH2 for
IMAP so that Thunderbird would keep working with Gmail.

[1] [https://security.googleblog.com/2014/04/new-security-
measure...](https://security.googleblog.com/2014/04/new-security-measures-
will-affect-older.html)

[2]
[https://bugzilla.mozilla.org/show_bug.cgi?id=1059100](https://bugzilla.mozilla.org/show_bug.cgi?id=1059100)

~~~
djsumdog
Woah. Yea I moved off Gmail in 2013. Their broken IMAP implementation is
terrible.

Even though a lot of my outgoing e-mail goes straight to spam, I'm glad I did.
I hate this crap.

~~~
sigjuice
What did you replace Gmail with?

~~~
djsumdog
Just started running my own server:

[http://penguindreams.org/blog/how-google-and-microsoft-
made-...](http://penguindreams.org/blog/how-google-and-microsoft-made-email-
unreliable/)

