Google Login Bug Allows Credential Theft (onthewire.io)

Trailrunner7 writes from a report via On the Wire: Attackers can add an arbitrary page to the end of a Google login flow that can steal users' credentials, or alternatively, send users an arbitrary file any time a login form is submitted, due to a bug in the login process. A researcher in the UK identified the vulnerability recently and notified Google of it, but Google officials said they don't consider it a security issue. The bug results from the fact that the Google login page will take a specific, weak GET parameter. Using this bug, an attacker could add an extra step to the end of the login flow that could steal a user's credentials. For example, the page could mimic an incorrect password dialog and ask the user to re-enter the password. [Aidan Woods, the researcher who discovered the bug,] said an attacker also could send an arbitrary file to the target's browser any time the login form is submitted. In an email interview, Woods said exploiting the bug is a simple matter. "Attacker would not need to intercept traffic to exploit -- they only need to get the user to click a link that they have crafted to exploit the bug in the continue parameter," Woods said. Google told Woods they don't consider this a security issue.

Comments

A bug?

[viperidaenz]

Isn't this by design?
You visit a page, it checks a cookie value with the authentication server, if it's invalid you get redirected to the authentication server, with a parameter that allows you to be redirected back to where you first tried to go.
When you're redirected back, the process starts again.

This is how a lot of SSO systems work.

The 'continue' parameter needs to accept every possible entry point to every website the SSO authentication server supports.

I don't see the bug either

[Jumunquo]

The article basically says the steps to exploit this are:
1) Get the user to visit your suspicious website/link.
2) Get them to click on a login using Google link that sends them to google.com/continue?= (something like this)
3) They enter their Google credentials
4) It redirects them to your fake login page that says wrong password.
5) They enter their Google credentials again, and you steal them.

So, really, you could omit steps 2 & 3 and just send them straight to the fake login page. In the end, the only real problem is entering your login details on a non-Google domain. Paypal/Facebook/Steam/etc. all do the same thing.

Re:I don't see the bug either

[swillden]

Maybe. I think the issue (if any) lies here:

2) Get them to click on a login using Google link that sends them to google.com/continue?= (something like this)

The problem is that the Google login page will be totally legitimate. The lock icon will be green, certificate pinning will ensure all is safe/good, etc. So it's not completely unreasonable that a person who might have been suspicious (but not too suspicious to click the link) prior to this point would now decide "okay, this is legit", and continue onward... and not notice that on the fake login page they're no longer on a Google site.

So, if it's a weakness, it's one that doesn't affect totally clueless users, who could have been directed to the fake login page to begin with, and it doesn't affect clueful/careful users who check their address bar at both the real and fake login pages and know how to tell the difference. It affects only somewhat careful users who check their address bar at the real login page and then figure they're safe from there on out. Well, it also has to be a user to is willing to click a Google login link from a random, untrusted site.

So I agree it's very, very narrow. I'm not sure I agree it's not an issue. But I know the Google Security Team guys well (I work for Google, on security, though not this stuff), and they're extraordinarily paranoid (that's a good thing), so my guess is that there is some other mitigating factor that I'm not seeing, and they just haven't done a good job of communicating the rationale to the researcher, or have some reason they can't communicate it.

I have asked on an internal mailing list. If the response is something I can share here, I will.

Re:I don't see the bug either

[swillden]

I have asked on an internal mailing list. If the response is something I can share here, I will.

The response is basically that it's not worth fixing because there are so many other ways to do the same thing, many of them arguably better (for the attacker). Fixing this would require redesign of lots of stuff... and it couldn't prevent any of the other attacks that achieve the same thing, so it would be a lot of effort for no return.

An example of a similar/better attack: http://lcamtuf.coredump.cx/swi...

In that demonstration the example banking site is not HTTPS-protected, but the attack would work just as well if it were. There are other ways as well, I'm told (I'm not a web security guy).

My takeaway is that *every* time I type or submit sensitive data into a web page I must check the address bar. I actually do that anyway; this just reaffirms the importance of that habit.