One of the reasons that mobile OSes such as iOS and Android are more secure than their desktop counterparts is that they include very robust controls over app permissions. Each app requests from the user and operating system permissions that, in theory, are limited to what they need.

As applied, they have not always worked. App developers tend to ask for more permissions than they need; users don’t always pay attention and will approve just about anything. Still, for all the faults of the permissions system, it was there, and users who wanted to be particularly careful about app permissions had a useful tool at their disposal.

Unfortunately, however, it turns out that Google has changed the permissions model of Android in a very fundamental way, significantly reducing its visibility and usability to users. It leaves much more room for malicious app developers to update their apps to add potentially risky permissions to their apps.

How was this done? Developers in various Android discussion forums found that the update to the Play Store – rolled out in mid-May – had also changed how permissions and app updates were handled, and not in a good way.

Previously, if an update to an app meant that it required new permissions, the user would have to explicitly review the permissions and approve it, as if a new app was being installed. That is no longer the case. Now, if the requested permission(s) are in the same group as one the user has granted access to, this explicit approval is no longer necessary. If app auto-updates is turned on, the app can update in the background without the user being aware of the changed permissions.

These permission groups are documented in the Android developer site. The groups are built around functionality; for example all permissions that deal with location services are in one group. The permissions for the wallpaper are in another; the permissions dealing with storage are in yet another. 31 groups in all are defined in the developer documentation, but a total of 13 are explicitly named by Google in an FAQ discussing this topic.

This is all well-meaning – it streamlines the permissions process and makes it simpler for the user. However, it can be highly problematic. It is now easy – trivial, even – to construct an app that starts out with clearly “innocent” permissions at first, then later integrated the permissions necessary for potentially malicious behavior. For example, permissions to use the flash and recording audio/video are under the same group. In effect, a flashlight app can be easily updated to become a recording/stalking app without the user noticing the change. Other permissions that belong to the same group include:

• Reading the contents of the external storage
• Modifying or deleting the contents of the external storage
• Formatting the external storage
• Mounting or unmounting the external storage

Using the list above as an example, an app with the permission to read the contents of the external storage can easily be “upgraded” to having the capability to change or remove content.

In general, because Google has built these groups around specific features and functions, reading and writing permissions tend to be lumped together. In effect, by giving any app the permissions to read something, we are giving that same app the permission to modify something. This sort of flies in the face of what we would consider normal behavior: if I lend something to a friend, I generally expect to get it in the same state it was when I lent it out.

In a very real way, all this breaks permissions and renders it useless. It is now very difficult for a user to control an app based on permissions, since each category is so broad that it becomes very likely that even the most simple app will ask for multiple permissions. Conversely, it becomes very easy for an app developer to insert permissions into an app after the user has installed it in the form of a silent update, which can then be used maliciously.

This means that a greater reliance is placed on other methods to control app behavior, such as Google Bouncer and app verification. All this would be fine, but both are historically proven to be circumventable. For example, Android apps may hide malicious code or dynamically load code from remote servers, making the task of detecting malicious behavior more difficult.

Users do not have much choice in trying to counteract this “update”. One option users may consider is to turn off background auto-updates entirely. The Google Play app will still inform users if updates are available, and users need to manually update and check the new permissions. Unfortunately, this process can be quite burdensome.

In addition, in today’s climate of privacy consciousness, “trust us” – as Google is, in effect, asking us to do – is not an ideal proposition. Users must have the tools to decide for themselves what they do or do not trust. Taking such tools away can only be described as an act of arrogance.

The 2014 FIFA World Cup in Brazil is all but underway, and the fervor of such a prestigious and newsworthy event is already setting competing nations’ populations on fire. Unfortunately, cybercriminals are getting into the mood too.

Besides recently flooding the internet with phishing scams and the taking down two Brazilian government sites by hacktivists (the Sao Paulo Military Police website  and the official World Cup 2014 Brazil website), cybercriminals are also targeting the mobile scene with scads of World Cup-themed mobile malware  - more than 375 of them already at last count. We found these malicious apps lurking in unauthorized/third party app download stores, just waiting for users to install them on their mobile devices.

Upon analysis, we found that the bulk of the malware in question are variants of prevalent mobile malware families.

App Fakery

One of the malware families detected is ANDROIDOS_OPFAKE.CTD  family. This particular family  first appeared in May, 2013, passing itself off as fake clones of popular apps. Its malicious routines included subscribing the user to premium services, leaking user-critical information (such as contact list/messages) as well as install malicious links and shortcuts on the mobile device home screen. In just one year, the number of detected ANDROIDOS_OPFAKE.CTD variants reached 100,000, faking 14,707  apps.

We also discovered that that the remote server the apps connect to has 66 different domains, with each domain spoofing famous websites like MtGox.com.

Figure 1 and 2: Fake World Cup game apps

Figure 3. Fake game app premium service abuse notification

 SMS filtering and theft

Another malware family we detected leveraging World Cup fever is the ANDROIDOS_SMSSTEALER.HBT family. Variants of this family share similar methods of fraud and fakery with OPFAKE, with one exception: they can connect to their remote C&C server to receive and execute commands, some of which being adding an SMS filter (to block/conceal certain incoming messages), sending SMS, and installing new malware.

Figures 4 and 5. More fake World Cup game apps

Analyzing its C&C servers, we found 76 domains, all of them registered to a Tanasov Hennadiy. We also found that the C&C servers in question were also used to host third-party app download websites, where most apps are repacked with advertisements and information theft routines.

Figure 6. C&C domain registrant name and address

Figure 7. List of hosted malicious apps/files

 Premium Service Abuse

We also found that the Trojan mentioned in our previous blog  is also part of the cybercriminals’ World Cup arsenal, with a new variant we detect as ANDROIDOS_OPFAKE.HTG. A typical Premium Service Abuser, affected users find themselves charged with exorbitant premium service fees that they never themselves purchased.

Figure 8. Fake World Cup game app/PSA

Slot Game Swindling

Finally, we found a malicious World Cup slot game app that we detect as ANDROIDOS_MASNU.HNT. Its malicious routines include filtering user payment confirmation messages, so that users may not notice the real amount of money they’ve been paying when playing this game, and thus spend more without restraint.

Figure 9. Malicious World Cup slot game app

Some football betting apps have also been found leaking information without user notification, as well as blatant security risks in their micropayment process. We advise users to be very careful with their financial and personal information when using these apps (or not to use them at all).

Besides these malware, we also found quite a few high-risk apps also themed after the World Cup. Most, if not all, sport some sort of information theft routine, as well as pushing ad notifications/unwanted app advertisements.

While it may be a fact of life that big sporting events like these will inevitably have some sort of cybercriminal attack or campaign following close behind, being a victim of them isn’t. Users are reminded not to download anything from third party app download sites, and to utilize mobile security solutions (such as our own Trend Micro Mobile Security) in order to keep their mobile devices secure.

Readers can be assured that we will continuously monitor these World Cup-related threats and publish news updates as we get them. Check out this blog as well as our Race to Security website for all the latest news regarding this particular topic.

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.