Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Login Bug Allows Credential Theft (onthewire.io)

Posted by BeauHD on from the identity-crisis dept.

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.

7 of 43 comments (clear)

  1. A bug? by viperidaenz · · Score: 3, Interesting

    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.

    1. Re:A bug? by viperidaenz · · Score: 2

      That would require a shared session be maintained between the two servers.
      The way it is designed, the SSO server doesn't require any session state at all.

  2. How is this different than Facebook phishing? by Anonymous Coward · · Score: 2, Funny

    I always said Facebook has a flawed login system because any website could say,"Login with Facebook." And have a fake login/password prompt to steal credentials.

    Is this what this also is doing? Cuz I never type my password in anywhere except Google... Or pokemon... ;)

    Or is this a more automatic things? Visit the wrong website and you're compromised?

  3. I don't see the bug either by Jumunquo · · Score: 5, Insightful

    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.

    1. Re:I don't see the bug either by swillden · · Score: 4, Insightful

      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.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    2. Re:I don't see the bug either by swillden · · Score: 4, Informative

      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.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  4. Re:SRP/Nonce puts an end to Phishing by brantondaveperson · · Score: 2

    The nonce+hash algorithm exists to prevent eavesdropping on the network traffic. This problem is solved better by just using SSL traffic for everything, since nonce+hash has the disadvantage that since the server never sees the actual password, the only authentication process that can realistically be supported is a local password database.

    Plus, of course, phishing has nothing to do with either method. Phishing is just faking the login page, and sending the credentials elsewhere.