Heartbleed and Mobile

Michael T. Raggo
Michael T. Raggo | April 24, 2014
Mobile Security

Now that most of the media hype around the OpenSSL Heartbleed vulnerability has subsided, I thought it would be good to review the vulnerability and provide additional guidance from a Mobile perspective to review the vulnerability and attack, as well as some proactive countermeasures provided by MobileIron.

Let's review how the attack works. There is currently Proof-of-Concept code in the wild today that allows an attacker to easily perform the attack, in fact it's simply one line of code that performs the exploit. Within TLS there is the support for DTLS (TLS over UDP - User Datagram Protocol) and a Heartbeat Extension. This Heartbeat Extension allows a keep-alive functionality for the connection without the need for renegotiation. When a user performs the attack on a vulnerable OpenSSL server, they send a packet with a larger than expected payload (i.e. custom payload). This then allows scraping of up to 64KB of memory from the web server outside the bounds of what Heartbeat is supposed to access. The following diagram outlines the attack:

How a Heartbleed attack works

As the diagram outlines, depending on the captured memory chunk, this can enumerate sensitive information stored in memory on the web server including passwords, data, and even the web server certificate's private key. If the first attempt is unsuccessful the attacker can simply run the attack a few more times to capture more information from memory. If the private key is captured, this can then be used to decrypt previously captured transmissions or existing transmissions to then reveal user credentials and additional data. It's important to note that this does not represent a fundamental flaw in the SSL/TLS protocol, but a bug in the OpenSSL implementation of the TLS/DTLS Heartbeat Extension itself.

The outlined remediation for this vulnerability is covered in the CVE and a plethora of other sites, but in summary involves patching OpenSSL on your particular server if found to be vulnerable. Our Knowledge-base article outlines the steps for identifying if your version of OpenSSL is vulnerable, and how to update it, more information can be found here.

It is important to note that foundational components of the MobileIron Infrastructure are not vulnerable to the attack including our VSP (management console), Sentry (Secure Mobile Gateway), ConnectedCloud, Anyware, and the MobileIron client. None of these product components are vulnerable. We also conducted a recent webinar reviewing this for our customers.

The MobileIron Platform

This may not be the last we hear of such vulnerabilities, so there are some additional ways you can further protect yourself from this attack from a proactive standpoint. The MobileIron Sentry (Secure Mobile Gateway) proactively protected our customers from the attack. For those customers that provide secure access to ActiveSync, Sharepoint, Fileshares, Web Servers, Apps, and more, these folks remain protected by their MobileIron Sentry. The MobileIron Sentry simply does not negotiate a Heartbeat request and thus any attempts at targeting servers running OpenSSL Servers behind the MobileIron Sentry remained protected. Many customers leverage the MobileIron AppTunnel (MobileIron-enabled or wrapped Apps) or our recently released MobileIron Tunnel (for native iOS 7 Apps) for secure access to these internal servers. This indirectly blocks other apps on the device, as well as other nefarious attacks like Heartbleed.

Protection form Heartbleed attacks

In summary, Mobile is different, and this is one of the many ways it's better, and more secure. Until next time, "may the force be with you."