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?

[hawguy]

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?

[icebike]

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 fields in various apps (say for instance your favorite email app).

After the first showing of the actual ASP google only refers to them by the Name you gave it, so your naming convention is exactly what they expect you to do.

The problem was that, with a carefully set up network, and if you know the device id, you could capture and decrypt the ASP, and use the decrypted form from then on. But you had to be quick, as the encrypted ASP was time sensitive.

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.

Surely this is expected

[cgimusic]

To be fair I can sort of see Google's point. An application specific password is meant to be given to the application once and then never typed again, heavily reducing the chance of it being compromised. It should still not be possible to turn off 2 step auth or change the users password with one though but I have never assumed that it couldn't. Google makes it quite clear that the password grants full account access.

Re:Nice Guys!

[Xicor]

you dont generally go public with an exploit until you have a fix for it. it seems silly to me to publicize a way to take over peoples' accounts that the person who found out is keeping quiet. if you do, then everyone who would be using exploits is now aware of an exploit that you cant fix in the immediate future

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

[hawguy]

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: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:Sounds like expected behavior to _me_

[Half-pint HAL]

The problem is that anyone who manages to log onto your laptop has access to your Google Drive account (expected behaviour). And anyone who has access to your Google Drive account has access to everything Google... including Google Wallet. I was online when this change was applied. I'd connected to Google via the Google Drive application (because I couldn't remember my password) before navigating through to Google Wallet. It didn't strike me at the time just how dangerous a security hole this is. A few minutes later I was asked to log in properly, so I had to reset my forgotten password by phone alert. But a malicious hacker would have been able to change that too, and I might have worked away for various clients for a month before I discovered that the money was no longer reaching my bank. (Online language teaching, small value payments -- Google and Paypal are the only viable options.)

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.