Bypassing Google's Two-Factor Authentication 49
An anonymous reader writes "The team at Duo Security figured out how to bypass Google's two-factor authentication, abusing Google's application-specific passwords. Curiously, this means that application-specific passwords are actually more powerful than users' regular passwords, as they can be used to disable the second factor entirely to gain control of an account. Duo [publicly released this exploit Monday] after Google fixed this last week — seven months after initially replying that this was expected behavior!"
Re: (Score:2)
Re:Nice Guys! (Score:5, Insightful)
The generally accepted behavior is to:
1. Report the bug to the developers.
2. Work out a disclosure timeline and give them time to fix the problem.
3. Disclose after the fix is released.
Except when the developer at stage two says; 'that's not a bug' or, 'that's intended design', or FOAD' or they ignore you completely. Then the responsible thing is to disclose the bug so that everyone knows that it is an issue and stops using the service until the developer is forced to address the issue.
In this case, Google said that it was by design. Meaning essentially that there was no fault/bug when there clearly was. At that point, with no expectation of it being fixed, Duo Security would have been well within the right to disclose and force Google's hand. Or, they could turn evil and profit from the exploit, since you seem to feel that they should not have disclosed a bug that Google was ignoring.
Re: (Score:2)
Re: (Score:1)
Re: (Score:1, Insightful)
They're a Google Ventures company.
Best not to bite that hand that feeds you.
Re:Nice Guys! (Score:5, Informative)
So, Google blows them off and the don;t go public for seven months? These are some nice guys!
Or perhaps they've been profiting for the past seven months. WFT Google?
Well, its not as easy as to pull off this exploit as it might seem.
From TFA:
So: given nothing but a username, an Application Specific Password, and a single request to https://android.clients.google.com/auth [google.com], we can log into any Google web property without any login prompt (or 2-step verification)!
So you had to know two things:
1) Someone's Username
2) Someones Application Specific Password.
You had to know their PASSWORD. Or you had to "set up an an intercepting proxy with a custom CA certificate to watch the network traffic" to try to capture the encrypted password". These ASPs are encrypted with the sending device id. (That Device ID is yet another thing that the attackers KNEW up front. If you didn't know that Device ID, setting up the Intercepting Proxy wouldn't help you.
Granted if you know the password its game over. Two factor authentication only works if every piece of software supports it, and until it does big long hairy App specific passwords still have to be used.
You can't derive this password unless you also know the device ID, because its encrypted.
The big HOLE here is that ANY one of your valid Application Specific Password gave you access to ALL parts of your Google Account.
So an ASP for SMTP allowed you to access your Account dashboard. They really weren't Application Specific on Google's end. That is the part Google fixed.
But again, its not as big of a gaping hole as the summary makes it out to be. Because you still needed to carefully craft an intercepting proxy, know the originating device id, decrypt the password, and log in VERY QUICKLY because the encrypted password is date stamped with a short life span. This would be very hard to pull off in the real world.
So yeah, it needed fixing.
I'm glad its fixed (for the most part), but there was no giant emergency here.
Re: (Score:2)
But again, its not as big of a gaping hole as the summary makes it out to be.
You could phish for them.
Release something 'useful' that uses an ASP and then harvest them...
Where's the surprise? (Score:5, Insightful)
Since the regular password as been changed to require an additional two-factor password they of course had to come up with this ASP idea for services where you cannot provide a two factor authentication and of course these have to be more powerful than the password that you now changed into a two factor. How can this be a surprise at all?
Re: (Score:1)
Wasn't the single factor password to be tied to a device and a service though?
I don't think it follows that it can obviously be used to disable 2 factor authorization (or even to get access to other services).
Re: (Score:2)
The service thing I understand. I'm not sure how you would tie, say an IMAP password, to a device though? What would differentiate two different IMAP clients?
Re: (Score:1)
Re: (Score:2)
I don't think you understand. How could Google identify one device from another?
Of course as the user you can manage your passwords in whatever way works best for you. I don't see how Google could manage what the poster above suggested - that the password be tied to a device. From google's end, one IMAP client will look very much like another.
Re: (Score:1)
Agreed, I wasn't thinking, Google's apps (such as android gmail) could authenticate as a specific device cryptographically, but there's no way to hack it into unaware apps such as an arbitrary IMAP client.
Re: (Score:1)
Re: (Score:3)
Actually TFA says the App Specific Password was encrypted with the device id. Google knows which device is talking to it.
You are correct that ANY one of your valid ASPs could be used for any Google service. This is the part that they fixed.
As you suggested, generating one single ASP and using it for everything would in fact work, but Google doesn't make this easy. You have to write them down somewhere, because once they show them to you, you can never see them again. You have to copy them into password
Re: (Score:2)
I don't think you understand. How could Google identify one device from another?
By using the unique password to identify the device?
Presumably Google has a password hash stored somewhere that they use to authenticate the device. If it matches password hash 1, then it's your phone, if it matches password hash 2 then it's your tablet.
They could also use unique usernames, but that may be harder for the user. user+myphone@gmail.com for the user's phone, user+mytablet@gmail.com for the user's tablet. But some software will probably get confused and not understand that the authentication use
Re: (Score:3, Informative)
Well, a session using an ASP should not be able to do things that an app has no business doing, such as visiting the account security page. Google seems to understand this:
This is no longer the case as of February 21st, when Google engineers pushed a fix to close this loophole. As far as we can tell, Google is now maintaining some per-session state to identify how you authenticated — did you log in using a MergeSession URL, or the normal username, password, 2-step verification flow? The account-settin
Re:Where's the surprise? (Score:5, Informative)
It's a privilege escalation problem. The surprise was that changing your main password or password recovery email should be only done by the full account, not an ASP context.
Re: (Score:2)
It's a privilege escalation problem. The surprise was that changing your main password or password recovery email should be only done by the full account, not an ASP context.
But that was the part that they fixed, No?
Re: (Score:3)
Since the regular password as been changed to require an additional two-factor password they of course had to come up with this ASP idea for services where you cannot provide a two factor authentication and of course these have to be more powerful than the password that you now changed into a two factor. How can this be a surprise at all?
Why does a device password have to be more powerful than my main two-factor protected password?
If my phone needs a device password to download email, why should that password also be able to change my password settings?
Re:Where's the surprise? (Score:4, Interesting)
From TFA:
This is no longer the case as of February 21st, when Google engineers pushed a fix to close this loophole. As far as we can tell, Google is now maintaining some per-session state to identify how you authenticated — did you log in using a MergeSession URL, or the normal username, password, 2-step verification flow? The account-settings portal will only allow you to access security-sensitive settings after username/password/2-step-verification prompt that you can’t skip.
So, yes, you are correct, that is how it used to work, but not any more.
Still these ASPs are not in fact "Application" specific. They probably should be, but that would be pretty convoluted and people would throw up their hands and walk away. (I read somewhere that something like 80% of the people that try 2-Factor give up when they see all the hoops that need jumping.
Re: (Score:2)
Allowing authentication with an application-specific password to give you permissions to change account settings like the email to send password reset information to was unlikely part of the design (it'd happen with the obvious implementations if not doing so wasn't explicit in the design of course).
You Didn't RTFA! (Score:4, Informative)
You missed the part where your individual ASP doesn't simply have access to YouTube, but rather to ALL of your Google services. And, worst of all, the ASP also gave full access to the password/account options page so, you could leverage an ASP and take complete control of all services managed by that Google account.
A single ASP completely bypassed all security and two factor authentication.
This was all clearly and plainly explained in the not-very-long fucking article!
Re:You Didn't RTFC! (Score:4, Insightful)
I think you're being over-critical of the commenter's diligence. There is some room for interpretation or confusion. Yes, application specific passwords are intended to provide single-step authentication to applications that don't participate in 2-step authentication. And yes, it's easy to gloss over the distinction between using an ASP to access application functions versus security aministration functions, and that's where the bug lies. Its easy to gloss over because ASPs were intended to replace 2-step authentication, and its a somewhat subtle point that this access should exclude administrative functions - subtle because that was never mentioned in the design/purpose of ASPs.
So I think the commenter's confusion/question is fair to some extent: Google representatives themselves probably glossed over the distinction between limiting ASP access to app-level functionality versus ASP access to admin-level functionality leading to their initial response that it was working as intended. Now you say that the commenter should have made that distinction, and that's true with the help of this article, but there's still a gray area that I think the commenter is trying to point out. Not only is there a distinction between app-level access and admin-level access that ASPs should have been conscious of. There's also a distinction between app-level access and app-specific access. In other words, an application could be limited to access only data relevant to its specific operation (just email content, for example), or it could be limited to access only data relevant to *any* application-level operation (exclude all admin functionality, but allow access to all other data), or it functions just like a mechanism to bypass 2-step authentication, accessing all functionality (which Google now agrees is "buggy").
The commenter acknowledges that yes, it would have been nice to have ASPs limited to app-specific functions, but notes that this level of refinement was never intended to be incorporated into ASPs. And I think the commenter is right on that point. My (and your) response to that however is the next level of distinction. This is not the level of distinction being called out in the article. I think the distinction is between app-level access versus admin-level access, not a reference to app-specific access. No application should have admin-level access when using an ASP. That's less of an enhancement and more of a security flaw when you get to that level of security hole.
Re: (Score:3)
You didn't RTFC. I didn't miss that part, I explicitly mentioned it. My question was fairly specific and was not answered in TFA. Thanks for proving the "33% of Slashdot responses are from dickheads" law, though.
So you understand the original problem, understand the weakness of an ASP having the same privileges as the 2-factor protected password, and you say it's working as designed and any fix would just be a "design improvement".
I think that's exactly what Google told the people that disclosed the bug 7 months ago, that everything was working according to design. A weakness is a weakness, even if it was designed that way, that doesn't mean it isn't a weakness or that it shouldn't be fixed.
Re: (Score:2)
A weakness is a weakness, even if it was designed that way, that doesn't mean it isn't a weakness or that it shouldn't be fixed.
And it was fixed. So why the venom?
By the way, reading TFA would reveal that using this design flaw as an attack was a LOT harder than it first appears. You actually had to know three things, a username, a device Id, just to decrypt the ASP that you captured on your carefully crafted network with an intercepting proxy with fake credentials. However, if the session all happened under SSL, all bets were off. (Always using SSL is an option offered in many, but not all google services).
Re: (Score:2)
Problem is that "design improvement" is a security concern, and required for the system to function as desired. Adding wheels to a car might be a "design improvement", but you'd better have them.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Just keep in mind that any application that has access the files on your computer (mainly the browser cookies) can bypass the 2-factor-auth. You just need to copy the cookie to another browser and BAM! - you're logged into Google.
You are confusing various unrelated items. (or maybe you're just oversimplifying things)
Just to clarify, authentication (2-factor or single factor) is separate from session management.
In addition, the application session is separate from the single sign on session.
Although google doesn't use Jasig CAS, I think it's protocol is one of the easiest ways to get a more detailed understanding of SSO: http://www.jasig.org/cas/protocol [jasig.org]
That protocol doc is actually quite readable. It differs from SAML in some respec
Not surprised... (Score:2)
I considered the 'application specific' passwords as just 'hard for human to remember password' and that divulging the password to the program meant I explicitly trust the program with access to my account (the big fat clue being no app specific configuration data other than a helpful descriptive tag).
I suppose they could enrich it by forbidding account management function, or scoping it more (e.g. mail versus jabber versus whatever as limited scope).
Surely this is expected (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
If it's kept in persistent storage by the application, that actually increases the chance of it being compromised. Rather than logging keystrokes or peeking at RAM or man-in-the-middling the application in some way, you can just read a file.
For what it's worth (Score:1)
I use the Application Specific passwords as Device Specific instead. I have a code for my Phone, laptop, and desktop computers. So...If one of the devices gets stolen or sold, I just expire the one code. Much easier to manage 4 or 5 codes than a bunch of codes for a lot of apps.
Re: (Score:2)
Probably said 'released Today' or something slightly more ambiguous than what they replaced it with.
google passing buck again? Or is it yet? (Score:1)
I wonder if that is why I found myself locked out of my gmail account as of about 3:38 am yesterday. Fetchmail reported a password problem. I called google on that number from fastsupport, and 2 different people, neither of whom spoke English well enough to talk to this old Iowa Farm boy, tell me that something was changed in my account that only my machine could have done, and accused my machine of being compromised. I'm running linux, and my whole home network is behind a dd-wrt router. I can see the
So is this a good summary? (Score:2)