cnt 5410 - computer and network security: mobile … network security: mobile phone security...

Southeastern Security for Enterprise and Infrastructure (SENSEI) Center

CNT 5410 - Computer and Network Security: Mobile Phone Security

Professor Kevin ButlerFall 2015


And what about apps?

2


What is Android?• The most popular smartphone operating system --

led by Google

• Complete software stack

• Open source (Apache v2 license) ... mostly

• Open Handset Alliance ... 30+ industrial partners

• Google, T-Mobile, Sprint, HTC, LG, Motorola, Samsung, Broadcom, Intent, NVIDIA, Qualcomm, and many more.

3


Android Phones• An Android contains a number of “applications”

• Android comes installed with a number of basic systems tools, e.g., dialer, address book, etc.

• Developers use the Android API to construct applications.• All apps are written in Java and executed within a custom Java

virtual machine.

• Each application package is contained in a jar file (.apk)

• Applications are installed by the user

• No “app store” required, just build and go.• Open access to data and voice services

4


Architecture• The Android smartphone operating system is built upon

Linux and includes many libraries and a core set of applications.

• The middleware makes it interesting

• Not focused on UNIX processes

• Uses the Binder component framework

• Originally part of BeOS, then enhancedby Palm, now used in Android

• Applications consist of many components of different types

• Applications interact via components

• We focus on security with respect to the component API

5

Phone Application

Contacts Application

Maps Application

Android Middleware

Linux

Reference

Monitor

Policy

Binder

Component

Framework


Component Model• While each application runs as its own UNIX uid,

sharing can occur through application-level interactions

• Interactions based on components

• Different component types

• Activity

• Service

• Content Provider

• Broadcast Receiver

• Target component in the same or different application

• but first ...

6

Starting an Activity for a Result

ActivityActivity

start

return

Communicating with a Service

Activity

callback

Service

call

start/stop/bind

Querying a Content Provider

Activity

Read/WriteQuery

return

Content Provider

Receiving an Intent Broadcast

System

Activity

Service

Broadcast Receiver

SendIntent


Intents• Intents are objects used as inter-component

signaling

• Starting the user interface for an application

• Sending a message between components

• Starting a background service

7


Activity Component• The user interface consists of a series of

Activity components.

• Each Activity is a “screen”.

• User actions tell an Activity to start another Activity, possibly with the expectation of a result.

• The target Activity is not necessarily in the same application.

• Directly or via Intent “action strings”.

• Processing stops when another Activity is “on top”.

8


Service Component• Background processing occurs in Service components.

• Downloading a file, playing music, tracking location, polling, etc.

• Local vs. Remote Services (process-level distinction)

• Also provides a “service” interface between applications• Arbitrary interfaces for data transfer

• Android Interface Definition Language (AIDL)

• Register callback methods• Core functionality often implemented

as Service components• e.g., Location API, Alarm service

• Multiple interfaces• Control: start, stop• Method invocation: bind

9


Content Provider Component• Content Provider components provide a standardized interface

for sharing data, i.e., content (between applications).

• Models content in a relational DB

• Users of Content Providers can perform queries equivalent to SELECT, UPDATE, INSERT, DELETE

• Works well when content is tabular

• Also works as means of addressing “files”

• URI addressing scheme

•content://<authority>/<table>/[<id>]

•content://contacts/people/10

10


Broadcast Receiver Component• Broadcast Receiver components act as specialized

event Intent handlers (also think of as a message mailbox).

• Broadcast Receiver components “subscribe” to specific action strings (possibly multiple)

• action strings are defined by the system or developer

• component is automatically called by the system

• Recall that Android provides automatic Activity resolution using “action strings”.

• The action string was assigned to an Intent object

• Sender can specify component recipient (no action string)

11


The Android Manifest• Manifest files are the technique for describing the

contents of an application package (i.e., resource file)• Each Android application has a special

AndroidManifest.xml file (included in the .apk package)• describes the contained components

• components cannot execute unless they are listed

• specifies rules for “auto-resolution”• specifies access rules• describes runtime dependencies• optional runtime libraries• required system permissions

12


Manifest Specification

13


Authorization• Is this a good or bad way to do authorization?

14


Example Applications• FriendTracker Application

• FriendTracker Service to poll for friend locations

• Broadcasts an Intent when near a friend

• FriendProvider Content Provider to store location of friends

• Cross references friends with system Contacts Provider

• FriendTrackerControl Activity to start and stop the Service

• BootReceiver Broadcast Receiver to start the service on boot

• FriendViewer Application

• FriendViewer Activity to display list of friend locations

• FriendMap Activity to show friends on a map (on right)

• FriendReceiver Broadcast Receiver to display when near

15


Component Interaction

16

FriendTracker Application

FriendProvider

BootReceiver

FriendTracker Control

FriendTracker

FriendViewer Application

FriendViewer

FriendMapFriendReceiver

System Server

System Service

Contacts Application

ViewContact

start/stop

start

read,write

BroadcastIntent

BroadcastIntent

read

read

start

start


Android Security• Applications are sandboxed using the Dalvik Virtual

Machine.

• Communication can occur through the previously discussed mechanisms.

• Assuming that the underlying isolation mechanisms are sufficient, where are attacks most likely to be found in these devices?

• Dalvik is being replaced by the Android Runtime (ART).

• Largely the same, except uses Ahead-of-Time (AOT) compilation, has improved garbage collection.

17


Studying Apps• Decompiled top 1,100 free apps from Android

market: over 21 million lines of source code

• We use static analysis to identify both dangerous behavior and vulnerabilities followed by inspection

• Must identify specific properties for analysis

• Note: Static analysis says what can happen not what does

18


Analysis Framework• Using Fortify SCA custom rules let you focus on

the what, not the how

• Control flow analysis: e.g., look at API options

• Data flow analysis: e.g., information leaks, injection attacks

• Structural analysis: “grep on steroids”

• Semantic analysis: look at possible variable values

19


Phone Identifiers• We’ve seen phone identifiers (Ph.#, IMEI,

IMSI, etc) sent to network servers, but how are they used?

• Program analysis pin-pointed 33 apps leaking Phone IDs

• Finding 2 - device fingerprints

• Finding 3 - tracking actions

• Finding 4 - along with registration and login

20


Device Fingerprints

21

com.avantar.wny - com/avantar/wny/PhoneStats.javapublic String toUrlFormatedString(){

StringBuilder $r4; if (mURLFormatedParameters == null) { $r4 = new StringBuilder(); $r4.append((new StringBuilder("&uuid=")).append(URLEncoder.encode(mUuid)).toString()); $r4.append((new StringBuilder("&device=")).append(URLEncoder.encode(mModel)).toString()); $r4.append((new StringBuilder("&platform=")).append(URLEncoder.encode(mOSVersion)).toString()); $r4.append((new StringBuilder("&ver=")).append(mAppVersion).toString()); $r4.append((new StringBuilder("&app=")).append(this.getAppName()).toString()); $r4.append("&returnfmt=json"); mURLFormatedParameters = $r4.toString(); }

return mURLFormatedParameters;}

IMEI


Tracking

22

public void onCreate(Bundle r1){

...IMEI = ((TelephonyManager) this.getSystemService("phone")).getDeviceId();

retailerLookupCmd = (new StringBuilder(String.valueOf(constants.server))).append("identifier=").append(EncodeURL.KREncodeURL(IMEI)).append("&command=retailerlookup&retailername=").toString(); ...}

http://kror.keyringapp.com/service.php

com.froogloid.kring.google.zxing.client.android - Activity_Router.java (Main Activity)

public void run(){

...r24 = (TelephonyManager) r21.getSystemService("phone");

url = (new StringBuilder(String.valueOf(url))).append("&vid=60001001&pid=10010&cid=C1000&uid=").append(r24.getDeviceId()).append("&gid=").append(QConfiguration.mGid).append("&msg=").append(QConfiguration.getInstance().mPCStat.toMsgString()).toString(); ...}

http://client.qunar.com:80/QSearch

com.Qunar - net/NetworkTask.java


Registration and Login

23

com.statefarm.pocketagent - activity/LogInActivity$1.java (Button callback)

public void onClick(View r1){

... r7 = Host.getDeviceId(this$0.getApplicationContext());

LogInActivity.access$1(this$0).setUniqueDeviceID(r7); this$0.loginTask = new LogInActivity$LoginTask(this$0, null); this$0.showProgressDialog(r2, 2131361798, this$0.loginTask); r57 = this$0.loginTask; r58 = new LoginTO[1]; r58[0] = LogInActivity.access$1(this$0); r57.execute(r58); ...}

IMEI

Is this necessarily bad?


Location• Found 13 apps with geographic location data

flows to the network

• Many were legitimate: weather, classifieds, points of interest, and social networking services

• Several instances sent to advertisers (same as TaintDroid). More on this shortly.

• Code recovery error in AdMob library.

24


Phone Misuse• No evidence of abuse in the sample set

• Hard-coded numbers for SMS/voice (premium-rate)

• Background audio/video recording

• Socket API use (not HTTP wrappers)

• Harvesting list of installed applications

25


Ad/Analytics Libraries• 51% of the apps included an ad or analytics

library (many also included custom functionality)

• A few libraries were used most frequently

• Use of phone identifiers and location sometimes configurable by developer

26

Num

ber

of li

brar

ies

1

10

100

1000

Number of apps

1 2 3 4 5 6 7 8

1

10815

3732

91

367

1 app has 8

Library Path # Apps Obtains

com/admob/android/ads 320 L

com/google/ads 206 -

com/flurry/android 98 -

com/qwapi/adclient/android 74 L, P, E

com/google/android/apps/analytics 67 -

com/adwhirl 60 L

com/mobclix/android/sdk 58 L, E

com/mellennialmedia/android 52 -

com/zestadz/android 10 -

com/admarvel/android/ads 8 -

com/estsoft/adlocal 8 L

com/adfonic/android 5 -

com/vdroid/ads 5 L, E

com/greystripe/android/sdk 4 E

com/medialets 4 L

com/wooboo/adlib_android 4 L, P, I

com/adserver/adview 3 L

com/tapjoy 3 -

com/inmobi/androidsdk 2 E

com/apegroup/ad 1 -

com/casee/adsdk 1 S

com/webtrents/mobile 1 L, E, S, I

Total Unique Apps 561

L = Location; P = Ph#; E = IMEI; S = IMSI; I = ICC-ID


public static String getDeviceId(Object r0){

Context r4; String r7; r4 = (Context) r0;

try { r7 = ((TelephonyManager) r4.getSystemService("phone")).getDeviceId();

if (r7 == null) { r7 = ""; } } catch (Exception $r8) { WebtrendsDataCollector.getInstance().getLog().d("Exception fetching TelephonyManager.getDeviceId value. ", $r8); r7 = null; }

return r7;}

Probing for Permissions (1)

27

com/webtrends/mobile/analytics/android/WebtrendsAndroidValueFetcher.java

Catches SecurityException


public static String getDeviceId(Context r0){

String r1; r1 = "";

label_19: { if (deviceId != null) { if (r1.equals(deviceId) == false) { break label_19; } }

if (r0.checkCallingOrSelfPermission("android.permission.READ_PHONE_STATE") == 0) { deviceId = ((TelephonyManager) r0.getSystemService("phone")).getSubscriberId(); } } //end label_19: ...}

Probing for Permissions (2)

28

com/casee/adsdk/AdFetcher.java

Checks before accessing


Developer Toolkits• We found identically implemented dangerous

functionality in the form of developer toolkits.

• Probing for permissions (e.g., Android API, catch SecurityException)

• Well-known brands sometimes commission developers that include dangerous functionality.

• “USA Today” and “FOX News” both developed by Mercury Intermedia(com/mercuryintermedia),which grabs IMEI on startup

29


Custom Exceptions

30

void init(){

URLConnection r3;...r3 = (new URL("http://www.word-player.com/HttpHandler/init.sample")).openConnection();...try{

$r27 = this.mkStr(((TelephonyManager) _context.getSystemService("phone")).getLine1Number());}catch (Exception $r81){

break label_5;}...

}

v00032.com.wordplayer - CustomExceptionHandler.java

Phone Number!?

http://www.word-player.com/HttpHandler/init.sample


Intent Vulnerabilities• Similar analysis rules as independently identified

by Chin et al. [Mobisys 2011]

• Leaking information to IPC - unprotected intent broadcasts are common, occasionally contain info

• Unprotected broadcast receivers - a few apps receive custom action strings w/out protection (lots of “protected bcasts”)

• Intent injection attacks - 16 apps had potential vulnerabilities

• Delegating control - pending intents are tricky to analyze (notification, alarm, and widget APIs) --- no vulns found

• Null checks on IPC input - 3925 potential null dereferences in 591 apps (53%) --- most were in activity components

31


Study Limitations• The sample set

• Code recovery failures

• Android IPC data flows

• Fortify SCA language

• Obfuscation

32


What this all means ...• Characterization of top 1,100 free apps (21+ MLOC) similar

to smaller, vertical studies (e.g., TaintDroid).

• Development of rules to identify vulnerabilities

• 27 Findings (more in Tech Report) providing insight into application developer behavior

• Several APIs need more oversight

• Phone identifiers are used in many different ways and are frequently sent to network servers.

• Many developers not sensitive to Intent API dangers

• Ad/Analytic libs in 51% -- as many as 8 in one app

• 4th party code is becoming a problem

33


Malware in Markets?• Android allows for users to select alternative

markets for downloading apps?

• Examples include Amazon (US), Ndoo (China), Anzhi (China), Softdroid (Russia)

• Is this good or bad?

• Malware has been detected in all of them…

34


Malware Detection (MAST)

• Rapid triage using permissions to detect “interesting” applications.

• Chakradeo et al., MAST: Triage for Market-scale Mobile Malware Analysis, In Proceedings of the ACM Conference

on Security and Privacy in Wireless and Mobile Networks (WiSec), 2013.

35

-4

-3

-2

-1

0

1

2

-2.5 -2 -1.5 -1 -0.5 0 0.5 1 1.5 2


Piracy Detection (DroidMoss)

• App similarity analysis to detect repackaging/piracy.

• Zhou, et al. Detecting Repackaged Smartphone Applications in Third-Party Android Marketplaces, Proceedings of CODASPY, 2012.

36

HashingExtraction

Feature

sequence

instruction

fingerprint

app Third Party

App Signatures

Third−party Apps

Author ID

FuzzyThird−party Apps

Author ID

app

fingerprint

Fuzzy

Hashing

instruction

sequenceExtraction

FeatureAndroidMarket Apps

App Signatures

AndroidMarket

Similarity

Scoring

Repackaged Apps

Figure 1: An Overview of DroidMOSS

feature directly. It turns out that it is not robust even for simpleobfuscation that could just change some string operands (such asstring names or hard-coded URLs). Because of that, we opt to makefurther abstraction by removing the operands and retaining only theopcode. The intuition is that it might be easy for repackagers tomodify or rename the (non-critical) operands, but much harder tochange the actual instructions. In the meantime, we also observethat apps intend to include various ad SDK libraries to fetch anddisplay ads. After being disassembled, these shared ad librariesunnecessarily introduce noise to our feature extraction. Fortunately,there are a limited number of them and our current prototype buildsa white-list to remove them from the extracted code.

For the author information, the META-INF subdirectory containsthe full developer certificate, from which we can obtain the devel-oper name, contact and organization information, as well as thepublic key fingerprints. For simplicity, we map each developer cer-tificate into one unique 32-bit identifier (or authorID). This uniqueidentifier is then integrated into the signature for comparison.

2.3 Fingerprint GenerationFor each app, our second step generates a fingerprint from the

extracted code. A common way of achieving that is throughhashing. Although hashing the entire code sequence of an app canuniquely determine whether two apps are the same, they are nothelpful to determine whether two files are similar. The reason issimply because one minor modification will dramatically changethe hashing value. From another perspective, calculating the editdistance between two given sequences is a well-known techniqueto measure their similarity. Unfortunately, it cannot be directlyapplied either. Considering each instruction sequence (of an app)could have hundreds of thousands of instructions, it will be veryexpensive to calculate one single edit distance between two apps,not to mention the large number of apps each needs to be pairedand compared with others.

In DroidMOSS, we adopt a specialized hashing technique calledfuzzy hashing [21]. Instead of directly processing or comparing theentire (long) instruction sequences, it first condenses each sequenceinto one much shorter fingerprint. The similarity between two appsis then calculated based on the shorter fingerprints, not the originalsequences. Therefore, a natural requirement for fuzzy hashing isthat the reduction into shorter fingerprints should minimize thechange, if any, to the similarity of two sequences.

To achieve that, we first divide the instruction sequence intosmaller pieces. Each piece is considered as an independent unit

Algorithm 1 Generate the app fingerprint

Input: Instruction sequence iseq of the appOutput: Fingerprint fpDescription: wsize - sliding window size, rp - reset point value,sw - content in sliding window, ph - the piece hash

1: set_wsize(wsize)2: set_resetpoint(rp)3: init_sliding_window(sw)4: init_piece_hash(ph)5: for all byte d from iseq do6: update_sliding_window(sw, d)7: rh← rolling_hash(sw)8: update_piece_hash(ph, d)9: if rh = rp then

10: fp← concatenate(fp, ph)11: init_piece_hash(ph)12: end if13: end for14: return fp

to contribute to the final fingerprint. Therefore, if the repackagingprocess changes one piece, its impact on the final fingerprint iseffectively localized and contained within this piece. For the restpieces that are not changed, their contributions to the final finger-print are still valid and persistent through the repackaging process,thus reflecting the similarity between the original app and therepackaged one. However, the challenge lies on the determinationof the boundary of each piece. In DroidMOSS, we use a slidingwindow that starts from the very beginning of the instruction se-quence and moves forward until its rolling hashing value equalsa pre-selected reset point, which determines the boundary of thecurrent piece. Specifically, if a reset point is reached, a new pieceshould be started. The concrete process is presented in Algorithm 1and visually summarized in Figure 2.

For further elaboration, suppose a repackaged app has addeda new instruction to invoke an external function. For simplicity,we assume the new instruction is inserted in the first piece of theinstruction sequence (i.e., piece 1 in Figure 2). Since our fuzzyhashing scheme uses a sliding window to calculate the rolling hashto determine the piece boundary, there are two possibilities aboutthe placement of the new instruction in the first piece, either fallingoutside or inside the last sliding window. The former affects only


Malware Installations

• DNS-based analysis shows that extremely small number of devices actually infected.

• C. Lever et al., The Core of the Matter : Analyzing Malicious Traffic in Cellular Carriers, In Proceedings of the ISOC Network & Distributed System Security Symposium (NDSS), 2013.

37

50 100 150 200 250 300 350 400 450 500 550

04-1504-16

04-1704-18

04-1904-20

04-2105-13

05-1405-15

05-1605-17

05-1805-19

06-1706-18

06-1906-20

06-2106-22

06-23

nonmobimobi


More Evidence?

• Even though some examples of mobile malware have been found, virtually nobody is actually infected.

• For perspective, you are much more likely to be struck by lightning than infected with mobil malware.

38

Malware Family

#Assoc.

Do-mains

#Devices(Any type)

#Devices(Mobile only)

DroidDreamLight*† 3 150 44DroidKungFu* 1 19 6

FakeDoc*† 1 5417 2145Fatakr* 1 328 151

GGTracker* 3 1 1Gone60*† 1 1 1

NotCompatible 3 2198 762Plankton*† 4 686 286Malware �* 1 18 1WalkInWat* 1 215 95

* Disclosed before any of our epochs† Distributed in Google Play market

Table 6: Malicious Apps with Domains in Mobile Net-work

Figure 10: DNS request volume for threat ✏ (2011)

Threat ✏ is an Android application that masquerades as alegitimate client to a popular Internet streaming media ser-vice. When run, the application presents a credible loginscreen. When the user attempts to log in, the applicationdisplays an error message and closes. In the meantime,it has sent the user’s credentials to domain qname

✏

in anHTTP request. This threat was publicly disclosed by a ma-jor anti-virus company in October 2011.

Threat � is an Android application that starts a serviceafter reboot that periodically contacts a C&C server hostedon domain qname

�

. The service will respond to commandsreceived from the C&C or via SMS. One command causesthe application to sign all contacts up to an on-line mailinglist, while another command has the application send in-fected download links to all contacts via SMS. These linksare on a different domain than qname

�

. The applicationwill automatically respond to received SMS with an offen-

Figure 11: DNS request volume for threat � (2010 to2011)

sive message, and in certain cases will send offensive SMSmessages to all contacts. This threat was publicly disclosedby a major anti-virus company in May 2011.

5.3.1 Lifetime and Infection Scale

Figure 10 shows the daily lookup volumes for qname✏

,which acts as a proxy for the victims of threat ✏. Theselookups could be recursive DNS servers, so we cannot makeany claims about the size of the overall infected population.The threat was most active on April 12th, but soon afterrapidly declines. The first lookup for qname

✏

was recordedon March 3rd, 2011, and by June 5th 3 there were DNSrequests from 2,731 unique requesters. Table 7 shows thequery volume, AS, and country code of the top ten net-works that sent requests to qname

✏

; the majority of theseare based in the US. Of note is that this threat seems tohave ended well before it was publicly disclosed in October2011; at the time of disclosure, qname

✏

no longer resolvedto a routable address.

Figure 11 shows the lifetime of threat � in terms of queryvolume. This threat became active in January of 2010, andat its peak in February – March 2011 it averaged more than70,000 DNS requests per day. Over the 14 months thatthis threat was active, 13,094 unique IP addresses queriedthe domain name qname

�

. As before, this number can-not be considered an absolute population estimate. Table 7shows the distribution of the infected populations for mo-bile threats � and ✏. We see that a significant portion ofthe infected population resides in Asia-based networks. Wealso note that Google (AS 15169) has a heavy impact on thenumbers in Table 7 (most likely due to crawling). Threat ✏was disclosed well past its peak in DNS requests.

3 We have no data from the authoritative DNS server after this date, sowe have no visibility into later activity


Conclusions• Today’s mobile devices are more powerful than

your desktop computers from a decade ago.

• Think of all the things you can do now that you couldn’t conceive of then.

• Operating Systems are better, but lots of potential still exists for bad behavior.

• Such bad behavior has largely been seen almost exclusively through “good” applications, which use private data in unexpected ways.

39

cnt 5410 - computer and network security: mobile … network security: mobile phone security...

Documents