This is the second part of a two-part blog based on my paper for AVAR 2012 that discusses the complications in automating the analysis of Android malware.
Continuing from the first part of my paper…
Detection Criteria for Automation
Automation requires a set of robust detection criteria which make it possible to determine if an application is malware or legitimate.
Some of the criteria, the key factors that could be used for automation, are described below:
Static Analysis
Permissions. As per the Android architecture, applications, at install time, request users to grant permissions (known as “capabilities” in the context of Android) to access device data or other application data. The manifest file, one of the main components of the Android application package, carries the information about these access permissions. By verifying the permission list which the application is requesting with reference to its purported functionality, the application can be classified as either dangerous or clean.
Fig. 2 below shows the manifest file for the malware Android.Nickispy .This application claims to be a legitimate alarm receiver application but requests permission to process outgoing calls, send SMS, etc., that are irrelevant to its functionality, thus raising the suspicious flag.
Fig. 2, Capabilities Requested by Nickispy
Class names. It is seen in some of the malware applications that a specific malicious class appears with the same name bundled into many legitimate applications. It may be possible to flag applications based on blacklisted malicious class names.
Author name. All Android applications have to be signed. Author names of the applications could also help in casting suspicion on an application. This is possible as some of the malware applications carry the same author names, e.g. KingMall2010, we20090202 and myournet. Crawling many of the third party websites for known malware author names is likely to help the automation process.
Generic or heuristic rules based on judicious combinations of static criteria could assist the automation detection system to identify a new variant of known threat families within no time.
Behavioural Analysis
Sandbox emulation plays a major role in spotting a malware application amidst other running legitimate applications. Running an application within a controlled environment aids the automation system to understand the behaviour of the application in question, and make a consequent decision. Few of the behaviours that can be used to establish an application as malware are described below:
Internet Usage. Monitoring the network activity, i.e. measuring the frequency of network access, or the network traffic with respect to a particular service of an application, or any installed application in relation to its purported functionality would provide extra scope to categorise applications.
Root Access. Many Android malware require root access (administrative power) to execute the desired malefide functions on the victim’s device. They acquire root access by bundling with other good applications that require root access, by triggering an application in the victim device that requires root access, or by invoking exploits such as Exploid and RageAgainstTheCage that they carry within themselves.
Root access enables a malware application to protect itself from being easily identifiable. Installing the dropped application in the system partition makes it difficult to be uninstalled by the user. Therefore applications that manage to acquire root access within a certain context could be highly indicative of malware.
Some legitimate applications may also exhibit runtime behaviour which would trigger the above criteria so the detection logic, perhaps based on a scoring system, needs to be formulated with some care.
Note, however, that malware writers may be able to evade detection by suppressing the malware behaviour of their packages by sensing the presence of emulators [5]. Even Google Bouncer, a behavioural detection system from Google, is no exception [6].
Difficulties in Automated Detection Posed by PUAs
A major challenge in automated detection of Android malware comes from Potentially Unwanted Applications. PUAs complicate matters since they may look and smell like malware, but may not, in fact, be malware. PUAs may include, but are not limited to, Adware, Toolbars, Monitoring and Hack Tools, and Tools used to create applications, etc. Such applications have proven to be a major headache in the PC malware domain. In 2012 PUAs contributed a decent number to the “malware” count. As per the research conducted, the numbers of these applications are expected to rise consistently.
PUAs are often found bundled with other applications that require a EULA (End User Licence Agreement). By accepting the terms and conditions in this EULA, the user is indirectly authorising the installation of ad-supported or other applications bundled in the package. Hence, the user may find it difficult to consistently distinguish the applications installed in addition to the original application. There are similar issues for automated systems.
Marketing. Few applications may come bundled with known Android packages as a marketing strategy to display notification advertisements to promote a different application or the new version of the same application, in which the user may be interested.
These types of applications may not satisfy any of the previously-mentioned detection criteria to declare them as a malware. On the other hand these programs cannot be flagged as safe either, as they install themselves on the device without the user’s knowledge. Decision making on these applications is really challenging, as some users may consider these PUAs to be beneficial, the risks notwithstanding.
Ad-networks. Of late it has been seen that there are fake markets resembling to a close degree the Android official marketplace, that host malware applications alone for all mobile Operating System platforms like Android, Symbian, and J2ME. Alongside these, there are Ad-networks that also allow advertisers to either display advertisements for their application in the middle of the application session, or to drop an icon ad on the phone desktop, or to leave an advertisement in the notification bar of the user’s device.
For instance, Airpush.com is a website that claims to be the first PUSH notification mobile ad network for Android Smartphones. This website carries an application which when run asks the user for the IMEI (International Mobile Equipment Identity), MEID (Mobile Equipment Identifier) and ESN (Electronic Serial Number) of the device, even for the user to unsubscribe from any of the ads by AirPush. Automating the process of classifying such ad-networks, and deciding on related supporting applications which request personal information, is truly complex.
DoS attacks. Similar to the PC malware, DDos attacks are also witnessed for Android. With the help of a free online service which just requires a URL or HTML to create Android applications, new applications with the desired functionality can be created. For example, Android/DIYDoS [McAfee], grouped under PUAs, works with LOIC (Low Orbit Ion Cannon) in JavaScript format to send out a large number of network packets directly from the browser in order to perform a DDoS attack on a particular domain. When the user runs this application, the content of the URL is displayed in a browser, while the hidden JavaScript carries out a DDoS attack in the background [7]. As this application just directs the user to a particular URL, these kinds of applications or tools demand more attention in the automated detection process.
Tools. Monitoring tools like keyloggers may log the activity on the device including SMS messages, call details, network traffic, etc., for which they have been designed. The questions lie in the installation method (if they get installed without the user’s knowledge), and if they leak the logged information.
There could also be a scenario when the application masquerades as a legitimate application that requires root access, and behind the scenes it acts as an agent for other malware applications, e.g. to provide them with root access. Analysing these kinds of applications automatically requires a lot of extra effort and care, as the maliciousness of one application can only be identified within the context of another application’s malware behaviour.
Mobile handset manufacturers build in a few applications which the manufacturing company believes to be of interest to the user. These applications may have the functionality to intercept user data. One such example, Android.HTClogger, collected significant amounts of user information and stored the data within itself. Even though these applications do not conduct any malpractice, there is a possibility that other malware applications could use this data.
Another interesting application of this kind, Mobile Tracker, comes inbuilt with the Samsung Dive that allows the owner to have control over the device through SMS, in case of it being lost or stolen. This application awaits a trigger from a predefined number or website from which it may intercept any incoming messages.
Some of the major problems in the automated detection process for Android threats are discussed above. Unfortunately automation may classify a PUA as malware, or may fail to classify a threat as malware, or may fail to flag a PUA if the thresholds are not hit. However, automation is not meant to be a 100% solution.
Mitigations
It goes without saying that the IT security industry always strives to protect the user from any threat, be it for computers or mobile phones. Automated detection systems would help protect users by flagging new variants of old threats, or even brand new threats, in a timely fashion. The pitfalls in this automated detection process have already been highlighted.
Fortunately, some of the static criteria used in the automated detection system can also contribute to whitelisting an Android application. There is an ongoing industry-wide effort to collate and store whitelist metadata (that could include inter alia checksum, signer’s name, capabilities, etc.,) for Android applications in a centralized location. AV vendors would then be able to query this central database to decide if an application is safe or not. This could allow AV vendors to be more aggressive with their detection criteria without increasing the risk of false positives.
In addition, mobile AV vendors could come up with a common set of rules to establish whether an application is a PUA or not. Doing so could reduce the level of ambiguity when attempting to categorise PUAs versus malware, and thus may minimize the complications posed by Android PUAs in the automated detection process.
Conclusion
The Android platform is here to stay. Given its mass user appeal for a variety reasons Android usage has shot through the roof. This provides an irresistible opportunity for malware authors and others who are ethically weak to milk Android users for monetary gain. They have grabbed this opportunity with glee.
As was the case for PC malware over the years, Android malware have evolved in number and diversity of functionality. There has even been a proliferation of Potentially Unwanted Applications for Android. The increasing number and severity of Android badware necessitates a robust AV industry response. AV vendors are likely to implement automated detection infrastructure based on static and dynamic rules, proactive protection, and cloud lookups with the aim to protect the Android user at the earliest. One gets a sense of déjà vu vis-a-vis the experience with PC malware.
PUAs are applications which sometimes have functionality or behaviour which push the boundaries between malware and not-malware, infuriating some users and complicating the process of detection, whether automated or proactive. This is because categorisation of PUAs is a subjective process, and the misclassification of a PUA as malware does not always go down too well with either the user or the software’s author.
Industry-wide collaborations to collate useful metadata on known clean Android applications, along with an agreed, consistent set of criteria to define PUAs could help in separating the wheat from the chaff, especially in the case of an automated detection system. Unfortunately, as opinions always differ, unearthing an Android app may yet remain a puzzle.
References:
[1]. Based on internal data
[2]. http://www.symantec.com/connect/blogs/android-trojan-invades-akb48-elections-japan
[3]. http://www.securityweek.com/resilient-smszombie-infects-500000-android-users-china
[4]. http://www.securelist.com/en/blog/208193306/Android_malware_new_traps_for_users
[5]. http://www.pcworld.com/article/256922/researchers_find_ways_to_bypass_googles_
android_malware_scanner.html
[6]. http://www.dexlabs.org/blog/btdetect
[7]. http://blogs.mcafee.com/mcafee-labs/android-diy-dos-app-boosts-hacktivism-in-south-america
Images courtesy of:
vectorcast.com
expertslogin.com
puvidya.wordpress.com
careerrocketeer.com
bambicorso.co
ihackers.info
businessreviewindia.in
ehow.com
agilehelpline.com
yourhealthyourhome.com
V.Dhanalakshmi
Malware Analyst, K7TCL
If you wish to subscribe to our blog, please add the URL provided below to your blog reader:
https://labs.k7computing.com/feed/
