Message-Id: <D4C2730D-A6A2-49D4-9713-B318FF0C362E@taddong.com>
Date: Fri, 4 Feb 2011 12:55:08 +0100
From: Raul Siles <raul@...dong.com>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: (TAD-2011-001) Vulnerability in HTC Peep: Twitter Credentials Disclosure


+ Vulnerability in HTC Peep: Twitter Credentials Disclosure

http://blog.taddong.com/2011/02/vulnerability-in-htc-peep-twitter.html


Title: Twitter credentials disclosure in HTC Peep mobile app (default HTC Twitter client)
Vulnerability ID: TAD-2011-001
Credits: This vulnerability was discovered by Raul Siles, Founder and Senior Security Analyst with Taddong (www.taddong.com)
Publication date: February 4, 2011
Vendors contacted: HTC (and MITRE - CVE ID)


-- Vulnerability description: 

The default Twitter client (or application) in HTC mobile devices is called HTC Peep. HTC Peep is vulnerable to two different credentials disclosure vulnerabilities during the authentication process against the Twitter service (twitter.com).

During the authentication process, the HTC Peep app establishes an HTTP (TCP/80) connection against the twitter.com servers, sending a few HTTP OAuth-related requests. The first two HTTP GET requests try to gather and make use of an OAuth token: "GET /oauth/request_token" (the response contains the "oauth_token") and "GET /oauth/authorize?oauth_token=...". 

The first vulnerability resides in the third HTTP request, a POST request towards the "/oauth/authorize" resource, which contains several parameters, including the Twitter username and password in the clear, making the authentication process vulnerable to eavesdropping attacks:

authenticity_token=c8b5abaf53f223e827d9258ddfef4285a816db5f&
oauth_token=I4FK956n1foaHjayLKXJT2IaBpsmoo0amKyPhebc&
session%5Busername_or_email%5D=USERNAME&session%5Bpassword%5D=PASSWORD

This authentication exchange should be protected by HTTPS, forcing the credentials to be sent over an encrypted channel.

The second vulnerability resides in the way HTC Peep works. Once the Twitter session has been established, all the HTTP requests from the mobile device to the Twitter service include an HTTP Basic authentication header that contains the Twitter username and password (although the app is supposed to be using OAuth). Examples of standard Twitter resources retrieved through HTTP GET requests: "/direct_messages.json?count=50&page=1", "/favorites.json?page=2", "/statuses/friends_timeline.json?count=50&page=1", or "/statuses/mentions.json?count=50&page=1".

GET /statuses/friends_timeline.json?count=50&page=1 HTTP/1.1
Accept: text/xml, application/xml;q=0.9, */*;q=0
Authorization: Basic BASE64("USERNAME:PASSWORD")
User-Agent: TwitterEngine
Host: twitter.com

OAuth is a technology that enables applications to access a service, in this case Twitter, on behalf of the user, with the user approval, without asking the user directly for (or storing) her password. HTTP Basic authentication is one of the most basic, hence the name, and insecure web-based authentication mechanisms. The credentials are sent (almost) in the clear on every HTTP request from the web client to the web server. In fact, the credentials ("username:password") are encoded in Base64 in the HTTP "Authorization" header. Simply by capturing or eavesdropping the web traffic and looking at the HTTP request headers, an attacker can easily obtain the user Twitter credentials.

The Twitter session can be protected by using a pure OAuth exchange, without making use of Basic authentication, or by protecting the whole session with HTTPS.

Coincidentally, the discovery of these vulnerabilities was aligned with Twitter's announcement to increase the security of third-party apps: "Starting August 31, all applications will be required to use “OAuth” to access your Twitter account". This service switch didn't make any difference regarding this vulnerability, as HTC Peep still works through its OAuth capabilities. However, as this advisory demonstrate, technology must be implemented properly. Historically, Twitter developers have been able to choose one of two authentication methods: Basic Authentication or OAuth. Somehow, HTC Peep is using both methods simultaneously, exposing the user credentials.

Modern mobile devices implement multiple communication technologies, such as IrDa, Bluetooth, Wi-Fi, and mobile (2G/3G). The last two, Wi-Fi and 2G/3G, are the most commonly used methods to establish data communications from the mobile device to other entities. Therefore, this vulnerability can be exploited on targeted attacks when the mobile device is using any of these two technologies:
	• Wi-Fi: When the mobile device connects to a Wi-Fi (802.11) network, an attacker can intercept all your web traffic if it is an open or WEP Wi-Fi network. If the network is based on WPA(2)-PSK, any user with access to that network can also collect all your traffic. You can protect your Wi-Fi data communications if you only connect to WPA2-Enterprise Wi-Fi networks (or, potentially, if you thoroughly make use of VPN technologies). Unfortunately, even when your device is not connected to any Wi-Fi network, still this vulnerability can be exploited in combination with other vulnerabilities, such as Karma-like attacks. See "TAD-2010-003: Full 802.11 Preferred Network List (PNL) disclosure in Windows Mobile 6.5".
	• 2G/3G: When the mobile device connects to a mobile network (2G or 2.5G: GPRS or EDGE) an attacker can intercept all your web traffic. You can protect your mobile data communications if you only connect to +3G data networks. For more information see the "GPRS/EDGE Security" blog post and the recent "A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications" BlackHat DC 2011 Taddong presentation, by David and Jose.

Independently of the data network access used by the mobile device, at some point the web traffic will enter on the public Internet in the clear (unencrypted), where it can be intercepted by anyone with access to capture the traffic on any of the intermediate network segments between the mobile device and Twitter.

The fact that Twitter credentials can be easily eavesdropped has a pretty significant impact, as most users assume other users credentials have not been hijacked, therefore, they blindly trust tweets (or microblog/blog posts) coming from trusted parties (their friends, people they frequently follow, public personalities...). Twitter account hijacking can be used for web-based & client-based targeted attacks (specially through the use of short URLs), and can cause a significant damage to the image and credibility of the victim user. 

While analyzing in-depth the affected HTC Peep version and the version associated to the temporary hotfix provided by HTC, we collected the following details from the Windows Mobile registry:

[HKEY_LOCAL_MACHINE\Software\OEM\MASD]
"Manila_Twitter"="2_5_19212224_0"

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\HotFix]
"Social_Networks_Engine_version"="20101005-00"
"Manila_Twitter_version"="20101005-00"
NOTE: Extract your own conclusions about the hotfix version number. Hint: It looks like a date.

-- Security solutions, workarounds, and countermeasures:

We think HTC should release a software update to change the vulnerable behavior in the HTC Peep mobile application, solving both credentials disclosure issues: the usage of HTTP Basic authentication versus pure OAuth capabilities, and the usage of HTTP versus HTTPS during the authentication process (and preferably, for the whole HTTP(S) session).

HTC has just confirmed (February 3, 2011 - 6pm CET) that an update is available, although it has not been released publicly. It will be delivered under request to any interested customer. If you are interested on the fix, you must contact HTC directly.  

Due to the absence of a public software update at this time (5 months since the initial notification), we strongly recommend users not to use HTC Peep to connect to Twitter. Users must evaluate the usage of HTC Peep as their preferred mobile Twitter client, and use other Twitter clients available for their HTC mobile device instead. There are multiple third-party Twitter clients for Windows Mobile (available through a simple Google search: "windows mobile twitter app (or client)") such as: ceTwit, GPS Twit, Jitter, Locify with Twitter, Pocket Tweet, PocketTwit, Quakk, SQIJ, TinyTwitter, Twibble, Twikini, TwitToday, Twitter2Go, Twitter Answers, Twitter deBolsillo, Twitula, Twobile, Viigo, or direct access to the official Twitter Mobile homepage (https://moblie.twitter.com/login) from a mobile web browser.
Disclaimer: These mobile Twitter applications have not been analyzed against these, similar, or other security vulnerabilities.

Users must avoid reusing their Twitter credentials in other services and applications (a common security best practice), as their Twitter username and password can be easily retrieved by an attacker. 

-- Vulnerable platforms:

HTC mobile devices running HTC Peep (HTC Peep is the default HTC Twitter client). HTC has confirmed HTC Peep is vulnerable at least in the following HTC mobile platforms: HD2, T-Mobile HD2, Topaz, Rhodium, and HD Mini.

Other mobile platforms running HTC Peep, based on Windows Mobile or other mobile operating system, such as Android (if available), could be affected too.

The vulnerability was discovered on an HTC HD2 mobile device running Windows Mobile 6.5 Professional and the built-in HTC Peep version ("2_5_19212224_0").

-- Vendor information:

HTC has confirmed the existence of this vulnerability and it is working to release a hotfix to solve the issue. The temporary hotfix provided was named "LEO_S01175" but it still discloses the Twitter credentials by using HTTP instead of HTTPS.

We at Taddong honestly believe this finding must be publicly known by the information security community in order to take appropriate countermeasures and mitigate the vulnerable behavior. Therefore, we have tried to coordinate the release of this security advisory together with the vendor, following responsible disclosure principles. This vulnerability is especially relevant considering the extensive number of HTC mobile devices available in the market and the potential impact of the associated attacks.

-- Vulnerability report timeline:

2010-08-21: Taddong tries to report the vulnerability to HTC through the standard channels (web, e-mail...) without success. 
2010-08-23: Taddong contacts other security researchers (Thanks Alberto!) previously involved in reporting vulnerabilities to HTC in order to identify a valid contact or notification channel to let HTC know about the issue.
2010-08-25: Taddong spends around a week trying to identify a secure channel to report the issue to HTC, without any success. Please, read "The Seven Deadly Sins of Security Vulnerability Reporting"!! [1]
2010-09-03: Taddong finally decides to notify HTC about the vulnerability through the only available (but insecure) web channel and sends a brief technical report.
2010-09-04: HTC confirms they "...will investigate (the issue) and get back to us as soon as they get a reply."
2010-09-19: Taddong contacts HTC again (after 15 days) emphasizing this is a serious issue that requires immediate action, as Twitter credentials are directly exposed. Taddong tried to get an estimated date when an update would be available in order to proceed to publicly and responsibly disclose the vulnerability.
2010-09-20: HTC replies and they "...apologize for the inconvenience and the delay. The case is being investigated and they will get back to us as soon as they get a reply."
2010-10-03: Taddong contacts HTC again (one month since the initial notification) in order to gather specific details, such as an official confirmation of the vulnerability and an estimated fix release date, trying to coordinate the publication of the associated advisory.
2010-10-10: No response was received from HTC. Taddong tries to contact HTC again (+1 week).
2010-10-22: HTC replies apologizing (again) for the delay and... asking for "all the details for further investigation"? Taddong replies and clarifies it is still waiting for a confirmation or any chance to discuss the technical details. At the same time, an estimated deadline is set by Taddong for the public release on November 4, 2010 (two months since the original notification).
2010-10-26: HTC clarifies the reason for its previous request (for further details), as it is still starting to "...check if there is in fact a vulnerability and try to reproduce it". Taddong replies back clarifying the details were provided on September 3, 2010, and offering again another brief technical description.
2010-11-06: Taddong contacts HTC again asking for the latest details or updates regarding the issue. The goal was to offer HTC an opportunity to step in prior to the public release, even delaying the previously set deadline (of Nov, 4), trying to be extremely responsible.
2010-11-08: HTC replies back informing Taddong that currently they are still analyzing it and will issue a notification on their website once they have reached a conclusion.
2010-11-21: Taddong informs HTC that plans to release the vulnerability to the public on Monday, December 6, 2010, and encourage them to contact us during the remaining two week period, as the best option would be having a fix/update ready in order to offer a solution to end users.
2010-11-22: HTC informs Taddong that the engineering department is investigating and finding a solution for this issue.
2010-12-01: Taddong asks HTC about the availability of (or future plans to get) a CVE ID for this issue prior to the final public disclosure, trying to coordinate both parties.
2010-12-02: HTC confirms the engineering department has been notified about the CVE proposal and will get back with a response (three months since the original notification).
2010-12-11: Due to the lack of a response, Taddong finally requests one (or two; this is left up to MITRE) CVE ID(s) to MITRE. The CVE ID request process is the reason for a new delay in the second proposed deadline for the public disclosure (Dec, 6).
2010-12-15: Taddong tries to confirm if the CVE ID request has been received by MITRE without success. Taddong never got a response from MITRE about the CVE ID request.
2010-12-16: HTC provides a hotfix for testing to Taddong (named "LEO_S01175").   
2010-12-17: Taddong replies back confirming that the hotfix solves the Basic authentication issue, as OAuth is the only authentication method used after applying the hotfix. However, still HTC Peep discloses the user credentials in the initial OAuth exchange through HTTP. Taddong suggests to use HTTPS for the whole Twitter session as the right solution (that would also solve other session-based attacks) and asks for the details of a future release.
2010-12-20: HTC confirms the suggested solutions have been notified to the engineering department, and that the fix is available for several models. Taddong requests details of the affected models.
2010-12-21: HTC confirms that the affected models include: HD2, T-Mobile HD2, Topaz, Rhodium, and HD Mini. There is no information yet about the web page where the update will be available.
2011-01-17: Taddong tries to gather details about the web page where the update will be available, as well as information about the pending issue, the credentials being disclosed through HTTP (vs. HTTPS). It is four and a half months since the original notification.
2011-01-18: HTC replies notifying they "haven’t received any further information yet (from engineering), and that they will resend our feedback regarding the update again and check with them if they will release any further upgrades soon".
2011-01-24: Taddong sets the final vulnerability advisory release for February 4, 2011 (in +10 days and five months since the initial notification), and notifies HTC accordingly, asking for HTTPS support over the hotfix functionality, and trying to retrieve the specific webpage where the update will be available to include it in the advisory. HTC confirmed the reception of this notification. Taddong sent an e-mail to MITRE trying, once again, to get one (or two) CVE IDs for these vulnerabilities.
2011-02-03: One day before publishing the advisory, Taddong contacts HTC and tries to gather details about the web page from where users could download a fix for this vulnerability, trying to include an official solution in the advisory. HTC replies back informing "...that for the time being the update hasn’t yet been released on the website however, any customer who wishes to download it can contact us and we will send it out to them". 
2011-02-04: Taddong publishes security advisory TAD-2011-001.

-- References:

[1] "The Seven Deadly Sins of Security Vulnerability Reporting". Raul Siles. Taddong. August 15, 2010.
http://blog.taddong.com/2010/08/seven-deadly-sins-of-security.html

-- About Taddong:

Taddong (www.taddong.com) is a company established in Spain in 2010 with the purpose of improving customer's information security, by discovering and eliminating or mitigating the real risks that threaten their networking and information technology infrastructures. To achieve this goal, Taddong's portfolio includes specialized information security services, requiring an in-depth technical knowledge and broad understanding of the information technology market, as well as training services, focused on providing customers with auto-defense skills. Taddong remains at the forefront of the security market through continuous research and education activities.

-- Disclaimer:

The contents of this security advisory are copyright (c) 2011 Taddong S.L., and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.






Download attachment "PGP.sig" of type "application/pgp-signature" (232 bytes)

Powered by blists - more mailing lists