Bypassing Google’s Two-Factor Authentication - Duo Blog (2024)

Duo Labs

February 25, 2013 Adam Goodman

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

Read ahead to learn more on how to bypass Google’s 2-step verification in detail and the updates released since the discovery.

(With all due respect toGoogle's old "Good to Know" ad campaign)

How to bypass Google’s 2-step verification through ASPs

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 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 bypass Google's 2-step verification by (ab)using their ASPs to gain full control over Google accounts, completely circumventing Google’s 2-step verification process. We communicated how we bypassed Google's two-step verification to their security team, and recently heard back that they had implemented some changes to mitigate the most serious of the threats we’d uncovered. Here’s what we found:

How do I bypass Google verification?

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 ofOAuth. 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, you are given a limited-access Google account bypass code, typically known as a “token,” which is used to authenticate your device/application in the future.

Actually, OAuth-style tokens and ASPs are 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 setting 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!

The second second point deserves some more attention. If you create an ASP for use in (for example) an XMPP chat client, that same ASP can also be used to read your email over IMAP or grab your calendar events with CalDAV. This shouldn’t be particularly surprising. In fact, Eric Grosse and Mayank Upadhyay of Google even call this weakness out in their recent publication about Google's authentication infrastructure:

“Another weakness of ASP is the misimpression that it 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 accessing your email over IMAP. In fact, an ASP can be used to bypass Google verification and log into almost any of Google’s web properties and access privileged account interfaces,in a way that bypasses 2-step verification!

How to bypass Google account verification with auto-login

So, to recap:

• You can use an ASP to link an Android device (or Chromebook, etc.) to a Google account

• 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

This was enough for us to realize that ASPs presented some surprisingly serious security threats, but we wanted to understand how the underlying mechanisms actually worked.

Want to learn more about two-factor authentication? Check out our guide to evaluating two-factor authentication!

How to bypass Google Account verification: Technical details

On his excellentAndroid Explorationsblog, Nikolay Elenkov documented arather in-depth investigationinto 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 bypass the account verification, we set up 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.1Host: 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 GoogleClientLogin 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 theAndroid API Docs: a randomly generated 64-bit value that is intended to uniquely identify an Android device.

Another of Elenkov’s blog postsled 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.1Host: 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, which allowed us to bypass Google verification. 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 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 returnedToken:

POST /auth HTTP/1.1Host: 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=AndroidWebLoginExpiry=0

From this request, we determined that the general format for the service parameter wasweblogin:continue=urlencode(destinationurl). We then decided to try specifying thisservicein our original request - i.e., with an ASP instead of theToken(and without trying to determine the provenance of an unknownclient_sig parameter):

POST /auth HTTP/1.1Host: 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=AndroidWebLoginExpiry=0

That MergeSession URL is the key here. If you open it in an un-authenticated web browser after making this API call (you must 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 Google's 2-step verification!

How to recover your Google account without a 2-step verification code

If you chose to use your phone as part of Google’s 2-step verification process, but don’t have access to it or that same phone number anymore, you can use Google’s Account Recovery service. If you are unable to provide one of the verification details required by Google, such as a recovery phone or email address, you may skip it by selecting "Try another way" in account recovery. Here are some of Google's tips to help you recover your account.

The only way to regain access to your Google account and any other Google applications like Gmail and Google Drive is through Google’s Account Recovery Service. If you didn’t elect a secondary device for two-step verification, you won’t need a phone or secondary email to log in, but your account won’t be as secure.

Can you still bypass Google verifications?

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 passhttps://accounts.google.com/b/0/UpdateAccountRecoveryOptions?hl=en&service=ozas 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 passhttps://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.

This is no longer the case as of February 21st, 2013, 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).

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.

Both these examples represent types of attacks that should be prevented simply by having users apply common sense and good digital hygiene—i.e., don’t use the same password on more than one site, and don’t click suspicious links in email messages. Unfortunately, this sort of “user education” program is something that rarely works well in practice (andmight not even make economic sense).

However, even with all-powerful ASPs, Google’s 2-step verification system should mitigate both 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, arerather notoriousfor 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 theprinciple 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 verbiage when an ASP is generated to warn users of their potential risk:

Update #2

Craig Young from NCircle gave atalkon 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 security@google.com.

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 addedthird-party account support to Duo Mobileso now your work and personal accounts can all live in one place!