February 28, 2013 at 14:44Google Two-Factor Authentication Bypass
- Transfer
An attacker can bypass two-factor authentication (2FA) on Google services, reset the user password and gain complete control over the account by simply obtaining the so-called. application password - PP (ASP - Application-Specific Passwords).
(With all due respect to Google ’s advertising campaign, “Good to Know” )
2FA Google provides material for the study of various problems that certainly arise in such a large-scale reliable authentication systems.
To make such authentication possible for all users (and seamlessly integrate it into an existing ecosystem), Google engineers had to make some compromises. Such as, for example, application passwords .
A few months ago, we found a way to use the software to get full control over your google account, completely bypassing 2FA. We told Google Security about our find and recently received a response from them that they took some steps to neutralize the most serious threats that we discovered. And so, here is what we found:
As soon as you enable 2FA, Google will ask you to create a separate password for each application that you use (hence the name "application password"), which does not support 2FA. You use this password instead of your primary. More specifically, you create software for most applications that do not use login from a web form: e-mail clients using IMAP and SMTP (Apple Mail, Thunderbird, etc.); XMPP chat clients (Adium, Pidgin, etc.), as well as various calendars synchronized using CalDAV (iCal, etc.).
Even some software from Google forces you to use the software - for example, to enable synchronization in Chrome or set up your account on an Android device. More recently, most of these clients have switched to authorization through OAuth. In this model, when you first log in to your new device or application, you receive a request for authorization in a web form that uses 2FA. After successful authorization, the server returns a limited access token, which is then used to authenticate your device / application.
In fact, OAuth tokens and PPs are very similar - in the end, it all ends up creating a unique authorization token for each device / application that you attach to your google account. In addition, each individual token can be revoked, without prejudice to the rest: if you lose your smartphone, you can be sure that no one will be able to access your mailbox without a password.
And so, the main differences between OAuth tokens and software are as follows:
Let us dwell on the second point in more detail. If you create a software for the XMPP chat client, this same password can be used to read mail via IMAP or to receive a list of events from the CalDAV calendar. Which, in fact, is not such a surprise. In fact, Eric Gorss and Mayank Upadhyay from Google have already pointed out this weakness in their article on Google’s 2FA:
Authentication at Scale from IEEE S&P Magazine vol. 11, no. 1
So, PPs can do much, much more than just gaining access to your mail. In fact, they can be used for authentication on most Google services bypassing 2FA!
In the latest versions of Android and ChromeOs, Google has included an auto-login mechanism in google accounts in its browsers. After you link your device to your account, the browser will use the existing authorization and stop requesting it through the web form. (There is even experimental support for this functionality in the desktop version of Chrome, you can enable it by opening “chrome: // flags /.”).
Until recently, this mechanism worked even for the most important part of a google account - the settings page. It includes a password recovery page where you can add and edit an e-mail address and phone numbers to which you will be sent the information necessary to reset the password. In short, if you can access this page, you can select an account from its rightful owner.
In his excellent Android Explorations blog, Nikolai Elenkov published an extensive study of the auto-login mechanism in Android. It was a great starting point, but it did not contain all the information we needed. We wanted to learn how to use this mechanism without having an Android device or Chromebook.
To do this, we set up an interception proxy to monitor traffic between the Android emulator and Google servers. When adding a google account, 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
answer, among other things, contained the following:
Token = 1 / f1Hu ...
Despite the fact that url and some parameters are not documented, it is very similar to Google ClientLogin API . In order to recreate such a request ourselves, we needed to understand what values should be passed in the parameters “EncryptedPasswd” and “androidId”. With the second, everything turned out to be simple - this is the “ANDROID_ID" parameter mentioned in the Android API Docs - a randomly generated 64-bit value that is intended to uniquely identify an Android device.
Another postElenkova inspired us with the hope that “EncryptedPasswd” could be our software, encrypted with a public 1024-bit RSA key, which is included in the Android platform. EncryptedPasswd was 130 bytes long binary data (base64 encoded), so it’s quite possible that it is. However, before moving on, we decided to try replacing this parameter with the “Passwd” parameter (not an encrypted password) from the documentation and setting it to value — our software:
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
And it worked! We got an answer that contained something very similar to a valid token. This token, created by the android.clients.google.com server, became visible in the “Connected Sites, Apps, and Services” section of our account and seems to give us full access to the account:
Continuing to monitor traffic, we noticed 2 different processes, related to auto-login in the browser. The simpler one was another client request for login, but used our 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
Этот запрос возвращал тело ответа, а так же следующую строчку:
Auth=https://accounts.google.com/MergeSession?args=continue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount&uberauth=AP...&source=AndroidWebLogin
Expiry=0
Из этого запроса мы установили, что форматом для параметра «service» является weblogin:continue=url_encode(destination_url). We decided to try to specify this parameter for our initial request with the PP instead of the token (instead of trying to understand the origin of the incomprehensible 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 & the lang = en & \
service, = weblogin% 3Acontinue% 3Dhttps% 253A% 2F% 2Faccounts.google.com% 2FManageAccount & \
-source = android & Passwd = xxxxxxxxxxxxxxxx & operatorCountry = us & sdk_version = 17 & has_permission = 1
and get answers repeating the previous one completely:
Auth = https: //accounts.google.com/MergeSession? Args = continue% 3Dhttps% 253A% 252F% 252Faccounts.google.com% 252FManageAccount & uberauth = AP ... & source = AndroidWebLogin
Expiry0
The key parameter here is "MergeSession". If you open this URL in an unauthorized browser after you complete the request (this must be done very quickly), you will be immediately logged into your account!
Thus, having only a username, software, and having executed a request to android.clients.google.com/auth, it is possible to log in to the account settings page, bypassing two-stage verification!
As noted earlier, this method works even for the most critical google account section - settings. An attacker can take a happy action using the victim's PP:
This is no longer possible starting February 21, when Google engineers closed the hole. As far as we can tell, Google now supports some additional state that allows you to determine exactly how you authenticated - using the MergeSession URL and using a normal username and password using 2FA. The settings page will only be available in the latter case. If you logged in using the MergeSession URL, you will be redirected to the 2FA page, which should not be missed.
We believe that this is a big hole in the authentication system, if the user has some form for entering a password, which will allow access to full control over the account. But despite this, we still agree that even before Google rolled out its fix, turning on 2FA on your account is much better than not doing it.
Nowadays, an attacker still has in his arsenal a set of methods for gaining control over an account. For instance:
Both of these examples are types of attacks that can be prevented by following simple rules and digital hygiene. For example, do not use the same password on different sites and do not click on suspicious links in e-mail messages. Unfortunately, such “educational programs for users” rarely work well in practice (and may not be practical from an economic point of view ).
Despite this, even with PP, Google’s 2FA can mitigate both of these types of attacks, even if users continue to do stupid things. PPs are generated by Google and do not involve user memorization, i.e. it is unlikely that he uses the exact same password on another site. Even if an attacker creates a phishing site and lures out the IP, his chances of success will be significantly (possibly by orders of magnitude) lower than with a regular password.
However, the widespread use of PP still carries a potential danger. If an attacker can force them to install malware, they can find and extract the software somewhere in the user system (for example, the popular Pidgin chat client stores passwords in clear text in an XML file) In addition, “thick-client” applications, the main user of software, are often exposed to the rather well-known problem of weak SSL certificate verification, which potentially allows you to steal software using a MiM attack.
Fix Google greatly helps in this situation. Despite the fact that the software can still cause significant harm to the user, he will be able to maintain control over his account and the ability to withdraw the software if something goes wrong. Nevertheless, we strongly believe in the principle of minimum privileges and would like to see further steps by Google aimed at restricting the privileges of individual software.
Update # 1
Google updated its alert when creating a software alert that warned of potential risk:
Update # 2
Craig Young from nCircle made a presentation on a similar issue at a BSides conference with RSA!
Timeline:
2012/07/16: Researchers from Duo have confirmed the existence of PP vulnerabilities.
2012/07/18: A description of the problem was sent to security@google.com.
2012/07/20: Discussion with Google Security to clarify details.
2012/07/24: The problem has been confirmed and classified by Google as “expected behavior”.
2013/02/21: Google has released a fix that prohibits access to critical information for PP sessions.
2013/02/25: Duo publish an article describing the problem.
(With all due respect to Google ’s advertising campaign, “Good to Know” )
Google app password abuse
2FA Google provides material for the study of various problems that certainly arise in such a large-scale reliable authentication systems.
To make such authentication possible for all users (and seamlessly integrate it into an existing ecosystem), Google engineers had to make some compromises. Such as, for example, application passwords .
A few months ago, we found a way to use the software to get full control over your google account, completely bypassing 2FA. We told Google Security about our find and recently received a response from them that they took some steps to neutralize the most serious threats that we discovered. And so, here is what we found:
Application passwords
As soon as you enable 2FA, Google will ask you to create a separate password for each application that you use (hence the name "application password"), which does not support 2FA. You use this password instead of your primary. More specifically, you create software for most applications that do not use login from a web form: e-mail clients using IMAP and SMTP (Apple Mail, Thunderbird, etc.); XMPP chat clients (Adium, Pidgin, etc.), as well as various calendars synchronized using CalDAV (iCal, etc.).
Even some software from Google forces you to use the software - for example, to enable synchronization in Chrome or set up your account on an Android device. More recently, most of these clients have switched to authorization through OAuth. In this model, when you first log in to your new device or application, you receive a request for authorization in a web form that uses 2FA. After successful authorization, the server returns a limited access token, which is then used to authenticate your device / application.
In fact, OAuth tokens and PPs are very similar - in the end, it all ends up creating a unique authorization token for each device / application that you attach to your google account. In addition, each individual token can be revoked, without prejudice to the rest: if you lose your smartphone, you can be sure that no one will be able to access your mailbox without a password.
And so, the main differences between OAuth tokens and software are as follows:
- OAuth tokens are created automatically, while PPs need to be created manually. You need to go to the google account settings to create it, and then copy it to the application.
- OAuth tokens provide a more flexible authorization model and can be used to restrict access only to certain data or services in your account. On the other hand, application passwords, to be completely accurate, are not entirely ONLY for applications!
Let us dwell on the second point in more detail. If you create a software for the XMPP chat client, this same password can be used to read mail via IMAP or to receive a list of events from the CalDAV calendar. Which, in fact, is not such a surprise. In fact, Eric Gorss and Mayank Upadhyay from Google have already pointed out this weakness in their article on Google’s 2FA:
“Another weakness of the software is the misleading impression that they provide access to a specific application, rather than full access to an account.”
Authentication at Scale from IEEE S&P Magazine vol. 11, no. 1
So, PPs can do much, much more than just gaining access to your mail. In fact, they can be used for authentication on most Google services bypassing 2FA!
Auto Login in Chrome
In the latest versions of Android and ChromeOs, Google has included an auto-login mechanism in google accounts in its browsers. After you link your device to your account, the browser will use the existing authorization and stop requesting it through the web form. (There is even experimental support for this functionality in the desktop version of Chrome, you can enable it by opening “chrome: // flags /.”).
Until recently, this mechanism worked even for the most important part of a google account - the settings page. It includes a password recovery page where you can add and edit an e-mail address and phone numbers to which you will be sent the information necessary to reset the password. In short, if you can access this page, you can select an account from its rightful owner.
Technical details
In his excellent Android Explorations blog, Nikolai Elenkov published an extensive study of the auto-login mechanism in Android. It was a great starting point, but it did not contain all the information we needed. We wanted to learn how to use this mechanism without having an Android device or Chromebook.
To do this, we set up an interception proxy to monitor traffic between the Android emulator and Google servers. When adding a google account, 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
answer, among other things, contained the following:
Token = 1 / f1Hu ...
Despite the fact that url and some parameters are not documented, it is very similar to Google ClientLogin API . In order to recreate such a request ourselves, we needed to understand what values should be passed in the parameters “EncryptedPasswd” and “androidId”. With the second, everything turned out to be simple - this is the “ANDROID_ID" parameter mentioned in the Android API Docs - a randomly generated 64-bit value that is intended to uniquely identify an Android device.
Another postElenkova inspired us with the hope that “EncryptedPasswd” could be our software, encrypted with a public 1024-bit RSA key, which is included in the Android platform. EncryptedPasswd was 130 bytes long binary data (base64 encoded), so it’s quite possible that it is. However, before moving on, we decided to try replacing this parameter with the “Passwd” parameter (not an encrypted password) from the documentation and setting it to value — our software:
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
And it worked! We got an answer that contained something very similar to a valid token. This token, created by the android.clients.google.com server, became visible in the “Connected Sites, Apps, and Services” section of our account and seems to give us full access to the account:
Continuing to monitor traffic, we noticed 2 different processes, related to auto-login in the browser. The simpler one was another client request for login, but used our 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
Этот запрос возвращал тело ответа, а так же следующую строчку:
Auth=https://accounts.google.com/MergeSession?args=continue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount&uberauth=AP...&source=AndroidWebLogin
Expiry=0
Из этого запроса мы установили, что форматом для параметра «service» является weblogin:continue=url_encode(destination_url). We decided to try to specify this parameter for our initial request with the PP instead of the token (instead of trying to understand the origin of the incomprehensible 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 & the lang = en & \
service, = weblogin% 3Acontinue% 3Dhttps% 253A% 2F% 2Faccounts.google.com% 2FManageAccount & \
-source = android & Passwd = xxxxxxxxxxxxxxxx & operatorCountry = us & sdk_version = 17 & has_permission = 1
and get answers repeating the previous one completely:
Auth = https: //accounts.google.com/MergeSession? Args = continue% 3Dhttps% 253A% 252F% 252Faccounts.google.com% 252FManageAccount & uberauth = AP ... & source = AndroidWebLogin
Expiry0
The key parameter here is "MergeSession". If you open this URL in an unauthorized browser after you complete the request (this must be done very quickly), you will be immediately logged into your account!
Thus, having only a username, software, and having executed a request to android.clients.google.com/auth, it is possible to log in to the account settings page, bypassing two-stage verification!
Fix Google
As noted earlier, this method works even for the most critical google account section - settings. An attacker can take a happy action using the victim's PP:
- It can pass " accounts.google.com/b/0/UpdateAccountRecoveryOptions?hl=en&service=oz " as an url in the API request. The MergeSession URL received in the response will lead it directly to the password recovery page, where it can reset the main password.
- Similarly, an attacker can send the url “ accounts.google.com/b/0/SmsAuthConfig?hl=en ” to the request , which will lead him to the page with 2FA settings, where he can add and remove software or disable 2FA at all.
This is no longer possible starting February 21, when Google engineers closed the hole. As far as we can tell, Google now supports some additional state that allows you to determine exactly how you authenticated - using the MergeSession URL and using a normal username and password using 2FA. The settings page will only be available in the latter case. If you logged in using the MergeSession URL, you will be redirected to the 2FA page, which should not be missed.
How bad was it?
We believe that this is a big hole in the authentication system, if the user has some form for entering a password, which will allow access to full control over the account. But despite this, we still agree that even before Google rolled out its fix, turning on 2FA on your account is much better than not doing it.
Nowadays, an attacker still has in his arsenal a set of methods for gaining control over an account. For instance:
- Creation of a phishing site in order to force the user to give his password.
- Using the fact that users often use the same password on different sites. Having cracked the database with the passwords of one vulnerable site, an attacker may try to gain access to accounts on other sites.
Both of these examples are types of attacks that can be prevented by following simple rules and digital hygiene. For example, do not use the same password on different sites and do not click on suspicious links in e-mail messages. Unfortunately, such “educational programs for users” rarely work well in practice (and may not be practical from an economic point of view ).
Despite this, even with PP, Google’s 2FA can mitigate both of these types of attacks, even if users continue to do stupid things. PPs are generated by Google and do not involve user memorization, i.e. it is unlikely that he uses the exact same password on another site. Even if an attacker creates a phishing site and lures out the IP, his chances of success will be significantly (possibly by orders of magnitude) lower than with a regular password.
However, the widespread use of PP still carries a potential danger. If an attacker can force them to install malware, they can find and extract the software somewhere in the user system (for example, the popular Pidgin chat client stores passwords in clear text in an XML file) In addition, “thick-client” applications, the main user of software, are often exposed to the rather well-known problem of weak SSL certificate verification, which potentially allows you to steal software using a MiM attack.
Fix Google greatly helps in this situation. Despite the fact that the software can still cause significant harm to the user, he will be able to maintain control over his account and the ability to withdraw the software if something goes wrong. Nevertheless, we strongly believe in the principle of minimum privileges and would like to see further steps by Google aimed at restricting the privileges of individual software.
Update # 1
Google updated its alert when creating a software alert that warned of potential risk:
Update # 2
Craig Young from nCircle made a presentation on a similar issue at a BSides conference with RSA!
Timeline:
2012/07/16: Researchers from Duo have confirmed the existence of PP vulnerabilities.
2012/07/18: A description of the problem was sent to security@google.com.
2012/07/20: Discussion with Google Security to clarify details.
2012/07/24: The problem has been confirmed and classified by Google as “expected behavior”.
2013/02/21: Google has released a fix that prohibits access to critical information for PP sessions.
2013/02/25: Duo publish an article describing the problem.