Google two-way authentication bypass
An attacker can bypass two-factor authentication (2FA) on Google services, reset the user password and gain complete control over the account, simply by getting so-called application password - PP (ASP - Application-Specific Passwords).
(With all due respect to Google 's Good to Know advertising campaign)
2FA Google provides material for researching various problems that always arise in such large-scale secure 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 application passwords , for example.
A few months ago, we found a way to use PP to gain complete control over a google account, completely bypassing 2FA. We told Google security about our discovery and we received a response from them recently that they took some steps to neutralize the most serious threats that we found. 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 main one. To put it 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 PP - for example, to enable synchronization in Chrome or set up your account on your Android device. Most recently, these clients for the most part 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 restricted access token, which is later used to authenticate your device / application.
In fact, OAuth tokens and PPs are very similar - in the end, everything ends with the creation of a unique authorization token for each device / application that you link to your google account. In addition, each individual token can be revoked, without prejudice to the others: if you have lost your smartphone, you can be sure that no one can access your mailbox without having a password.
And so, the main differences between OAuth tokens and PP are as follows:
Let us dwell on the second paragraph in more detail. If you are creating a PP for an XMPP chat client, the same password can be used to read mail via IMAP or get a list of events from the CalDAV calendar. That, actually, is not such a surprise. In fact, Eric Gorss and Mayank Upadhyay of Google have already pointed to this weakness in their article on Google 2FA:
Authentication at Scale from IEEE S & P Magazine vol. 11, no. one
It turns out, PP can be much, much more than just getting access to your mail. In fact, they can be used to authenticate 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 associate your device with an account, the browser will use the already existing authorization and stop requesting it via 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 e-mail addresses 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 take away the account from its legal owner.
In his excellent Android Explorations blog, Nikolay Elenkov has published an extensive study of the auto-login mechanism in Android. It was an excellent 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 a Hrombuk.
To do this, we installed a snooping proxy to monitor the traffic between the Android emulator and Google servers. While 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 the URL and some parameters are not documented, it is very similar to the Google ClientLogin API . To recreate such a request ourselves, we needed to understand what values ​​should be passed in the “EncryptedPasswd” and “androidId” parameters. 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 the Android device.
Another Elenkov post inspired us with the hope that the “EncryptedPasswd” could be our software, encrypted with a public 1024-bit RSA key, which is included in the Android platform. EncryptedPasswd was binary data (base64 encoded) 130 bytes long, so it is quite possible that this is the case. However, before proceeding further, we decided to try to replace this parameter with the “Passwd” parameter (unencrypted password) from the documentation and set its value — our PP:
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 received a response 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 the traffic, we noticed 2 different processes related to auto-login in the browser. The simpler one was the next client login request, 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
This query returned the response body, as well as the following line:
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 found that the format for the “service” parameter is weblogin: continue = url_encode (destination_url) . We decided to try to specify this parameter for our initial request from 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 & 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 we received a response that repeats the previous one:
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 needs to be done very quickly), you will be logged in to your account immediately!
Thus, having only a username, PP and completing a request to android.clients.google.com/auth, it is possible to log into the account settings page, bypassing the two-step verification!
As noted earlier, this method works even for the most critical section of a google account - settings. The attacker can take action, using the victim's PP:
This is no longer possible, since February 21, when Google engineers have closed this 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 login and password using 2FA. The settings page will be available only in the latter case. If you logged in with the help of the MergeSession URL, you will be redirected to the 2FA page, which cannot be skipped.
We believe that this is a big hole in the authentication system, if the user has some form to enter 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, it is much better to include 2FA on your account than not to do it.
Nowadays, the attacker still has in his arsenal a set of methods for gaining control over the account. For example:
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, this kind of “educational programs for users” rarely work well in practice (and may be impractical from an economic point of view ).
Despite this, even with PP, Google 2FA can smooth both of these types of attacks, even if users continue to do stupid things. PPs are generated by Google and do not involve memorization by the user, 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 a PP, his chances of success will be significantly (perhaps orders of magnitude) lower than with a regular password.
Nevertheless, the widespread use of PP still carries a potential danger. If an attacker can force malware to be installed, it can find and extract the PP somewhere on the user's 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 the software, are often exposed to the rather well-known problem of weakly verifying the SSL certificate, which potentially makes it possible to steal software with the help of a MiM attack.
Google fix helps a lot in this situation. Despite the fact that the PP can still cause significant harm to the user, he will be able to retain control of his account and the ability to withdraw the PP if something goes wrong. Nevertheless, we firmly believe in the principle of minimal privileges and would like to see further steps by Google aimed at restricting the privileges of individual PPs.
Update # 1
Google updated its warning when creating a PP, which warns of potential risk:
Update # 2
Craig Young of nCircle made a presentation on a similar problem at the BSides conference held jointly with RSA!
Chronology of events:
2012/07/16: Duo researchers confirmed the presence of PP vulnerabilities.
2012/07/18: The description of the problem is directed to security@google.com.
2012/07/20: Discussion with Google Security to clarify details.
2012/07/24: Google confirmed the problem and classified it 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 Good to Know advertising campaign)
Abuse of Google Application Passwords
2FA Google provides material for researching various problems that always arise in such large-scale secure 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 application passwords , for example.
A few months ago, we found a way to use PP to gain complete control over a google account, completely bypassing 2FA. We told Google security about our discovery and we received a response from them recently that they took some steps to neutralize the most serious threats that we found. 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 main one. To put it 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 PP - for example, to enable synchronization in Chrome or set up your account on your Android device. Most recently, these clients for the most part 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 restricted access token, which is later used to authenticate your device / application.
In fact, OAuth tokens and PPs are very similar - in the end, everything ends with the creation of a unique authorization token for each device / application that you link to your google account. In addition, each individual token can be revoked, without prejudice to the others: if you have lost your smartphone, you can be sure that no one can access your mailbox without having a password.
And so, the main differences between OAuth tokens and PP are as follows:
- OAuth tokens are created automatically, while the PP needs to be created manually. You need to go to your 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 to only certain data or services in your account. On the other hand, application passwords, to be precise, are not entirely ONLY for applications!
Let us dwell on the second paragraph in more detail. If you are creating a PP for an XMPP chat client, the same password can be used to read mail via IMAP or get a list of events from the CalDAV calendar. That, actually, is not such a surprise. In fact, Eric Gorss and Mayank Upadhyay of Google have already pointed to this weakness in their article on Google 2FA:
"Another weakness of the PP is the deceptive impression that they provide access to a specific application, rather than full-scale access to the account"
Authentication at Scale from IEEE S & P Magazine vol. 11, no. one
It turns out, PP can be much, much more than just getting access to your mail. In fact, they can be used to authenticate on most Google services bypassing 2FA!
Chrome auto-login
In the latest versions of Android and ChromeOs, Google has included an auto-login mechanism in google accounts in its browsers. After you associate your device with an account, the browser will use the already existing authorization and stop requesting it via 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 e-mail addresses 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 take away the account from its legal owner.
Technical details
In his excellent Android Explorations blog, Nikolay Elenkov has published an extensive study of the auto-login mechanism in Android. It was an excellent 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 a Hrombuk.
To do this, we installed a snooping proxy to monitor the traffic between the Android emulator and Google servers. While 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 the URL and some parameters are not documented, it is very similar to the Google ClientLogin API . To recreate such a request ourselves, we needed to understand what values ​​should be passed in the “EncryptedPasswd” and “androidId” parameters. 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 the Android device.
Another Elenkov post inspired us with the hope that the “EncryptedPasswd” could be our software, encrypted with a public 1024-bit RSA key, which is included in the Android platform. EncryptedPasswd was binary data (base64 encoded) 130 bytes long, so it is quite possible that this is the case. However, before proceeding further, we decided to try to replace this parameter with the “Passwd” parameter (unencrypted password) from the documentation and set its value — our PP:
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 received a response 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 the traffic, we noticed 2 different processes related to auto-login in the browser. The simpler one was the next client login request, 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
This query returned the response body, as well as the following line:
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 found that the format for the “service” parameter is weblogin: continue = url_encode (destination_url) . We decided to try to specify this parameter for our initial request from 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 & 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 we received a response that repeats the previous one:
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 needs to be done very quickly), you will be logged in to your account immediately!
Thus, having only a username, PP and completing a request to android.clients.google.com/auth, it is possible to log into the account settings page, bypassing the two-step verification!
Fix google
As noted earlier, this method works even for the most critical section of a google account - settings. The attacker can take action, using the victim's PP:
- He can submit “ accounts.google.com/b/0/UpdateAccountRecoveryOptions?hl=en&service=oz ” as a 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 an “ accounts.google.com/b/0/SmsAuthConfig?hl=en ” URL to the request, which brings him to a page with 2FA settings, where he can add and remove PP or disable 2FA completely.
This is no longer possible, since February 21, when Google engineers have closed this 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 login and password using 2FA. The settings page will be available only in the latter case. If you logged in with the help of the MergeSession URL, you will be redirected to the 2FA page, which cannot be skipped.
How bad was everything?
We believe that this is a big hole in the authentication system, if the user has some form to enter 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, it is much better to include 2FA on your account than not to do it.
Nowadays, the attacker still has in his arsenal a set of methods for gaining control over the account. For example:
- Creating a phishing site, in order to force the user to give your password.
- Using the fact that users often use the same password on different sites. Having cracked the base with the passwords of one weakly protected 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, this kind of “educational programs for users” rarely work well in practice (and may be impractical from an economic point of view ).
Despite this, even with PP, Google 2FA can smooth both of these types of attacks, even if users continue to do stupid things. PPs are generated by Google and do not involve memorization by the user, 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 a PP, his chances of success will be significantly (perhaps orders of magnitude) lower than with a regular password.
Nevertheless, the widespread use of PP still carries a potential danger. If an attacker can force malware to be installed, it can find and extract the PP somewhere on the user's 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 the software, are often exposed to the rather well-known problem of weakly verifying the SSL certificate, which potentially makes it possible to steal software with the help of a MiM attack.
Google fix helps a lot in this situation. Despite the fact that the PP can still cause significant harm to the user, he will be able to retain control of his account and the ability to withdraw the PP if something goes wrong. Nevertheless, we firmly believe in the principle of minimal privileges and would like to see further steps by Google aimed at restricting the privileges of individual PPs.
Update # 1
Google updated its warning when creating a PP, which warns of potential risk:
Update # 2
Craig Young of nCircle made a presentation on a similar problem at the BSides conference held jointly with RSA!
Chronology of events:
2012/07/16: Duo researchers confirmed the presence of PP vulnerabilities.
2012/07/18: The description of the problem is directed to security@google.com.
2012/07/20: Discussion with Google Security to clarify details.
2012/07/24: Google confirmed the problem and classified it 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.
Source: https://habr.com/ru/post/171037/
All Articles