Google Login Bug Allows Credential Theft (onthewire.io) 43
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.
A bug? (Score:4, 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.
Re: (Score:2)
Well, there are a few other ways to communicate the parameter other than as a GET parameter (or POST). For example the server one is trying to sign into could send it direct to google via a side channel, that said, this only stops a MITM modifying the string in flight, not a bad server sending a bad string anyway, this is how paypal handles payment amounts for example.
Re: (Score:3)
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.
"Invalid" password (Score:1)
Geez, especially considering how often address bars are hidden by default on mobile, I can really see this being a huge security risk, but how could Google even really protect against something like a fake invalid password prompt? A "you logged in sucessfully page"? Would an ordinary user know something was amiss if it wasn't there? I don't think I'd notice even. I guess DFA is really the only protection against this.
How is this different than Facebook phishing? (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?
Re: (Score:2)
That's only an issue with "Login with Facebook" (or the "Login with Google" equivalent) for users who aren't already logged into Facebook(/Google). If they're logged in all the time like most people, there's never a login prompt so they may think twice when they see one. Likewise people should be extra skeptical when redirected to a failed login page for an openid-type login.
Re: (Score:2)
Likewise people should be extra skeptical when redirected to a failed login page for an openid-type login.
You have too much faith in users... (-_-')
You mean... (Score:2)
Re: You mean... (Score:1)
No it's like you can make your site use Google to log in for your site. That sends the user to an actual Google login page. Then after they login your site mimics Google's invalid password page.
Re: (Score:2)
Re: (Score:2)
The difference here is people are idiots and are trained to accept logging into shit with Google for some reason.
So even if they're smart and check that they're on google.com when they initiate the login, they're vulnerable if they don't check the URL again during the malicious step at the end.
I don't see the bug either (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.
Re:I don't see the bug either (Score:5, 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.
Re: (Score:2)
I would imagine the "Login using Google" at third-party sites wouldn't work w/o this:
https://developers.google.com/... [google.com]
Google Wallet might not work too smoothly either What Paypal does is display a message that you're being redirected and waits a few seconds before redirect, and I've seen other sites do this too. Does Google do the same thing?
Re: (Score:2)
Re: (Score:2)
Um, its not a weakness at all. You can't prevent it. If someone types their credentials in a fake login page and submits it, well then that is how the web works.
You didn't read the post you responded to.
Re: (Score:2)
But then people would complain 'what if they had a slow internet and went to sip a cup of coffee or something' if the time is too short. The click-through idea seems viable enough. However I'm still skeptical that a user that would be vigilant about the address bar would suddenly stop being vigilant if the page clearly reloads. Either they are vigilant throughout or they would fall for a phishing page without ever touching google's servers.
Re:I don't see the bug either (Score:5, 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... [coredump.cx]
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.
Re: (Score:2)
An example of a similar/better attack: http://lcamtuf.coredump.cx/swi... [coredump.cx]
That says in my address bar:
data:text/html;-peak.us/banking_interface/%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2
Working for Google on security (Score:2)
> I know the Google Security Team guys well (I work for Google, on security
I've been working in internet security for 20 years, and of course Google stands out as possibly a very interesting place to work. You Googlers do some really neat stuff. I'd be interested to hear anything more you have to say about working for Google on security. Do you enjoy it? Any suggestions for someone who might end up working there sometime relatively soon?
Re: (Score:2)
Google is a great place to work. With regard to security, it's especially satisfying because (a) what you do matters, given the scope and scale of the company, and (b) the company really takes security seriously.
I'd be happy to discuss this more deeply. Feel free to e-mail me.
Re: (Score:1)
Our company had this exact phishing possibility in one of our product's authentication flow. The solution was to white-list the domain being returned to, as it had to be previously known by the system as either an identification provider or service provider.
SRP/Nonce puts an end to Phishing (Score:2)
Whatever happened to the basic nonce? You know, the thing in every browser since Netscape that lets you type in a password but the password does not actually get sent to the server, just a hash of it and the password. Puts an end to this type of thing.
An even better algorithm is SRP https://en.wikipedia.org/wiki/... [wikipedia.org] which provides good security even on weak passwords. (Ordinary nonces can be brute forced off line, SRP cannot.)
But no, the critical thing is a pretty user interface. And the browser/nonce
Re: (Score:3)
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.
Re: (Score:2)
And very few people in real user land ever checks the URL in the browser. So PKI certificates are worthless.
So you've never seen one of these [eff.org] eh? Weird.
Re: (Score:2)
Of course there is TOTP (which can use pretty much *any* compute device) and U2F (dongle required). Practically speaking, requiring one of these two neatly gets the Nonce behavior you desire (well, roughly, a phishing attack would get a token that would be valid for at least a short period of time).
I agree SRP was a nice concept, but in practice, no one is interested.
Re: (Score:2)
You are talking challenge response authentication. The problem with that generally is that the shared secret (password ore hash of the password that is then used as the password so an attacker can just skip the hashing step in an attack) has to be stored in plain text on the server (obviously this means we have a major credential theft issue server side) as to be able to calculate the response, this is true for CRAM-MD5 (which is why it hasn't been updated from MD5), CHAP, OATH, DIGEST-MD5, and zero knowled
Re: (Score:1)
Properly implemented, SRP does not store the the secret on the server end. It only stores v=pow(g,x) mod N, where "x" is a secret needed on the client end (derived from the password), and can't be extracted from v without either using a brute-force algorithm (try all weak passwords), or solving the discrete logarithm problem. You may want to read https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol [wikipedia.org] more carefully.
I hadn't looked at SCRAM before, but from at a quick glance it looks like the only
Re: (Score:2)
While your use of the term 'nonce' is correct English, it's probably worth checking other uses for the term in the UK if you're planning to speak to international audiences.
You don't want to be labelled a nonce.