SECURITY AND PRIVACY OF MOBILE APPSFred McMahan

INTRODUCTION AND MOTIVATION

INTRODUCTION AND MOTIVATION

Increase in the number of smart devices

Number of applications available for the smart device Who developed that app? Do we trust them?

Leads to a increase in the possibility of a dangerous app Malware Privacy Leak

Up to the user to determine if the app is safe

IOS VS. ANDROID

ITunes Over 550,000 Apps 25 Billion downloads

Google Play Over 450,00 Apps 10 billion downloads

IOS

SDK available to anyone

Closed OS Source Code

Closed Publication Requires Apples approval

before adding it to ITunes

Magic Delete Button Disable or delete apps at

will

ANDROID OS SDK available to

anyone

Open source OS

Open Publication Open Content

Potential for more Malware

Research more focused with Android OS

CURRENT SECURITY AND PRIVACY MODELS

IOS

Every App is validated before publishing to ITunes This protects the user from potential malware

Apps must request permission from user to use personal data

ANDROID

Multiple places to download applications Apps may not be

checked by any authority before published

Uses permission scheme User must approve an

app to use a specific feature

GOOGLE'S BOUNCER

A background system that runs on Google Play

Check each application on the market for malware

Runs each application in the cloud to look for suspicious activity

40% decrease in the number of potentially malicious downloads

Is this enough security?

RUN-TIME PROTECTION

RUN-TIME PROTECTION

Apps developed to monitor other applications Lookout Security & Antivirus

Also monitors for privacy leaks

Have the ability to monitor the inter process communication

Monitor for malicious activity

Is this enough security? May not always catch malicious code

SAINT

Uses a pre-defined policy to monitor inter-process communications Each application run on it own virtual machine

SAINT rejects the communication if it is not defined in the policy

SAINT ANALYSIS

Provides a basic run-time security

Pre-defined policies may not account for all malicious activity

INSTALL-TIME PROTECTION

INSTALL-TIME PROTECTION

Allows malicious apps to be avoided

Inform the user User needs a security tool to quantify a threat

level when they downloads an application

Provide a user with accurate evaluation of how much of a threat the application presents

How do we develop Install-time protection?

REVERSE ENGINEER CODE

Most effective Easy to locate privacy leak and malicious code

Time consuming

Complexity Currently not able to do on the phone

SCANDROID

Automated security tool designed to compare installing application against installed applications

Reverse engineers byte code to obtain Java code Maps the flows of the program

Data entering and leaving the application

Compares this to other installed applications

Gives the user the ability to not install the application

SCANDROID ISSUES

Time complexity Larger programs take longer

Not currently able to accomplish on the device

PERMISSIONS

114 Permissions required to gain access to functionality ACCESS_FINE_LOCATION – GPS ACCESS_COURSE_LOCATION – Cell Tower CAMERA

Find an entire lists at: http://developer.android.com/reference/android/

Manifest.permission.html

PERMISSIONS MANIFEST FILE

A file included with every Android App to tell the OS what features it needs to access

Presents the required permissions to the user at install time User must accept the permission before being

able to install the app Most users probably just skip over the list

SAMPLE PERMISSION MANIFEST<activity android:name=".app.DeviceAdminSample" android:label="@string/activity_sample_device_admin"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.SAMPLE_CODE" /> </intent-filter> </activity><receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver" android:label="@string/sample_device_admin" android:description="@string/sample_device_admin_description" android:permission="android.permission.BIND_DEVICE_ADMIN"> <meta-data android:name="android.app.device_admin" android:resource="@xml/device_admin_sample" /> <intent-filter> <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> </intent-filter></receiver>

KIRIN SECURITY TOOL

Analyzes security configuration from the package manifest before app installation Every application has a security configuration

which tells the OS what inter-process communication (IPC) are going to be used

SAMPLE THREAT FACTORS

KIRIN PRELIMINARY RESULTS

Rule 2: An application must not have PHONE_STATE, RECORD_AUDIO, and INTERNET permission labels.

KIRIN PRELIMINARY RESULTS Rule 4: An application must

not have ACCESS_FINE_LOCATION, INTERNET, and RECEIVE_BOOT_COMPLETE permission labels.

Rule 5: An application must not have ACCESS_COARSE_LOCATION, INTERNET, and RECEIVE_BOOT_COMPLETE permission labels.

KIRIN ANALYSIS

Provides a good introduction to using manifest file at install time

Does not give user any information

Misidentify applications as malicious

STOWAWAY

Designed to identify over-privileged applications Over-privileged applications can lead to

malicious applications taking advantage of them Find the cause of over privilege

Reverse engineer to get the API calls

Matches the API calls to the Permission Requests

Identifies Permission not required

STOWAWAY SAMPLE

BatteryBoosters.apk ocd.apk

STOWAWAY RESULTS

Out 900 Apps 323 were over-privileged

CAUSES FOR OVER-PRIVILEGING

Small amount of over-privileging comes from developers purposely

The majority of over-privileging comes from: Misunderstanding of the API API documentation errors

CURRENT RESEARCH

CURRENT RESEARCH Working on a tool to quantify a threat level when a

user downloads an application using the permission manifest file

Must be able to run fast with low overhead

Detect multiple attacks including: Spam attacks DoS Battery exhaustive Privacy violation

Provide a user with accurate evaluation of how much of a threat the application presents

CURRENT RESEARCH Gather permission manifest files from known safe

apps

Using frequency counts of label-label occurrence for all label possibility (114 – Labels) Global Categorical

Use the matrices to calculate risk Global Manifest Matrix (GMM) Categorical Manifest Matrix (CMM)

Use the matrices to build graphs to look for possible attacks Manifest Permission Graphs (MPG)

GMM & CMM Store the counts into matrix

L1 – Manifest Label fL1 – Frequency count for manifest label fL1,L2 – Frequency count for manifest label 1 and 2

Perform statistical analysis using the frequency counts Labels counts with low frequency may pose more risk

Perform matrix operations to find anomalies

EXTRACTED PERMISSIONS

MPG

Use the matrices to build Manifest Graphs Frequency counts become weights Lower weights account for less connection

between two labels

Run graphing algorithms with the un-trusted application to find possible malicious activity

Graphs allow us to visually see the potential for security leaks

PERMISSION MANIFEST ISSUES

Manifest file does not allow us to know how many times a permission is requested during run-time

The order in which the permission are used

The manifest file does not incorporate all sensors Accelerometer is accessed directly through API Designers use this sensor to build other

applications that go beyond the sensors original intention

Opens a possible hole for a leak of private information.

FUTURE WORK

Still lots of research to pursue: Devices are getting more CPUs and Memory

Does this allow us to reverse engineer on the mobile device

What about those adds that pop up while using an app What kind of information do they collect on a

user Do they inform the user about the information

they are collecting. Who has access to this information

CONCLUSION Further research in security and privacy is vital as

the use of smart device increases

User knowledge is a major part of protection scheme

Manifest file provides a good starting point to install-time protection but requires refinement

Users need both install-time and run-time protection to be better protected

As long as people have malicious intent there will always be malicious programs to protect against

QUESTIONS

REFERENCES [1] Android Manifest Permission Reference,

http://developer.android.com/reference/android/Manifest.permission.html 2012. [2] K. W. Y. Au, Y. F. Zhou, Z. Huang, P. Gill and D. Lie. Short paper: A look at smartphone

permission models. Presented at Proceedings of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices. 2011, .

[3] D. Barrera, H. G. Kayacik, P. C. van Oorschot and A. Somayaji. A methodology for empirical analysis of permission-based security models and its application to android. Presented at Proceedings of the 17th ACM Conference on Computer and Communications Security. 2010, .

[4] J. Bickford, R. O'Hare, A. Baliga, V. Ganapathy and L. Iftode. Rootkits on smart phones: Attacks, implications and opportunities. Presented at Proceedings of the Eleventh Workshop on Mobile Computing Systems & Applications. 2010, .

[5] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer and A. R. Sadeghi. XManDroid: A new android evolution to mitigate privilege escalation attacks. Security 2011.

[6] J. Burns. Developing secure mobile applications for android. White Paper of iSEC Partners 2008.

[7] M. Conti, V. Nguyen and B. Crispo. CRePE: Context-related policy enforcement for android. Information Security pp. 331-345. 2011.

[8] R. Dantu, P. Kolan and J. Cangussu. Network risk management using attacker profiling. Security and Communication Networks 2(1), pp. 83-96. 2009.

[9] L. Davi, A. Dmitrienko, A. R. Sadeghi and M. Winandy. Privilege escalation attacks on android. Information Security pp. 346-360. 2011.

[10] W. Enck. Defending users against smartphone apps: Techniques and future directions.

REFERENCES [11] W. Enck, D. Octeau, P. McDaniel and S. Chaudhuri. A study of android application security.

Presented at USENIX Security. 2011, . [12] W. Enck, M. Ongtang and P. McDaniel. On lightweight mobile phone application certification.

Presented at Proceedings of the 16th ACM Conference on Computer and Communications Security. 2009, .

[13] W. Enck, M. Ongtang and P. McDaniel. Understanding android security. Security & Privacy, IEEE 7(1), pp. 50-57. 2009.

[14] A. P. Felt, E. Chin, S. Hanna, D. Song and D. Wagner. Android permissions demystified. Presented at Proceedings of the 18th ACM Conference on Computer and Communications Security. 2011, .

[15] A. P. Felt, K. Greenwood and D. Wagner. The effectiveness of application permissions. Presented at Proc. of the USENIX Conference on Web Application Development. 2011, .

[16] A. P. Fuchs, A. Chaudhuri and J. S. Foster. SCanDroid: Automated security certification of android applications. Manuscript, Univ.of Maryland, Http://www.Cs.Umd.Edu/~ avik/projects/scandroidascaa 2009.

[17] C. Gehrmann and P. Ståhl. Mobile platform security. ERICSSON REVIEW the Telecommunications Technology Journal 2pp. 59-70. 2008.

[18] K. Kostiainen, E. Reshetova, J. E. Ekberg and N. Asokan. Old, new, borrowed, blue--: A perspective on the evolution of mobile platform security architectures. Presented at Proceedings of the First ACM Conference on Data and Application Security and Privacy. 2011, .

[19] D. Muthukumaran, A. Sawani, J. Schiffman, B. M. Jung and T. Jaeger. Measuring integrity on mobile phone systems. Presented at Proceedings of the 13th ACM Symposium on Access Control Models and Technologies. 2008, .

[20] M. Nauman, S. Khan and X. Zhang. Apex: Extending android permission model and enforcement with user-defined runtime constraints. Presented at Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security. 2010, .

REFERENCES [21] M. Ongtang, S. McLaughlin, W. Enck and P. McDaniel. Semantically rich

application-centric security in android. Presented at Computer Security Applications Conference, 2009. ACSAC'09. Annual. 2009, .

[22] I. Rassameeroj and Y. Tanahashi. Various approaches in analyzing android applications with its permission-based security models. Presented at Electro/Information Technology (EIT), 2011 IEEE International Conference on. 2011, .

[23] G. Russello, B. Crispo, E. Fernandes and Y. Zhauniarovich. YAASE: Yet another android security extension. Presented at Privacy, Security, Risk and Trust (PASSAT), 2011 IEEE Third International Conference on and 2011 IEEE Third International Confernece on Social Computing (SocialCom). 2011.

[24] A. Shabtai, Y. Fledel and Y. Elovici. Securing android-powered mobile devices using SELinux. Security & Privacy, IEEE 8(3), pp. 36-44. 2010.

[25] W. Shin, S. Kiyomoto, K. Fukushima and T. Tanaka. A formal model to analyze the permission authorization and enforcement in the android framework. Presented at Social Computing (SocialCom), 2010 IEEE Second International Conference on. 2010, .

[26] W. Shin, S. Kwak, S. Kiyomoto, K. Fukushima and T. Tanaka. A small but non-negligible flaw in the android permission scheme. Presented at Policies for Distributed Systems and Networks (POLICY), 2010 IEEE International Symposium on. 2010, .

[27] W. Tang, G. Jin, J. He and X. Jiang. Extending android security enforcement with a security distance model. Presented at Internet Technology and Applications (iTAP), 2011 International Conference on. 2011, .