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    
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Weichao Sun (Mobile Threats Analyst)

    Alipay is a popular third-party payment platform in China that is operated by Alibaba, one of the biggest Internet companies in China. We recently found two vulnerabilities in their Android app that could be exploited by an attacker to carry out phishing attacks to steal Alipay credentials.  We disclosed the said vulnerabilities to Alipay; they acknowledged the issue and provided updates to their users earlier this month which fixed this vulnerability.  Version 8.2 and newer of the Alipay app no longer contain this vulnerability. We urge all users of the Alipay app to check if they still have the vulnerable version and update to the latest version (if needed).

    First vulnerability: Exported activity

    Android applications have several important components, one of which is Activities. This has an important attribute, android:exported. If this attribute is set as “true”, every application installed on the same device can call this activity. Developers should take care so that their exported activities are not abused.

    We found that the official Android app for Alipay was vulnerable to exactly this kind of exploitation. This particular activity can be used to add an Alipay passport (known as Alipass). An attacker, using a specially created Alipass, can use this activity  to create an Alipass login display. This can be used to lead the user to a phishing page or to display a QR code. Before the activity is launched, the user will be asked to enter the Alipay unlock pattern, which makes the user believe the login really is from Alipay.

    Figure 1. Phishing URL delivered by activity

    Vulnerability #2: Malicious permission

    We discussed earlier how permissions can also be exploited by permission preemption. In this attack, a malicious app ius installed before the target application which grants the target application’s customized permission and access the components protected by the permission

    Alipay’s app defined the permission to protect the component This component is used by the Alipay app to receive messages from the Alipay server. One particular message is the a message informing the user that an update for their app is present.

    After a malicious app is granted the PUSHSERVICE permission, an attacker can simply construct a message and send it to the RecvMsgIntentService to push an update notification to user.

    Figure 2. Test notification exploiting vulnerability

    Figure 3. Notification asking to install a malicious app.

    Once the user has accepted the update, another application will be downloaded and installed. The URL where this download app will come from is controlled by the attacker as well. Combined with the recently uncovered Android launcher vulnerability, we can hijack the Alipay’s shortcut and launch the faked Alipay to get user’s account.

    Android’s exported activities are not the last mobile operating system feature that might be thought of as a security risk. For example, iOS allegedly contained a backdoor – before it later emerged that this was simply a diagnostic tool. Real or not, mobile OS features can become security threats down the road if developers do not use these in a secure manner.

    Posted in Mobile, Vulnerabilities |

    The recent introduction of ransomware in the mobile threat landscape was followed by a new development: the usage of TOR to hide C&C communication.

    In our analysis samples we now detect as AndroidOS_Locker.HBT, we found that this malware  shows a user interface that notifies the user that their device has been locked down, and that they need to pay a ransom of 1000 rubles to unlock it. The interface also states that failure to pay would result in the destruction of all data in the mobile device.

    Examples of apps we’ve seen display this routine are found in third-party app stores, bearing names such as Sex xonix, Release, Locker, VPlayer, FLVplayer, DayWeekBar, and Video Player. Non-malicious apps with these names are available from various app stores.

    Here is the warning shown to the user, which is in Russian:

    Figure 1. Warning to user (Click to enlarge)

    Here is a rough translation of the warning:

    For downloading and installing software nelitsenzionnnogo your phone has been blocked in accordance with Article 1252 of the Civil Code of the Russian Federation Defence exclusive rights.

     To unlock your phone pay 1000 rubles.

     You have 48 hours to pay, otherwise all data on your phone will be permanently destroyed!

     1. Locate the nearest terminal payments system QIWI

     2. Approach to the terminal and choose replenishment QIWI VISA WALLET

     3. Enter the phone number 79660624806 and press next

     4. Window appears comment – then enter your phone number without 7ki

     5. Put money into terminal and press pay

     6. Within 24 hours after payment is received, your phone will be unlocked.

     7. So you can pay via mobile shops and Messenger Euronetwork

     CAUTION: Trying to unlock the phone yourself will lead to complete full lock your phone, and the loss of all the information without further opportunities unlock.

    The user will be asked to pay to account 79660624806/79151611239/79295382310 by QIWI or 380982049193 by Monexy within 48 hours. This UI will also keeping popping out, thus preventing the user from being able to use their device properly. At the same time, files on device (both in internal and external storage) with following format are encrypted:

    • jpeg
    • jpg
    • png
    • bmp
    • gif
    • pdf
    • doc
    • docx
    • txt
    • avi
    • mkv
    • 3gp
    • mp4

    While the above-mentioned routines are typical of ransomware, we found that it communicates to its command-and-control server via TOR. Although this is not the first time we’ve seen Android malware use TOR, this is the first ransomware we’ve seen that uses it. Considering the amount of data that users now store in their mobile devices, we predict that this is just the start of the continuous development of mobile ransomware.

    How to Remove this Ransomware?

    For users whose devices are infected with this ransomware, the malicious app can be manually removed through the Android Debug Bridge. The adb is part of the Android SDK, which can be freely downloaded from the Android website. The process would proceed as follows:

    1. Install the Android SDK on a PC, including the adb component.
    2. Connect the affected device via USB to the PC.
    3. Run the following command from the command line:
      adb uninstall “org.simplelocker” 

    This procedure will work without problem for devices with Android versions lower than 4.2.2. For 4.2.2 and later users, however, there is a problem: the phone will prompt the user with a dialog to accept a key to allow debugging. However, the ransomware’s own UI will keep interrupting this, making it difficult to use adb to remove the phone.

    Note that in all cases, the user must have enabled USB debugging on their device before being infected; doing this may be difficult as the steps differ from device to device. In addition, turning USB debugging on is a security risk in and of itself, as it means an attacker who gets physical access to a device can easily get files from it without having to enter information in the Android lockscreen.

    The above step-by-step procedure will remove the ransomware, but not recover any locked files. Recovering the files is difficult, as is the case with ransomware on PCs. We recommend that users recover their files from their backups, whether these are online or offline.

    The SHA1 hashes of the samples used to analyze this attack are as follows:

    • 3313e82160fe574b4d4d83ec157d96980c0e88c4
    • 4824c957b7804d27c56002c93496182c8ec2840d
    • 5a102f0e6238418d8c73173752e20a5914ec4958
    • 725e9553040845d4b7ad2b0fd806597666d61605
    • 808df267f38e095492ebd8aeb4b56671061b2f72
    • 979020806f6fcb8a46a03bb4a4dcefcf26fa6e4c
    • b4bc70e7f046894ef12b5836f70b0318ca7ad06f
    • b5aab4bdb6bbb5914b1860c47080ccb558f07e5b
    • c85e49e0e99c2c0e531f723bf14d84339919985d
    • e6ee6dac2e6bd97c93a6a746442bfc0930e637af

    We’ve recently found a vulnerability in certain Android apps that may leave user data at risk of being captured or being used to launch attacks. The two affected apps we investigated are both highly popular:

    • The productivity app has at least 10M installs and hundred thousands of customer reviews based on their download page
    • The shopping-related app has at least 1M installs and several thousand customer reviews based on their download page

    This issue lies in a certain Android component which basically executes functions of the app. This component has an attribute named “android:exported“, which, when set to “true”, allows this component to be executed or accessed by other applications. This means that apps installed within a device may be able to trigger certain functions in other apps. This has obvious convenient uses for developers and vendors who want to strike partnerships with apps by other vendors, but from a security standpoint, this also poses an opportunity for cybercriminals.

    Using Activities to Launch Attacks

    Ways to exploit this issue may vary, depending on the intent of the attacker and the nature of the vulnerable application. As an example, in our analysis, we found that a particular Activity in a shopping app –one related to showing pop-ups whenever the user makes a purchase– is vulnerable to abuse and can be triggered by other apps.

    A possible implication of this is that a malicious application can display pop-ups in the shopping app and use it to launch attacks. The attacker may craft the malicious application to display pop-ups that lead to malicious links or other malicious apps.

    Using Content Providers to Steal Information

    Another possible way to take advantage of this security issue is to target content providers that handle critical information in order to collect them. A content provider related to storing user input in a productivity app, for example, may be used to capture data.

    Such content provider that can be considered as critical may be protected by defining permissions. However, not putting the proper permission protection level can still leave the content provider vulnerable to abuse. In the mentioned productivity app, the content provider to store user input was protected by READ and WRITE permissions. However, both permissions were given “normal” protection level, which means that all applications installed in the device are granted the two permissions as well.

    What Can Be Done?

    For developers, this issue highlights the importance of putting the appropriate restrictions in the different components of apps. Components that are prone to abuse should be protected with permissions — and with the proper protection level. As we’ve reported in the past, using protection levels in order to secure Android components may not be fool-proof, but it offers a good level of security.

    We strongly advise developers to check components used in their app and make sure that access to them are restricted properly. We’ve already reached out to the developers of the apps mentioned above and informed them of this issue. We believe that some other popular apps may be affected and we will work to inform them as we encounter them.

    Update as of June 1, 2013, 7:15 PM PDT:

    Trend Micro is working closely with the vendors and developers that were initially found to be affected by the vulnerability discussed. This does not imply that these are the only apps affected, though, hence the names were not disclosed. 

    We are working with the vendors of these affected apps to responsibly disclose details about this vulnerability in the near future. This blog entry is meant for other app developers to immediately learn about the vulnerability before full disclosure, in order to check whether or not their apps are likewise affected.


    A key part of Anrdoid’s access control policies are permissions. To access certain resources on an Android device, applications need to request and be granted specific permissions. However, beyond those permissions specified by the operations system, an app can define its own customized permissions. Generally, this is done to protect an app’s own functions or data.

    Custom permissions like these are usually defined at either the “signature” or “signatureOrSystem” protection levels. These are defined in the Android Open Source Project (AOSP) documentation as:

    signature A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user’s explicit approval.
    signatureOrSystem A permission that the system grants only to applications that are in the Android system image or that are signed with the same certificate as the application that declared the permission. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. The signatureOrSystem permission is used for certain special situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.

    This made Android developers believe that only system applications or applications with the same signature (probably created by the same developer) can access these permissions. Because of this, additional access control may not have been implemented. That is not the case, however.

    The Android operating system keeps track of these custom permissions using only their names. Once a permission is defined, other apps cannot modify them. Suppose that a well-known app “A” defined the permission permission-A with a signature protection level in order to protect its own data. However, let’s suppose that before installing A, the user has installed a malicious app B. If B is designed to steal information from the legitimate app A, it would create permission-A before “A” has a chance to create it, and then application “B” can be granted permission-A . Once application “A” installed, “B” will have the permission to read the protected data of application “A”.

    We have found almost 10,000 apps that are at risk to this vulnerability. We are not disclosing which apps are immediately vulnerable, but a quick check we did of vulnerable apps include:

    • A popular online store leaks its online browsing history.
    • A popular chat app leaks the user’s in-app purchases.
    • A popular social network can have fake messages inserted via its app.

    Developers should not rely exclusively on the protection levels when their Activities/Receivers/Services/Providers are accessed. Several functions such as getCallingUid and getCallingPackage are provided by the operating system, and can be used to identify any apps requesting the above and implement access control as needed.

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

    With additional analysis from Veo Zhang

    Posted in Mobile, Vulnerabilities | Comments Off

    App developers often include ads on their applications to increase revenue. These ads feature enticing titles or blurbs to surge more user hits. Typically, clicking these ads either prompt users to download an app or be redirected to a web page. However, cybercriminals who never run out of new ways to spread their deeds, could also use this as a venue to steal user information.

    We recently spotted a fraudulent website which is pushed by ads found in multiple Android apps. (Some of these apps were downloaded from the Google Play store, while others were found from third-party stores.) These ads use popular brands as hooks like “iPhone 5” and “Samsung Galaxy Note II” and supposedly selling these items for a ridiculously low price. Once users click the ad, it will lead them to a website which shows many means to buy the said phones.

    Figure 1. Ad for Samsung Galaxy Note II


    Figure 2. Ad for iPhone 5

    In reality, these sites are just scam sites that try to defraud users out of their money. They do not actually sell the devices they are promoting.

    Figure 3. Fraudulent website advertising Samsung Galaxy Note II

    Figure 4. Fraud website with iPhone 5 ad

    These ads are being delivered by a large, mainstream ad network, which claims to be used by more than 90,000 apps. While this attack is currently limited to Chinese users, because of the large number of apps on this particular ad network it is possible that similar attacks will be delivered to other users in the future.

    Last March, we blogged about Google’s decision to remove apps that block ads and the potential risks this may pose on unsuspecting users. No doubt the insufficient audit of ads on the Android platform may lead to more fraud, phishing attacks or even malware distribution. We recommend ad providers to provide more powerful audit mechanisms to protect users from attacks leveraging ads.

    Trend Micro protects users from this attack by blocking the said malicious website. We also advise Android users to be cautious in clicking ads on their devices as this may potentially lead to information and identity theft. For better protection of your devices, users should also be wary of other mobile threats like malicious URLs and mobile phishing sites.

    We’re trying to make the Security Intelligence Blog better. Please take this survey to tell us how.

    Posted in Bad Sites, Mobile | Comments Off


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