Jump to content

Blog

Shield

SSL Vulnerabilities: Who listens when Android applications talk?

Summary

The Android ecosystem is all about communicating, and right now it’s screaming for help. That’s because SSL vulnerabilities and the Man-In-The-Middle (MITM) attacks they enable are wreaking havoc on data security. The scariest part? SSL vulnerabilities are evident in many of today’s most popular applications as we recently uncovered.

The FireEye Mobile Security Team analyzed Google Play’s most downloaded Android applications and found that a significant portion of them are susceptible to MITM attacks. These popular apps allow an attacker to intercept data exchanged between the Android device and a remote server. We notified the developers, who acknowledged the reported vulnerabilities and addressed them in subsequent versions of their applications.

Our researchers also constructed a MITM attack demonstration for each of the case studies in this blog. We did not use the infrastructure to glean any private or personal information of any user, other than that of the synthetic user we created to demonstrate the applications mentioned.

Introduction

Mobile applications often talk to remote servers for their functionality. Applications can communicate using the HTTP protocol, which makes it easy for others to intercept data, or the HTTPS protocol – which makes it harder, if not impossible, to intercept data. The security properties of HTTPS stem from Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS).

The Android platform provides libraries and methods to communicate with a server using these secure network protocols, forming the underpinnings of Public-Key Infrastructure (PKI). But, while the SSL/TLS protocol is designed for enhanced security, incorrect use of the Android platform’s SSL libraries can expose applications to MITM attacks. In these attacks, an MITM attacker intercepts traffic from the application to a server or vice versa and may:

  • be a quiet listener that exfiltrates data sent either by the application or by the server,
  • intercept data from the server and either modify or replace it with malicious data that gets injected into the application, and
  • redirect traffic to an entirely new destination controlled by the attacker.

For a clearer explanation of MITM attacks, at the end of this blog we included a detailed walkthrough of the attack mechanics .

Detecting SSL Vulnerabilities in Android

The following is a subset of the SSL/TLS vulnerabilities that we analyzed using our Mobile Threat Prevention platform:

  • The use of trust managers that do not check certificate chains from remote servers, making it possible for an MITM attack to succeed.
    • Verifying certificates to ensure that they are signed by a known and trusted Certifying Authority (CA) is an integral part of certificate- based, client-server communication.
  • The replacement of platform hostname verifiers by application hostname verifiers that do not verify the hostname of the remote server.
    • Having a trust manager that checks certificates is not sufficient in this case, as the attacker may have a certificate signed by a trusted certifying authority and may present a valid certificate chain. Therefore, to prevent a MITM attack, the hostname of the server extracted from the CA-issued certificate must match the hostname of the server the application intends to connect,
  • Applications ignoring SSL errors when they use WebKit to render server pages in mobile applications.
    • With server communications that use SSL/TLS, any errors generated should be caught. Otherwise we open up the vulnerable applications to MITM attacks that may exploit vulnerabilities such as Javascript Binding Over HTTP (JBOH).

SSL Vulnerabilities in the Google Play 1,000 Most Downloaded Applications

We reviewed the 1,000 most-downloaded free applications in the Google Play store as of July 17, 2014. Of these, 674 (~68%) have at least one of the three SSL vulnerabilities that we studied. In Figure 1, we present the number of vulnerable applications we found in each category:

  • Using trust managers that do not check certificates
    • Of the 614 applications that use SSL/TLS to communicate with a remote server, 448 (~73%) do not check certificates
  • Using hostname verifiers that do nothing
    • 50 (~8%) use their own hostname verifiers that do not check hostnames
  • Ignoring SSL errors in Webkit
    • Of the 285 that use Webkit, 219 (~77%) ignore SSL errors generated in Webkit

androidssl1

Figure 1. SSL vulnerabilities in the Google Play top 1000 applications

SSL Vulnerabilities at Large

We analyzed roughly 10,000 applications from the Google Play store. This was a random sample of free applications. Roughly 4,000 (40%) use trust managers that do not check server certificates, exposing any data they exchange with their servers to potential theft. Furthermore, around 750 (7%) applications use hostname verifiers that do not check hostnames, implying that they are incapable of detecting redirection attacks where the attacker redirects the server request to a malicious webserver controlled by the attacker. Finally, 1,300 (13%) do not check SSL errors when they use Webkit.

Case Studies (Applications rendered vulnerable due to vulnerable libraries)

Applications may use third-party libraries to enable part of their functionality. When these libraries have baked-in vulnerabilities, they are particularly dangerous because they make all applications that use them, and frequently the devices that run them, vulnerable. Furthermore, these vulnerabilities are not weaknesses in the applications themselves, but in the features they rely upon for functionality.

Flurry. Flurry is the number-one ranked ad library in the market used by 9,702 out of 70,000+ Google Play apps with 50,000 or more downloads. These applications have been downloaded over 8.7 billion times. As with many ad libraries, Flurry (prior to version 3.4) uses HTTPS with a vulnerable trust manager to upload information like device IMEI and location.

In a proof of concept for an MITM attack, we successfully used a vulnerable version of Flurry to capture the information sent to the remote server https://data.flurry.com. We successfully matched the location of the simulation device against the data being sent by Flurry. In Figure 2, we show a hexdump of the data we captured during this MITM attack.

Ad libraries enable the delivery of targeted advertisements by transmitting sensitive user information, but it is essential that they use HTTPS to send it in a manner that protects against MITM attacks.  The potential privacy breach is compounded when users are unaware of the ad libraries used and how their personal information can be read by unintended recipients.

androidssl2

Figure 2. Hexdump of the data that is being sent using insecure HTTPS

The presence of this vulnerability was communicated to the Flurry developers. They acknowledged the vulnerability was addressed starting in version 3.4 of the ad library.

Chartboost. Chartboost is an ad library used by 5,170 of 70,000+ Google Play apps with 50,000 or more downloads. The aggregate download count for all these applications is over 4.5 billion. Chartboost also used a trust manager that is vulnerable to MITM attacks. In this experimental setup, we intercepted traffic that contains the device IMEI sent over SSL/TLS sockets. While Chartboost has addressed this vulnerability after version 2.0.1, a number of applications with over 5 million downloads in the Google Play store still use vulnerable versions of Chartboost.

The presence of these vulnerabilities was communicated to the developers of Chartboost. They acknowledged that the vulnerability was addressed in a release subsequent to 2.0.1 of the ad library.

Case Studies (Applications that are inherently vulnerable)

Camera360 Ultimate. This is an application that has more than 250 million downloads worldwide. The following is the description of the application from the Google Play store.

Camera360, loved by more than 250 million users globally, is No.1 camera app in many countries. Together with HelloCamera, Movie360, and Pink360, Camera360 provides a comprehensive suite of professional yet fun mobile photography options.
To make your life even easier, Camera360 has introduced Camera360 Cloud, a cloud platform that can help you manage, edit, store, and share your photos all in one place. Join the millions of users in enjoying these FREE services!

Besides inheriting SSL vulnerabilities from the ad libraries used by the application, none of the application’s trust managers uses check server certificates. In another proof-of-concept for an MITM attack that exploits these vulnerabilities, we intercepted all HTTPS traffic between the application and the remote servers it used, allowing us to potentially:

  1. Steal or inject photos/albums at random;
  2. Steal user’s login “local key” to the Camera360 cloud, and many other local device/user specifications (device model, android version, user nickname, user email account, etc.); and
  3. Intercept user credentials (Facebook, Twitter, Sina, QQ, etc.), or inject fake login pages/malicious Javascript to steal any account credentials.

The app has Javascript Binding Over HTTP (JBOH) together with many powerful permissions (camera, audio recording, video recording, etc.), which opens the door to even more sophisticated attacks.

These vulnerabilities were communicated to the Camera360 developers, who were highly proactive in fixing the reported issues and releasing an update addressing them on July 29, 2014.

Application “X”. This application has over 100M downloads and is one of the fastest-growing applications in the Google Play marketplace. Similar to Camera360, Application “X” does not check server certificates when establishing SSL connections. This app’s core functionality pushes images of interest to users. This functionality can be hijacked using an MITM attack, allowing a hacker to inject malicious images into the application, launch a denial of service attack, or worse yet, hold a user’s data for ransom using a DOS attack.

Repeated attempts to contact the developers of Application “X” went unanswered. We therefore chose to anonymize the name of the application until a fix is put in place.

Best Practices

For a detailed explanation of common SSL pitfalls and ways to alleviate them, please see Android Security-SSL. Any application connecting to a third-party web service is likely automatically able to verify server certificates and hostnames.  These platforms usually have more than 100 CAs, and will validate any third-party server that presents a certificate signed by any of them.

If the server certificate is self-signed or comes from a CA the Android platform doesn’t trust, it requires the attention of the application developer. In these cases, the steps to use a custom trust manager are as follows:

  1. Create a KeyStore and set its certificate entry to the certificate to authenticate against
  2. Initialize a TrustManager instance with the KeyStore
  3. Use this instance of the TrustManager class in SSLContext objects used to establish remote server connections

Mobile device users can protect themselves by not accessing websites that require user login credentials when using public wi-fi networks. This in itself, with general vigilance in opening emails from unknown sources, will go a long way in protecting sensitive information from MITM attacks.

We hope that publications like this encourage application developers to stay current on the versions of third-party libraries they use, and to talk to the developers of third-party libraries to ensure the end users’ privacy is not compromised through backdoors.

Acknowledgments: We would like to thank Tao Wei and Dawn Song for their technical inputs that lead to developing of the SSL vulnerability detection capability, and Rebecca Stroder, Kyrksen Storer and the team behind the FireEye Mobile Threat Prevention Platform for their feedback. We also acknowledge the developers of Camera360 Ultimate, Flurry, and Chartboost for being proactive in fixing all reported issues.

Appendix: MITM Attacker and the Mechanics of an MITM Attack

As shown in Figure 3, a Man-In-The-Middle (MITM) attack works as follows:

  • Alice initiates a conversation with Bob
  • Mallory intercepts the conversation and relays the request to Bob
  • Bob responds, Mallory intercepts the response and forwards it to Alice

Neither Alice nor Bob are aware of Mallory’s presence. In our scenario, Alice is an Android application and Bob is the remote server. Mallory is a Man-In-The-Middle attacker with Internet access. Correct use of the platform SSL/TLS library would prevent Mallory from masquerading as Bob in his communication with Alice, and as Alice in her communication with Bob.

androidssl3

Figure 3. A Man-In-The-Middle attack flow

An MITM attacker has access to the Internet and controls a network proxy to direct all traffic originating from a network, such as a wi-fi network, to the Internet. Setting up an MITM attack is as easy as having access to the network proxy and using an off-the-shelf MITM proxy in place of a standard proxy. A standard proxy is limited to setting up an opaque conduit for all communication with no mechanism to read the data that is actually sent. An MITM proxy, on the other hand, plays the role of Mallory in Figure 3, masquerading as the remote server to mobile clients and as the mobile client to the remote server. Public wi-fi networks such as those in airports, cafes, etc., are open to exploitation by such MITM attackers. These networks use basic configurations without firewalls, VPNs, or intrusion detection systems. Attackers build open networks to snoop data that passes between user devices and remote servers. Sophisticated MITM attackers may use phishing emails to change a user’s device configurations, directing all Internet traffic originating from the device to a proxy server they control.

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>