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