SSL Vulnerabilities: Who listens when Android applications talk?


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.


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


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 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.


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.


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.

If an Android Has a Heart, Does It Bleed?

The OpenSSL Heartbleed vulnerability “allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read” [1]. Heartbleed surprised the public by allowing attackers to steal sensitive information from vulnerable websites by sending crafted SSL heartbeat messages. However, due to the fact that servers can send heartbeats to clients as well, malicious servers can, in turn, attack vulnerable clients and steal sensitive information. For the Android platform, we find that roughly 150M downloads of Android apps contain OpenSSL libraries vulnerable to Heartbleed.

Currently there are about 17 antivirus apps on Google Play branded as “Heartbleed detectors”. Six of them scan the OpenSSL library belonging to the Android platform for vulnerabilities. Unfortunately, this method isn’t sufficient for detecting the Heartbleed vulnerability on Android. Except in limited Android versions (mainly 4.1.0-4.1.1), the majority of Android platforms are not vulnerable, as most versions use OpenSSL libraries that are not vulnerable or simply have the OpenSSL heartbeat functionality disabled.

However, Android apps frequently use native libraries, which either directly or indirectly leverage vulnerable OpenSSL libraries. Therefore, even though the Android platform itself is not vulnerable, attackers can still attack those vulnerable apps. They can hijack the network traffic, redirect the app to a malicious server and then send crafted heartbeats messages to the app to steal sensitive memory contents.

We studied apps with vulnerable OpenSSL libraries and confirmed this attack. Most of the vulnerable apps are games, and some are office-based applications. Although there is not much valuable information in the game apps, attackers can steal OAuth tokens (access tokens and refresh tokens) to hijack the game accounts; as such, the information might be useful for hijacking those linked social network accounts with incorrect configurations. Office apps vulnerable to Heartbleed are much more dangerous due to further potential data leakage.

During our investigation of the office apps that contains a vulnerable version of OpenSSL, we were surprised that they were not vulnerable to the Heartbleed attack. How could it be? A deeper look shows that these apps either make a mistake in the native code linkage, or just contain dead code. Therefore, when they try to invoke SSL functions, they directly use the non-vulnerable OpenSSL library contained within the Android OS, instead of using the vulnerable library provided by the app. The linkage mistake is common for Android applications built with native code. As such, the side-effect of this mistake helps reduce the apps’ overall risk profile.

Within the 17 Heartbleed detector apps on Google play, only 6 detectors check installed apps on the device for Heartbleed vulnerability. Within the 6, 2 report all apps installed as “Safe”, including those we confirmed as vulnerable. One detector doesn’t show any app scan results and another one doesn’t scan the OpenSSL version correctly. Only 2 of them did a decent check on Heartbleed vulnerability of apps. Although they conservatively labeled some non-vulnerable apps as vulnerable, we agree it is a viable report which highlights both the vulnerabilities and the linkage mistakes. We’ve also seen several fake Heartbleed detectors in the 17 apps, which don’t perform real detections nor display detection results to users and only serve as adware.

On April 10th, we scanned more than 54K Google Play apps (each with over 100K downloads) and found that there were at least 220 million downloads affected by the Heartbleed vulnerability. We have notified some of the app developers and library vendors about the OpenSSL Heartbleed vulnerability found in their products. Fortunately, it seems most app developers and library vendors take Heartbleed seriously, as we have started to see apps updated with proper fixes. The total number of vulnerable apps download has since decreased to 150 million on April 17th.

[1] Vulnerability Summary for CVE-2014-0160

Occupy Your Icons Silently on Android

FireEye mobile security researchers have discovered a new Android security issue: a malicious app with normal protection level permissions can probe icons on Android home screen and modify them to point to phishing websites or the malicious app itself without notifying the user. Google has acknowledged this issue and released the patch to its OEM partners.

Normal vs. Dangerous Permissions: A Background

Android Open Source Project (AOSP) classifies Android permissions into several protection levels: “normal”, “dangerous”, “system”, “signature” and “development” [1][2][3].

Dangerous permissions “may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities”. In contrast, normal permissions are automatically granted at installation,  “without asking for the user's explicit approval (though the user always has the option to review these permissions before installing)” [1].

On the latest Android 4.4.2 system, if an app requests both dangerous permissions and normal permissions, Android only displays the dangerous permissions, as shown in Figure 1. If an app requests only normal permissions, Android doesn’t display them to the user, as shown in Figure 2.

Figure 1. An Android app asks for one dangerous permission (INTERNET) and some normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS). Android doesn’t notify the user about the normal permissions.

Figure 1. An Android app asks for one dangerous permission (INTERNET) and some normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS). Android doesn’t notify the user about the normal permissions.

Figure 2. An Android app asks for normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS) only. Android doesn’t show any permission to the user.

Figure 2. An Android app asks for normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS) only. Android doesn’t show any permission to the user.

Normal Permissions Can Be Dangerous

We have found that certain “normal” permissions have dangerous security impacts. Using these normal permissions, a malicious app can replace legit Android home screen icons with fake ones that point to phishing apps or websites.

The ability to manipulate Android home screen icons, when abused, can help an attacker deceive the user. There’s no surprise that the permission, which allows an app to create icons, was recategorized from “normal” to “dangerous” ever since Android 4.2. Though this is an important security improvement, an attacker can still manipulate Android home screen icons using two normal permissions: and These two permissions enable an app to query, insert, delete, or modify the whole configuration settings of the Launcher, including the icon insertion or modification. Unfortunately, these two permissions have been labeled as “normal” since Android 1.x.

As a proof of concept attack scenario, a malicious app with these two permissions can query/insert/alter the system icon settings and modify legitimate icons of some security-sensitive apps, such as banking apps, to a phishing website. We tested and confirmed this attack on a Nexus 7 device with Android 4.4.2. (Note: The testing website was brought down quickly and nobody else ever connected to it.) Google Play doesn’t prevent this app from being published and there’s no warning when a user downloads and installs it. (Note: We have removed the app from Google Play quickly and nobody else downloaded this app.)

Lastly, this vulnerability is not limited to Android devices running AOSP. We have also examined devices that use non-AOSP Launchers, including Nexus 7 with CyanogenMod 4.4.2, Samsung Galaxy S4 with Android 4.3 and HTC One with Android 4.4.2. All of them have the protection levels of and WRITE_SETTINGS as “normal”.

Google acknowledged this vulnerability and has released the patch to its OEM partners. Many android vendors were slow to adapt security upgrades. We urge these vendors to patch vulnerabilities more quickly to protect their users.



JS-Binding-Over-HTTP Vulnerability and JavaScript Sidedoor: Security Risks Affecting Billions of Android App Downloads

Third-party libraries, especially ad libraries, are widely used in Android apps. Unfortunately, many of them have security and privacy issues. In this blog, we summarize our findings related to the insecure usage of JavaScript binding in ad libraries.

First, we describe a widespread security issue with using JavaScript binding (addJavascriptInterface) and loading WebView content over HTTP, which allows a network attacker to take control of the application by hijacking the HTTP traffic. We call this the JavaScript-Binding-Over-HTTP (JS-Binding-Over-HTTP) vulnerability. Our analysis shows that, currently, at least 47 percent of the top 40 ad libraries have this vulnerability in at least one of their versions that are in active use by popular apps on Google Play.

Second, we describe a new security issue with the JavaScript binding annotation, which we call JavaScript Sidedoor. Starting with Android 4.2, Google introduced the @JavascriptInterface annotation to explicitly designate and limit which public methods in Java objects are accessible from JavaScript. If an ad library uses @JavascriptInterface annotation to expose security-sensitive interfaces, and uses HTTP to load content in the WebView, then an attacker over the network could inject malicious content into the WebView to misuse the exposed interfaces through the JS binding annotation. We call these exposed JS binding annotation interfaces JS sidedoors.

Our analysis shows that these security issues are widespread, have affected popular apps on Google Play accounting for literally billions of app downloads. The parties we notified about these issues have been actively addressing them. Continue reading »

Monitoring Vulnaggressive Apps on Google Play

Vulnaggressive Characteristics in Mobile Apps and Libraries

FireEye mobile security researchers have discovered a rapidly-growing class of mobile threats represented by popular ad libraries affecting apps with billions of downloads. These ad libraries are aggressive at collecting sensitive data and able to perform dangerous operations such as downloading and running new code on demand. They are also plagued with various classes of vulnerabilities that enable attackers to turn their aggressive behaviors against users. We coined the term “vulnaggressive” to describe this class of vulnerable and aggressive characteristics. We have published some of our findings in our two recent blogs about these threats: “Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions” and “Update: Ad Vulna Continues”.

As we reported in our earlier blog “Update: Ad Vulna Continues”, we have observed that some vulnaggressive apps have been removed from Google Play, and some app developers have upgraded their apps to a more secure version either by removing the vulnaggressive libraries entirely or by upgrading the relevant libraries to a more secure version which address the security issues. However, many app developers are still not aware of these security issues and have not taken such needed steps. We need to make a community effort to help app developers and library vendors to be more aware of these security issues and address them in a timely fashion.

To aid this community effort, we present the data to illustrate the changes over time as vulnaggressive apps are upgraded to a more secure version or removed from Google Play after our notification. We summarize our observations below, although we do not have specific information about the reasons that caused these changes we are reporting. Continue reading »

Update: Ad Vulna Continues

This is an update to our earlier blog “Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions”.

Since our last notification to Google and Ad Vulna (code name for anonymity), we have noticed a number of changes to the impacted apps that we reported to both companies. We summarize our observations below, although we do not have specific information about the reasons that caused these changes we are reporting.

First, a number of these vulnaggressive apps and their developers’ accounts have been removed from Google Play, such as app developer “Itch Mania”. The total number of downloads of these apps was more than 6 million before the removal. While removing these apps from Google Play prevents more people from being affected, the millions of devices that already downloaded them remain vulnerable. Continue reading »

Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions

FireEye researchers have discovered a rapidly-growing class of mobile threats represented by a popular ad library affecting apps with over 200 million downloads in total. This ad library, anonymized as “Vulna,” is aggressive at collecting sensitive data and is able to perform dangerous operations such as downloading and running new components on demand. Vulna is also plagued with various classes of vulnerabilities that enable attackers to turn Vulna’s aggressive behaviors against users. We coined the term “vulnaggressive” to describe this class of vulnerable and aggressive characteristics. Most vulnaggresive libraries are proprietary and it is hard for app developers to know their underlying security issues. Legitimate apps using vulnaggressive libraries present serious threats for enterprise customers. FireEye has informed both Google and the vendor of Vulna about the security issues and they are actively addressing it.

Recently FireEye discovered a new mobile threat from a popular ad library that no other anti-virus or security vendor has reported publicly before. Mobile ad libraries are third-party software included by host apps in order to display ads. Because this library’s functionality and vulnerabilities can be used to conduct large-scale attacks on millions of users, we refer to it anonymously by the code name “Vulna” rather than revealing its identity in this blog. Continue reading »