1. FireDroid: Hardening Security in Almost-Stock Android Presented By: Kenneth Siu

2. Motivation Malware prevalent on Android devices Anti-virus software fails to detect 21% of malware Devices are still vulnerable to many attacks Need more sophistication than checking privileges Need a way to enforce policies Most fine-grained approaches require modifying the Android image Difficult because of many variations of Android images available

3. Recent Malware Examples http://blog.checkpoint.com/2015/09/21/braintest-a-new-level-of- sophistication-in-mobile-malware/ App disguised as a game Gains root access and installs an APK (“The Backdoor”) as a system application Uses package of exploits to gain root access APK executes code from a server and does not let user uninstall Overlays ads on other applications

4. Recent Malware Examples Durak, IQ Test App, History App, and many more. Waits multiple weeks before opening ads every time a user unlocks phone Sends premium SMS if user follows ads Sometimes even sends users to security apps https://blog.avast.com/2015/02/03/apps-on-google-play-pose-as-games-and- infect-millions-of-users-with-adware/ https://www.youtube.com/watch?v=UkRAu2xcuTU

5. Introduction to FireDroid Enforces fine-grained security policies Does not need to change internal modules of Android OS (no need to modify Android Image) Exploits how Android spawns applications Does not rely on user input Able to monitor any code executed on a device Implements a FireDroid Policy Language to easily maintain permissions on any application

6. FireDroid System Overview

7. FireDroid App Monitor (FDAM) Each Linux process monitored by FDAM Attaches to process using ptrace() Policy Enforcement Point (PEP) Policy Decision Point (PDP) Policy Repository (PR) System call arguments are sent to the buffer before copying arguments back to original address

8. FireDroid Service (FDS) Service implemented as an app Requests user for input on whether to allow, deny, or kill Policy Administration Point (PAP) Remote Policy Manager (RPM) Global Policy Repository (GPR)

9. Zygote Zygote Process Forks new processes and copies its initialized structures Allows for faster startup of applications Exploit this process http://multi-core-dump.blogspot.com/2010/04/android-application-launch.html

10. FireDroid Main Monitor (FDMM) Responsible for monitoring Zygote it forks() itself FDMM is inserted as a parent process to Zygote By becoming the parent process, it becomes the parent process to all processes run on the device Can intercept and monitor all system calls Zygote ptrace() FDMM

11. Implementation of FDMM Need to modify init.rc init.rc is a text file that is used in android when booting up. May need device to be rooted to extract boot partition Unroots device after modification of file Allows one to monitor both third-party and pre-installed applications Can even control IPC https://android.googlesource.com/platform/system/core/+/master/rootdir/init.rc

12. FireDroid Policy Language Syntax of FireDroid Policy Language

13. Limiting SMS Messages Preventing Malicious Code to Hide Received SMS Prevent Sending of SMS Messages

14. Preventing Vulnerabilities Prevent Application from Forking Too Many Times

15. Testing – Benchmarks Used Quadrant and BenchmarkPi as benchmarking tools (HTC One X) Tested on a variety of devices Large overhead in I/O Overhead due to context switching

16. Testing – Test Application Created Test Application Simulates web browsing Sends implicit intent Accesses contact list Accesses GPS FireDroid allows each of these actions Tested Energy Efficiency Only 3.3% less efficient than without FireDroid

17. Related Work - MockDroid Modified Image of Android ‘Mocks’ application access to a resource Can send constant or empty values Revoke resources at run-time Needs to modify the Android OS Inflexible and is difficult to implement in a variety of devices

18. Related Work – TISSA Taming Information-Stealing Smartphone Applications Focuses on adding a privacy mode to users that can be controlled in a fine-grained manner Uses the PEP and PAP similar to FireDroid Can send bogus or anonymized results back to application Needs a modification to the Android Image Only focuses on protecting privacy Does not allow the user to decide on a permission nor does it allow the killing of a process

19. Related Work – RetroSkeleton Rewrites applications and repackages APK Redeploys APK with policy enforcer in place Does not need rooting the device nor changing the Android OS High level of flexibility Each app has to be digitally resigned – will use a different developer key Does not work for Native Development Kit (NDK) applications

20. Related Work - RecDroid Builds on top of the idea of FireDroid Also uses the idea that users are mainly inexperienced Takes into account expert’s opinion on applications Ranks applications based on security assessment Needs changing the Android OS

21. Critique Somewhat high overhead – especially in I/O intensive applications Claims to not change Android OS – still needs to root device and change init.rc Not as flexible as frameworks like RetroSkeleton Can not modify what happens on policy invocation

22. Future Work Change how FireDroid interacts with ptrace() Can assess system calls without context switching Reduce overhead Allow for dynamic analysis of system calls All FireDroid does currently is checks if a system call is being invoked Create a more flexible framework Allow for changing functionality when some permissions are requested Allow to send back bogus or anonymous information

23. Questions?

24. Bibliography 1.Giovanni Russello, Arturo Blas Jimenez, Habib Naderi, and Wannes van der Mark. 2013. FireDroid: hardening security in almost-stock Android. In Proceedings of the 29th Annual Computer Security Applications Conference (ACSAC '13). ACM, New York, NY, USA, 319-328. DOI=http://dx.doi.org/10.1145/2523649.2523678 2.Alastair R. Beresford, Andrew Rice, Nicholas Skehin, and Ripduman Sohan. 2011. MockDroid: trading privacy for application functionality on smartphones. In Proceedings of the 12th Workshop on Mobile Computing Systems and Applications (HotMobile '11). ACM, New York, NY, USA, 49-54. DOI=http://dx.doi.org/10.1145/2184489.2184500 3.Benjamin Davis and Hao Chen. 2013. RetroSkeleton: retrofitting android apps. In Proceeding of the 11th annual international conference on Mobile systems, applications, and services (MobiSys '13). ACM, New York, NY, USA, 181-192. DOI=http://dx.doi.org/10.1145/2462456.2464462 4.Yajin Zhou, Xinwen Zhang, Xuxian Jiang, and Vincent W. Freeh. 2011. Taming information-stealing smartphone applications (on Android). In Proceedings of the 4th international conference on Trust and trustworthy computing (TRUST'11), Jonathan M. McCune, Boris Balacheff, Adrian Perrig, Ahmad-Reza Sadeghi, and Angela Sasse (Eds.). Springer-Verlag, Berlin, Heidelberg, 93-107. 5.Bahman Rashidi, Carol Fung, and Tam Vu. 2014. RecDroid: a resource access permission control portal and recommendation service for smartphone users. In Proceedings of the ACM MobiCom workshop on Security and privacy in mobile environments (SPME '14). ACM, New York, NY, USA, 13-18. DOI=http://dx.doi.org/10.1145/2646584.2646586