Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    July 2014
    S M T W T F S
    « Jun    
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Veo Zhang (Mobile Threats Analyst)




    The security of the Android platform is based on its sandbox and permission protection mechanism, which isolates each app and restricts how processes can communicate with each other. However, because it is designed to be open to include other open source projects like Linux and OpenSSL, it can inherit many features as well as vulnerabilities.

    This means that the protection of the sandbox cannot cover every aspect of the system, and threats to Android still remain. Open ports are one potential source of vulnerabilities, and we recently found a new vulnerability in the app of a Chinese deals site, Meituan, that highlighted this problem.

    Earlier this year, Heartbleed was a notable example; apps with their own vulnerable OpenSSL library to create TLS/SSL connections are at risk of leaking local memory information. Similarly, any vulnerability in an app or external module may affect the security of the entire system.

    Linux is also a potential source of vulnerabilities. Because Android is based on the Linux kernel and still uses many native Linux APIs, Linux vulnerabilities may affect Android as well. For example, CVE-2014-3153 was used by root exploit tools like TowelRoot. Another example was CVE-2014-0196.

    Network protocol implementations in Linux are also facing security challenges. Vulnerabilities seen this year in the Linux TCP/IP stack included CVE-2014-0100CVE-2014-2523 also affected Android as well. These vulnerabilities, if exploited, put users at risk, as an attacker would be able to exploit their machine remotely.

    Android systems that insecurely use these network protocols may also have vulnerabilities. CVE-2011-3918 was a vulnerability in the zygote process, which allowed an attacker to launch a local denial of service via a malicious app. The cause was the developer used the socket protocol without setting the right permissions. Similar vulnerabilities include CVE-2011-1823, CVE-2013-4777, CVE-2013-5933. Developers need to be aware of  of the security risks when using these protocols, as there can be serious consequences resulting from their mistakes.

    User installed apps may increase this risk as well. Look at the following screenshot:

    Figure 1. Apps with open ports

    The screenshot shows how many apps listen on an open TCP port, which means the device is exposed online without the benefit of a firewall. What if an app was built by a developer who wasn’t aware of the security issues? Even well-known software applications have their share of network-related vulnerabilities. As it stands, it would be better to have a firewall of some kind to protect Android users, but that is not part of the mobile OS today.

    These kind of vulnerabilities do exist on Android.  We found a vulnerability in the Android app of Meituan, a Chinese site similar to Groupon. It affects versions of the Meituan app below 4.6.0. Vulnerable versions of this app listen on TCP port 9517, which allows the app to receive messages from a server. However, because it does not authenticate the sender, any machine on the Internet can trigger a command on the phone.

    The code snippet responsible for the vulnerability is below:

    Figure 2. Vulnerable app code

    It parses the received TCP data in a certain format and then sends android.intent.action.VIEW with the “intent” in the received data. Using this vulnerability, an attacker can send large numbers of messages using your phone to a fraudulent number, or open phishing websites.

    If your Android version is older than 4.0.4, the USSD vulnerability may also be triggered by this problem. This means that your phone may even be remotely wiped by an attacker!

    We are looking forward to enhancements to Android security like SELinux, Storage Access Framework, and Device Administration. However, there are still many unprotected parts of the Android system. These network vulnerabilities will be a significant problem moving forward.

    We disclosed this vulnerability to Meituan on June 3 of this year, and the vendor confirmed it to us on the same day. A fix was issued to users two days later on June 5, with version 4.6.1 of the app. Trend Micro and Meituan worked together on the solution, and we mutually agreed to disclose details of this vulnerability at this time.

     
    Posted in Mobile, Vulnerabilities |



    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.

     
    Posted in Mobile |



    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.

     

     
    Posted in Bad Sites, Malware, Mobile, Social |



    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.

    140415comment02

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

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

    140415comment03

    140415comment04

    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:

    Hearbleed Chart

    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:

     



    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:

     


     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice