Does your phone warn you when it is not encrypting your calls?

Looking at the following picture, do you know what the open lock icon, near the top left corner of the screen of the Nokia phone, mean?



In short, it means that the phone call is not being encrypted. But that being the case, shouldn't the iPhone be displaying a similar icon? (the call in progress in the picture was established between the two phones). Keep on reading, and you will see that there is more to it than meets the eye.

GSM usually encrypts your calls to protect your privacy, and the same goes for your GPRS/EDGE data connections. Now, GSM has many security problems, but for the purpose of this discussion, let us concentrate on the "usually" part in the above sentence.

The GSM specification gives full control to the network to select the encryption algorithm to be used to protect the communications on the radio interface, choosing from a set of supported algorithms, which nowadays in most cases include only two choices: A5/1, which is the most commonly used encryption algorithm in GSM networks (already broken, but that's another story), and A5/0, which is an euphemism for no-encryption-at-all. Thus, the network can choose to encrypt, or not, your communications.

Most GSM operators do encrypt their subscribers' communications, but some may choose not to do it, and in some countries, like India, they may even be required by law not to use encryption. Making things even more worrisome, an attacker can very easily set up a rogue GSM base station, pretending to belong to your usual network operator, and route all your calls and data connections, unencrypted, through his base station.

So, you cannot decide whether the communication will be encrypted or not. But, could you, at least, KNOW if your communication is being encrypted or not?

The GSM specification states that you, the user, "should" be informed by your mobile device when the communication is not encrypted (3GPP Rel.9 TS 33.102-920 "3G Security Architecture" 5.5.1 Visibility):

"Although in general the security features should be transparent to the user, for certain events and according to the user's concern, greater user visibility of the operation of security features should be provided. This yields to a number of features that inform the user of security-related events, such as: indication of access network encryption: the property that the user is informed whether the confidentiality of user data is protected on the radio access link, in particular when non-ciphered calls are set-up; [...] The ciphering indicator feature is specified in 3GPP TS 22.101 [...]"

The referenced 3GPP TS 22.101 specification (R99 22.101-3.17.0), on section 13, "Types of features of UEs", says:

"The basic mandatory UE requirements are: [...] - Ciphering Indicator for terminals with a suitable display; The ciphering indicator feature allows the ME to detect that ciphering is not switched on and to indicate this to the user. The ciphering indicator feature may be disabled by the home network operator setting data in the SIM/USIM. If this feature is not disabled by the SIM, then whenever a connection is in place, which is, or becomes unenciphered, an indication shall be given to the user. Ciphering itself is unaffected by this feature, and the user can choose how to proceed;"

Interesting! So, according to the specification, our mobile devices should tell us that the communication is not encrypted and we should be allowed to choose how to proceed, unless our SIM card were configured to disable this feature. However, is that how it is in real life?

In a little experiment we did in our lab, we took 2 SIM cards from 2 different network operators, let us call them Operator1 and Operator2, and we inserted them in the phones you saw in the previous picture, an old (2004) Nokia 6230, and a more recent (2008) iPhone 3G. Then, we established a call between them, using our own base station with A5/0, that is, no encryption, and the result was the one depicted in the previous picture: the old Nokia phone displayed the open lock icon, indicating that the call was not being encrypted, while the iPhone did not show any indication of this fact.

Then, we swapped the SIM cards between the two phones, and established again a call between them. The result: this time neither the Nokia 6230 nor the iPhone 3G displayed any indication of the call not being encrypted, as you can see in the following picture:



The conclusions we can draw from this little experiment are:

• the Nokia 6230 will show an open lock icon when a call is not encrypted, unless the SIM card disables this feature,


• the iPhone 3G will never notify the user about a call not being encrypted,


• the SIM card from Operator1 (inserted in the Nokia Phone in the first picture) does not disable the ciphering indicator, and


• the SIM card from Operator2 (inserted in the Nokia Phone in the second picture) disables the ciphering indicator

Think about it for a second, and then try again to answer the question in the title of this article: does your phone warn you when it is not encrypting your calls?

<plug>
If you want to find out, bring your mobile phone and SIM card to our GSM/UMTS (2G/3G) SECURITY training course, and you will be able to test it yourself! Sessions available in English and in Spanish!
</plug>

Vulnerability in HTC Peep: Twitter Credentials Disclosure

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
Last update: March 17, 2011 - FOTA fixes released by HTC for Tattoo & Hero. See timeline and (UPDATE2) marks.
Previous updates: February 14, 2011 - Fix released by HTC and validated by Taddong. See timeline and (UPDATE) marks.
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 (LEO_S01175.exe), 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.

(UPDATE) While validating the software update released by HTC on February 10, 2011, the version associated to the final hotfix (LEO_S01236.exe), replaces the following details on the Windows Mobile registry:

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\HotFix] "Social_Networks_Engine_version"="20110208-00" "Manila_Twitter_version"="20110208-00"

NOTE: It is a date ;)

Security solutions, workarounds, and countermeasures:
(UPDATE2) HTC has publicly released a couple of FOTA (Firmware Over-The-Air) fixes or updates [3] for HTC Tattoo and HTC Hero associated to the HTC Peep Client. Please note that these two HTC mobile devices are not based on Windows Mobile but on Android.

(UPDATE) HTC has publicly released a hotfix [2] that forces HTC Peep not to use HTTP Basic authentication but OAuth during the whole Twitter session, and that performs the authentication process over HTTPS (versus HTTP) against the "api.twitter.com" service on port TCP/443, not disclosing the user credentials for the Twitter service. However, after completing the OAuth authentication process over HTTPS, HTC Peep switches to HTTP for the remaining of the Twitter session, making the unencrypted session vulnerable to HTTP session hijacking attacks based on eavesdropping Twitter's session id (e.g. cookies). 

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.

(UPDATE2) A new hotfix is available for HTC Tattoo & HTC Hero [3]. 

(UPDATE) The final hotfix is available for HTC Touch Pro2/HTC HD2/HTC Touch Diamond2/HTC HD mini [2].

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.

(UPDATE2) On March 11, 2011, HTC released a hotfix for the HTC Peep Client in the form of a FOTA update for HTC Tattoo and HTC Hero, both based on Android [3]. The build numbers after installing the updates will be 1.67.405.70 (for Tattoo) and 3.36.405.1 (for Hero): "From the Home Screen go to MENU> Settings> About Phone> Software Information> Software number".

(UPDATE) On February 10, 2011, HTC released a hotfix for this HTC Peep credentials disclosure security vulnerability for HTC Touch Pro2/HTC HD2/HTC Touch Diamond2/HTC HD mini [2]. The hotfix filename for the various HTC models varies: LEO_S01236.exe (HD2), PHO03880.exe (HD mini), RHO_S2_00923.exe (Touch Pro2), and TOP_S2_00478.exe (Touch Diamond2).

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.
2011-02-04: (11:30pm CET) Bugtraq ID assigned: 46153.
2011-02-10: (UPDATE) HTC releases on its support website the fix for the HTC Peep credentials disclosure security vulnerability. The fix for the following models, HTC Touch Pro2/HTC HD2/HTC Touch Diamond2/HTC HD mini, is available at http://www.htc.com/europe/SupportViewNews.aspx?dl_id=1085&news_id=866 [2].
2011-02-14: (UPDATE) Taddong validates the fix on a HTC HD2 device and updates this advisory accordingly.
2011-03-11: (UPDATE2) HTC released a new update for HTC Tattoo and HTC Hero, both based on Android (and not Windows Mobile).
2011-03-17: (UPDATE2) Taddong updates this advisory with the new Android-based hotfixes.

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
[2] "Update for HTC Touch Pro2/HTC HD2/HTC Touch Diamond2/HTC HD mini Peep Security update". HTC. February 10, 20111.
http://www.htc.com/europe/SupportViewNews.aspx?dl_id=1085&news_id=866
[3] "HTC Support (Europe)". HTC. March 11, 2011.
http://www.htc.com/europe/support.aspx

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.