Android malware finds new ways to derive current running tasks

KNOWLEDGE BELONGS TO THE WORLD
Share on FacebookTweet about this on TwitterShare on LinkedInShare on RedditShare on Google+Share on TumblrPin on PinterestDigg this
Android banking and ad-fraud Trojans leverage ideas found in GitHub-hosted open source projects and use the UsageStats API to bypass Android 5.0 and 6.0 security enhancements.
As we have discussed in our previous blogs, the ability to determine what app is currently running in the foreground is central for mobile banking malware to create overlay “injections” to phish the current running application. Android 5.0 Lollipop and Android 6.0 Marshmallow have thwarted malware’s ability to find the current running task by deprecating getRunningTasks() API, but ever since Google rolled out the Android security enhancement, malware authors have engaged in a cat-and-mouse game of workarounds and fixes. We have been blogging about each of these malware evolutions as we spot them in the wild.

The recent variants of Android.Bankosy and Android.Cepsohord, observed over the last quarter, are using two new tricks to circumvent the new security enhancements. One of these two techniques requires an additional special permission from the user, while another does not require any additional permission at all.

Technique #1: Leverage an open source project to find the current running task
This technique uses a popular open source project hosted on GitHub and does not require any additional permissions. It reads the “/proc/” file system to enumerate running processes and finds the current foreground app. It should be noted that the open source project itself is not malicious—the malware authors just leverage this project to get around security measures.

This technique will not work on the next Android version (codenamed as “N” as of now).

Technique #2: Deriving the current running task from the UsageStatsManager API output
This technique uses the UsageStatsManager API introduced in Android 5.0 to gain access to a device’s usage history and statistics. The malware queries the usage statistics of all the applications for the past two seconds and then computes the most recent activity.

code_to_get_top_activity_0.PNG
Figure 1. Getting usage stats for all applications in the past two seconds, then computing the most recent

The malware requests the user to grant a system-level permission, “android.permission.PACKAGE_USAGE_STATS”, to use this API. This permission can only be granted through the Settings application. In order to overcome this, the malware uses social engineering by programmatically starting the usage access permission activity while masquerading as Google Chrome by mimicking the app’s icon and name.

Chrome_social_engineering_280.jpg
Figure 2. Starting intent programmatically to get PACKAGE_USAGE_STATS permission

The malware author may have got the inspiration for this idea from a proof-of-concept overlay malware project also hosted on GitHub. This technique of programmatically starting this particular activity is not supported by certain OEM vendors, such as Samsung.

Malware outsmarts new security enhancements
It is interesting to monitor how relentlessly the malware authors try to outsmart new security enhancements. Here the attackers have employed an effective social-engineering technique to remind us once again that the security of any system takes into account users’ level of awareness. Sometimes, the users just happen to be the weakest link in the system.

Source:http://www.symantec.com/

KNOWLEDGE BELONGS TO THE WORLD
Share on FacebookTweet about this on TwitterShare on LinkedInShare on RedditShare on Google+Share on TumblrPin on PinterestDigg this