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


  • Recent Posts

  • Calendar

    March 2015
    S M T W T F S
    « Feb    
    1234567
    891011121314
    15161718192021
    22232425262728
    293031  
  • Email Subscription

  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Veo Zhang (Mobile Threats Analyst)




    Recently, we have noticed large numbers of repackaged Android apps showing up in Chinese app stores. While these apps pretend to be “free”, in the end they cost the users time and money: they are either shown various ads or they are subscribed to various premium SMS numbers. (Note that these apps were not found in the official Google Play store.)

    Two channels are at work here. First, foreign apps that have been localized or repackaged by Chinese companies and used for various schemes. Secondly, paid/premium apps can be repackaged by pirates to produce a “free” version that contains ads or other added code. In either case, there is a risk that the repackaged code may be malicious.

    In the first case, local Chinese companies have been contracted by the original developers to localize apps for the Chinese market. This includes translation, as well as changing payment methods to those used in the Chinese market. However, unscrupulous companies may add their own code at this stage to add advertisements and collect money from users via SMS numbers.

    These advertisements collect the user’s location, phone model, and other installed apps without explicitly getting the user’s permission. The apps may also be designed so that in some circumstances, users may “accidentally” click on the button which sends an SMS payment. Payment notices may also be intercepted, as seen in the following code:

    Figure 1. Code intercepting payment notice text messages

    In the second case, pirates (either individuals or companies) crack paid apps, add their code, and distribute them via major Chinese app stores. Using commercials and fake downloads, these repackaged apps reach the top lists of these app stores, with millions of downloads.

    Figure 2. repackaged version of Minecraft with 52 thousand downloads per week

    These apps contain display multiple advertisements when they are launched, and trying to close them just leads to download another app with even more advertisements. We even found spyware pushed as a security app; this particular app required root privileges and a result it is not easy to remove. (The screenshot below shows an ad for one of these spyware apps.)

    Figure 3. Ads at app startup that lead to other risky apps

    Figure 4. App permissions requested by app installed by ad in Figure 3

    Apps being used to promote various scams are also a widespread problem. This malicious app repackaged the original Monument Valley game with an advertisement library; in addition it randomly pushes scams messages to users, which lead them to further phone scams.

    Figure 5. repackaged Monument Valley, with 520 thousand downloads

    This app displays advertisements via system notifications that leads to a website at hxxp://abcdefg2.jjzl.com.cn/tmall3_daigou/ip6.php. This site contains offers for the user to purchase iPhones and other mobile devices for approximately $100 cash on delivery. The user is asked to enter his name, phone number, and shipping address. There is at least one known case where the victim was later called and asked to pay a “prepaid shipping fee.”

    Acquiring this personal information is the goal of this scam. which is detected as ANDROIDOS_SCAMAD.HBT. The user is at risk of receiving more fraudulent calls, unless they change their phone number.

    Figure 6. App notification for iPhones being sold

    Figure 7. Website gathering user information

    The above screenshot shows some of the items for sale (different variants of the iPhone 5S); the next three fields are where the user would enter their personal information before clicking one of the buttons below, which would submit the information to the attacker.

    The malicious apps in this post are mostly gathered from the top app lists of some major Chinese app stores. These top lists contain many repackaged apps, which pose serious risks to users. Users – particularly those in China – should be careful about downloading these apps. Last year, we discussed the threats of repackaged apps in a white paper titled Fake Apps: Feigning LegitimacyTrend Micro Mobile Security protects users against these threats by scanning apps that are installed onto the device.

     
    Posted in Malware, Mobile |



    We recently encountered a high-risk Android app detected as ANDROIDOS_STIP.A in Chile. This app, found distributed through forums and blogs, can be used to hack into the user’s RFID bus transit card to recharge the credits. What is the mechanism behind this, and what is the security risk of RFID payment cards in general?

    Paying via RFID cards is becoming more popular nowadays as more mobile devices add NFC support. Banks, merchants or public services issue RFID cards to their customers with prepaid credits.

    Note: The malware samples discussed below were not obtained from the Google Play Store.

    Security Issues with RFID Cards

    Because it is widely used, it’s no surprise that that RFID cards have become targeted by attacks. Take for instance the recent Tarjeta bip! card hacking incident in Chile. These cards are MIFARE-based smartcards; MIFARE refers to a family of chips widely used in contactless smart cards and proximity cards.

    mifare-cards

    Figure 1. MIFARE devices

    Looking at the code of the Android app, we found that if it runs on a device equipped with NFC it can read and write to these cards.  The malicious app writes predefined data onto the card, raising the user’s balance to 10,000 Chilean pesos (approximately 15 US dollars). This particular trick will only work with this particular fare card, since it relies on the format of the card in question.

    Read the rest of this entry »

     
    Posted in Mobile | 1 TrackBack »



    Recently, it has been reported that apps downloaded via third-party app stores in South Korea have resulted in more than 20,000 smartphones being infected with malicious apps. Note that none of these apps were found on the official Google Play store.

    The apps involved in this attack are detected as ANDROIDOS_KRBOT.HRX. We decided to look further into this slew of infections.

    Identifying Who’s Responsible

    The cybercriminals behind these attacks are active members of underground forums involving pirated apps. Frequently, these are cracked versions of top gaming apps. These criminals collecting these cracked apps and repackage them with malicious code, and redistribute them.

    The attackers distribute these apps via various Bittorrent sites, forums, and various third-party stores.

    Figure 1.Malicious app posts in underground forums

    Figure 1. Posts for pirated app in underground forum

    Figure 2. Malicious app in Google Drive

    Figure 2. Pirated app hosted on Google Drive

    Figure 3. Malicious app found in torrent websites

    Figure 3. Pirated app found in torrent websites

    Once the malicious app is run, it starts a background service, which connects to predefined mail servers.

    ksa_fig4

    Figure 4. Hidden bot service

    Our investigation revealed that some of the email accounts were deserted, suggesting that this attack was no longer ongoing.

    ksa_fig5_new

    Figure 5. Deserted email accounts

    However, new variants of this malware family are still being encountered. We soon learned that some variants have been updated with new email accounts, which were still active. These email accounts received encrypted commands from a sender with the name “Res Sou.”

    igure 5. Encrypted control code in mail inbox

    Figure 6. Encrypted control code in mail inbox

    The code in the mail can be decrypted into a socket server, http://{BLOCKED}dapp[.]ocry[.]com:50080/php/download.php:55555, and an HTTP server, http://{BLOCKED}dapp[.]ocry[.]com:50080/php/download.php. The socket server is used by the bot to get remote commands.

    The commands are as follows:

    “register” Register to remote server
    “request_call_log” Request call log record
    “request_contact” Request contacts list
    “request_file_list” Request to list files in device storage
    “request_create_new_dir” Request to create new directory in device storage
    “request_file_upload” Request to upload files in device storage
    “request_file_download” Request to download files into device storage
    “request_item_delete” Request to delete files in device storage
    “request_calendar_event” Request to upload calendar events
    “request_del_message” Request to delete SMS message.
    “request_send_message” Request to upload SMS message.
    “request_send_all_message” Request to upload all SMS message.
    “request_endcontrol” End remote control

    Collected data are stored in /data/data/[package name]/sent_data.db. Files are meanwhile uploaded and downloaded via the HTTP server.

    Tracking Recent Activities

    From recent activities of the email accounts, we learned that the mail account was created with a Japanese IP address, and signed in from different parts of Japan. It’s likely that the cybercriminal used Japan-based proxies to hide his tracks.

    Figure 7. Recent activities of the malicious mail account

    Figure 7. Recent activities of the malicious mail account

    The domain for the command-and-control server used a dynamic DNS service, with the actual server located in Kuala Lumpur, Malaysia. We found a legitimate website hosted on this server. Further investigation revealed that normal web service is not available, with no replies from the company owning the site. This suggests that this particular server might have been compromised to serve as a C&C server.

    The victims’ information was then sent to the following IP addresses:

    • 101[.]99[.]65[.]100
    • 85[.]214[.]211.47

    The servers at these addresses are located in Malaysia and Germany, respectively.

    Reviving the Bot

    We have found evidence that in addition to South Korean users, this app is now targeting Chinese users as well. We found posts in one of the biggest Chinese app forums with links to one of these pirated apps. This means that the attacks are no longer limited to South Korean users.

    ksa_fig9_new

    ksa_fig10_new

    Figures 8 and 9. Variants targeting Chinese users

    While the number of downloads may still be low, the fact that this was seen in Chinese forums means that the cybercriminals are expanding their net of potential victims. We advise users to avoid downloading apps from third-party app stores and to rely only on official app stores.

    We detect variants of this malware family as ANDROIDOS_KRBOT.HRX. Trend Micro Mobile Security products use the Smart Protection Network to block all related threats. We advise users to install security software in their mobile devices to secure it from malicious apps and threats.

     
    Posted in Malware, Mobile | Comments Off



    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 | Comments Off



    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 | Comments Off


     

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