In an earlier blog post, we mentioned that mobile apps are also affected by the Heartbleed vulnerability. This is because mobile apps may connect to servers affected by the bug. However, it appears that mobile apps themselves could be vulnerable because of a bundled OpenSSL library.

OpenSSL Library Present in Android 4.1.1 and Certain Mobile Apps

We have information that although the buggy OpenSSL is integrated with the Android system, only the Android 4.1.1 version is affected by Heartbleed vulnerability. For devices with that version, any app installed with OpenSSL which is then used to establish SSL/TLS connections is possibly affected and can be compromised to get user information from the device memory.

However, even if your device is not using the affected version, there is still the matter of the apps themselves. We have found 273 in Google Play which are bundled with the standalone affected OpenSSL library, which means those apps can be compromised in any device.

In this list, we see last year’s most popular games, some VPN clients, a security app, a popular video player, an instant message app, a VOIP phone app and many others. As you may well know, the OpenSSL library is used by apps for secure communications. Lots of apps are from top developers. We also found the vulnerability in the older versions of Google’s apps.

Figure 1. Apps vulnerable to Heartbleed include those that are highly popular

These apps statically link to the vulnerable OpenSSL library as shown below:

Figure 2. Vulnerable OpenSSL Library

A reverse client-side Heartbleed attack is possible if the remote servers those apps connect to are compromised. A reverse Heartbleed can of course also expose user device memory to a cybercriminal. The memory may contain any sensitive information stored in these apps locally. If you use a vulnerable VPN client or VOIP app to connect to an evil service, you may lose your private key or other credential information, then the hacker may forge your identity and do other bad things from there.

We advise the app developer to hasten the speed to upgrade the OpenSSL library, and publish them to end-users. For general users, you need to be aware of the fact that your clients are able to leak information, no matter how secure the remote server is, or the good reputation or trustworthiness of the app developer. You should also update your apps as soon as a fix is made available. Google is currently distributing patching information for the affected Android version—you should also check if an update is made available for your device.

We will also be creating a tool very soon to check if your apps are vulnerable.

An Update on Apps Connecting to Servers Vulnerable to Heartbleed

After we disclosed about the mobile apps connecting to vulnerable servers, we continued to monitor them. We have seen up to 7,000 apps at the time of monitoring that are connecting to Heartbleed-vulnerable servers, while in our latest verification, around 6,000 apps are still affected. Let’s see what types of mobile apps they are:

Figure 3. Distribution of Mobile Apps Vulnerable to Heartbleed, by Category

For discussion purposes, we highlight only the app categories that we consider possibly sensitive in that they may store users’ private information on the server, which means users may be leaking information by using these apps. We see that a large portion of these kinds of apps are Lifestyle apps. These apps include anything from ordering food, grocery items, equipment, reading books, couponing, clothing, furniture, etc. This also means that if a user for instance orders food or supplies through one of these affected apps, information about their order, including user credentials, their home address—or worse, their credit card information—can be leaked.

Note that we have informed Google about this issue.

For other posts discussing the Heartbleed bug, check these other posts:

• Trend Micro Heartbleed Detector Now Available
• Heartbleed Bug—Mobile Apps are Affected Too
• Heartbleed Vulnerability Affects 5% of Select Top Level Domains from Top 1M
• Skipping a Heartbeat: The Analysis of the Heartbleed OpenSSL Vulnerability

The severity of the Heartbleed bug has led countless websites and servers scrambling to address the issue. And with good reason—a test conducted on Github showed that more than 600 of the top 10,000 sites (based on Alexa rankings) were vulnerable. At the time of the scanning, some of the affected sites included Yahoo, Flickr, OKCupid, Rolling Stone, and Ars Technica.

All the extended coverage of the flaw begs the question, “Are mobile devices affected by this?” The short answer: yes.

Mobile apps, like it or not, are just as vulnerable to the Heartbleed Bug as websites are because apps often connect to servers and web services to complete various functions. As our previous blog entry has shown, a sizable number of domains are affected by this vulnerability.

Suppose you’re just about to pay for an in-app purchase, and to do so you need to input your credit card details. You do so, and the mobile app finishes the transaction for you. While you’re getting on with your game, your credit card data is stored in the server that the mobile app did the transaction with, and may stay there for an indeterminate period of time. As such, cybercriminals can take advantage of the Heartbleed bug to target that server and milk it of information (like your credit card number). It’s as simple and easy as that.

What about apps that don’t offer in-app purchases? Are they safe from this vulnerability? Not really—as long as it connects to an online server, it’s still vulnerable, even if your credit card isn’t involved. For example, your app could ask you to ‘like’ them on a social network, or ‘follow’ them on yet another for free rewards.

Suppose you decide to do so, and tap ‘OK’. Chances are your app will open the website on their own, through their own in-app browser, and have you log into the social network there. While we’re not saying the social networks you go are vulnerable to the Heartbleed bug, the possibility is there, and thus the risk is there as well.

We looked deeper into the matter, and inspected some web services used by popular mobile apps and the results show that the vulnerability still exists.

We scanned around 390,000 apps from Google Play, and found around 1,300 apps connected to vulnerable servers. Among them are 15 bank-related apps, 39 online payment-related, and 10 are online shopping related. We also found several popular apps that many users would use on a daily basis, like instant messaging apps, health care apps, keyboard input apps–and most concerning, even mobile payment apps. These apps use sensitive personal and financial information—data mines just ripe for the cybercriminal’s picking.

What can be done against the Heartbleed bug, then? Not a whole lot, we’re afraid. We can tell you to change your password, but that’s not going to help if the app developers—and the web service providers as well—don’t fix the problem on their end. This means upgrading to the patched version of OpenSSL, or at least turning off the problematic heartbeat extension.

Until then, what we can advise you to do is to lay off the in-app purchases or any financial transactions for a while (including banking activities), until your favorite app’s developer releases a patch that does away with the vulnerability. We’ll keep you updated in the meantime as to all that’s happening with the Heartbleed bug.

Update as of April 11, 2014, 8:45 A.M. PDT

After doing a second round of scanning, we have found that around 7,000 apps are connected to vulnerable servers. 

For other posts discussing the Heartbleed bug, check these other posts:

• Trend Micro Heartbleed Detector Now Available
• Bundled OpenSSL Library Also Makes Apps and Android 4.1.1 Vulnerable to Heartbleed
• Heartbleed Vulnerability Affects 5% of Select Top Level Domains from Top 1M
• Skipping a Heartbeat: The Analysis of the Heartbleed OpenSSL Vulnerability

Recently, other researchers reported that a new Android malware family (detected as ANDROIDOS_KAGECOIN.HBT) had cryptocurrency mining capabilities. Based on our analysis, we have found that this malware is involved in the mining for various digital currencies, including Bitcoin, Litecoin, and Dogecoin. This has real consequences for users: shorter battery life, increased wear and tear, all of which could lead to a shorter device lifespan.

The researchers originally found ANDROIDOS_KAGECOIN as repacked copies of popular apps such as Football Manager Handheld and TuneIn Radio. The apps were injected with the CPU mining code from a legitimate Android cryptocurrency mining app; this code is based on the well-known cpuminer software.

To hide the malicious code, the cybercriminal modified the Google Mobile Ads portion of the app, as seen below:

Figure 1. The modified Google Mobile Ads code

The miner is started as a background service once it detects that the affected device is connected to the Internet. By default, it launches the CPU miner to connect to a dynamic domain, which then redirects to an anonymous Dogecoin mining pool.

By February 17, his network of mobile miners has earned him thousands of Dogecoins. After February 17, the cybercriminal changed mining pools. The malware is configured to download a file, which contains the information necessary to update the configuration of the miner. This configuration file was updated, and it now connects to the well-known WafflePool mining pool. The Bitcoins mined have been paid out (i.e., transferred to the cybercriminal’s wallet) several times.

Figure 2. Coin pool configuration code

The coin-mining apps discussed above were found outside of the Google Play store, but we have found the same behavior in apps inside the Google Play store. These apps have been downloaded by millions of users, which means that there may be many Android devices out there being used to mine cryptocurrency for cybercriminals. We detect this new malware family as  ANDROIDOS_KAGECOIN.HBTB. (As of this writing, these apps are still available.)

Figure 3. Mining Apps in Google Play

Figure 4. Download count of mining apps

Analyzing the code of these apps reveal the cryptocurrency mining code inside. Unlike the other malicious apps, in these cases the mining only occurs when the device is charging, as the increased energy usage won’t be noticed as much.

Figure 5. Cryptocurrency mining code

The same miner configuration updating logic is also present here. Analyzing the configuration file, it seems that the cybercriminal responsible is switching into mining Litecoins.

Figure 6. Configuration file, showing switch into LiteCoin mining

We believe that with thousands of affected devices, cybercriminal accumulated a great deal of Dogecoins.

Reading their app description and terms and conditions on the websites of these apps, users may not know that their devices may potentially be used as mining devices due to the murky language and vague terminology.

Clever as the attack is, whoever carried it out may not have thought things through. Phones do not have sufficient performance to serve as effective miners. Users will also quickly notice the odd behavior of the miners – slow charging and excessively hot phones will all be seen, making the miner’s presence not particularly stealthy. Yes, they can gain money this way, but at a glacial pace.

Users with phones and tablets that are suddenly charging slowly, running hot, or quickly running out of batteries may want to consider if they have been exposed to this or similar threats. Also, just because an app has been downloaded from an app store – even Google Play – does not mean it is safe.

We have informed the Google Play security team about this issue.

Note: We have clarified the use of the word “bricking” in this blog post, and added a solution for developers and other power users.

We recently read about an Android system crash vulnerability affecting Google’s Bouncer™ infrastructure, one that, alarmingly, also affects mobile devices with Android OS versions 4.0 and above. We believe that this vulnerability may be used by cybercriminals to do some substantial damage on Android smartphones and tablets. The device is stuck in an endless reboot loop, or a bootloop. This can render the device unusable, which some may consider “bricking” it.

How did they do it?

Our analysis shows that the first crash is caused by the memory corruption in WindowManager, the interface that apps use to control the placement and appearance of windows on a given screen. Large amounts of data were entered into the Activity label, which is the equivalent of the window title in Windows.

If a cybercriminal builds an app containing a hidden Activity with a large label, the user will have no idea whatsoever that this exploit is in fact taking place. Cybercriminals can further conceal the exploit by setting a timed trigger event that stops the current app activity and then opens the hidden Activity. When the timed event is triggered, the exploit runs, and the system server crashes as a result. This stops all functionality of the mobile device, and the system will be forced to reboot.

An even worse case is when the malware is written to start automatically upon device startup. Doing so will trap the device in a rebooting loop, rendering it useless. In this case, only a boot loader recovery fix will work, which means that all the information (contacts, photos, files, etc.) stored inside the device will be erased.

Bug found to crash a series of services. 

Further research on our part revealed that apart from the WindowManager service, PackageManager and ActivityManager are also susceptible to a similar crashing vulnerability. The critical difference here is that the user’s device will crash immediately once the malicious exploit app is installed. Note that the exploit app in this case does not need any special permission.

In AndroidManifest.xml, apps’ label names can be set in the “android:label” attribute of the element, and it can be written with a raw string, not only with the reference of the string resource. Normally, apps with very long raw string labels declared in AndroidManifest.xml cannot be installed, due to the Android Binder’s transaction buffer size limit. But through the ADB (Android Debug Bridge) interface, which is used by many third-party market clients, such apps can be installed–which, inevitably, causes an instant PackageManager service crash.

Figure 1. PackageManager service crash

In a chain reaction, all other processes that depend upon PackageManager crashes and leaves the Android device completely unusable. Below are notifications of some crashed services, which include Launcher and android.process.acore.

Figure 2.Crashed services that depend on PackageManager

The system service ActivityManager is also affected due to the continuous error in the Binder transaction. This may possibly lead to a Binder driver crash, which then results in an automatic rebooting of the device. At this point, users would have no other recourse but to do a hard factory reset on the device while running the risk of erasing all of the stored data.

Figure 3.Binder driver crash (click thumbnail for full view)

What should users do?

As always, we advise users to never download apps from third-party app stores. It’s important to treat third-party apps with a healthy dose of suspicion and skepticism as cybercriminals are always on the lookout to find and exploit every nook and cranny in Android devices. Google has already been notified about the vulnerabilities but users should still take the necessary precautions in order to protect their mobile devices.

Developers familiar with the use of the Android Debug Bridge can use this as well to remove problematic apps in question. (We would like to thank rmack for pointing out this option for developers and other power users.)

We have informed Google’s Android security team about this issue.

Earlier we talked about some Flappy Bird-related threats. In the course of uncovering their background, we found several third-party app stores that distributed or created similarly dangerous mobile apps.

These third-party app stores target mobile users in Vietnam and inject advertising or even malicious code into popular apps. These apps put the user’s privacy at risk, and may even cause financial loss – the recent Trojanized Flappy Bird app used premium service abuse to profit, and also connected to a command-and-control server in order to receive commands.

This example of a third-party app store imitates the Google Play store and contains various well-known apps that have been Trojanized. Even a fake version of the Google Play app itself is present, but it leads to their own third-party store.

Figure 1. Example of imitated Google Play’s page

The apps in this store contain added advertising code; the profit from these ads goes to the cybercriminals and not the app developers. Among the information sent is the user’s phone number, email address, and device information.

Figure 2. Advertising information

In addition, this advertising module may remotely load code to be executed on the device, effectively acting as a backdoor. This poses a great risk for users.

Figure 3. Backdoor code

Apps with this malicious code are detected as ANDROIDOS_FLEXLEAK.HBT.

Another third-party store was even riskier – this single store contained more than 500 OPFAKE malware variants. One of the malicious Flappy Bird apps was downloaded from this store. Not only do they contain the potentially malicious advertising code, they also abuse premium service numbers in order to get money directly from the user.

Adult apps are also present on this store, with the users having to pay via SMS to use these apps.

Figure 4. Second malicious third-party store

A third app store has similar threats as the other stores mentioned in this post. This one, however, has higher download counts (more than 70,000 downloads).

Figure 5. Third malicious third-party store

These incidents highlight the possible dangers from downloading apps from third-party stores. Users often visit third-party app stores to obtain apps that may be unavailable in official app stores or  even pirated apps (like free versions of paid apps). Some users, meanwhile, rely on these sites because of the unavailability of official app stores in their region.

However, visiting these sites can often be a hit-or-miss. Third-party app sites may not be as strict in monitoring and removing malicious apps compared to, say, Google Play. Apps from these third-party sites should be treated as potentially malicious, as a user has no easy way to determine what malicious code was added.

We detect all the apps listed in these stores that contain malicious content or may violate a user’s privacy.