Bypassing Google's Two-Factor Authentication

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!"

Comments

Where's the surprise?

[F.Ultra]

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:Where's the surprise?

[Anonymous Coward]

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-settings portal will only allow you to access security-sensitive settings in the latter case (i.e. if you logged in using a MergeSession URL, it will give you a username/password/2-step-verification prompt that you can’t skip.)

Re:Where's the surprise?

[Talennor]

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:Where's the surprise?

[icebike]

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.

You Didn't RTFA!

[Anonymous Coward]

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:Nice Guys!

[Anonymous Coward]

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:Nice Guys!

[icebike]

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, 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:You Didn't RTFC!

[BlueMonk]

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.