Bypassing Google’s Two-Factor Authentication

Bypassing Google’s Two-Factor Authentication

TL;DR – An attacker can bypass Google’s two-step login verification, reset a user’s master password, and otherwise gain full account control, simply by capturing a user’s application-specific password (ASP).

(With all due respect to Google’s “Good to Know” ad campaign)

Abusing Google’s (not-so-) Application-Specific Passwords

Google’s 2-step verification makes for an interesting customer story in some of the challenges that go with such a wide-scale, comprehensive deployment of strong authentication. To make 2-step verification usable for all of their customers (and to bootstrap it into their rather expansive ecosystem without breaking everything), Google’s engineers had to make a few compromises. In particular, with 2-step verification came a notion of “Application-Specific Passwords” (ASPs).

Some months ago, we found a way to (ab)use ASPs to gain full control over Google accounts, completely circumventing Google’s 2-step verification process. We communicated our findings to Google’s security team, and recently heard back from them that they had implemented some changes to mitigate the most serious of the threats we’d uncovered. Here’s what we found:

Application-Specific Passwords

Generally, once you turn on 2-step verification, Google asks you to create a separate Application-Specific Password for each application you use (hence “Application-Specific”) that doesn’t support logins using 2-step verification. Then you use that ASP in place of your actual password. In more-concrete terms, you create ASPs for most client applications that don’t use a web-based login: email clients using IMAP and SMTP (Apple Mail, Thunderbird, etc.); chat clients communicating over XMPP (Adium, Pidgin, etc.), and calendar applications that sync using CalDAV (iCal, etc.).

Even some of Google’s own software initially required you to use ASPs – e.g. to enable Chrome’s sync features, or to set up your Google account on an Android device. More recently, these clients have generally shifted to using methods along the lines of OAuth. In this model, when you first log in using a new application or device, you get an authorization prompt — including 2-step verification — in a webview; after a successful login, Google’s service returns a limited-access “token”, which is used to authenticate your device/application in the future.

Actually, OAuth-style tokens and ASPs are notionally very similar — in each case, you end up creating a unique authorization token for each different device/application you connect to your Google account. Further, each token can be individually revoked without affecting the others: if you lose your smartphone, you can make sure that it no longer has access to your GMail account without having to memorize a new password.

So then, the major differences between OAuth tokens and ASPs are:

• OAuth tokens are created automatically, while ASPs are a thoroughly manual affair. You have to log into Google’s account settings page to create one, and then transcribe (or copy/paste) it into your application.
• OAuth tokens use a flexible authorization model, and can be restricted to accessing only certain data or services in your account. By contrast, ASPs are — in terms of enforcement — not actually application-specific at all!

“Another weakness of ASP is the misimpression that is provides application-limited rather than full-scope account access.” – Authentication at Scale, appearing in IEEE S&P Magazine vol. 11, no. 1

As it turns out, ASPs can do much, much more than simply access your email over IMAP. In fact, an ASP can be used to log into almost any of Google’s web properties and access privileged account interfaces, in a way that bypasses 2-step verification!

Auto-Login with Chrome

In recent versions of Android (and ChromeOS), Google has included, in their browser, an “auto-login” mechanism for Google accounts. After you’ve linked your device to a Google account, the browser will let you use your device’s existing authorization to skip Google’s web-based sign-on prompts. (There is even experimental support for this in desktop versions of Chrome; you can enable it by visitingchrome://flags/.)

Until late last week, this auto-login mechanism worked even for the most sensitive parts of Google’s account-settings portal. This included the “Account recovery options” page, on which you can add or edit the email addresses and phone numbers to which Google might send password-reset messages. In short, if you can access the “Account recovery options” page for a Google account, then you can seize complete control of that account from its rightful owner.

So, to recap:

• You can use an ASP to link an Android device (or Chromebook, etc.) to a Google account, and
• With that linked device, you could (until very recently) access the account’s recovery options (using auto-login to bypass any sign-on pages), change the password-reset settings, and gain full control over the account.

Want to learn more about two-factor authentication? Download our guide to evaluating two-factor authentication

Technical Details

On his excellent Android Explorations blog, Nikolay Elenkov documented a rather in-depth investigation into the web auto-login mechanism on Android. This was a great starting point but still left a few gaps for our purposes. We wanted to learn how to exploit Google’s auto-login mechanism without using an Android device (or Chromebook, etc.) at all.

To do this, we set up an an intercepting proxy with a custom CA certificate to watch the network traffic between an Android emulator instance and Google’s servers. When adding a Google account to the emulator (using an ASP), we saw the following request:

POST /auth HTTP/1.1 Host: android.clients.google.com ... accountType=HOSTED_OR_GOOGLE&Email=user%40domain.com&has_permission=1&add_account=1&EncryptedPasswd=AFcb4...&service=ac2dm&source=android&androidId=3281f33679ccc6c6&device_country=us&operatorCountry=us&lang=en&sdk_version=17

The response body contained, among other things:

Token=1/f1Hu...

While the URL and some of the parameters aren’t documented, this very closely resembles the Google ClientLogin API. To recreate this request on our own, we’d need only to figure out what values to fill in for the EncryptedPasswd and androidId parameters. It turns out that androidId is simple; we’re confident in assuming it is the same “Android ID” mentioned in the Android API Docs: a randomly-generated 64-bit value that is intended to uniquely identify an Android device.

Another of Elenkov’s blog posts led us to believe that EncryptedPasswd might be our ASP, encrypted with a 1024-bit RSA public key included in the Android system. EncryptedPasswd was, in fact, 130 bytes of (base64-encoded) binary data, so this seems quite possible. However, before digging too deeply into this, we decided to try replacing the EncryptedPasswd parameter with the (unencrypted) Passwd parameter from the ClientLogin API documentation, set to our ASP:

POST /auth HTTP/1.1 Host: android.clients.google.com ... accountType=HOSTED_OR_GOOGLE&Email=user%40domain.com&has_permission=1&add_account=1&Passwd=xxxxxxxxxxxxxxxx&service=ac2dm&source=android&androidId=3281f33679ccc6c6&device_country=us&operatorCountry=us&lang=en&sdk_version=17

This worked! Again, we got a response containing what appeared to be a valid Token. The token created by the android.clients.google.com endpoint was now visible in our account’s “Connected Sites, Apps, and Services” interface, appearing to offer “Full Account Access”:

Continuing on with our captured traffic, we subsequently saw two different workflows for the browser’s auto-login functionality. The simpler of the two was another ClientLogin-style request, but using the returned Token:

POST /auth HTTP/1.1 Host: android.clients.google.com ... accountType=HOSTED_OR_GOOGLE&Email=user%40domain.com&has_permission=1&Token=1%2Ff1Hu...&service=weblogin%3Acontinue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount&source=android&androidId=3281f33679ccc6c6&app=com.android.browser&client_sig=61ed377e85d386a8dfee6b864bd85b0bfaa5af81&device_country=us&operatorCountry=us&lang=en&sdk_version=17

This request returned a response body along the lines of:

Auth=https://accounts.google.com/MergeSession?args=continue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount&uberauth=AP...&source=AndroidWebLogin Expiry=0

From this request, we determined that the general format for the service parameter was weblogin:continue=url_encode(destination_url). We then decided to try specifying this service in our original request – i.e. with an ASP instead of the Token (and without trying to determine the provenance of an unknown client_sig parameter):

POST /auth HTTP/1.1 Host: android.clients.google.com ... device_country=us&accountType=HOSTED_OR_GOOGLE&androidId=3281f33679ccc6c6&Email=user%40domain.com&lang=en&service=weblogin%3Acontinue%3Dhttps%253A%2F%2Faccounts.google.com%2FManageAccount&source=android&Passwd=xxxxxxxxxxxxxxxx&operatorCountry=us&sdk_version=17&has_permission=1

This returned us the same form of response:

Auth=https://accounts.google.com/MergeSession?args=continue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount&uberauth=AP...&source=AndroidWebLogin Expiry=0

That MergeSession URL is the key here. If you open it in an un-authenticated web browser after making this API call (you have to do this quickly; it has a very short expiration window), you will be immediately logged into your account settings page, with no authentication prompt!

So: given nothing but a username, an ASP, 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)!

Google’s Fix

As we mentioned before, this worked on even the most sensitive sections of Google’s account-settings portal. An attacker could perform a variety of privileged actions using a victim’s ASP:

• An attacker could pass https://accounts.google.com/b/0/UpdateAccountRecoveryOptions?hl=en&service=oz as the destination URL in the API request, and the resulting MergeSession URL would take them immediately to the “Account recovery options” page, in which they could modify the password recovery email address to perform a reset of the victim’s master password.
• Similarly, an attacker could pass https://accounts.google.com/b/0/SmsAuthConfig?hl=en, and the resulting URL would take them to the settings for 2-step verification, in which they could create/edit ASPs, or turn off 2FA for the account altogether.

Was This So Bad?

We think it’s a rather significant hole in a strong authentication system if a user still has some form of “password” that is sufficient to take over full control of his account. However, we’re still confident that — even before rolling out their fix — enabling Google’s 2-step verification was unequivocally better than not doing so.

These days, attackers still have a lot of success using some very simple methods to take over accounts. For example, by:

• Creating a phishing site to trick users into giving up their passwords.
• Exploiting the fact that users often share passwords between sites, by cracking a (poorly-protected) password database from one site, and using the recovered passwords to attempt to break into users’ accounts on other sites.

However, even with all-powerful ASPs, Google’s 2-step verification system should mitigate both of these types of attacks, even if users continue to do “stupid” things. Application-Specific Passwords are generated by Google, and not intended for users to memorize, so it’s extremely unlikely that a user might share one with other websites. Similarly, if a phishing site demanded users submit an Application-Specific Password, we imagine its success rate would be far lower (perhaps orders of magnitude lower) than normal.

That said, all-powerful ASPs still carry some serious potential for harm. If an attacker can trick a user into running some malware, that malware might be able to find and extract an ASP somewhere on that user’s system (for example, Pidgin, a popular chat client often used with Google Talk, stores passwords in plaintext in an XML file). In addition, thick-client applications, the primary consumer of ASPs, are rather notorious for poor SSL certificate verification, potentially allowing ASPs to be captured on the wire via MITM attacks.

Google’s fix helps this situation significantly. Though a compromised ASP could still inflict significant harm on a user, that user should ultimately retain control over his account (and the ability to revoke the ASP at the first sign something has gone wrong). However, we’re strong believers in the principle of least privilege, and we’d love to see Google implement some means to further-restrict the privileges of individual ASPs.

*Update #1*

Google has updated their verbage when an ASP is generated to warn users of their potential risk:

*Update #2*

Craig Young from nCircle gave a talk on similar ASP/2SV issues this week at the BSides event co-located with RSA!

Disclosure Timeline

2012/07/16: Duo researchers confirm presence of ASP weakness. 2012/07/18: Issue reported to [email protected]. 2012/07/20: Communication with Google Security Team clarifying the issue. 2012/07/24: Issue is confirmed and deemed “expected behavior” by Google Security Team. 2013/02/21: Fix is pushed by Google to prevent ASP-initiated sessions from accessing sensitive account interfaces. 2013/02/25: Public disclosure by Duo.

P.S.

Inspired to enable two-factor authentication with your Google account? No need to download yet another app. We recently added third-party account support to Duo Mobile so now your work and personal accounts can all live in one place!

Two-Factor Authentication Evaluation Guide

Download our free guide for a deep-dive into evaluating a modern two-factor solution that can meet your organization’s security needs.

Download the Guide