Going Native: Using a Large-Scale Analysis of Android Apps to Create a Practical Native-Code Sandboxing Policy
No ratings
Presented at NDSS 2016 by
Current static analysis techniques for Android applications operate at the Java level - that is, they analyze either the Java source code or the Dalvik bytecode. However, Android allows developers to write code in C or C++ that is cross-compiled to multiple binary architectures. Furthermore, the Java-written components and the native code components (C or C++) can interact. Native code can access all of the Android APIs that the Java code can access, as well as alter the Dalvik Virtual Machine, thus rendering static analysis techniques for Java unsound or misleading. In addition, malicious apps frequently hide their malicious functionality in native code or use native code to launch kernel exploits. It is because of these security concerns that previous research has proposed native code sandboxing, as well as mechanisms to enforce security policies in the sandbox. However, it is not clear whether the large-scale adoption of these mechanisms is practical: is it possible to define a meaningful security policy that can be imposed by a native code sandbox without breaking app functionality? In this paper, we perform an extensive analysis of the native code usage in 1.2 million Android apps. We first used static analysis to identify a set of 446k apps potentially using native code, and we then analyzed this set using dynamic analysis. This analysis demonstrates that sandboxing native code with no permissions is not ideal, as apps' native code components perform activities that require Android permissions. However, our analysis provided very encouraging insights that make us believe that sandboxing native code can be feasible and useful in practice. In fact, it was possible to automatically generate a native code sandboxing policy, which is derived from our analysis, that limits many malicious behaviors while still allowing the correct execution of the behavior witnessed during dynamic analysis for 99.77% of the benign apps in our dataset. The usage of our system to generate policies would reduce the attack surface available to native code and, as a further benefit, it would also enable more reliable static analysis of Java code. Vitor Afonso and Paulo de Geus (University of Campinas) and Antonio Bianchi, Yanick Fratantonio, Christopher Kruegel and Giovanni Vigna (UC Santa Barbara) and Adam Doupe (Arizona State University) and Mario Polino (Politecnico di Milano) Life after App Uninstallation: Are the Data Still Alive? Data Residue Attacks on Android Uninstalling apps from mobile devices is among the most common user practices on smartphones. It may sound trivial, but the entire process involves multiple system components coordinating to remove the data belonging to the uninstalled app. Despite its frequency and complexity, little has been done to understand the security risks in the app's uninstallation process. In this project, we conduct a systematic analysis of Android's data cleanup mechanism during the app uninstallation process. Our analysis reveals that data residues are pervasive in the system after apps are uninstalled. For each identified data residue instance, we have formulated hypotheses and designed experiments to see whether it can be exploited to compromise the system security. The results are surprising: we have found 12 instances of vulnerability caused by data residues. By exploiting these vulnerabilities, adversaries can steal user's online-account credentials, access other app's private data, escalate privileges, eavesdrop on user's keystrokes, etc. We call these attacks the data residue attacks. To evaluate the real-world impact of the attacks, we have conducted an analysis on the top 100 apps in each of the 27 categories from GooglePlay. The result shows that a large portion of the apps can be the targets of the data residue attacks. We further evaluate how effective the existing app markets, including Google, Amazon, and Samsung, can prevent our attacking apps from reaching their markets. Moreover, we study the data residue attacks on 10 devices from different vendors to see how vendor customization can affect our attacks. Google has acknowledged all our findings, and is working with us to get the problems fixed.