Author Archive - Weichao Sun (Mobile Threats Analyst)

Vulnerabilities in apps are always a cause for concern, especially when said apps handle sensitive information, particularly financial. We examined two popular in-app payment (IAP) SDKs—Google Wallet and the Chinese payment platform Alipay—and discovered that these contain a vulnerability that can be exploited for phishing attacks. The versions we analyzed were Google IAP versions 2 and 3 and Alipay SDK 1.0.

We have notified the developers of these findings. As of this writing, Alipay has patched the vulnerability. Meanwhile, Google is encouraging developers to use a newer version of its platform, which offers better security. They have also notified developers of several apps who are using the specific SDKs.

The Issue with Intents and Intent-Filters

The vulnerability is related to the intent and intent filter used by the apps. The intent is a “messaging object” that can be used to request an action or process from an app component. They (intents) can be used for communication between app components. Explicit intents are used if the developer wants an action to be performed by a specific component in a specific app. Implicit intents are used when a developer allows the process to be performed by components of other apps. For example, if an app needs to show the user a specific location, it can allow a different app to receive the GPS location.

The Android platform uses intent-filters of apps to determine which app can perform the implicit intent. If an app contains the matching intent-filter, it can perform the task requested by the intent.

There appears to be a flaw in the communication between the mobile payment application and the payment client applications. The mobile payment apps used an implicit intent, which can be intercepted by a malicious app via a high priority intent filter. An intent filter can be made “high priority” by combining several system APIs.

The Flaw in the Google Wallet SDK

For transactions involving the affected Google Wallet SDK, the app must communicate with the Google Play app on the device so that Google Play can notify the user about the payment and then request confirmation.

Figure 1. Confirmation message

However, the IAP SDK uses an implicit intent, ACTION=”com.android.vending.billing.MarketBillingService.BIND,” which can be intercepted by the intent filter action android:name=”com.android.vending.billing.MarketBillingService.BIND.” A malicious app can use the same intent-filter to display a phishing page such as the one below.

Figure 2. Sample phishing message

Phishing Via the Alipay SDK

Alipay has the same process as that of Google Wallet. After the user clicks the “pay” button, the app will communicate with the Alipay mobile client so that the client will display a confirmation message. And just like the flaw in Google Wallet, the communication can be intercepted by a malicious app by using the same intent-filter. In this case, the intent filter is action android:name=”com.alipay.android.app.IAlixPay.” The malicious app can then send its own message in lieu of the legitimate message.

Figure 3. Fake Alipay message

Third party apps employ Google Wallet or Alipay SDK to communicate to the legitimate Google Wallet or Alipay SDK and for real payment process. The purpose of the said SDK is to send the pay intent to the Google Wallet or Alipay. A malicious app can replace the real Google Wallet or Alipay to receive the payment intent.

For example users make a payment via third party apps and of course, they expect to see the legitimate Google Wallet or Alipay. In this case, however, a phishing app may come out to appear like the real Google Wallet or Alipay. As such, users may trust the phishing app and input his/her password and bank account details.

Phishing and Financial Loss

These fake messages show the potential for phishing attacks. However, phishing attacks could just be the beginning. Once cybercriminals have access to user accounts, they can then proceed to steal information stored in the account. Given that the affected apps handle payments, it’s a very likely that credit card and other payment information could be stolen. They can then use that information or sell it in the cybercriminal underground.

Moreover, users may not suspect these malicious messages. Since the apps handle payments, they might assume that the messages are simply intended to confirm the accounts before proceeding with the actual payment.

Fixing the Flaw

Developers should always use explicit intents for processes dealing with sensitive information. In such cases, only the desired app will be able to perform the process, minimizing the possibility of interception via malicious app. However, explicit intents are not enough. Developers can also require that their apps check for the signatures of other apps as proof of their legitimacy before communicating with them.

As previously mentioned, we informed Google and Alipay about this issue on May 27th. Alipay fixed the issue by July 18th, rolling out the SDK version 2.0. Google has informed us that the current IAP code includes code that uses an explicit intent. We advise developers to use these new versions for their applications. Google has also stated that they are currently monitoring for and have not seen any evidence of exploits of the said vulnerability.

We continue to actively monitor for any threats that may take advantage of this vulnerability. We advise users to install security software in their mobile devices to detect and block malicious apps that may take advantage of vulnerabilities such as this one.

We have previously discussed an Android vulnerability that may lead to user data being captured or used to launch attacks. We discovered that the popular Android app for Evernote contained the said vulnerability. We disclosed the details to Evernote, and they took action by issuing an update to the Android version of their app. Evernote has added additional controls to protect user data in Evernote for Android 5.8.5. Android users who are running versions below 5.8.5 should update to the latest version.

The Content Providers Vulnerability

The patched vulnerability is related to the Android component that stores application data. This component has an attribute (android:exported) which may allow other apps to read or write certain data on the affected app.

The previous version of Evernote has defined two permissions to protect the content provider that is used to store almost all of the user’s data. However, the protection level of these two permissions has been set as “normal,” which means other applications on the device can be granted these two permissions.

Cybercriminals may create malicious applications that may be used to capture the data stored in the Evernote app. For users who rely on Evernote to store sensitive information such as user accounts and passwords, this could lead to data theft, identity fraud, and more.

Exposed, Unencrypted Data

Apart from the vulnerability explained above, we’ve also found another vulnerability that may allow malicious apps to see all the notes in the affected device because of where the notes are stored.

The Evernote app stores all the user’s notes in external storage under the directory /sdcard/Android/data/con.evernote/files/. Unfortunately, the files stored in this folder are not encrypted and can be read by other apps.

Figure 3. Sample note

Figure 4. The note is accessed by exploiting the SD card vulnerability

The Android OS version of the affected device also affects the amount of access given to apps. For Android 4.3 and earlier versions, an app doesn’t even require special permission to access the said folder. For Android 4.4 and later versions, the READ_EXTERNAL_STORAGE permission is required. However, this permission is common for most apps so a malicious app requesting this permission will not arouse suspicion.

Malicious users can write a simple code snippet to read/write files stored by the said app and inject it to repackaged applications that have the READ_EXTERNAL_STORAGE permission. Attackers can then use these repackaged apps to trick users into giving them the said permission.

We are disclosing this information in order for developers who may have likewise incorrectly implemented this external storage provision to modify their apps. Developers should also define their permissions in the signature level to protect their important components. We also encourage developers to implement encryption for any content the app creates, handles, and transmits. If possible, any sensitive information should not be stored in external storage.

We have notified Evernote of this new vulnerability. We are not currently aware of any active attacks using this flaw.

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 is 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 com.alipay.mobile.push.permission.PUSHSERVICE to protect the component com.alipay.mobile.push.integration.RecvMsgIntentService. 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.

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:

Install the Android SDK on a PC, including the adb component.

Connect the affected device via USB to the PC.

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:

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.