Friday, April 18, 2014

Mobile considerations on Heartbleed (Android)


Heartbleed became quickly popular due to the risks it poses to SSL privacy model. In real life, exploits and proof of concepts around showed that it's practically possible to steel credentials and certificates from an affected server. Being involved in Mobile Security, one of the most recurring questions I hear is: how Heartbleed impacts mobile world?

Heartbleed is an OpenSSL vuln, the "need to go, I am tired but must code this before" type, the classical vuln introduced when developing in a hurry, tired before going home at the end of your working hours. Only affected systems are the ones running OpenSSL. The core problem is the unsafe handling of a length parameter passed into the heartbeat payload which allow leak of information from the target host memory (returning part of the target stack content). Without going into details, this site provides enough insights: http://heartbleed.com/

Strip iOS and Windows Mobile out of the picture, Android is the only one using OpenSSL in his public AOSP.

When I think of Heartbleed, I tend to consider it as Server vulnerability, especially when looking at the logic of a possible real attack. From a profit standpoint, I really struggle imaging a complex attack scenario targeting a mobile client. Will discuss this with much detail later.

Let's first answer the one million dollar question, is it Android vulnerable? It depends, and of course, keep OpenSSL version in consideration.

Here you have a list of vulnerable OpenSSL versions:
  • OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
  • OpenSSL 1.0.1g is NOT vulnerable
  • OpenSSL 1.0.0 branch is NOT vulnerable
  • OpenSSL 0.9.8 branch is NOT vulnerable
(Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug).

There is no point to get lost in the list, spend your time if you run a webserver or in general if you are exposing services based on OpenSSL (like SSL VPN software which should drive you crazy both server and client side). If your concern is Android, the two variables to play with are: version of OpenSSL and compile flag (-DOPENSSL_NO_HEARTBEAT).  Yes, the latter disables heartbeat functionalities at compile time, thus even if you are running on a vulnerable version, with the feature disabled you practically patched the issue at the root.

Now, let's go back to Android. Everything before version 4 (Ice Cream Sandwich) is running an old version of OpenSSL, not featuring heartbeat, thus clean and safe; end of the story, it was fast. Funny enough, against all my recommendations to avoid using pre-ICS versions, they are all not vulnerable. Android 4.0.0 and 4.0.4 (the first wide-spread ICS version) are running OpenSSL v1.0.0 which is again not vulnerable. Later versions are running on v1.0.1c. There we start worrying about it. 

All of a sudden, some enlightened engineer at Google decided that heartbeats are useless on a mobile client, who knows, it look like he knew about the vulnerability somehow :) (or at least detected something wrong in the piece of code) and disabled the feature at compile time starting from version 4.1.2. Said that, it looks that only Android 4.1.1 is vulnerable.

Andrew Blaich from Bluebox provided a table on his observations up to KitKat:


AOSP Version
OpenSSL Version
Vulnerable OpenSSL Version
Heartbeats Disabled
Overall Vulnerable
4.4.2_r2
1.0.1e
yes
yes
no
4.4.2_r1
1.0.1e
yes
yes
no
4.4
1.0.1e
yes
yes
no
4.3
1.0.1e
yes
yes
no
4.2.2
1.0.1c
yes
yes
no
4.2
1.0.1c
yes
yes
no
4.1.2
1.0.1c
yes
yes
no
4.1.1
1.0.1c
yes
no
yes
4.0.4
1.0.0e
no
n/a
no

Another important problem to consider, adds Andrew, is that there is plenty of Android Apps that embed their own version of OpenSSL. If you are doing something like that while developing your App or your BSP/ROM, it's time to update and/or patch, issue new certificates and all the jazz you heard about.

Let's flip the coin. As a user you should know if your Apps are making this 'savvy' move to use their own OpenSSL.

To solve the issue, BlueBox released a scanner, available on the play store, which will scan your APKs and give an answer. I guess it needs privileges to run through.


Heartbleed Scanner Screenshot


Now, there are other couple of points I wish to consider:
  • how many Android 4.1.1 are out there?
  • what about the real impact? looking at the attack surface and considering a possible scenario, what an hacker could do?

(1)

The 4th of April, Google on a blog post states exactly the same thing: only Android 4.1.1 JellyBean could be affected by Heartbleed.

Google's statistics only show that over one-third of Android users are on some version in the 4.1.X range though, leaving it unclear just how many devices are vulnerable. It's a relatively small portion of the market.
Ad network firm Chitika ran an analysis of North American Web traffic from April 7 to April 13 for the Guardian, which show that 19% of Jelly Bean users were running the vulnerable 4.1.1 version. Now, it's up to you to decide if 19% is a small portion.

For non-rooted Android users which are affected, there is no way to patch the issue. The solution is a ROM (or BSP firmware) upgrade. Updates are usually released by hardware vendor's, you probably know, at notable slow pace. We can easily conclude that vulnerable clients will be around for a while. Rooted users could start looking to patched versions of the lib or to make their own patch recompiling the same version of OpenSSL they are running from the AOSP and messing around with the phone filesystem.

(2)

As a matter of fact, yes, clients are vulnerable. So far the attention has been focused on servers as they are much more open and profitable to exploitation. I have the feeling that the scenario won't change. For sure, I see space for improvement in client exploitation.

IBM Security Services is investigating additional methods of exploiting this vulnerability that are emerging to include Reverse Heartbleed exploitation as well as possible amplification attacks. The IBM MSS SOC has been researching both reverse Heartbleed and the possibility of Heartbleed Datagram TLS (DTLS) amplification attacks. IBM MSS SOC contends both attacks are valid and possible. Although similar to the Heartbleed attack, the reverse Heartbleed targets clients using OpenSSL 1.0.1-1.0.1f.

This blog http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html describes the vulnerability from a source code standpoint. The bottom line message is that tls_process_heartbeat() is affected the same way of the more incriminated dtls_process_hearbeat(). This function is used also by client applications, thus not only servers are vuln as initially stated.

Due to the nature of the DTLS protocol and its use of UDP, there is the possibility of amplification attacks stemming from the use of DTLS. At this time, the SOC is unaware of any proof-of-concept code in the wild but will keep customers appraised as the situation develops. Xforce (IBM) is releasing IDPS updates for this vector at the time of this update. We will continue to incorporate IDPS coverage’s as they are released by their respective vendors.

I took this text out from the IBM Security Services MSS and ERS client report.

Without discussing too much development details, I found a module for metasploit to test the vulnerability, if you really need it when version crossed compile flag is not enough.

Another live tester for "reverse" vulnerability is here: https://reverseheartbleed.com/
I am mainly concerned about VPN clients that uses OpenSSL; that's would worth the exploitation efforts.

Marc Rogers, principal security researcher with mobile security vendor Lookout Inc., said that while millions of devices may technically be vulnerable to Heartbleed due to the inclusion of a vulnerable OpenSSL version, many such devices might not have the necessary heartbeats functionality enabled, making an attack impossible.

Sensitive clients, like VPN or privacy holding apps (banking apps, social media, and in general any cloud client) that may or may not use its own OpenSSL are intrinsically at risk to expose keys. Be careful, I am not saying that data is likely to be considered in clear. Besides that, what are the real impacts on a plain vanilla Android?

Attack scenarios are high impractical. I am thinking of a browser client exposed; the leak of info could affect the SSL keys in use on the same session (the page which exploits the client), not a big deal, or any other tabs open at the same time. In the latter case, the attack should be targeted to the specific service with some evident limitations on the exploitability scenario. Another way the vulnerability could be exploited client side is via MiTM attack, terrible fascinating again back from the old times. Don't forget that heartbleed is supposed to be exploitable only after SSL handshake, thus you'll need to find a way to cheat on certificates validation of the mobile device to get something out of a serious service.

Exploiting client-side is much more difficult than server-side, requires more targeted preparation and finally type and amount of leaked data could be "not that interesting" to hackers (there is a size limit on what can be stolen). At the moment of writing, I am not aware of successful client-side exploits implementations.


Heartbleed is definitely a serious vulnerability to take care of immediately.

No comments:

Post a Comment