S P M A

idleheadedceleryMobile - Wireless

Dec 10, 2013 (3 years and 7 months ago)

61 views

S
ECURITY

AND

P
RIVACY

OF

M
OBILE

A
PPS

Fred McMahan

I
NTRODUCTION

AND

M
OTIVATION

I
NTRODUCTION

AND

M
OTIVATION


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
. A
NDROID


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

A
NDROID

OS


SDK available to anyone



Open source OS



Open Publication


Open Content



Potential for more
Malware



Research more focused
with Android OS

C
URRENT

S
ECURITY

AND

P
RIVACY

M
ODELS

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





A
NDROID


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



G
OOGLE
'
S

B
OUNCER


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?

R
UN
-
T
IME

P
ROTECTION

R
UN
-
T
IME

P
ROTECTION


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 A
NALYSIS


Provides a basic run
-
time security



Pre
-
defined policies may not account for all
malicious activity




I
NSTALL
-
T
IME

P
ROTECTION

I
NSTALL
-
TIME

P
ROTECTION


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?


R
EVERSE

ENGINEER

CODE


Most effective


Easy to locate privacy leak and malicious code



Time consuming



Complexity


Currently not able to do on the phone


SC
AN
D
ROID


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

SC
AN
D
ROID

I
SSUES


Time complexity


Larger programs take longer



Not currently able to accomplish on the device

P
ERMISSIONS


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





P
ERMISSIONS

M
ANIFEST

F
ILE



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







S
AMPLE

P
ERMISSION

M
ANIFEST

<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>

K
IRIN

S
ECURITY

T
OOL


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



S
AMPLE

T
HREAT

F
ACTORS

K
IRIN

P
RELIMINARY

R
ESULTS

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

K
IRIN

P
RELIMINARY

R
ESULTS


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.


K
IRIN

A
NALYSIS


Provides a good introduction to using manifest
file at install time



Does not give user any information



Misidentify applications as malicious


S
TOWAWAY


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


S
TOWAWAY

S
AMPLE

BatteryBoosters.apk

ocd.apk

S
TOWAWAY

R
ESULTS


Out 900 Apps 323 were over
-
privileged



C
AUSES

FOR

O
VER
-
PRIVILEGING


Small amount of over
-
privileging comes from
developers purposely



The majority of over
-
privileging comes from:


Misunderstanding of the API


API documentation errors

C
URRENT

R
ESEARCH

C
URRENT

R
ESEARCH


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


C
URRENT

R
ESEARCH


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


f
L1



Frequency count for manifest label


f
L1,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

E
XTRACTED

P
ERMISSIONS

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


P
ERMISSION

M
ANIFEST

I
SSUES


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.

F
UTURE

W
ORK


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


C
ONCLUSION


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


Q
UESTIONS

R
EFERENCES


[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.

R
EFERENCES


[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 2
pp. 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, .

R
EFERENCES


[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, .