firedroid: hardening security in almost-stock android presented by: kenneth siu
TRANSCRIPT
FireDroid: Hardening Security in FireDroid: Hardening Security in Almost-Stock AndroidAlmost-Stock Android
Presented By: Kenneth Siu
MotivationMotivation• 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
Recent Malware ExamplesRecent 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
Recent Malware ExamplesRecent 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
Introduction to FireDroidIntroduction 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
FireDroid System OverviewFireDroid System Overview
FireDroid App Monitor (FDAM)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
FireDroid Service (FDS)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)
ZygoteZygote• 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
FireDroid Main Monitor (FDMM)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
ZygoteZygote
ptrace()ptrace()
FDMMFDMM
Implementation of FDMMImplementation 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
FireDroid Policy LanguageFireDroid Policy Language
Syntax of FireDroid Policy Language
Limiting SMS MessagesLimiting SMS Messages
Preventing Malicious Code to Hide Received SMS
Prevent Sending of SMS Messages
Preventing VulnerabilitiesPreventing Vulnerabilities
Prevent Application from Forking Too Many Times
Testing – BenchmarksTesting – 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
Testing – Test ApplicationTesting – 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
Related Work - MockDroidRelated 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
Related Work – TISSARelated 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
Related Work – RetroSkeletonRelated 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
Related Work - RecDroidRelated 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
CritiqueCritique• 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
Future WorkFuture 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
Questions?Questions?
BibliographyBibliography1. 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