SECURITY AND PRIVACY OF
MOBILE APPS
Fred 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/Manif
est.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)



Use the matrices to calculate risk



Global
Categorical
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 installtime 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 applicationcentric 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 nonnegligible 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, .