Catching AuthTokens in the Wild The Insecurity of Google's ClientLogin Protocol
In a recent blog post Dan Wallach outlined some of the risks of using Android smartphones in open Wifi networks. He found that some Android applications transmit data in the clear, allowing an attacker to eavesdrop any transmitted information. Besides third-party apps, such as Twitter or Facebook, also the Google Calendar app transmitted unencrypted information. Wallach stated that "an eavesdropper can definitely see your calendar transactions and can likely impersonate you to Google Calendar". A fact that also applies to Google Contacts as another blog post revealed.
We wanted to know if it is really possible to launch an impersonation attack against Google services and started our own analysis. The short answer is: Yes, it is possible, and it is quite easy to do so. Further, the attack is not limited to Google Calendar and Contacts, but is theoretically feasible with all Google services using the ClientLogin authentication protocol for access to its data APIs.
ClientLogin is meant to be used for authentication by installed applications and Android apps. Basically, to use ClientLogin, an application needs to request an authentication token (authToken) from the Google service by passing an account name and password via a https connection. The returned authToken can be used for any subsequent request to the service API and is valid for a maximum duration of 2 weeks. However, if this authToken is used in requests send over unencrypted http, an adversary can easily sniff the authToken (e.g. with Wireshark, see screenshot below). Because the authToken is not bound to any session or device specific information the adversary can subsequently use the captured authToken to access any personal data which is made available through the service API. For instance, the adversary can gain full access to the calendar, contacts information, or private web albums of the respective Google user. This means that the adversary can view, modify or delete any contacts, calendar events, or private pictures. This is not limited to items currently being synced but affects all items of that user.
The attack is very similar to stealing session cookies of websites (Sidejacking). The feasibility of Sidejacking attacks against well-known websites such as Facebook or Twitter, has lately been demonstrated by the Firesheep plugin which attracted a lot of attention.
Screenshot of Wireshark showing the authToken for ClientLogin in a data API request to the Picasa Web Albums service.
Scope
We tested this attack with Android versions 2.1 (Nexus One), 2.2 (HTC Desire, Nexus One), 2.2.1 (HTC Incredible S), 2.3.3 (Nexus One), 2.3.4 (HTC Desire, Nexus One), and 3.0 (Motorola XOOM) and with the native Google Calendar, Google Contacts, and Gallery apps (or respective synchronization services).
Until Android 2.3.3 the Calendar and Contacts apps transmit any request in the clear via http and are therefore vulnerable to the authToken attack. This affects 99.7% of all Android smartphones (stats from 2nd of May 2011). Since Android 2.3 the Gallery app provides Picasa Web Albums synchronization which is also not encrypted.
Since Android 2.3.4, the Calendar and Contacts apps are using a secure https connection. However, the Picasa synchronization is still using http and thus is still vulnerable.
Our sniffed authTokens were valid for several days (14 days for a sniffed Calendar authToken), which enables adversaries to comfortably capture and make use of tokens at different times and locations.
Use of HTTPS in Android Google Apps:
Android version Calendar Sync
Contacts Sync
Picasa Sync (Gallery)
3.0 yes yes ?
2.3.4 yes yes no
2.3.3 no no no
2.2.1 no no n/a
2.2 no no n/a
2.1 no no n/a
Note that this vulnerability is not limited to standard Android apps but pertains to any Android apps and also desktop applications that make use of Google services via the ClientLogin protocol over HTTP rather than HTTPS. For example, the Google Calendar provider for Thunderbird if Google Calendar URLs are used without leading "https".
Collecting authTokens
To collect such authTokens on a large scale an adversary could setup a wifi access point with a common SSID (evil twin) of an unencrypted wireless network, e.g., T-Mobile, attwifi, starbucks. With default settings, Android phones automatically connect to a previously known network and many apps will attempt syncing immediately. While syncing would fail (unless the adversary forwards the requests), the adversary would capture authTokens for each service that attempted syncing. Due to the long lifetime of authTokens, the adversary can comfortably capture a large number of tokens and make use of them later on from a different location.
Implications
The implications of this vulnerability reach from disclosure to loss of personal information for the Calendar data. For Contact information, private information of others is also affected, potentially including phone numbers, home addresses, and email addresses. Beyond the mere stealing of such information, an adversary could perform subtle changes without the user noticing. For example, an adversary could change the stored email address of the victim's boss or business partners hoping to receive sensitive or confidential material pertaining to their business.
Fixing the issue
What app developers can do:
Android apps and synchronization services using ClientLogin should immediately switch to https. In the newest Android release (2.3.4) this step was already taken for the Google Calendar and Contacts apps, but other apps need to follow. The Gallery app is developed by Cooliris who probably were not made aware of the issue. However, the Android security team told us that they are investigating the Gallery app as well. So hopefully a fix should be integrated in the next release.
Google APIs offer more secure authentication services. Switching to oAuth for authentication would mitigate the authToken capture issue. Https should be used in addition to prevent synced data to be transmitted in the clear.
What Google/Android can do:
The lifetime of an authToken should be drastically limited.
Google services could reject ClientLogin based requests from insecure http connections to enforce use of https. Https is already required for the Google Docs API und will be required for Google Spreadsheet and Google Sites APIs in September 2011. It should be mandatory for all of Google's data APIs.
Automatically connecting to known Wifi-networks could be limited to protected networks. At least a respective option should be provided to users.
What Android users can do:
Update to Android 2.3.4. Update your phone to the current Android version as soon as possible. However, depending on your phone vendor you may have to wait weeks/months before an update is available for your phone. Hopefully this will change in the future.
Switch off automatic synchronization in the settings menu when connecting with open Wifi networks.
Let your device forget an open network you previously connected to, to prevent automatic reconnection (long press network name and select forget)
The best protection at the moment is to avoid open Wifi networks at all when using affected apps.
References:
http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html
http://code.google.com/apis/gdata/faq.html#clientlogin_expire
http://developer.android.com/resources/dashboard/platform-versions.html
source
We wanted to know if it is really possible to launch an impersonation attack against Google services and started our own analysis. The short answer is: Yes, it is possible, and it is quite easy to do so. Further, the attack is not limited to Google Calendar and Contacts, but is theoretically feasible with all Google services using the ClientLogin authentication protocol for access to its data APIs.
ClientLogin is meant to be used for authentication by installed applications and Android apps. Basically, to use ClientLogin, an application needs to request an authentication token (authToken) from the Google service by passing an account name and password via a https connection. The returned authToken can be used for any subsequent request to the service API and is valid for a maximum duration of 2 weeks. However, if this authToken is used in requests send over unencrypted http, an adversary can easily sniff the authToken (e.g. with Wireshark, see screenshot below). Because the authToken is not bound to any session or device specific information the adversary can subsequently use the captured authToken to access any personal data which is made available through the service API. For instance, the adversary can gain full access to the calendar, contacts information, or private web albums of the respective Google user. This means that the adversary can view, modify or delete any contacts, calendar events, or private pictures. This is not limited to items currently being synced but affects all items of that user.
The attack is very similar to stealing session cookies of websites (Sidejacking). The feasibility of Sidejacking attacks against well-known websites such as Facebook or Twitter, has lately been demonstrated by the Firesheep plugin which attracted a lot of attention.
Screenshot of Wireshark showing the authToken for ClientLogin in a data API request to the Picasa Web Albums service.
Scope
We tested this attack with Android versions 2.1 (Nexus One), 2.2 (HTC Desire, Nexus One), 2.2.1 (HTC Incredible S), 2.3.3 (Nexus One), 2.3.4 (HTC Desire, Nexus One), and 3.0 (Motorola XOOM) and with the native Google Calendar, Google Contacts, and Gallery apps (or respective synchronization services).
Until Android 2.3.3 the Calendar and Contacts apps transmit any request in the clear via http and are therefore vulnerable to the authToken attack. This affects 99.7% of all Android smartphones (stats from 2nd of May 2011). Since Android 2.3 the Gallery app provides Picasa Web Albums synchronization which is also not encrypted.
Since Android 2.3.4, the Calendar and Contacts apps are using a secure https connection. However, the Picasa synchronization is still using http and thus is still vulnerable.
Our sniffed authTokens were valid for several days (14 days for a sniffed Calendar authToken), which enables adversaries to comfortably capture and make use of tokens at different times and locations.
Use of HTTPS in Android Google Apps:
Android version Calendar Sync
Contacts Sync
Picasa Sync (Gallery)
3.0 yes yes ?
2.3.4 yes yes no
2.3.3 no no no
2.2.1 no no n/a
2.2 no no n/a
2.1 no no n/a
Note that this vulnerability is not limited to standard Android apps but pertains to any Android apps and also desktop applications that make use of Google services via the ClientLogin protocol over HTTP rather than HTTPS. For example, the Google Calendar provider for Thunderbird if Google Calendar URLs are used without leading "https".
Collecting authTokens
To collect such authTokens on a large scale an adversary could setup a wifi access point with a common SSID (evil twin) of an unencrypted wireless network, e.g., T-Mobile, attwifi, starbucks. With default settings, Android phones automatically connect to a previously known network and many apps will attempt syncing immediately. While syncing would fail (unless the adversary forwards the requests), the adversary would capture authTokens for each service that attempted syncing. Due to the long lifetime of authTokens, the adversary can comfortably capture a large number of tokens and make use of them later on from a different location.
Implications
The implications of this vulnerability reach from disclosure to loss of personal information for the Calendar data. For Contact information, private information of others is also affected, potentially including phone numbers, home addresses, and email addresses. Beyond the mere stealing of such information, an adversary could perform subtle changes without the user noticing. For example, an adversary could change the stored email address of the victim's boss or business partners hoping to receive sensitive or confidential material pertaining to their business.
Fixing the issue
What app developers can do:
Android apps and synchronization services using ClientLogin should immediately switch to https. In the newest Android release (2.3.4) this step was already taken for the Google Calendar and Contacts apps, but other apps need to follow. The Gallery app is developed by Cooliris who probably were not made aware of the issue. However, the Android security team told us that they are investigating the Gallery app as well. So hopefully a fix should be integrated in the next release.
Google APIs offer more secure authentication services. Switching to oAuth for authentication would mitigate the authToken capture issue. Https should be used in addition to prevent synced data to be transmitted in the clear.
What Google/Android can do:
The lifetime of an authToken should be drastically limited.
Google services could reject ClientLogin based requests from insecure http connections to enforce use of https. Https is already required for the Google Docs API und will be required for Google Spreadsheet and Google Sites APIs in September 2011. It should be mandatory for all of Google's data APIs.
Automatically connecting to known Wifi-networks could be limited to protected networks. At least a respective option should be provided to users.
What Android users can do:
Update to Android 2.3.4. Update your phone to the current Android version as soon as possible. However, depending on your phone vendor you may have to wait weeks/months before an update is available for your phone. Hopefully this will change in the future.
Switch off automatic synchronization in the settings menu when connecting with open Wifi networks.
Let your device forget an open network you previously connected to, to prevent automatic reconnection (long press network name and select forget)
The best protection at the moment is to avoid open Wifi networks at all when using affected apps.
References:
http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html
http://code.google.com/apis/gdata/faq.html#clientlogin_expire
http://developer.android.com/resources/dashboard/platform-versions.html
source
Posts
No comments: