+ 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.
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
