When you buy through affiliate links in our content, we may earn a commission at no extra cost to you. Learn 
Android application markets are a convenient way for users to get apps. The markets are also a convenient way for bad guys to deliver malware. Marketplace owners, to their credit, try to sniff out bad apps using security measures such as Google Bouncer. Sadly, most – including Bouncer – are not up to the task. Bad guys almost immediately figured out how to tell when Bouncer, an emulation environment, was testing their code. In an earlier interview, Jon Oberheide, co-founder of Duo Security and the person who notified Google of the problem, explained:
"In order to make Bouncer effective, it must be indistinguishable from a real user’s mobile device. Otherwise, a malicious application will be able to determine it is running with Bouncer and not execute its malicious payload."
Another way bad guys fool Bouncer is by using a logic bomb. Throughout their history, logic bombs have wreaked havoc on computing devices. In this case, logic bomb code quietly thwarts malware checkers, much like Bouncer’s failure to activate the payload until the malicious app installs on an actual mobile device.
The bottom line is that Android app markets, unless they become efficient at detecting malware payloads in apps, are, in fact, a major distribution system for malware.
A New Twist to an Old Approach
The North Carolina State University research team of Tsung-Hsuan Ho, Daniel Dean, Xiaohui Gu, and William Enck may have found a solution. In their paper PREC: Practical Root Exploit Containment for Android Devices, the research team introduced their version of an anomaly detection scheme. PREC consists of two components: one that works with the app store’s malware detector, and one that is downloaded with the application to the mobile device.
The app store component is unique in that it employs what the researchers call "classified system call monitoring." This approach can dynamically identify system calls from high-risk components like third-party libraries (those not included in the Android system, but that come with the downloaded application). The logic here is that many malicious apps use their own libraries.
System calls from the high-risk third-party code obtained from this monitoring, plus the data obtained from the app-store detection process, allows PREC to create a normal behavior model. The model is uploaded to the PREC service, compared to existing models for accuracy, overhead, and robustness to mimicry attacks.
The updated model is then ready to be downloaded with the application any time the app is requested by someone visiting the app store.
That is considered the monitoring phase. Once the PREC model and application are downloaded to the Android device, PREC enters the enforcement stage – in other words, anomaly detection and malware containment.
Anomaly Detection
Once the app and PREC model are ensconced on the Android device, PREC monitors the third-party code, specifically system calls. If the system-call sequence is different from that monitored in the app store, PREC determines the likelihood that the abnormal behavior is an exploit. Once PREC determines that the activity is malicious, it moves into malware containment mode.
Malware Containment
If understood correctly, malware containment makes PREC unique when it comes to Android anti-malware. Due to the nature of the Android operating system, Android anti-malware applications are unable to remove malware or place it in quarantine because every application resides in a sandbox. This means that the user must manually remove the malicious app by first locating the malware in the Application section of the device’s System Manager, then opening the malware app’s statistics page, and tapping "uninstall."
What makes PREC unique is what the researchers call a "delay-based fine-grained containment mechanism." The general idea is to slow down suspicious system calls using a pool of separate threads. This forces the exploit to time out., resulting in an "Application Not Responding" status wherein the app is ultimately shut down by the Android operating system.
PREC could be programmed to kill the system-call threads, but it might break normal application operations if the anomaly detector makes a mistake. Rather than risk that, the researchers insert a delay during the thread’s execution.
"Our experiments show that most root exploits become ineffective after we slow down the malicious native thread to a certain point. The delay-based approach can handle the false alarms more gracefully since the benign application will not suffer from crashing or termination due to transient false alarms," the paper explains.
Test Results
To evaluate PREC, the researchers built a prototype and tested it against 140 apps (80 with native code and 60 without native code) – plus 10 apps (four known root exploit applications from the Malware Genome project, and six repackaged root exploit applications) – that contained malware. The malware included versions of DroidDream, DroidKungFu, GingerMaster, RATC, ZimperLich and GingerBreak.
The results:
- PREC successfully detected and stopped all the tested root exploits.
- It raised zero false alarms on the benign applications without native code. (Traditional schemes raise 67-92% per-app false alarms.)
- PREC reduced the false alarm rate on the benign applications with native code by more than one order of magnitude over traditional anomaly detection algorithms
Detailed test results can be found in the PREC research paper.
Benefits of PREC
Besides performing well in the tests and forwarding a workable method to contain Android malware, PREC had decidedly better numbers when it came to false positives and loss of performance. As to performance, the paper stated that PREC’s "classified monitoring scheme imposes less than 1% overhead, and the SOM anomaly detection algorithm imposes up to 2% overhead. Overall, PREC is lightweight, which makes it practical for smartphone devices."
Current malware-detection systems used by app stores are ineffective. PREC provides a high degree of detection accuracy, a low percentage of false alarms, and malware containment – something that does not currently exist.
The Challenge
The key to getting PREC to work is buy-in from the app marketplaces. It is just a matter of creating a database that describes how an application performs normally. PREC is one tool that can be used to accomplish that. Then, when a user downloads a desired application, the performance information (PREC profile) goes with the app, and will be used to baseline the app’s behavior while it is installed on the Android device.
