adam good man
tl;dr – An attacker can bypass google’s two-step login verification, reset a user’s master password, and otherwise gain full control of the account , simply 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) app-specific passwords
A few months ago, we found a way to (ab)use asps to gain full control of google accounts, completely bypassing google’s two-step verification process. We reported our findings to Google’s security team, and they recently responded that they had implemented some changes to mitigate the most serious threats we had discovered. this is what we found:
application-specific passwords
even some of google’s software initially required you to use asps, e.g. to enable chrome sync features or to set up your google account on an android device. more recently, these clients have generally moved to using methods similar to sworn authentication. In this model, when you sign in for the first time with a new app or device, you receive an authorization message, including 2-Step Verification, in a web view; After a successful login, the google service returns a limited access “token”, which is used to authenticate your device/application in the future.
Actually, oauth and asps style tokens are theoretically very similar: in each case, you end up creating a unique authorization token for each different device or app you connect to your google account. In addition, each token can be revoked individually without affecting the others: if you lose your smartphone, you can ensure that you no longer have access to your Gmail account without having to memorize a new password.
so the main differences between oauth and asps tokens are:
- oauth tokens are created automatically, while asps are a completely manual affair. you need to sign in to the google account settings page to create one and then transcribe (or copy/paste) it into your app.
- auth tokens use a flexible authorization model and can be restricted to access only certain data or services in your account. conversely, asps, in application terms, are not application specific at all!
“another weakness of asp is the mistaken impression that it provides limited account access to the application rather than full access”. – authentication at scale, featured in ieee s&p magazine vol. 11, no. 1
automatic login with chrome
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 recovery options (using auto login to bypass the login pages), change the password reset settings and gain full control over the account.
Would you like more information about two-factor authentication? download our guide to evaluating two-factor authentication
technical details
To do this, we set up an intercepting proxy with a custom CA certificate to watch network traffic between an android emulator instance and google servers. when adding a google account to the emulator (using an asp), we saw the following request:
the response body contained, among other things:
Although the url and some of the parameters are not documented, this looks a lot like the google client login api. to recreate this request on our own, we would just need to figure out what values to fill in for the encryptedpasswd and androidid parameters. turns out androidid is simple; we trust to assume that 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 the encrypted password might be our asp, encrypted with a 1024-bit rsa public key included in the android system. encryptedpasswd was, in fact, 130 bytes of binary data (base64 encoded), so this seems quite possible. however, before we get too deep into this, we decided to try replacing the encrypted password parameter with the (unencrypted) password parameter from the client login api documentation, configured in our asp:
this worked! again, we received 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, and appeared 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:
This request returned a response body similar to:
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 to specify this service in our original request, i.e. with an asp instead of the token (and without trying to determine where an unknown client_sig parameter came from):
this returned the same form of response:
that mergesession url is the key here. if you open it in an unauthenticated web browser after making this api call (you need to do it quickly; it has a very short expiration window), you’ll be immediately logged into your account settings page, with no authentication prompt! /p>
so: with just a username, an asp and a single request to https://android.clients.google.com/auth, we can log in to any google web property without any startup prompt login (or two-step verification)!
google’s solution
- 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 mergesession url The resulting account would immediately take them to the “account recovery options” page, where they could modify the password recovery email address to reset 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 2-Step Verification setup, where they could create/edit asps or disable 2fa for the entire account.
was this so bad?
Currently, attackers are still very successful using some very simple methods to take over accounts. for example, by:
- create a phishing site to trick users into handing over their passwords.
- exploit the fact that users often share passwords between sites, by cracking a database of passwords (poorly protected) from one site and use the recovered passwords to try to break into user accounts on other sites.
however, even with asps almighty, google’s two-step verification system should mitigate both types of attacks, even if users continue to do “stupid” things. App-specific passwords are generated by Google and are not intended to be memorized by users, so it is highly unlikely that a user could share one with other websites. Similarly, if a phishing site required users to submit an application-specific password, we imagine its success rate would be much lower (perhaps an order of magnitude lower) than normal.
That said, the almighty asps still carry some serious damage potential. if an attacker can trick a user into running some malware, that malware could 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 plain text in an xml file). furthermore, fat client applications, the main consumer of asps, are quite notorious for poor ssl certificate verification, potentially allowing asps to be captured on the wire via mitm attacks.
Google’s solution significantly helps this situation. Although a compromised asp could still inflict significant damage on a user, that user should ultimately retain control over their account (and the ability to revoke the asp at the first sign something went wrong). however, we strongly believe in the principle of least privilege and would love to see google implement some means of further restricting the privileges of individual asps.
*update #1*
*Update #2*
disclosure schedule
p.d.
