2019 IEEE International Conference on Software Testing,Verification and Validation Workshops (ICSTW) Automatic Generation of Capability Leaks' Exploits for Android Applications Mingsong Zhou,Fanping Zeng,Yu Zhang,Chengcheng Lv,Zhao Chen,Guozhu Chen University of Science and Technology of China Hefei.Anhui,China billzeng @ustc.edu.cn Abstract-The capability leak of Android applications is one 1)We propose a tool which can automatically generate kind of serious vulnerability.It causes other apps to leverage its capability leaks'exploits of Android applications. functions to achieve their illegal goals.In this paper,we propose 2)We utilize CFG reduction and CG search optimization a tool which can automatically generate capability leaks' to optimize symbolic execution,which make our tool exploits of Android applications with path-sensitive symbolic execution-based static analysis and test.It can aid in reducing can apply to practical apps. false positives of vulnerability analysis and help engineers find 3)We analyzed 439 popular apps of various categories. bugs.We utilize control flow graph(CFG)reduction and call And we found 2239 capability leaks of 16 permissions, graph(CG)search optimization to optimize symbolic execution, including some very serious capability leaks. which make our tool applicable for practical apps.By applying our tool to 439 popular applications of the Wandoujia(a famous II.SYSTEM OVERVIEW app market in China)in 2017,we found 2239 capability leaks of 16 kinds of permissions.And the average analysis time was Figure I depicts an overview of our work,which is 4 minutes per app.A demo video can be found at the website https://youtu.be/dXFMNZWxEc0. mainly divided into four parts.In the first part,we extract Index Terms-capability leak,Android,inter-component app's call graph,control flow graphs for each method and communication,symbolic execution find all Android permission-protected APIs (i.e.tgtAPD). Then we reduce our CG by removing methods that are I.INTRODUCTION not in paths between exported-components'methods (i.e. Capability Leak,also known as Permission Re-Delegation startPoint)and tgtAPI.In the second part,we find all paths [1],occurs when a vulnerable application performs a priv- between startPoint and tgtAPI,which represent all possible ileged action on behalf of a malicious application with- capability leak paths.We utilize CFG reduction and CG out permission.Inter-component communication between search optimization to optimize the process of finding paths. Then we extract the intent constraints of each path and Android applications is common.A lot of apps provide convert these intent constraints into SMT2 language in the some special functions for other apps by exported compo- third part.Using the Microsoft Z3 constraint solver [4]to nents.However,many developers do not fully understand solve,we generate intent test cases based on the results of the confused use rules in Android application components. They either expose the components unintentionally [2].or Z3.In the fourth part,test-app utilizes the intent test cases expose them intentionally but fail to check the component to launch the instrumented app.Then our tool reads the test caller's permissions.It causes several security problems.For log and generate the detection report of the detected app. example,a capability leak MASTER CLEAR is found in The detection report includes capability leaks of detected Samsung Epic 4Gs phone image [3].It is easy to delete app and exploits of these capability leaks.In the following all user data by constructing an intent.Therefore,research sections,we will introduce each part in detail. of capability leaks of Android applications is important and A.Extract CG and each method's CFG significant. In this paper,we elaborate capability leak of Android To obtain a call graph suitable for analysis of Android applications as follows:if there is an app B.without per- apps,the call graph must take into account implicit calls mission p.can invoke A's code protected by permission of Android app.Android implicit calls include component p directly (without user's UI operation)from A's exported lifecycle methods,callback methods,inter-component com- components,we say that app A has a permission p capability munication methods.Our tool is based on soot [5]and we leak.In our paper,we take into account all APIs protected by use identical methods as described in previous works [6][7]. permissions even if external intent data do not flow in these where the call graph is continuously updated with identified APIs.Because some APIs do not need any parameters and callback registrations until a fixed point is reached. APIs without external input data can also cause immense To know what permissions the API's invocation needs,we destruction. use the APIPermissionMap provided by the Androguard [8]. Our main contributions are as follows: which stores the map between Android permissions and the 978-1-7281-0888-9/19/S31.00©2019EEE 291 IEEE D0I10.1109/1CSTW.2019.00068 Φcomputer society
Automatic Generation of Capability Leaks’ Exploits for Android Applications Mingsong Zhou, Fanping Zeng, Yu Zhang, Chengcheng Lv, Zhao Chen, Guozhu Chen University of Science and Technology of China Hefei, Anhui, China billzeng@ustc.edu.cn Abstract—The capability leak of Android applications is one kind of serious vulnerability. It causes other apps to leverage its functions to achieve their illegal goals. In this paper, we propose a tool which can automatically generate capability leaks’ exploits of Android applications with path-sensitive symbolic execution-based static analysis and test. It can aid in reducing false positives of vulnerability analysis and help engineers find bugs. We utilize control flow graph (CFG) reduction and call graph (CG) search optimization to optimize symbolic execution, which make our tool applicable for practical apps. By applying our tool to 439 popular applications of the Wandoujia (a famous app market in China) in 2017, we found 2239 capability leaks of 16 kinds of permissions. And the average analysis time was 4 minutes per app. A demo video can be found at the website https://youtu.be/dXFMNZWxEc0. Index Terms—capability leak, Android, inter-component communication, symbolic execution I. INTRODUCTION Capability Leak, also known as Permission Re-Delegation [1], occurs when a vulnerable application performs a privileged action on behalf of a malicious application without permission. Inter-component communication between Android applications is common. A lot of apps provide some special functions for other apps by exported components. However, many developers do not fully understand the confused use rules in Android application components. They either expose the components unintentionally [2], or expose them intentionally but fail to check the component caller’s permissions. It causes several security problems. For example, a capability leak MASTER CLEAR is found in Samsung Epic 4Gs phone image [3]. It is easy to delete all user data by constructing an intent. Therefore, research of capability leaks of Android applications is important and significant. In this paper, we elaborate capability leak of Android applications as follows: if there is an app B, without permission p, can invoke A’s code protected by permission p directly (without user’s UI operation) from A’s exported components, we say that app A has a permission p capability leak. In our paper, we take into account all APIs protected by permissions even if external intent data do not flow in these APIs. Because some APIs do not need any parameters and APIs without external input data can also cause immense destruction. Our main contributions are as follows: 1) We propose a tool which can automatically generate capability leaks’ exploits of Android applications. 2) We utilize CFG reduction and CG search optimization to optimize symbolic execution, which make our tool can apply to practical apps. 3) We analyzed 439 popular apps of various categories. And we found 2239 capability leaks of 16 permissions, including some very serious capability leaks. II. SYSTEM OVERVIEW Figure 1 depicts an overview of our work, which is mainly divided into four parts. In the first part, we extract app’s call graph , control flow graphs for each method and find all Android permission-protected APIs (i.e. tgtAPI). Then we reduce our CG by removing methods that are not in paths between exported-components’ methods (i.e. startPoint) and tgtAPI. In the second part, we find all paths between startPoint and tgtAPI, which represent all possible capability leak paths. We utilize CFG reduction and CG search optimization to optimize the process of finding paths. Then we extract the intent constraints of each path and convert these intent constraints into SMT2 language in the third part. Using the Microsoft Z3 constraint solver [4] to solve, we generate intent test cases based on the results of Z3. In the fourth part, test-app utilizes the intent test cases to launch the instrumented app. Then our tool reads the test log and generate the detection report of the detected app. The detection report includes capability leaks of detected app and exploits of these capability leaks. In the following sections, we will introduce each part in detail. A. Extract CG and each method’s CFG To obtain a call graph suitable for analysis of Android apps, the call graph must take into account implicit calls of Android app. Android implicit calls include component lifecycle methods, callback methods, inter-component communication methods. Our tool is based on soot [5] and we use identical methods as described in previous works [6] [7], where the call graph is continuously updated with identified callback registrations until a fixed point is reached. To know what permissions the API’s invocation needs, we use the APIPermissionMap provided by the Androguard [8], which stores the map between Android permissions and the 291 2019 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW) 978-1-7281-0888-9/19/$31.00 ©2019 IEEE DOI 10.1109/ICSTW.2019.00068
2.Find all paths between 3.Compute path's intent test cases a startPoint and tgtAPI CFG reducedcr G a川 extract intent SMT 2 CG Z3 SMT result paths constraints language」solver model Map gtAP start input intent e instrument app using log test cases app statement before tgtAPI test-app app analyse detection report test log 4.Test-app reads intent test cases and starts instrumented app Fig.1.System overview Android API.We utilize it to find all Android permission- 1//before reduction protected APIs (tgtAP/s).Then we utilize backward traversal public void doTaskl(String pName){ int pid=643: from tgtAP/and forward traversal from startPoint to remove if (x>5) nodes (methods)not in the paths between startPoint and rgtAPI,which can substantially reduce the search scope if (intent.getAction.equals("kill")) //branchI when find all paths between startPoint and tgtAPI. String keys=”pid"; pid=intent.getIntExtra(key); B.Get Intent Conditions of Paths between StartPoint and 10 TgtAPI 11 else f...}//branch 2 12 CG and CFG are directed cyclic graph.In our paper, 1 else the paths that we search between startPoint and tgtAPI are { Eulerian path.To reduce the scale of problem,we optimize 15 if (y 7){...//branch 5 analysis. 18 else {...}/branch 6 1)CG Search Optimization:Suppose there is a path 30 killProcess (pName,pid)://tgtAPI ABCDE,where A,B.C,D and E are methods.A is 21 startPoint and E is tgtAPI.At First,we use the way of sec- after reduction tion II-B2 to reduce CFG of each method.Then we compute public void doTask2(String pName){ int pid 643: all intent constraints of all paths between two methods (i.e. if(x>5) A and B.B and C.C and D.D and E).And we utilize Z3 to solve all intent conditions of all paths between methods if (intent.getAction.equals("kill")) //branch I (named intentConditionSet).This process will be introduced String key-”pid”; in section II-C in detail.intentConditionSet will be saved and pid=intent.getIntExtra(key); use repeatedly.It will save a lot of time,because an edge Helse {//branch 2 2 (method invocation)will be in multiple paths.Finally,we else (}//branch 3 get intent conditions of this path(i.e.ABCDE)by using 34 killProcess(pName,pid)://tgtAPI intersection operation for these intentConditionSets.When we compute intent conditions of a path,we merge identical Listing 1.Reduce CFG intent conditions and remove conflict intent conditions.This reduces the number of intent conditions that need to be 2)CFG Reduction:In our paper,we only focus on combined when we search a path and it avoids duplicate statements related to external intent (intent from another and useless intent test cases.We also use function summary application).because the unique input of inter-component which stores all possible intent conditions of paths from communication is intent.We utilize a light-weight inter- current method to tgtAP/.When the method is analyzed procedural data-flow analysis from sources [9](only use again,the result is taken directly and do not need further sources related to external intent,for example:getIntent(, analysis. onReceive(Intent))to remove the statements that are not 292
Fig. 1. System overview Android API. We utilize it to find all Android permissionprotected APIs (tgtAPIs). Then we utilize backward traversal from tgtAPI and forward traversal from startPoint to remove nodes (methods) not in the paths between startPoint and tgtAPI, which can substantially reduce the search scope when find all paths between startPoint and tgtAPI. B. Get Intent Conditions of Paths between StartPoint and TgtAPI CG and CFG are directed cyclic graph. In our paper, the paths that we search between startPoint and tgtAPI are Eulerian path. To reduce the scale of problem, we optimize search process and reduce each method’s CFG by data-flow analysis. 1) CG Search Optimization: Suppose there is a path ABCDE, where A, B, C, D and E are methods. A is startPoint and E is tgtAPI. At First, we use the way of section II-B2 to reduce CFG of each method. Then we compute all intent constraints of all paths between two methods (i.e. A and B, B and C, C and D, D and E). And we utilize Z3 to solve all intent conditions of all paths between methods (named intentConditionSet). This process will be introduced in section II-C in detail. intentConditionSet will be saved and use repeatedly. It will save a lot of time, because an edge (method invocation) will be in multiple paths. Finally, we get intent conditions of this path (i.e. ABCDE) by using intersection operation for these intentConditionSets. When we compute intent conditions of a path, we merge identical intent conditions and remove conflict intent conditions. This reduces the number of intent conditions that need to be combined when we search a path and it avoids duplicate and useless intent test cases. We also use function summary which stores all possible intent conditions of paths from current method to tgtAPI. When the method is analyzed again, the result is taken directly and do not need further analysis. 1 // before reduction 2 public void doTask1 ( S t r i n g pName ) { 3 int pid =643; 4 i f ( x > 5 ) 5 { 6 i f ( intent . getAction . equals ( ”kill” ) ) 7 { // branch1 8 String key=”pid” ; 9 pid=intent . get IntExt ra ( key ) ; 10 ... 11 } else { ... } // branch 2 12 } 13 else 14 { 15 i f ( y 7 ) { ... } // branch 5 18 else { ... } // branch 6 19 } 20 killProcess ( pName , pi d ) ; // tgtAPI 21 } 22 // after reduction 23 public void doTask2 ( S t r i n g pName ) { 24 int pid = 643; 25 i f ( x>5) 26 { 27 i f ( intent . getAction . equals ( ”kill” ) ) 28 { // branch 1 29 String key=”pid” ; 30 pid=intent . get IntExt ra ( key ) ; 31 } else {} // branch 2 32 } 33 else {} // branch 3 34 killProcess ( pName , pi d ) ; // tgtAPI 35 } Listing 1. Reduce CFG 2) CFG Reduction: In our paper, we only focus on statements related to external intent (intent from another application), because the unique input of inter-component communication is intent. We utilize a light-weight interprocedural data-flow analysis from sources [9] (only use sources related to external intent, for example: getIntent(), onReceive(Intent)) to remove the statements that are not 292
related to the external intent.Our inter-procedural data-flow RQ 1:What is the accuracy of path's intent conditions is mainly based on the reaching definition technique [10]. we generate? which focuses on statically determining which definitions RQ 2:Can our tool be applied to practical apps and may reach a given point in the code.But we do not find capability leaks Can exploits help devel- remove intent-irrelevant condition statements if their branch opers find bugs? statements contain intent-relevant statements.For example RQ 3:Our tool uses symbolic execution,what is run- as shown in Listing 1,the statement if(z 5)can not time efficiency of our work? be removed because the true branch of if(5)has intent-relevant statements.But we can remove if(y7).We also reserve statements that intent- APK Size APK SLOC relevant statements depend.For example,the statement Distribution Distribution String key ="pid"will not be removed in listing 100,00 1000.00 90.00 8 900.00 92137 1.Since most statements are not related to intent,it is 0.00 800.00 76,33 possible to substantially reduce the CFG.Thus,our method 70.00 700.00 is efficient.As shown in Listing 1,there are 6 branches 60.00 600.00 50.0 500.00 in total 6 paths in the doTask/method.But none of the 40.00 400.00 5 branches have any statements related to intent data,so 30.00 300.00 20.00 we can simplify doTaskI method into doTask2 method and 200.00 10.00 100.00 doTask2 method only has 3 branches in total 3 paths. 0.00 0.00 247 C.Compute Path's Intent Constraints Z3 is a state-of-the-art theorem prover from Microsoft Fig.2.APK Size and SLOC Distribution Research.It can be used to check the satisfiability of logical formulas over one or more theories.We uti- The following experiment results are collected on Ubuntu lize Z3 to solve intent conditions.At first,we get 18.04 with a 3.6GHz Intel Core i7 CPU and 32GB RAM all statements of a path.Then we will process state- Our dataset consists of 18 categories of applications from ments separately to generate intent constraints in for- Wandoujia in 2017.We select 45 most popular apps for each mat of SMT2 language.These statements mainly in- category and in total 810 apps,then remove hardened apps clude intent.get Action,intent.hasCategory,intent.get [11]and apps that soot can not analyze [12].Finally,we Extra,equals,if,variable definition and other operation get 439 apps.These apps size and SLOC(source lines of statements about value of intent attribute.For example. code)are shown in figure 2.What we need to explain is if statement is if(str.equals("success")),the SMT2 lan- that the use of harden technology is becoming more and guage is(assert(=str”success'”)）.Z3 will return more popular,which causes that we can not get the real the value of str is"success".Our tool can get correct string source code of app.Fortunately,our tool is proposed for and primitive values in most cases when compute path's developers,and developers can use our tool to detect the app intent constraints. before it is hardened,so our tool is still useful.To answer D.Test-app Test Instrumented App RQ1,we divide 439 apps into five categories (0-9M,9M- 18M,18M-27M,27M-36M,36M-)according to app size.We The intent test cases that we generate satisfy the intent select 5 apps randomly from each category in total 25 apps conditions of paths,but there are some other conditions of to evaluate our tool. paths that we can not control.So we need use dynamic way to test whether paths are reachable.We insert log statements before tgtAPIs in detected app and repackage A.ROl:Accuracy of Path's Intent Conditions detected app as a new app (named instrumented app).And the log statement mainly records these information:test case We run our tool for these 25 apps and record the number,exported-component's name,package name,tgtAPI statements that we can not handle (named unhandledSer). and etc.Then we develop test-app which do not have any At the same time,we manually check each statement we permissions and it utilizes test cases to test instrumented can handle and record the statements that we can not app.If the tgtAPI can be triggered,the log will be generated, get correct value (named incorrectSer).For example,a indicating that the app occurs a capability leak.Then our tool string value from network.allStatementsSet is a set of all reads the test log to generate a detection report for detected intent-relevant statements.We use the following correctness app.The exploits of capability leaks in detection report can metric to access the accuracy of intent conditions that we trigger the corresponding capability leak,and they can help generate: size(allStatementsSet)-size(unhandledSet)-size(incorrectSet) developers analyse bugs. size(allstatementsSet) The accuracy results are shown in figure 3.The accuracy of III.EVALUATION path's intent conditions is high and no app has a rate lower To assess our work,we study the following research than 90%.This indicates that for the overwhelming majority questions: of cases,our tool can generate correct intent conditions. 293
related to the external intent. Our inter-procedural data-flow is mainly based on the reaching definition technique [10], which focuses on statically determining which definitions may reach a given point in the code. But we do not remove intent-irrelevant condition statements if their branch statements contain intent-relevant statements. For example, as shown in Listing 1, the statement if(x > 5) can not be removed because the true branch of if(x > 5) has intent-relevant statements. But we can remove if(y 7). We also reserve statements that intentrelevant statements depend. For example, the statement String key = ”pid” will not be removed in listing 1. Since most statements are not related to intent, it is possible to substantially reduce the CFG. Thus, our method is efficient. As shown in Listing 1, there are 6 branches in total 6 paths in the doTask1 method. But none of the 5 branches have any statements related to intent data, so we can simplify doTask1 method into doTask2 method and doTask2 method only has 3 branches in total 3 paths. C. Compute Path’s Intent Constraints Z3 is a state-of-the-art theorem prover from Microsoft Research. It can be used to check the satisfiability of logical formulas over one or more theories. We utilize Z3 to solve intent conditions. At first, we get all statements of a path. Then we will process statements separately to generate intent constraints in format of SMT2 language. These statements mainly include intent.getAction,intent.hasCategory, intent.get ∗ Extra, equals, if, variable definition and other operation statements about value of intent attribute. For example, if statement is if(str.equals(”success”)), the SMT2 language is (assert (= str ”success”)). Z3 will return the value of str is ”success”. Our tool can get correct string and primitive values in most cases when compute path’s intent constraints. D. Test-app Test Instrumented App The intent test cases that we generate satisfy the intent conditions of paths, but there are some other conditions of paths that we can not control. So we need use dynamic way to test whether paths are reachable. We insert log statements before tgtAPIs in detected app and repackage detected app as a new app (named instrumented app). And the log statement mainly records these information: test case number, exported-component’s name, package name, tgtAPI and etc. Then we develop test-app which do not have any permissions and it utilizes test cases to test instrumented app. If the tgtAPI can be triggered, the log will be generated, indicating that the app occurs a capability leak. Then our tool reads the test log to generate a detection report for detected app. The exploits of capability leaks in detection report can trigger the corresponding capability leak, and they can help developers analyse bugs. III. EVALUATION To assess our work, we study the following research questions: RQ 1: What is the accuracy of path’s intent conditions we generate? RQ 2: Can our tool be applied to practical apps and find capability leaks ? Can exploits help developers find bugs? RQ 3: Our tool uses symbolic execution, what is runtime efficiency of our work? Fig. 2. APK Size and SLOC Distribution The following experiment results are collected on Ubuntu 18.04 with a 3.6GHz Intel Core i7 CPU and 32GB RAM. Our dataset consists of 18 categories of applications from Wandoujia in 2017. We select 45 most popular apps for each category and in total 810 apps, then remove hardened apps [11] and apps that soot can not analyze [12]. Finally, we get 439 apps. These apps size and SLOC(source lines of code) are shown in figure 2. What we need to explain is that the use of harden technology is becoming more and more popular, which causes that we can not get the real source code of app. Fortunately, our tool is proposed for developers, and developers can use our tool to detect the app before it is hardened, so our tool is still useful. To answer RQ1, we divide 439 apps into five categories (0-9M,9M- 18M,18M-27M,27M-36M,36M-) according to app size. We select 5 apps randomly from each category in total 25 apps to evaluate our tool. A. RQ1: Accuracy of Path’s Intent Conditions We run our tool for these 25 apps and record the statements that we can not handle (named unhandledSet). At the same time, we manually check each statement we can handle and record the statements that we can not get correct value (named incorrectSet). For example, a string value from network. allStatementsSet is a set of all intent-relevant statements. We use the following correctness metric to access the accuracy of intent conditions that we generate: size(allStatementsSet)−size(unhandledSet)−size(incorrectSet) size(allstatementsSet) The accuracy results are shown in figure 3. The accuracy of path’s intent conditions is high and no app has a rate lower than 90%. This indicates that for the overwhelming majority of cases, our tool can generate correct intent conditions. 293
1000 is on the youtube 2.Except for capability leaks,we found 10 98.00% that a lot of apps crashed when we used our exploits to launch them.which is a kind of local denial of service attack. 96.00 So these apps must be more robust,it may be leveraged by 94.00% other apps for vicious competition.Therefore,our exploits 9200 are valid and help users find bugs. C.RO3:Runtime Efficiency 8800 Table II presents static analysis part and dynamic test part's average,minimum,and maximum execution time of 891011121314151617181920212223242 439 apps.As shown in table II,The total average time for each app analysis is less than 4 minutes.The maximum time Fig.3.Accuracy of Intent Conditions for static analysis app is 5168.494s,which is about 1.43h. 1.43h is a reasonable analysis time for generating highly precise intent test cases and few apps'static analysis is more B.RO2:Can our tool apply to practical apps? than 16 min in our statistics.Therefore,our optimization 1)Experiment Results:The analysis result of 439 apps for symbolic execution of inter-component capability leaks is shown in Table I,For each capability leak,we counted detection is efficient,and our tool meets the requirement of the number of apps have the capability leak (i.e.App actual use Count column)and the number of the capability leak's points in all apps (i.e.All Count column).There are 2239 TABLE II EXECUTION-TIME capability leaks of 16 kinds of permissions.including some serious capability leaks,such as DISABLE_KEYGUARD. Execution Time Period KILL BACKGROUND PROCESSES. Average Minimum Maximum MOD- Static 185.228s(3min) 0.078s 5168.494s1.43h) IFY_AUDIO_SETTINGS and so on.Therefore, ou山 Dynamic 52.984s 7.414s 889.919s14.82min) tool can detect capability leaks efficiently. TABLE I IV.RELATED WORK CAPABILITY LEAKS LIST There are many static analysis works for detecting security Permission App Count All Count problems of inter-component communication (for example: DISABLE KEYGUARD 8 9 [13].[14)).But they all cannot determine whether the CHANGE_WIFI MULTICAST_STATE SET_WALLPAPER HINTS 4 4 vulnerability really exists and developers have to spend much BROADCAST STICKY 84 time in vulnerability analysis.Fang Liu et al.[15]proposed ACCESS FINE LOCATION 106 180 the MR-Droid to find inter-component communication vul- ACCESS COARSE LOCATION 94 157 CHANGE WIFI STATE nerabilities among practical apps.which uses the map-reduce ACCESS NETWORK STATE 323 1071 system to detect communication vulnerabilities among large- GET TASKS 216 272 scale apps.The results of the tool are limited by the dataset WAKE LOCK 56 81 and it does not take into account malicious apps.Its result ACCESS WIFI STATE 227 318 MODIFY_AUDIO_SETTINGS 4 4 can not indicate the detected app is security.And [16]also SET_WALLPAPER 1 has this problem. BLUETOOTH 10 READ PHONE_STATE V.CONCLUSION 30 35 KILL_BACKGROUND_PROCESSES We propose an effective tool which can automatically generate capability leaks'exploits of Android applications 2)Exploitation Analysis:App A is a popular lock screen with symbolic execution and test.It can aid in reducing app and has been downloaded more than 10 million times. false positives of vulnerability analysis and help developers We found that it has a DISABLE_KEYGUARD capabil- find bugs.Our tool can apply to practical apps because of ity leak.We guess that there is an illegal login vulner- our optimized symbolic execution.We analyzed 439 apps in ability.Then We use exploits generated by our tool to Wandoujia and found 2239 capability leaks of 16 kinds of attack app and they help us pass the lock sceen without permission. a password.The attack demo is on the youtube I.We ACKNOWLEDGMENT have informed the app's developers.App B is a clean This work is mainly inspired by LetterBomb [171.This app,whose function is phone clean.And we found that it work is supported partly by the National Key RD Program has KILL_BACKGROUND_PROCESSES capability leak.It of China 2018YFB0803400 and National Natural Science may be used by other apps to kill processes.The attack demo Foundation of China (NSFC)under grant 61772487. 1https://youtu.be/rWdSiWUy2bc 2https://youtu.be/YE84G4yko0A 294
Fig. 3. Accuracy of Intent Conditions B. RQ2: Can our tool apply to practical apps? 1) Experiment Results: The analysis result of 439 apps is shown in Table I, For each capability leak, we counted the number of apps have the capability leak (i.e. App Count column) and the number of the capability leak’s points in all apps (i.e. All Count column). There are 2239 capability leaks of 16 kinds of permissions, including some serious capability leaks, such as DISABLE KEYGUARD, KILL BACKGROUND PROCESSES, MODIFY AUDIO SETTINGS and so on. Therefore, our tool can detect capability leaks efficiently. TABLE I CAPABILITY LEAKS LIST Permission App Count All Count DISABLE KEYGUARD 8 9 CHANGE WIFI MULTICAST STATE 1 1 SET WALLPAPER HINTS 4 4 BROADCAST STICKY 84 84 ACCESS FINE LOCATION 106 180 ACCESS COARSE LOCATION 94 157 CHANGE WIFI STATE 3 4 ACCESS NETWORK STATE 323 1071 GET TASKS 216 272 WAKE LOCK 56 81 ACCESS WIFI STATE 227 318 MODIFY AUDIO SETTINGS 4 4 SET WALLPAPER 1 1 BLUETOOTH 7 10 READ PHONE STATE 30 35 KILL BACKGROUND PROCESSES 7 8 2) Exploitation Analysis: App A is a popular lock screen app and has been downloaded more than 10 million times. We found that it has a DISABLE KEYGUARD capability leak. We guess that there is an illegal login vulnerability. Then We use exploits generated by our tool to attack app and they help us pass the lock sceen without a password. The attack demo is on the youtube 1. We have informed the app’s developers. App B is a clean app, whose function is phone clean. And we found that it has KILL BACKGROUND PROCESSES capability leak. It may be used by other apps to kill processes. The attack demo 1https://youtu.be/rWdSiWUy2bc is on the youtube 2. Except for capability leaks, we found that a lot of apps crashed when we used our exploits to launch them, which is a kind of local denial of service attack. So these apps must be more robust, it may be leveraged by other apps for vicious competition. Therefore, our exploits are valid and help users find bugs. C. RQ3: Runtime Efficiency Table II presents static analysis part and dynamic test part’s average, minimum, and maximum execution time of 439 apps. As shown in table II, The total average time for each app analysis is less than 4 minutes. The maximum time for static analysis app is 5168.494s, which is about 1.43h. 1.43h is a reasonable analysis time for generating highly precise intent test cases and few apps’ static analysis is more than 16 min in our statistics. Therefore, our optimization for symbolic execution of inter-component capability leaks detection is efficient, and our tool meets the requirement of actual use. TABLE II EXECUTION-TIME Period Execution Time Average Minimum Maximum Static 185.228s(3min) 0.078s 5168.494s(1.43h) Dynamic 52.984s 7.414s 889.919s(14.82min) IV. RELATED WORK There are many static analysis works for detecting security problems of inter-component communication (for example: [13], [14]). But they all cannot determine whether the vulnerability really exists and developers have to spend much time in vulnerability analysis. Fang Liu et al. [15] proposed the MR-Droid to find inter-component communication vulnerabilities among practical apps, which uses the map-reduce system to detect communication vulnerabilities among largescale apps. The results of the tool are limited by the dataset and it does not take into account malicious apps. Its result can not indicate the detected app is security. And [16] also has this problem. V. CONCLUSION We propose an effective tool which can automatically generate capability leaks’ exploits of Android applications with symbolic execution and test. It can aid in reducing false positives of vulnerability analysis and help developers find bugs. Our tool can apply to practical apps because of our optimized symbolic execution. We analyzed 439 apps in Wandoujia and found 2239 capability leaks of 16 kinds of permission. ACKNOWLEDGMENT This work is mainly inspired by LetterBomb [17]. This work is supported partly by the National Key RD Program of China 2018YFB0803400 and National Natural Science Foundation of China (NSFC) under grant 61772487. 2https://youtu.be/YE84G4yko0A 294
REFERENCES applications,"in Proceedings of the 2017 1Ith Joint Meeting on Foundations of Sofware Engineering.ESEC/FSE 2017.Paderborn. [I]A.P.Felt,H.J.Wang.A.Moshchuk,S.Hanna,and E.Chin Germany.September 4-8.2017.2017.pp.661-671.[Online]. "Permission re-delegation:Attacks and defenses,"in 20th USENIX Available:http://doi.acm.org/10.1145/3106237.3106286 Security Symposium.San Francisco.CA.USA.August 8-12,2011. Proceedings.2011.[Onlinel.Available:http://static.usenix.org/events/ secl1/tech/full_papers/Felt.pdf [2]J.Yan,X.Deng.P.Wang,T.Wu,J.Yan,and J.Zhang,"Characterizing and identifying misexposed activities in android applications,"in Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering.ASE 2018,Montpellier.France. September 3-7.2018,2018,pp.691-701.[Online].Available: htps/doi.org/10.1145/3238147.3238164 [3]M.C.Grace.Y.Zhou.Z.Wang.and X.Jiang,"Systematic detection of capability leaks in stock android smartphones,"in 19th Annual Network and Distributed System Security Symposium.NDSS 2012.San Diego,California,USA.February 5-8,2012.2012 [Online].Available:https://www.ndss-symposium.org/ndss2012/ systematic-detection-capability-leaks-stock-android-smartphones [4]"Z3 wiki,"https://github.com/Z3Prover/z3/wiki. [51 "Soot."https://sable.github.io/soot/. [6]S.Arzt,S.Rasthofer.C.Fritz,E.Bodden,A.Bartel,J.Klein, Y.L.Traon,D.Octeau,and P.D.McDaniel,"Flowdroid:precise context,flow,field,object-sensitive and lifecycle-aware taint analysis for android apps,"in ACM SIGPLAN Conference on Programming Language Design and Implementation,PLDI '14.Edinburgh,United Kingdom June 09.11.2014.2014.pp.259-269.[Online]. Available:http://doi.acm.org/10.1145/2594291.2594299 [7]L.Li,A.Bartel,T.F.Bissyande,J.Klein,Y.L.Traon,S.Arzt, S.Rasthofer,E.Bodden.D.Octeau.and P.D.McDaniel,"Iccta Detecting inter-component privacy leaks in android apps"in37h IEEE/ACM International Conference on Software Engineering,ICSE 1 IOnlimel Avable:hps/dorC0 2015.Florence.Italy.May 16-24.2015.Volume 1.2015. [8]A.Desnos er al.,"Androguard:Reverse engineering.malware and goodware analysis of android applications,"URL code.google com/p/androguard,p.153.2013. [9]S.Rasthofer,S.Arzt,and E.Bodden,"A machine-learning for classifving and categorizing android sources and sinks. Annual Network and Distributed System Security Symposium,NDSS 2014.San Diego,Califoria.USA.February 23-26.2014.2014. [Online].Available: https://www.ndss-symposium.org/ndss2014/ machine-learning-approach-classifying-and-categorizing-android- sources-and-sinks [10]"Reaching definition wiki,"https://en.wikipedia.org/wiki/Reaching_ definition. [11]"Dexguard."https://www.guardsquare.com/en/products/dexguard. [12]A.Bartel,J.Klein,Y.L.Traon,and M.Monperrus,"Dexpler converting android dalvik bytecode to jimple for static analysis with soot,"in Proceedings of the ACM SIGPLAN International Workshop on State of the Art in Java Program analysis,SOAP 2012. Beijing.China,June 14,2012,2012.pp.27-38.[Online].Available: https:/ldoi.org/10.1145/2259051.2259056 [13]Y.He and Q.Li,"Detecting and defending against inter-app permission leaks in android apps."in 35th IEEE International Performance Computing and Communications Conference,IPCCC 2016.Las Vegas,NV.USA,December 9-11,2016,2016.pp.1-7. [Online].Available:https://doi.org/10.1109/PCCC.2016.7820624 [14]E.Chin.A.P.Felt.K.Greenwood,and D.A.Wagner."Analyzing inter-application communication in android,"in Proceedings of the 9th International Conference on Mobile Systems,Applications, and Services (MobiSys 2011).Bethesda,MD.USA.June 28- July 01.2011,2011.pp.239-252.[Online].Available:http: /doi.acm.org/10.1145/1999995.2000018 [15]F.Liu,H.Cai,G.Wang,D.Yao.K.O.Elish,and B.G.Ryder,"Mr- droid:A scalable and prioritized analysis of inter-app communication risks."in 2017 IEEE Security and Privacy Workshops.SP Workshops 2017.San Jose,CA.USA.May 25.2017.2017.pp. 189-198. [Online].Available:https://doi.org/10.1109/SPW.2017.12 [16]X.Zhong.F.Zeng.Z.Cheng,N.Xie,X.Qin,and S.Guo,"Privilege escalation detecting in android applications,"in 3rd International Conference on Big Data Computing and Communications,BIGCOM 2017,.Chengdu.China,.August10-1,2017,2017.pp.3944. [Online].Available:https://doi.org/10.1109/BIGCOM.2017.21 [17]J.Garcia,M.Hammad,N.Ghorbani,and S.Malek,"Automatic generation of inter-component communication exploits for android 295
REFERENCES [1] A. P. Felt, H. J. Wang, A. Moshchuk, S. Hanna, and E. Chin, “Permission re-delegation: Attacks and defenses,” in 20th USENIX Security Symposium, San Francisco, CA, USA, August 8-12, 2011, Proceedings, 2011. [Online]. Available: http://static.usenix.org/events/ sec11/tech/full papers/Felt.pdf [2] J. Yan, X. Deng, P. Wang, T. Wu, J. Yan, and J. Zhang, “Characterizing and identifying misexposed activities in android applications,” in Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering, ASE 2018, Montpellier, France, September 3-7, 2018, 2018, pp. 691–701. [Online]. Available: https://doi.org/10.1145/3238147.3238164 [3] M. C. Grace, Y. Zhou, Z. Wang, and X. Jiang, “Systematic detection of capability leaks in stock android smartphones,” in 19th Annual Network and Distributed System Security Symposium, NDSS 2012, San Diego, California, USA, February 5-8, 2012, 2012. [Online]. Available: https://www.ndss-symposium.org/ndss2012/ systematic-detection-capability-leaks-stock-android-smartphones [4] “Z3 wiki,” https://github.com/Z3Prover/z3/wiki. [5] “Soot,” https://sable.github.io/soot/. [6] S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel, J. Klein, Y. L. Traon, D. Octeau, and P. D. McDaniel, “Flowdroid: precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps,” in ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI ’14, Edinburgh, United Kingdom - June 09 - 11, 2014, 2014, pp. 259–269. [Online]. Available: http://doi.acm.org/10.1145/2594291.2594299 [7] L. Li, A. Bartel, T. F. Bissyande, J. Klein, Y. L. Traon, S. Arzt, ´ S. Rasthofer, E. Bodden, D. Octeau, and P. D. McDaniel, “Iccta: Detecting inter-component privacy leaks in android apps,” in 37th IEEE/ACM International Conference on Software Engineering, ICSE 2015, Florence, Italy, May 16-24, 2015, Volume 1, 2015, pp. 280–291. [Online]. Available: https://doi.org/10.1109/ICSE.2015.48 [8] A. Desnos et al., “Androguard: Reverse engineering, malware and goodware analysis of android applications,” URL code. google. com/p/androguard, p. 153, 2013. [9] S. Rasthofer, S. Arzt, and E. Bodden, “A machine-learning approach for classifying and categorizing android sources and sinks,” in 21st Annual Network and Distributed System Security Symposium, NDSS 2014, San Diego, California, USA, February 23-26, 2014, 2014. [Online]. Available: https://www.ndss-symposium.org/ndss2014/ machine-learning-approach-classifying-and-categorizing-androidsources-and-sinks [10] “Reaching definition wiki,” https://en.wikipedia.org/wiki/Reaching definition. [11] “Dexguard,” https://www.guardsquare.com/en/products/dexguard. [12] A. Bartel, J. Klein, Y. L. Traon, and M. Monperrus, “Dexpler: converting android dalvik bytecode to jimple for static analysis with soot,” in Proceedings of the ACM SIGPLAN International Workshop on State of the Art in Java Program analysis, SOAP 2012, Beijing, China, June 14, 2012, 2012, pp. 27–38. [Online]. Available: https://doi.org/10.1145/2259051.2259056 [13] Y. He and Q. Li, “Detecting and defending against inter-app permission leaks in android apps,” in 35th IEEE International Performance Computing and Communications Conference, IPCCC 2016, Las Vegas, NV, USA, December 9-11, 2016, 2016, pp. 1–7. [Online]. Available: https://doi.org/10.1109/PCCC.2016.7820624 [14] E. Chin, A. P. Felt, K. Greenwood, and D. A. Wagner, “Analyzing inter-application communication in android,” in Proceedings of the 9th International Conference on Mobile Systems, Applications, and Services (MobiSys 2011), Bethesda, MD, USA, June 28 - July 01, 2011, 2011, pp. 239–252. [Online]. Available: http: //doi.acm.org/10.1145/1999995.2000018 [15] F. Liu, H. Cai, G. Wang, D. Yao, K. O. Elish, and B. G. Ryder, “Mrdroid: A scalable and prioritized analysis of inter-app communication risks,” in 2017 IEEE Security and Privacy Workshops, SP Workshops 2017, San Jose, CA, USA, May 25, 2017, 2017, pp. 189–198. [Online]. Available: https://doi.org/10.1109/SPW.2017.12 [16] X. Zhong, F. Zeng, Z. Cheng, N. Xie, X. Qin, and S. Guo, “Privilege escalation detecting in android applications,” in 3rd International Conference on Big Data Computing and Communications, BIGCOM 2017, Chengdu, China, August 10-11, 2017, 2017, pp. 39–44. [Online]. Available: https://doi.org/10.1109/BIGCOM.2017.21 [17] J. Garcia, M. Hammad, N. Ghorbani, and S. Malek, “Automatic generation of inter-component communication exploits for android applications,” in Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2017, Paderborn, Germany, September 4-8, 2017, 2017, pp. 661–671. [Online]. Available: http://doi.acm.org/10.1145/3106237.3106286 295