Slashdot Mirror
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.
God! I LOVE a parade!
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.
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.
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?
...I could construct a web page that looks like a Google login page, and then read the credentials typed in? Witchcraft!
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.
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/... 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 interface has not been updated in decades. And it can be spoofed -- the nonce password needs to be entered in the URL bar.
The whole basis of web security is that users always check the URL is exactly valid. Which was known to be bullshit from the beginning.
This is a problem that could and should have been solved long ago. And actually, it was...
> 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?
I rarely post on Slashdot so have to be AC but wanted to point out that I personally reported this security vulnerability to the Google Security Team in 2011 and was met with the exact same response.
An exact quote from their email response:
"In these instances, we believe the usability and security benefits of a well-implemented and carefully monitored URL redirector tend to outweigh the perceived risks."
Joseph Foulds
Well Google don't really care do they,as long as they get as much data as possible,they don't worry that other people can get access to the same data as well,Google are on3 of only a small number of organisations who can do anything useful with bulk personal data in that amount,they certainly don't care about individual users of their services,try making a complaint to Google's customer services,if you can find an email address or phone number to do so,even if you do,all they will do is ignore you,the only time they react is if it's the start of a legal action and it's from serious legal firms,I have made multiple complaints to Google over the years and have only ever recieved one auto reply,yet if you want to give them some money or owe them money,they are on your tail 24/7.
What they meant years ago was not do no evil but don't get caught doing evil..
Google = a long way of spelling shit..