Open Doors for Bob and Mallory Open Port Usage in

Android Apps and Security Implications

Yunhan Jack Jia Qi Alfred Chen Yikai Lin Chao Kong Z Morley Mao

University of Michigan

jackjia alfchen yklin chaokong zmaoumichedu

AbstractmdashOpen ports are typically used by server software

to serve remote clients and the usage historically leads to

remote exploitation due to insufficient protection Smartphone

operating systems inherit the open port support but since they

are significantly different from traditional server machines in

performance and availability guarantees little is known about

how smartphone applications use open ports and what the

security implications are In this paper we perform the first

systematic study of open port usage on mobile platform and

their security implications To achieve this goal we design

and implement OPAnalyzer a static analysis tool which can

effectively identify and characterize vulnerable open port usage

in Android applications

Using OPAnalyzer we perform extensive usage and vul-

nerability analysis on a dataset with over 100K Android

applications OPAnalyzer successfully classifies 99 of the

mobile usage of open ports into 5 distinct families and from

the output we are able to identify several mobile-specific

usage scenarios such as data sharing in physical proximity

In our subsequent vulnerability analysis we find that nearly

half of the usage is unprotected and can be directly exploited

remotely From the identified vulnerable usage we discover

410 vulnerable applications with 956 potential exploits in total

We manually confirmed the vulnerabilities for 57 applications

including popular ones with 10 to 50 million downloads on

the official market and also an app that is pre-installed on

some device models These vulnerabilities can be exploited to

cause highly-severe damage such as remotely stealing contacts

photos and even security credentials and also performing

sensitive actions such as malware installation and malicious

code execution We have reported these vulnerabilities and

already got acknowledged by the application developers for

some of them We also propose countermeasures and improved

practices for each usage scenario

1 Introduction

An open port (or a listening port) is a communicationendpoint for accepting incoming connections in computernetworking model typically used by server applications tohandle requests from remote clients However these portscan also be connected by malicious clients if not carefullyprotected exposing potential vulnerability in the server soft-ware to remote exploitation Such inherent weakness has

always accompanied the usage of open ports throughout thehistory of network services opening doors for large num-bers of severe Internet attacks such as TCP SYN floodingattacks [27] the Conficker worm [14] and more recentlythe Heartbleed bug [9] To mitigate the problem in thesetraditional usage scenarios firewalls and user authenticationmechanisms are usually adopted

In the recent evolution to the mobile era smartphoneoperating systems inherit the support for open port But forsmartphone applications (apps) traditional open port usecases such as hosting network services no longer applyOne major reason is that compared to stationary servermachines with wired network connectivity the mobilitynature of smartphones makes it difficult to maintain a stableIP address Moreover the IPs assigned to mobile devicesare often behind a NAT (network address translation) pre-venting incoming network connections Also continuouslyreceiving network traffic can easily drain the battery of amobile device leading to a form of denial-of-service (DoS)attack [49] Due to these inherent differences our currentunderstanding about smartphone usage of open ports arerather limited

With the immense popularity of smartphones any po-tential smartphone open port usage may directly expose endusers to severe damage Several such examples have alreadybeen reported recently called ldquoWormholerdquo apps [12] whereopen ports in popular Android apps allow an attacker toremotely collect location data insert contacts and eveninstall app without authorization and over 100M devicesare affected While these exploits are alarming it is stillunclear whether these vulnerabilities are exposed by popularuse cases of open ports in the smartphone ecosystem or justby poor implementation practices

In this work we perform the first systematic study ofopen port usage and the security implications on mobileplatform To achieve this goal we design and implementa tool called OPAnalyzer which can effectively identifyand characterize vulnerable open port usage in Androidapps To use OPAnalyzer we first formalize open port appdesign pattern in the language of program analysis whichin high level specifies what sensitive functions are triggeredfrom open ports and how they are triggered With thesedefinitions OPAnalyzer first uses static taint analysis totrack the information flow from the remote input entry pointand identifies the sensitive functionalities that can potentially

be triggered After this step a set of usage paths of theopen port are generated which will lead to remote exploitsif not well protected To help prioritize human inspectionOPAnalyzer examines the security checks along the usagepaths guarding the sensitive functionality If the executionof a given path is found to have no constraints or containsonly weak checks a potential remote exploit is directlyrevealed (sect44) OPAnalyzer also dynamically tests whetherthe vulnerable port is open by default and labels the weakpaths as highly insecure if the corresponding port opensautomatically at app launching time For high precisionour design leverages the Amandroid approach [46] whichsupports flow- context-sensitive data-flow analysis

To ensure high effectiveness we overcome several en-gineering challenges in the tool implementation First ouranalysis needs accurate identification of the permission-protected APIs but the API to permission mappings pro-vided by the most recent work PScout [21] are incompletefor our purpose since it does not consider the prerequisitesof the API usage To address this limitation we improvePScout to automatically fix some common missing cases(sect43) Second we find that Java reflection is commonlyused to handle remote input from open ports which isnot resolved by many static taint analysis tools such asAmandroid To ensure the call graph completeness weadd an extra analysis to locate the target class or methodwhich successfully resolves over 86 Java reflection usecases in our app dataset (sect44) Third we find that manyapps actually implement open port usage in native codewhich cannot be captured by Java-layer static analysis aloneTherefore our tool also includes native code support basedon binary analysis techniques which is commonly excludedin nearly all existing static analysis tools on Android appsdue to high engineering efforts [20] [33] [34] [46](sect42)

Using OPAnalyzer we perform an open port usageanalysis on 24K popular Android apps from Google Playand successfully classify 99 of the usage paths into 5categories data sharing proxy remote execution VoIP calland PhoneGap (sect52) We also find that significantly dif-ferent from traditional usage ports in some categories weremostly intended only for clients in physical proximity of thesmartphone or even on the same device

Among these open port usage families many are foundto directly enable a number of serious remote exploits ifnot well protected More specifically we use OPAnalyzerto examine the security checks along the identified usagepaths and find that they generally lack sufficient protectionfor the most popular usage data sharing over half of thepaths can be easily triggered by any remote attacker and insome usage categories such as proxy over 80 of the pathsare not protected From OPAnalyzer output we uncover410 vulnerable applications with 956 potential exploits intotal and manually confirm 57 vulnerable apps that havenot been previously reported including popular ones onthe market and even a pre-installed app on some devicemodels These newly-discovered exploits can lead to a largenumber of severe security and privacy breaches for exampleremotely stealing sensitive data such contacts photos and

even security credentials and performing malicious actionssuch as executing arbitrary code and installing malware re-motely (sect6) To get an initial estimate on the impact of thesevulnerabilities in the wild we performed a port scanning inour campus network and immediately found a number ofmobile devices in 2 minutes which were potentially usingthese vulnerable apps we have reported these vulnerabilitiesto the relevant parties through vulnerability tracking systemsincluding CVE [5] and CERT [16] and some of them havebeen acknowledged (eg CVE-2016-5227 VR-176) Weencourage readers to view several short attack video demosat httpssitesgooglecomsiteopenportsec [11]

Leveraging the insights from these analysis we furthercategorize the vulnerable apps based on their intentions ofopen port and discuss defense strategies depending on theunique characteristics in each category (sect7) Specificallyfor the physical proximity usage which does not have anyeffective and usable protection yet we propose a transparentsocket-level solution that allows users to conveniently verifya connection from a device nearby and can be easily adoptedby app developers

We summarize the key contributions of this paperbull We formalize open port app design pattern and

develop OPAnalyzer to systematically characterize open portusage in Android apps and detect exposed vulnerability Toensure high accuracy we tackle several challenges eg

improving the API to permission mapping completenessresolving Java reflection and enabling native code analysis

bull Using our tool we perform the first systematicstudy of open port usage and their security implicationson mobile platform We are able to classify 99 of theidentified usage into 5 distinct usage families and discoversome mobile-specific scenarios We find that nearly half ofthese usage paths have no protection implemented whichcan directly be triggered by remote attackers to leak sensitiveinformation and perform high-privileged actions

bull We perform an in-depth analysis on the vulnerableopen port usage and construct real exploits to validate thethreats From the results we manually confirmed 57 newvulnerable apps containing popular ones on the market andalso a pre-installed app on some device models which canbe used to remotely steal sensitive user data such as photossecurity credentials and perform malicious actions such asexecuting arbitrary code and installing malware We alsosuggest countermeasures and improved practices to mitigatethese problems in each intended open port usage scenario

2 Background and Threat Model

In this paper we broadly define mobile apps with openTCP or UDP ports as open port apps And two types ofopen port apps are covered by our study (1) Mobile service

app provides useful functionality such as sharing files on thehandset by opening a file server to be connected by userrsquosdesktop (2) Malicious open-port apps intentionally openports to carry out malicious activities such as receiving com-mands from remote attackers for data theft or device controlOur study does not focus on malware detection since itrsquos

2

be triggered After this step a set of usage paths of theopen port are generated which will lead to remote exploitsif not well protected To help prioritize human inspectionOPAnalyzer examines the security checks along the usagepaths guarding the sensitive functionality If the executionof a given path is found to have no constraints or containsonly weak checks a potential remote exploit is directlyrevealed (sect44) OPAnalyzer also dynamically tests whetherthe vulnerable port is open by default and labels the weakpaths as highly insecure if the corresponding port opensautomatically at app launching time For high precisionour design leverages the Amandroid approach [46] whichsupports flow- context-sensitive data-flow analysis

To ensure high effectiveness we overcome several en-gineering challenges in the tool implementation First ouranalysis needs accurate identification of the permission-protected APIs but the API to permission mappings pro-vided by the most recent work PScout [21] are incompletefor our purpose since it does not consider the prerequisitesof the API usage To address this limitation we improvePScout to automatically fix some common missing cases(sect43) Second we find that Java reflection is commonlyused to handle remote input from open ports which isnot resolved by many static taint analysis tools such asAmandroid To ensure the call graph completeness weadd an extra analysis to locate the target class or methodwhich successfully resolves over 86 Java reflection usecases in our app dataset (sect44) Third we find that manyapps actually implement open port usage in native codewhich cannot be captured by Java-layer static analysis aloneTherefore our tool also includes native code support basedon binary analysis techniques which is commonly excludedin nearly all existing static analysis tools on Android appsdue to high engineering efforts [20] [33] [34] [46](sect42)

Using OPAnalyzer we perform an open port usageanalysis on 24K popular Android apps from Google Playand successfully classify 99 of the usage paths into 5categories data sharing proxy remote execution VoIP calland PhoneGap (sect52) We also find that significantly dif-ferent from traditional usage ports in some categories weremostly intended only for clients in physical proximity of thesmartphone or even on the same device

Among these open port usage families many are foundto directly enable a number of serious remote exploits ifnot well protected More specifically we use OPAnalyzerto examine the security checks along the identified usagepaths and find that they generally lack sufficient protectionfor the most popular usage data sharing over half of thepaths can be easily triggered by any remote attacker and insome usage categories such as proxy over 80 of the pathsare not protected From OPAnalyzer output we uncover410 vulnerable applications with 956 potential exploits intotal and manually confirm 57 vulnerable apps that havenot been previously reported including popular ones onthe market and even a pre-installed app on some devicemodels These newly-discovered exploits can lead to a largenumber of severe security and privacy breaches for exampleremotely stealing sensitive data such contacts photos and

even security credentials and performing malicious actionssuch as executing arbitrary code and installing malware re-motely (sect6) To get an initial estimate on the impact of thesevulnerabilities in the wild we performed a port scanning inour campus network and immediately found a number ofmobile devices in 2 minutes which were potentially usingthese vulnerable apps we have reported these vulnerabilitiesto the relevant parties through vulnerability tracking systemsincluding CVE [5] and CERT [16] and some of them havebeen acknowledged (eg CVE-2016-5227 VR-176) Weencourage readers to view several short attack video demosat httpssitesgooglecomsiteopenportsec [11]

Leveraging the insights from these analysis we furthercategorize the vulnerable apps based on their intentions ofopen port and discuss defense strategies depending on theunique characteristics in each category (sect7) Specificallyfor the physical proximity usage which does not have anyeffective and usable protection yet we propose a transparentsocket-level solution that allows users to conveniently verifya connection from a device nearby and can be easily adoptedby app developers

We summarize the key contributions of this paperbull We formalize open port app design pattern and

develop OPAnalyzer to systematically characterize open portusage in Android apps and detect exposed vulnerability Toensure high accuracy we tackle several challenges eg

improving the API to permission mapping completenessresolving Java reflection and enabling native code analysis

bull Using our tool we perform the first systematicstudy of open port usage and their security implicationson mobile platform We are able to classify 99 of theidentified usage into 5 distinct usage families and discoversome mobile-specific scenarios We find that nearly half ofthese usage paths have no protection implemented whichcan directly be triggered by remote attackers to leak sensitiveinformation and perform high-privileged actions

bull We perform an in-depth analysis on the vulnerableopen port usage and construct real exploits to validate thethreats From the results we manually confirmed 57 newvulnerable apps containing popular ones on the market andalso a pre-installed app on some device models which canbe used to remotely steal sensitive user data such as photossecurity credentials and perform malicious actions such asexecuting arbitrary code and installing malware We alsosuggest countermeasures and improved practices to mitigatethese problems in each intended open port usage scenario

2 Background and Threat Model

In this paper we broadly define mobile apps with openTCP or UDP ports as open port apps And two types ofopen port apps are covered by our study (1) Mobile service

app provides useful functionality such as sharing files on thehandset by opening a file server to be connected by userrsquosdesktop (2) Malicious open-port apps intentionally openports to carry out malicious activities such as receiving com-mands from remote attackers for data theft or device controlOur study does not focus on malware detection since itrsquos

2

very hard to distinguish malicious and legitimate open portusage without having a comprehensive understanding ofthe designed functionality of each app Instead we focuson identifying problematic usage (including both maliciousand legitimate) that exposes vulnerabilities to attacker andaffects the well-being of the user

Threat model The threat to an app with open portscomes from the attackers with the ability to reach theseports In the design of popular smartphone operating systemssuch as Android ports are reachable from both the samedevice eg another app or a script on the web page and an-other host in the same network with the victim device Thuscompared to the majority of previously-reported smartphoneapp vulnerabilities that only consider the threat from on-device malware [20] [28] [30] [50] [51] open port appsadditionally face threats from network attackers eg localnetwork attacks and web attackers eg malicious scriptswhich is much more diverse and also of wider range Morespecifically in this paper we consider the following three

adversary types(1) Malware on the same device A malicious

app or malware installed by the smartphoneuser can use netstat command or proc fileprocltpidgtnettcp to find the listening portson the same device and send exploitation traffic

(2) Local network attacker For victims behind NATor using private WiFi networks attackers sharing the samelocal network can use ARP scanning [4] to find reachablesmartphone IP addresses at first and then launch targetedport scanning to discover vulnerable open ports

(3) Malicious scripts on the web When a victim uservisits an attacker-controlled website using their mobile de-vice malicious scripts running in the handsetrsquos browser canexploit the vulnerable open ports on the device by sendingnetwork requests which doesnrsquot require any permission

For each of these three threat models we have preparedshort attack video demos on our website [11] to help readersmore concretely understand their practicality

Scope and assumptions Our study focuses on TCPports which are most commonly used We did not studyUDP ports but we argue that our methodology can be easilyadapted for it Our tool is expected to handle obfuscatedAndroid apps as long as they can be disassembled In thecurrent implementation our tool only fails to analyze veryfew samples (06 of apps in our dataset) for them eventhe disassembling process cannot succeed

3 Design Pattern of Open Port Apps

Figure 1 shows a simple example Android app thatopens a port for accepting remote command to push no-tifications on the userrsquos device The app first creates aServerSocket to listen on a TCP port Once a clientconnects to the port the app reads the remote input fromthe socket and serves the request In this example theapp checks whether the remote input contains the ldquoPUSHrdquocommand and if so it starts pushing the messages containedin the remote input to devicersquos notification bar

ServerSocket ss =

new ServerSocket(port)

Bind to a TCP port

Socket s = ssaccept()

Accept an incoming socket

input = sgetInputStream()

read remote input

if (input[0] == ldquoPUSHrdquo)

Check remote input

Push_Notification(input[1])

API being triggered

Remote Input

Sensitive Functionality

Constraints

Entity Dependency

Datadependency

Controldependency

1

2

3

4

5

6

7

8

9

10

11

12

13

Figure 1 Design pattern of open port Android app

We generalize the logic of Android apps with open portsas the design pattern shown on the right side of Figure 1consisting of three different entities and the dependencyrelationship among them

Remote entry point is defined as the content passedto the open port app from the incoming sockets And itserves as the entry point in our analysis framework (sect41)Security mechanisms such as authentication token can beused to authorize the remote access to the app

Sensitive functionality refers to the sensitive API setthat can be triggered by remote input The sensitive APIset defined in this work contains (1) APIs protected by theAndroid permission system eg sendTextMessage()protected by SEND_SMS permission and (2) APIs not pro-tected by permissions but considered sensitive in the openport context For example an app does not require anypermission to read its own data cache However if the datais written back to the incoming socket and transmitted tothe remote client a potential information leakage is causedsince the app cache may contain sensitive user data Wedescribe our approach to construct sensitive API set in sect43

Constraints refer to the conditional statements alongthe path between the remote input and the sensitive APIsIt is usually introduced by the protocols that the app usesto communicate with the remote clients If the constraintson a path are easy to bypass the sensitive functionality onthe path may be exploitable by remote attacker to launchprivilege escalation attack We discuss more on the strengthof the constraints in sect44

Dependency We identify the dependency between re-mote input and sensitive API as the Program Dependencyconsisting of control dependency and data dependency Weuse it to describe the ldquotriggerrdquo relationship between thesource and the sink which is shown to be efficient for us tocharacterize open port usage and understand their securityimplications

In practice the dependency between the remote entrypoint and sensitive API set of an app is not easy to charac-terize The analysis must handle various program flow jumpsin the Android lifecycle including inter-component commu-nications Java reflection and even jumps from native codeto accurately model the open port functionality Moreover

3

APK

Native CodeAnalyzer

ApplicationLayer

Analyzer

Environment Builder

Usage Path Analyzer

Entry Points Sensitive APIs

Reachability Analyzer

Constraints Analyzer

Taint Analysis Engine

Usage Paths

Weak Paths

Highly InsecurePaths

OPAnalyzer Output

Exploits

Figure 2 OPAnalyzer approach overview

to identify those vulnerable paths that can be leveraged byremote attacker the analyzer is required to evaluate whethera given usage path is practically exploitable in terms of thetiming window for attacker and the strengths of the checksperformed on the path We design OPAnalyzer to analyzethe usage and security implications of these apps to addressthese technical challenges

4 OPAnalyzer Approach

The goal of OPAnalyzer is bi-fold (1) to characterizethe open port usage on mobile devices and (2) to identifyvulnerability exposed by the usage To achieve the goalwe design OPAnalyzer to automatically discover all thesensitive functionalities that can be triggered by remote inputand examine the constraints that guard them We define ausage path as a program path from the remote entry pointto a single sensitive functionality with all the conditionalstatements along the path annotated OPAnalyzer performsthe analysis on usage path level so that various functionalityof a given open port can be comprehensively examined

Figure 2 shows the overview of OPAnalyzerrsquos approach(1) OPAnalyzer takes apk files as input extracts bothDalvik bytecode and native shared objects to build the envi-ronment for the app (2) It calculates the entry points fromboth the native code and Dalvik bytecode for subsequentstatic analysis(sect41) (3) It constructs the Inter-componentData Flow Graph (IDFG) and Data Dependency Graph(DDG) from the entry points based on Amandroid whichare both flow- and context-sensitive (4) It performs taintanalysis to study the dependency between remote inputand a precomputed sensitive API set(sect43) and outputs thepaths(5) Constraints analyzer examines all the checks alongthe paths that are control dependent on the remote input andannotates the strength of each constraint (6) Reachabilityanalyzer filters those paths unreachable from the programentry set and annotates the run-time reachability for eachpath(sect44) Usage categorization and vulnerability discoveryare then performed on the annotated usage paths

In the remainder of this section we provide an overviewof the main analysis steps and how we overcome severalchallenges

41 Entry Point Analysis

Entry point analysis collects the remote entry pointsfrom both Dalvik and native code It integrates apktoolas its front-end to decompress the apk file Dalvik bytecodesare decoded to smali format and further converted toan IR called Pilar The application layer analyzer ex-tracted those Java classes that accept connections from eitherServerSocket or ServerSocketChannel which arethe only Android framework APIs for apps to open TCP portin Java as entry points However apps can also embed theopen port functionality into the native code either for thepurpose of disguising their stealth behavior or for perfor-mance reasons Thus we implement a native code analyzerto collect those entry points embedded in native code andcapture the control-flow jumps from native code to the Javalayer

42 Native Code Analyzer

Figure 3 is a code snippet from a real app showing theopen port functionality embedded in native code The appaccepts the incoming socket in native C code and passes thecontrol-flow to application layer to serve the request Shownon line 4 native code broadcasts an intent using thesystem function and the intent is captured by the Javalayer receiver and triggers the ActionReceiver logicAnother type of control-flow jump in this example is shownon line 8 The app starts a service defined in the Androidmanifest from native code and the UploadService startsrunning in the background Such cross-layer interactionscannot be captured by existing static analysis approachesleading to inaccuracy in the security analysis We designand implement a native code analyzer that captures suchcontrol-flow jumps based on inter-procedure taint analysis

The native code analyzer takes the shared object filesextracted from the apk as input and performs taint analysison the decompiled assembly code The taint source is thesocket accepted from the open port while the sinks arethose function calls that can initiate control-flow jump toapplication layer such as system() After locating thesource and sink in the assembly code it analyzes whetherthere is a path that propagates the taint value to the sinkeither explicitly or implicitly The system() function calls

4

v0 = accept( sockampaddrampaddr_len)

accept a remote incoming socket

if (v0 == ldquoactionrdquo)

system(ldquoam broadcast comexampleactionrdquo)

broadcast an intent in Java layer

else

system(ldquoam startservice comexampleUploadServicerdquo)

start an application service in Java layer

ltreceiver androidname=ldquocomexampleActionReceiverrdquogt

ltintent-filtergt

ltaction androidname=ldquocomexampleactionrdquo gt

specify that action will be handled by receiver

ltintent-filtergt

ltreceivergt

ltservice androidname=ldquocomexampleUploadServicerdquo

androidprocess=ldquouploadServicerdquo gt

an upload service that runs in separate process

1

2

3

4

5

6

7

8

9

10

Figure 3 Snippet from real app showing control-flow jump from the native code layer (Left) to the application layer (Right)

in Figure 3 are not directly tainted by the source butare control-dependent on the tainted conditional statementas an example of implicit taint The taint analysis handlesinter-procedure calls as well as asynchronous IO Tohandle many clients simultaneously in native code appcan perform non-blocking IO using Linuxrsquos epoll fa-cility [8] which provides readiness notification to simulateIO multiplexing To serve multiple requests the threaduses epoll_wait to get tasks from event queue andepoll_ctl to add new connections waiting to be handledinto the event queue The taint analysis propagates taintvalues accurately through such asynchronous function callsby keeping track of each event queue We show how thenative code analyzer improves the effectiveness of our toolin sect45

The native code analyzer is implemented as a plug-infor IDAPro written in Python It uses IDAPro [10] asthe front-end and performs the inter-procedural data-flowanalysis on the CFG of the assembly code The time it takesfor analyzing an app depends on the number of shared objectfiles contained in the app The mean analyzing time is 800seconds with the interquartile range of 749 seconds

43 Sensitive API Selection

OPAnalyzer aims at characterizing all the sensitive func-tionality triggered by remote input To define the sensitiveAPI set and categorize their functionality we need an ac-curate mapping from Android APIs to the permissions theyrequire However constructing such mapping for our usecase is non-trivial because our analysis is performed on thecomponent level We detail the challenges and our solutionsbelow

PScout [21] provides a static analysis approach to findthe mappings between API calls and permissions Howeverwe find that it suffers from some completeness problemsTaking the ServerSocket as an example which re-quires Android Internet permission In the mappingsgenerated by PScout we only find the constructor ofthe ServerSocket mapped to the Internet permis-sion while other sensitive APIs such as accept() andgetOutputStream() are missing We suspect that itis because Android enforces some permission checks atthe class level instead of API level Although enforcing

the permission check at the constructor implies that allthe member functions of this class are also protected theincompleteness of the lt API permission gt mappingsrestricts its usability for program analysis especially whenthe analysis is performed on the component level To addressthis problem we design a static analysis tool to automati-cally add such missing APIs to the mappings For every classconstructor presented in the original PScout output the tooltakes the AOSP source code as input and extracts all themember functions of the class to complete the mappings

In addition we find that some APIs are not protectedby Android permissions however when used together arealso considered sensitive in the mobile service context Forexample an app retrieves the device location and stores it inthe application data cache Once a remote connection comesin it reads the location data from the cache and sends it tothe remote attacker In this scenario the incoming socketdoes not trigger any permission check except INTERNETwhich we think is granted by default but the sensitivelocation data is stolen and leaked asynchronously To capturesuch sensitive functionality in the mobile service context wemanually collect all the sources that an app can retrieve dataasynchronously that do not require permission includingapp cache database shared preference etc We define apseudo permission called DATA_LEAK If the data writtento the incoming socket is dependent on the data retrievedfrom these asynchronous sources we consider it as invokingthe DATA_LEAK permission check The pseudo permissiontogether with the associated API pairs are added to thesensitive API set

44 Usage Path Analysis

To identify program dependency OPAnalyzer performstaint analysis on the DDG rooted from remote entry pointstaking the remote input as source and sensitive API setas sink It outputs all the usage paths that the remote inputcan trigger together with all the constraints that guard thesinks which are useful for open port usage categorizationand vulnerability discovery

IDFG and DDG are built for each remote entrypoint using Amandroid which include all those Inter-Component Communication (ICC) edges and are both flow-and context-sensitive However the control-flow jumps in-

5

socket = ServerSocketaccept()

socket = Source1()

remote_input = socketgetInputStream()

flag = remote_input[0]

if (flag == ldquoTruerdquo)

password = getSharedPreferences(ldquopasswordrdquo0)

password = Source2()

outStream = socketgetOutputStream()

outStreamwrite(password)

Sink()

1

2

3

4

5

6

7

8

9

10

11

Figure 4 An example for implicit and explicit taint logic

Socket socket = ServerSocketaccept()

InputStream in = socketgetInputStream()

String input = inreadLine()

String command = inputsplit(ldquo=ldquo)[0]

String value = inputsplit(ldquo=ldquo)[1]

Map map = new HashMapltStringStringgt()

mapput (commandvalue)

if (mapsize() gt 0) C1

if (command == ldquoSEND_SMSrdquo) C2

SendSMS(value) Sink()

1

2

3

4

5

6

7

8

9

10

11

12

Figure 5 Sample app code showing that sensitive API isprotected by constraints

troduced by Java reflection cannot be captured by this ap-proach Since we find that reflections are heavily used in ourdataset and also are found in those well-known Wormhole

apps we add reflection support to the taint analysis engine

Java reflection is used by programs to examine ormodify the runtime behavior of apps running in Java virtualmachine We have seen reflections used in apps for bothlegitimate purpose (eg bypass some API-level restrictions)and malicious purpose (eg disguise the entry to maliciouscode) Handling reflection accurately is impossible for staticanalysis and remains challenging even combining runtimeanalysis [43] To capture the control-flow jumps of reflectionto our best effort we implement a handler in the IDFGbuilder similar to the one used in FlowDroid [20] whichcan link the target class or method invoked by reflectionto the calling function and add the missing edges to theIDFG Currently it only handles reflection calls with targetsexplicitly provided in the same procedure and will missthose whose targets are not deterministic statically Howeverwe find that over 86 of reflections in our dataset can behandled by applying this heuristic and it also helps identifysignificantly more vulnerable paths as shown in sect45

Java layer taint analysis is used to examine the depen-dency among remote input and sensitive APIs We definea notion to describe the explicit and implicit dependencyrelationships among statements The notion is further usedto categorize usage

Notion 1 The dependency relationship between two state-

ments along the same usage path is either implicit orexplicit and transitivity applies

stmt1Eminusrarr stmt2 if stmt2 is explicitly tainted by

the return value of stmt1

stmt1Iminusrarr stmt2 if stmt2 is implicitly tainted by

the return value of stmt1

stmt1Iminusrarr stmt2

Eminusrarr stmt3 if stmt3 is explic-

itly tainted by the return value of stmt2 and bothstmt2 and stmt3 are implicitly tainted by the returnvalue of stmt1

Explicit taint describes the data dependency relationshippropagated by assignment expressions while implicit taintreflects the ldquotriggeringrdquo relationship in which the source ispresented in the conditional statements Shown in Figure 4the first taint source comes from the remote input and flagis explicitly tainted by the remote_input since it is de-rived from it All the statements in the if block are implic-itly tainted by the flag since they are control-dependenton the if statement Specifically another taint source isidentified as the getSharedPreferences which readsdata from an asynchronous source The password readfrom the shared preferences is written to the socket identi-fied as an explicit taint relationship between statements inline 5 and line 6 Thus the dependency relationship alongthis usage path is expressed as

accept()Iminusrarr getSharedPreferences()

Eminusrarr write()

To further narrow down the potential vulnerable path listand provide insights to identify the vulnerability OPAna-lyzer integrates both constraints analysis and reachabilityanalysis to help analyst prioritize paths output by OPAna-lyzer to reduce human efforts

Constraints analyzer examines all the conditional state-ments along the usage path to which the sensitive APIis control dependent on Shown in Figure 5 the remoteinput is separated into two substrings and put into a MapThe sensitive API SendSMS is control dependent on twoconstraints Constraint C1 defined in line 8 checks whetherthe Map is empty while the constraint C2 in line 9 checkswhether the command passed in from remote input isldquoSEND SMSrdquo Both checks are easy to bypass an arbitraryremote attacker can construct the input string to bypassthe checks and trigger the malicious payload to be sentvia SMS which results in a remote privilege redelegationattack [30] OPAnalyzer annotates a constraint as weak if itis either (1) comparison with constants or (2) comparisonwith a predefined set of trivial API (eg Mapsize()SetisEmpty()) The heuristic reduces human effortsby prioritizing usage paths that are obviously easy to becontrolled but could introduce false negatives(sect 45)

Reachability analyzer characterizes the reachability ofa path using both static and dynamic approaches First thestatic analysis models the app Activity lifecycle andfilters those usage paths unreachable from the program entryset The dynamic approach identifies those usage paths thatstart with a port that is open by default at app launching

6

OPAnalyzer

Categorization

apk

usage path

No

Usage families

Pattern matches

Yes

open port usage family

Convert to

Notation 1

Generalize

usage pattern

Figure 6 Usage categorization methodology

time These paths are annotated as highly insecure sinceremote attacker has a large timing window to exploit themNote that ports that are not open by default are still vulner-able to the on-device malware in our threat model sincethe malware can monitor the proc file and exploit thevulnerable paths as long as it detects the port is open Thedynamic analysis is implemented using function hookingbased on Xposed framework [17] and combined with deviceautomation the analyzer automatically annotates reachabil-ity results on the usage paths

Usage categorization methodology Shown in Figure 6OPAnalyzer aggregates usage paths with similar open portusage into one family based on the sensitive APIs theycontain and the notion It extracts usage paths and convertsthem to Notion 1 The categorization approach matches thenotion of new paths with those already identified patternsIf an incoming path cannot be categorized into any of theexisting families we manually generalize its usage to apattern and add a new family to the existing usage familyset Following this approach OPAnalyzer categorizes mostof the usage paths except a few that cannot be converted toNotion 1(sect52)

Vulnerability discovery methodology Considering anattacker in our threat model to exploit a usage path andtrigger the sensitive functionality he needs to (1) find theright timing when the port is open (2) bypass all the checksalong the path to execute the sensitive API The usagepaths output from OPAnalyzer come with the reachabilityinformation sensitive functionality and strengths of predi-cates all annotated help human analyst efficiently examinethese two prerequisites for an attack and identify vulnera-bility Specifically OPAnalyzer prioritize ldquoweak pathsrdquo andldquohighly insecurerdquo paths for manual inspection And notethat we also selectively examined the other usages paths inthe OPAnalyzer output since they may also be vulnerableto remote exploits Some of the interesting vulnerabilities(eg AirDroid exploit) in our case study(sect6) are actuallyidentified in those non-weak usage paths

45 Evaluation

We obtain 24000 apps from the PlayDrone dataset [45]to evaluate our tool which contains top 1000 popular apps

from each of the 24 categories in the Google Play includingentertainment tools etc Our evaluation focuses on thevulnerability discovery of OPAnalyzer which is the mostsecurity critical functionality

Discovery accuracy To evaluate the false positives(FPs) of the weak path detection we first define the FPsas ldquoweakrdquo paths that are verified to be not exploitablethrough manual inspection We examined the weak usagepaths output by OPAnalyzer and constructed remote inputto see if the sensitive functionality could be triggered Wecall these weak paths that are verified to be exploitablevulnerable paths and the rest of them are considered asFPs Among the 24000 apps 68 of them (1632) haveopen-port functionality and 133 weak paths are identifiedto be reachable at app launching time by OPAnalyzer Wemanually identified 113 vulnerable paths that can be easilyexploited by constructing remote input (FP rate 151)The FPs mainly come from paths that contain checks on theruntime property of the app As an example a usage path isguarded by the constraint if (debugMode == True)

will not be triggered when the app is in release mode butwill be output falsely as weak path

Due to the lack of any publicly accessible study of openport vulnerabilities on mobile platform we run OPAnalyzeron the recently-reported Wormhole apps from the Chineseapp market to evaluate the false negatives (FNs) of OP-Analyzer To the best of our knowledge they are the onlyreported instances that contain confirmed open port exploitswhich are usable as ground truth in the FN evaluation TheFNs of the weak path detection are those paths that are notannotated as ldquoweakrdquo but are verified to be exploitable withour manual inspection Wormhole apps are vulnerable dueto their integrations of vulnerable SDKs including BaiduQihoo360 AMap and Tencent [12] and thus we choosethe most popular apps in each SDK category We do nottest on Qihoo360 library since the problem only affects anold beta version which can no longer be found in apps onmajor app markets

As shown in Table 1 OPAnalyzer discovers usage pathsthat contain sensitive functionality in all of the three appswith some of them reported as weak paths Unfortunatelythe report has no detailed path information that can be usedas ground truth for evaluation we do our best to manuallyanalyze the decompiled app to find exploitable paths ForBaidu SDK OPAnalyzer detects all the exploitable pathsthat we manually discovered and even discovers new ex-ploits that have not been reported in the report such asstealing the WiFi BSSID For AMap OPAnalyzer reportsfour usage paths while none of them are recognized as weakpaths However three exploits (FNs) from those non-weakpaths are identified We find that one of the conditionalstatement shared by all 4 usage paths depends on valuethat is defined beyond the IDFG of the remote entry pointOPAnalyzer thus does not consider the check as ldquoweakrdquosince its value cannot be determined while it turns out to beconstant in the run time It is due to the limitation of lackingof backward analysis support so that OPAnalyzer doesnrsquothave enough visibility into how a variable encountered on

7

Wormhole family Sample app Version Entry points Usage path Weak path Not weak path

total exploitable total exploitable

Baidu combaiduBaiduMap 850 1 15 8 8 7 0

Tencent comtencentandroidqqdownloader 570 4 16 1 1 15 1

AMap comautonaviminimap 734 1 4 0 0 4 3

TABLE 1 OPAnalyzer output for three popular ldquoWormholerdquo apps that are reported vulnerable

Feature of usage

Improv Featured applibpaths captured

none 636 NA WiFi file transfer

+ reflection 804 +26 OpenVPN

+ API 1472 +131 AMap

+ native 845 +33 Tencent XG

+ all 1934 +204 Baidu wormhole

TABLE 2 Evaluation of accumulative improvement broughtby (1) handling explicit Java reflection and (2) adding open-port specific sensitive API (3) capturing native code jump

the usage path is propagated to this procedure if it isdefined beyond the IDFG of the entry point This affects theaccuracy of the information leakage tracking and constraintsanalysis and can be solved by integrating backward slicingtechnique [20] [48] We plan to add that to the OPAnalyzerin the future

False negatives may also be introduced by the na-tive code analyzer due to a limitation inherited from theIDA-PRO front end ARM processor supports multiple in-teraction sets mixed in one segment in the runtime whilethe disassembler can interpret one type at the same time inthe static analysis [3] And when the 16-bit ldquoThumbrdquo and32-bit ldquoARMrdquo instructions coexist within one segment dueto optimization the disassembling result may be incorrectAdditionally the native code analysis of OPAnalyzer doesnot cover all possible types of interactions between nativecode and Java code Combining native code and Java codeanalysis is a fundamental challenge of Android app analy-sis [38] and we leave it as future work to accurately modelall the control- and data-flow transitions between native andJava layers

We also evaluate the improvement on the effectiveness ofOPAnalyzerrsquos path discovery brought by three of our engi-neering efforts namely (1) adding open-port specific APIs tothe sensitive API set (2) handling explicit Java reflectionsand (3) capturing native code jump Shown in Table 2integrating these features greatly improves the coverage ofOPAnalyzer by 204 while completing the sensitive APIset turns out to be the most effective engineering effort wespent These improvements reduce false negatives which iscrucial to our system

Performance The most compute-intensive step in OP-Analyzer is the taint analysis which includes building theIDFG and DDG and running the Dijkstrarsquos algorithm on theDDG to find all the usage paths We measure the time toperform the taint analysis for the top 1000 popular apps fromour dataset The experiment runs on a machine with IntelCore i5-3470 CPU and 8GB of RAM For apps with at least

one entry point the median processing time for OPAnalyzerto finish the taint analysis is 615 seconds with standarddeviation of 1272

5 Usage and Vulnerability

With the usage paths output from OPAnalyzer we sys-tematically study open port usage and their security impli-cations in the top 1000 popular apps from each of the 24different categories on Google play

51 Popularity and Permission Usage

Among the 24000 apps we identified open port func-tionality in 68 (1632) while 50 of these open port appshave more than 500K downloads

Sensitive permission usage To understand the mostcommon functionality triggered by remote input we usethe API to permission mappings constructed in sect43 to getthe set of sensitive permissions Figure 7 shows the topsecurity-sensitive permissions involved in open port usageSurprisingly we find that in open port apps a rich set ofhighly-sensitive OS-level functions in Android can be in-voked remotely ranging from accessing private data such ascontacts and location to performing sensitive actions such asusing camera and sending SMS If not protected sufficientlythis usage can be remotely exploited to cause severe dam-ages such as privacy leakage and privileged code executionsjust like the recently reported Wormhole exploits [12] Inaddition we find that the pseudo permission DATA_LEAK

(defined in sect43) which indicates that data is read fromasynchronous sources such as internal storage or contentproviders and sent to the remote end has top popularity inopen-port apps This shows that open port usage commonlyhas potential risk of exposing internal application data to theremote attacker which typically involves plenty of sensitivedata such as credentials and conversation history [51]

52 Usage Family Categorization

Using OPAnalyzer we categorize usage paths into differ-ent usage families defined by code patterns Table 3 showsthe 5 major usage families we identified in our datasettogether with the path categorization results and the typesof potentially-exposed vulnerabilities As shown 99 ofreachable usage paths of open port apps are categorized intoone of the five families which are described in detail asfollows

Data sharing path a usage path through which data readfrom the device is sent to the remote host In this category

8

0

5

10

15

20

25

WRITE_EXTERNAL_STORAGE

C2DM_RECEIVE

DATA_LEAK

ACCESS_COARSE_LOCATION

ACCESS_FINE_LOCATION

GET_TASK

CAMERA

READ_CONTACTS

DISABLE_KEY_GUARD

WRITE_SETTING

RECORD_AUDIO

CALL_PHONE

SEND_SMS

o

f o

pe

n p

ort

ap

ps

Sensitive permissions

Figure 7 Permission protected APIs triggered by remote input

Usage category Pattern Usage path Perc App Weak path Vulnerability

Data sharing accept()Iminusrarr APIdata read

Eminusrarr write() 1340 693 425 775 V1

Proxy accept()Eminusrarr APIout connection 122 63 59 101 V1V3

Remote execution accept()I or Eminusminusminusminusrarr APIexecution 127 65 41 69 V2V3

VoIP call accept()Iminusrarr APIaudio setting 45 23 27 11 V3

PhoneGap Categorized using code signature 282 146 141 0 NA

Uncategorized NA 18 09 10 0 NA

TABLE 3 Open port usage and potential vulnerability V1sensitive data leakage V2 privileged remote execution V3 DoS

the most commonly used protocol for data sharing is HTTPwhile HTTPS FTP UPnP [15] and some customized proto-cols are also observed As shown nearly 60 of the pathsin this category are found to be weakly protected withoutany client authentication leaving them easily exploitable(examples in sect6) By examining the apps in this category wealso identified a mobile-specific open port usage scenariodata sharing in physical proximity eg allowing a userto transfer photo to her PC nearby This usage turns tobring most exploits in this family as shown later in sect624 out of 26 exploits in data sharing are associated withthis particular usage Also worth noting is that in this usagefamily sensitive data can be leaked without invoking anypermission-protected APIs along the tainted path Due toour improvement in sensitive API selection (sect43) our toolcan successfully capture these cases

Proxy path is defined as forwarding requests in remoteinput to other destinations We find that all the paths in theseapps are used as local proxy eg for advertising and contentfiltering For example to overcome the content modificationrestrictions in Android WebView a web browsing app startsas background service a local web proxy so that it can insertits own ads into the fetched web pages If exposed to remoteattackers such local proxy can be used as a reflector intargeted DDoS attacks Also if it is configured to cachepages or store cookies attackers can access personalizedpages to harvest user privacy or even hijack victimrsquos emailor social network accounts for spear phishing attacks

Remote execution path refers to usage paths that cantrigger certain actions on the device such as sending SMS

and writing to storage Besides common use cases suchas push notification we also observe interesting usage inphysical proximity which allows the same user to use mo-bile device functionality through PC interface eg textingSMS using keyboard However there are also sensitive func-tionality that can be executed remotely and are beyond thedeclared functionality of the app which we suspect to beldquobackdoorsrdquo left by app developers

VoIP call paths are used in apps to listen on incomingcall requests based on the Session Initiation Protocol (SIP)After accepting a SIP invite message from the port theapp extracts information such as caller ID and starts thering tone to notify the user Remote attackers in theory cansend spoofed packet to ring the phone and spoof the callerID However due to the IPSec support in SIP such off-pathattack is unlikely to be practical

PhoneGap paths belong to apps developed by Phone-GapCordova a hybrid app development framework al-lowing developers to quickly build apps using JavaScriptand HTML5 It uses open ports to serve requests fromthe JavaScript client and handle the API calls The resultwritten to the incoming socket is not defined in the IDFGof the remote entry point making it difficult for OPAna-lyzer to capture sensitive APIs To address this we usethe presence of several PhoneGap-specific classes such asCallbackServer as the code signatures to identify theseusage paths The port intended for IPC is falsely openedto the Internet However we find that the usage paths ofPhoneGap are protected by strong security checks whichverifies whether the request contains a 128-bit token derived

9

Open port intention Vulnerability description Featured attacks Vulnerable app example App 1

Usage of the app userLack of authentication to verify that Data theft WiFi file transfer 24connections come from the app user Privilege escalation AirDroid PhonePal 10

Communication with Lack of authentication to verify the requests Data theft Lenjoy 15backend are from authentic app backend server Privileged escalation KindeeExpress 5

Local communicationPort used for on-device communication DoS VGet Fast secure VPN 12falsely opened to the network Data theft CachedProxy 1

1 Number of vulnerable apps in the same category An app may be vulnerable to both attacks in each category

TABLE 4 Case study of verified exploitable app categorized by the intended usage of open port

from the devicersquos Universally Unique Identifier (UUID) [1]Thus we consider the open service of PhoneGap as well-protected

53 Security Implications

Usage paths in different families if not well protectedcan lead to different security breaches As shown in table3 OPAnalyzer outputs 956 weak paths We find that nearlyhalf of the total usage paths are considered ldquoweakrdquo In theproxy category over 80 of the paths are not protectedFrom these weak paths we identify three vulnerabilitycategories sensitive data leakage (V1) privileged remoteexecution (V2) and DoS (V3) Besides we also discovera new problem that any open port on smartphones can beexploited to harvest cellular IPv6 addresses which allowsattacker to collect victim IPs without scanning the huge IPv6address space and further launch attack to exploit vulnerableports The vulnerability is detailed in the Appendix A

V1 Sensitive data leakage Sensitive data of a mobiledevice can be retrieved from many sources such as SD Cardsensor etc If these paths are not well protected remoteattacker can exploit them to steal sensitive data that areeven protected by Android permission or UNIX uidgid

check More importantly if the victim IP is public suchvulnerabilities can be easily revealed using fast Internet-wide scanning tools such as ZMap [26] causing large scaledata theft

V2 Privileged remote execution Vulnerable paths thattrigger native actions can be leveraged by remote attackersto execute privileged functionality such as sending SMS andmodifying contacts Moreover by exploiting the broadcast-ing Intent mechanism provided by Android attackers caneven execute functionality beyond the vulnerable app Forexample an unprotected usage path that sends Intent

based on remote input can be leveraged to launch YouTubeapp to play the video from the URL passed by the remoteattacker By uploading a maliciously crafted MP4 file to theURL attacker can gain full control of the device exploitingthe Stagefright vulnerability [6]

V3 Denial of service Most remote execution paths arevulnerable to DoS attack against the device user For thelocal proxy usage paths they can also be used by attackersas reflectors in targeted DDoS attack against victims inthe Internet to hidden their IP addresses Other securityproblems of open proxies such as leaking internal networkdata and IP spoofing based attack also apply

6 Exploits Case Studies

To broaden the scope of our vulnerable study and dis-cover more exploitable open port usage we extended ourdata set to include all the 78K apps from the Tools cate-gory of the PlayDrone dataset to our vulnerability analysisbased on the observation that the percentage of open-portapps in the Tools(109) is significantly higher than theaverage (68) Furthermore we also crawled the top 3000most popular apps from a Chinese app market [2] wherethe Wormhole problem was reported from

By analyzing the annotated usage paths from the OPAna-lyzer output we successfully discover several new exploitsof sensitive data leakage and privileged remote execution inboth apps and third-party libraries including some high-profile ones with millions of downloads and even pre-installed apps Moreover we classify these vulnerable appsinto 3 categories based on the intended usage scenario of theopen port inferred from the manual analysis (1) intendedfor use by app users (2) intended for communication withthe backend and (3) intended for local communicationSuch categorization helps better understand the challengesin securing the port opened for different purposes Table 4shows an overview of the 57 exploitable apps that are man-ually verified from the OPAnalyzer output A case study ofinteresting vulnerability in each category is presented belowThe video demos for some of the implemented attacks areshown on our website [11]

61 Intended for Use by App Users

Such apps open ports for different purposes intendedfor the app users such as transferring file from the phoneto another device of the same user However essentialchecks are found missing in many apps in this category thusexposing the sensitive data and also privileged functionalityof the device to attackers

Virtual data cable is a popular app on China marketthat helps user transfer their photos to PC by opening a webserver on the phone The server port opens by default at applaunch time and silently runs in the background It does notauthenticate clients nor notify incoming connections thuscan be easily scanned and exploited by remote attackersMoreover it does not check the requested file path so thatattacker can access files beyond the photo folder on SD cardby adding ldquordquo to the path and steal sensitive data fromapp cache and system directory Similarly a popular file

10

sharing app WiFi file transfer with 10 million installs doesnot authenticate clients while it opens the server port onlywhen user presses a toggle button However an on-devicemalware that only has Internet permission in our threatmodel can listen on the status of the port by monitoring theproc file system and steal data from the port as long asit is open

PhonePal allows a user to remotely control hisherdevice with a web-browser which contains highly sensitiveusage paths such as open URLs in the Android browserand open videos in the YouTube app All these usage pathsare found unprotected which puts the device at the riskof phishing attack and even compromise [6] Moreovervulnerabilities such as allowing attacker to remotely installapps on the victim device are identified in the high-profileapp AirDroid pre-installed on Samsung Chromebook andSmartisan phone [13] We present a case study of this appin the mitigation strategy section (sect7)

62 Intended for Communication with Backend

Open ports in these apps are intended to communicatewith the app developerrsquos backend server for various pur-poses If the open port service does not authenticate theidentity of the remote server attackers can spoof the appserver Interestingly by manually examining the apps wefind that open port usage of some apps are beyond the appsrsquodeclared functionality implying potentially covert maliciousbehavior

KindeExpress is the most popular mailpackage trackingapp on a China market with 1 million downloads whosefunctionality is to provide tracking information from manydelivery service providers One of its usage path is able tostart an Activity of the app and display the data fromremote input on the apprsquos UI which also brings the app tothe front even when it is running in the background Weverified that none of the declared functionality of the appdepends on this usage path and we suspect it to be usedfor advertising Unfortunately this path is not protected byany authentication mechanism and remote attacker can sendcommand to the app pretending as it comes from the appserver to display deceptive content on the app UI

Huang CheatMaker is a game modifier app that helpsusers cheat when playing mobile games We identified ausage path that accepts data pushed from the app serverstores the data as a shared object (so) file and loadsit at run-time The authentication along the path is weakand the app dynamically loads the code without verifyingwhere it comes from nor its integrity which enables remoteattackers to inject malicious payload to the app to that willbe executed thus compromising the device

63 Intended for Local Communication

Usage paths in Proxy and PhoneGap families are in-tended for on-device communication which can be eitherIPC among different components of an app or proxy fordifferent apps on the device to use However open ports

in some apps that are intended for local usage are falselyexposed to the network and thus lead to security breaches

OpenVPN is an open-source VPN implementation thatis integrated by several popular VPN apps on Google PlayMultiple interfaces are provided by OpenVPN for the appto configure the local VPN settings while the open TCPport interface is identified to be the least secure one Aremote attacker can DoS the victim user by changing proxysettings such as port number on the device Fortunatelysome app developers paid extra attention when integratingOpenVPN and closed the insecure configuration interfacefrom the open TCP port but VPN apps vulnerable to thisproblem still remain (eg Fast secure VPN)

CacheProxy is an app that opens local proxy with thecapability of caching the web page content Upon receivinga request the proxy first checks whether the request can beserved using cached content before fetching the page withno authentication performed on the source of the incomingrequest Remote attackers can thus easily access sensitiveinformation of the victim such as e-mails by requesting thee-mail page since the page is retrieved from the cache forthe attacker

To get an initial estimate on the severity of open portvulnerabilities in the wild we performed a small scale portscan in a subnet of a campus network The ports scannedare those opened by the most popular vulnerable apps inour dataset whose port number needs to be static andunique Note that we only scanned for the existence ofthe open ports but did not send any data to the ports toverify the vulnerability for ethical concerns We performedonly one scan using a scanning tool [26] which finished intwo minutes Surprisingly 40 hosts identified to be mobiledevices open such ports Although different apps that usethe same port number may introduce false positives thescanning result indicates that immediately exploitable openports exist in the wild

7 Mitigation Strategy

Traditional solutions to protect an open port fromInternet attackers are through firewall which monitors andcontrols incoming and outgoing traffic based on prede-termined security policies However the firewall solutionsuffers from usability in the mobile context since it ishard for individual users to configure suitable firewall rulesfor each app installed on the device and coordinate bothapp functionality and security assurance Moreover in thephysical proximity use scenario since users can initiateconnections from arbitrary hosts it is hard to configure rulesin advance

Despite a variety of open port usage described thefundamental problem is the lack of proper client authen-tications However we find that it is non-trivial to provide ageneral solution to patch the security problems for all usagecases while preserving usability We discuss the major chal-lenges in different scenarios and propose countermeasures

Intended for communication with backend For theopen port mobile app to verify that the incoming connection

11

is from the authentic server we suggest using secure tokensto perform authentication Although tokens are already usedin some open port apps implementation flaws are commonlyseen For example a third-party push notification servicethat distributes token to app developers for them to embedin the app is vulnerable because the token can be extractedfrom the released app binary by attacker to exploit the vul-nerable app installed on other victim devices We suggest theapp and server negotiate a shared token using mechanismssuch as Diffie-Hellman [7] at app launching time And openport app uses the token to authenticate further incomingconnections

Intended for use by app users Compared to theprevious usage scenario open port apps in this case do notknow in advance the legitimate remote hosts that shouldconnect to them Depending on the usage of the app userthe trusted remote hosts can be userrsquos desktop or even hisfriendrsquos laptop A general solution is to use password or pincode to authenticate incoming connections however somesecurity issues are raised in practice As an example allthe apps we examined that use password provide hard-codedefault password that does not require users to change beforeusing the app leading to the potential use of the defaultpassword and degrading app security Randomly generatedpin codes in the open port apps we examined are usuallyno longer than 4 characters which is trivial to enumerateExperiment in our local WiFi network indicates that it takesless than 5 minutes to send probing requests that enumerateall the 4-character strings

Another authentication solution adopted by the toptrending apps for this usage scenario is the incoming con-nection notification which pops up a window when a newhost connects to the open port and displays the IP addressof the host And the request is not served until user explic-itly accepts the client by clicking the ldquoallowrdquo button Forordinary users the timing of the pop-up window is also animportant indicator for them to make the decision of whetherto allow or deny the request However on-device malwarecan infer the timing when there is an incoming connection tothe port by monitoring procnet[tcp][tcp6] andsend request immediately to trick user into also allowing itsconnection by overlaying the pop-up window We furtherfind that even the most popular apps in this category hasimplementation flaws that can be practically exploited byattackers in our threat model

AirDroid1 is a top-ranked app on the market that allowsusers to access and manage their Android device wirelesslyfrom desktop by opening a server on the phone It providesa rich set of functionality to users such as access cameraand install apps remotely and uses the incoming connectionnotification schema to authenticate client However if thetiming of user initiated connection is inferred by the attackerwith the help of an on-device malware and attacker sendsrequest to the open port before the user accepts the previousconnection the app wonrsquot pop up another window Insteadthe attacker connection silently replaces the previous legit-

1 AirDroid httpswwwairdroidcom

ServerSocket

SecureServerSocket Remote client

Requestfrom IP0

Return IP0

as QR code

Scan

Trust IP0

Requestfrom IP0

Return

Socket Socket

Display

Check IP0

Figure 8 SecureServerSocket design

imate connection in the waiting queue without changingthe IP address displayed on the pop-up window And whena user clicks the button to allow the legitimate connectionthe attacker client is allowed instead and numerous sensitivecapabilities of AirDroid are granted to the attacker

Usage in this category is usually for the cable-less com-munication with nearby hosts of the user We confirmed that24 out of the 26 vulnerable apps in this category are intendedfor the use in physical proximity We demonstrate a transpar-ent socket-level solution that addresses the security and us-ability challenges in this usage scenario Shown in Figure 8we provide SecureServerSocket which encapsulatesthe Android ServerSocket API to accept incoming sock-ets When a remote client the userrsquos desktop for exampletries to connect to the port the SecureServerSocket

first puts the connection on hold and then encodes the IPaddress of the client into a QR code and returns to theremote client The remote client is required to display theQR code and let the user scan it using the mobile device inorder to get access

Once the QR code is scanned the decoded IP addressis returned to the SecureServerSocket and the con-nection from this IP is allowed It then returns the incom-ing socket to the upper application layer to be handledThis approach authenticates clients on the IP layer andensures that the open port only serves clients in physicalproximity of the device user and it achieves both securityand usability We provide SecureServerSocket as alibrary that app developers can simply use as a replacementof ServerSocket No changes on the client side arerequired if the client is a web browser which is the commoncase in our app dataset For other client types that cannotdisplay QR code we suggest using one-time pin code to dothe authentication instead Demo of the SecureServerSocketimplementation can also be found on our website [11] Andfor future work we plan to conduct a user study to evaluatethe effectiveness of this approach

Intended for local communication For the local usageof on-device proxy the best practice is to bind the proxy tothe loopback address of the device which makes the serviceunreachable from the network For another local usage

12

APK

Native CodeAnalyzer

ApplicationLayer

Analyzer

Environment Builder

Usage Path Analyzer

Entry Points Sensitive APIs

Reachability Analyzer

Constraints Analyzer

Taint Analysis Engine

Usage Paths

Weak Paths

Highly InsecurePaths

OPAnalyzer Output

Exploits

Figure 2 OPAnalyzer approach overview

to identify those vulnerable paths that can be leveraged byremote attacker the analyzer is required to evaluate whethera given usage path is practically exploitable in terms of thetiming window for attacker and the strengths of the checksperformed on the path We design OPAnalyzer to analyzethe usage and security implications of these apps to addressthese technical challenges

4 OPAnalyzer Approach

The goal of OPAnalyzer is bi-fold (1) to characterizethe open port usage on mobile devices and (2) to identifyvulnerability exposed by the usage To achieve the goalwe design OPAnalyzer to automatically discover all thesensitive functionalities that can be triggered by remote inputand examine the constraints that guard them We define ausage path as a program path from the remote entry pointto a single sensitive functionality with all the conditionalstatements along the path annotated OPAnalyzer performsthe analysis on usage path level so that various functionalityof a given open port can be comprehensively examined

Figure 2 shows the overview of OPAnalyzerrsquos approach(1) OPAnalyzer takes apk files as input extracts bothDalvik bytecode and native shared objects to build the envi-ronment for the app (2) It calculates the entry points fromboth the native code and Dalvik bytecode for subsequentstatic analysis(sect41) (3) It constructs the Inter-componentData Flow Graph (IDFG) and Data Dependency Graph(DDG) from the entry points based on Amandroid whichare both flow- and context-sensitive (4) It performs taintanalysis to study the dependency between remote inputand a precomputed sensitive API set(sect43) and outputs thepaths(5) Constraints analyzer examines all the checks alongthe paths that are control dependent on the remote input andannotates the strength of each constraint (6) Reachabilityanalyzer filters those paths unreachable from the programentry set and annotates the run-time reachability for eachpath(sect44) Usage categorization and vulnerability discoveryare then performed on the annotated usage paths

In the remainder of this section we provide an overviewof the main analysis steps and how we overcome severalchallenges

41 Entry Point Analysis

Entry point analysis collects the remote entry pointsfrom both Dalvik and native code It integrates apktoolas its front-end to decompress the apk file Dalvik bytecodesare decoded to smali format and further converted toan IR called Pilar The application layer analyzer ex-tracted those Java classes that accept connections from eitherServerSocket or ServerSocketChannel which arethe only Android framework APIs for apps to open TCP portin Java as entry points However apps can also embed theopen port functionality into the native code either for thepurpose of disguising their stealth behavior or for perfor-mance reasons Thus we implement a native code analyzerto collect those entry points embedded in native code andcapture the control-flow jumps from native code to the Javalayer

42 Native Code Analyzer

Figure 3 is a code snippet from a real app showing theopen port functionality embedded in native code The appaccepts the incoming socket in native C code and passes thecontrol-flow to application layer to serve the request Shownon line 4 native code broadcasts an intent using thesystem function and the intent is captured by the Javalayer receiver and triggers the ActionReceiver logicAnother type of control-flow jump in this example is shownon line 8 The app starts a service defined in the Androidmanifest from native code and the UploadService startsrunning in the background Such cross-layer interactionscannot be captured by existing static analysis approachesleading to inaccuracy in the security analysis We designand implement a native code analyzer that captures suchcontrol-flow jumps based on inter-procedure taint analysis

The native code analyzer takes the shared object filesextracted from the apk as input and performs taint analysison the decompiled assembly code The taint source is thesocket accepted from the open port while the sinks arethose function calls that can initiate control-flow jump toapplication layer such as system() After locating thesource and sink in the assembly code it analyzes whetherthere is a path that propagates the taint value to the sinkeither explicitly or implicitly The system() function calls

4

v0 = accept( sockampaddrampaddr_len)

accept a remote incoming socket

if (v0 == ldquoactionrdquo)

system(ldquoam broadcast comexampleactionrdquo)

broadcast an intent in Java layer

else

system(ldquoam startservice comexampleUploadServicerdquo)

start an application service in Java layer

ltreceiver androidname=ldquocomexampleActionReceiverrdquogt

ltintent-filtergt

ltaction androidname=ldquocomexampleactionrdquo gt

specify that action will be handled by receiver

ltintent-filtergt

ltreceivergt

ltservice androidname=ldquocomexampleUploadServicerdquo

androidprocess=ldquouploadServicerdquo gt

an upload service that runs in separate process

1

2

3

4

5

6

7

8

9

10

Figure 3 Snippet from real app showing control-flow jump from the native code layer (Left) to the application layer (Right)

in Figure 3 are not directly tainted by the source butare control-dependent on the tainted conditional statementas an example of implicit taint The taint analysis handlesinter-procedure calls as well as asynchronous IO Tohandle many clients simultaneously in native code appcan perform non-blocking IO using Linuxrsquos epoll fa-cility [8] which provides readiness notification to simulateIO multiplexing To serve multiple requests the threaduses epoll_wait to get tasks from event queue andepoll_ctl to add new connections waiting to be handledinto the event queue The taint analysis propagates taintvalues accurately through such asynchronous function callsby keeping track of each event queue We show how thenative code analyzer improves the effectiveness of our toolin sect45

The native code analyzer is implemented as a plug-infor IDAPro written in Python It uses IDAPro [10] asthe front-end and performs the inter-procedural data-flowanalysis on the CFG of the assembly code The time it takesfor analyzing an app depends on the number of shared objectfiles contained in the app The mean analyzing time is 800seconds with the interquartile range of 749 seconds

43 Sensitive API Selection

OPAnalyzer aims at characterizing all the sensitive func-tionality triggered by remote input To define the sensitiveAPI set and categorize their functionality we need an ac-curate mapping from Android APIs to the permissions theyrequire However constructing such mapping for our usecase is non-trivial because our analysis is performed on thecomponent level We detail the challenges and our solutionsbelow

PScout [21] provides a static analysis approach to findthe mappings between API calls and permissions Howeverwe find that it suffers from some completeness problemsTaking the ServerSocket as an example which re-quires Android Internet permission In the mappingsgenerated by PScout we only find the constructor ofthe ServerSocket mapped to the Internet permis-sion while other sensitive APIs such as accept() andgetOutputStream() are missing We suspect that itis because Android enforces some permission checks atthe class level instead of API level Although enforcing

the permission check at the constructor implies that allthe member functions of this class are also protected theincompleteness of the lt API permission gt mappingsrestricts its usability for program analysis especially whenthe analysis is performed on the component level To addressthis problem we design a static analysis tool to automati-cally add such missing APIs to the mappings For every classconstructor presented in the original PScout output the tooltakes the AOSP source code as input and extracts all themember functions of the class to complete the mappings

In addition we find that some APIs are not protectedby Android permissions however when used together arealso considered sensitive in the mobile service context Forexample an app retrieves the device location and stores it inthe application data cache Once a remote connection comesin it reads the location data from the cache and sends it tothe remote attacker In this scenario the incoming socketdoes not trigger any permission check except INTERNETwhich we think is granted by default but the sensitivelocation data is stolen and leaked asynchronously To capturesuch sensitive functionality in the mobile service context wemanually collect all the sources that an app can retrieve dataasynchronously that do not require permission includingapp cache database shared preference etc We define apseudo permission called DATA_LEAK If the data writtento the incoming socket is dependent on the data retrievedfrom these asynchronous sources we consider it as invokingthe DATA_LEAK permission check The pseudo permissiontogether with the associated API pairs are added to thesensitive API set

44 Usage Path Analysis

To identify program dependency OPAnalyzer performstaint analysis on the DDG rooted from remote entry pointstaking the remote input as source and sensitive API setas sink It outputs all the usage paths that the remote inputcan trigger together with all the constraints that guard thesinks which are useful for open port usage categorizationand vulnerability discovery

IDFG and DDG are built for each remote entrypoint using Amandroid which include all those Inter-Component Communication (ICC) edges and are both flow-and context-sensitive However the control-flow jumps in-

5

socket = ServerSocketaccept()

socket = Source1()

remote_input = socketgetInputStream()

flag = remote_input[0]

if (flag == ldquoTruerdquo)

password = getSharedPreferences(ldquopasswordrdquo0)

password = Source2()

outStream = socketgetOutputStream()

outStreamwrite(password)

Sink()

1

2

3

4

5

6

7

8

9

10

11

Figure 4 An example for implicit and explicit taint logic

Socket socket = ServerSocketaccept()

InputStream in = socketgetInputStream()

String input = inreadLine()

String command = inputsplit(ldquo=ldquo)[0]

String value = inputsplit(ldquo=ldquo)[1]

Map map = new HashMapltStringStringgt()

mapput (commandvalue)

if (mapsize() gt 0) C1

if (command == ldquoSEND_SMSrdquo) C2

SendSMS(value) Sink()

1

2

3

4

5

6

7

8

9

10

11

12

Figure 5 Sample app code showing that sensitive API isprotected by constraints

troduced by Java reflection cannot be captured by this ap-proach Since we find that reflections are heavily used in ourdataset and also are found in those well-known Wormhole

apps we add reflection support to the taint analysis engine

Java reflection is used by programs to examine ormodify the runtime behavior of apps running in Java virtualmachine We have seen reflections used in apps for bothlegitimate purpose (eg bypass some API-level restrictions)and malicious purpose (eg disguise the entry to maliciouscode) Handling reflection accurately is impossible for staticanalysis and remains challenging even combining runtimeanalysis [43] To capture the control-flow jumps of reflectionto our best effort we implement a handler in the IDFGbuilder similar to the one used in FlowDroid [20] whichcan link the target class or method invoked by reflectionto the calling function and add the missing edges to theIDFG Currently it only handles reflection calls with targetsexplicitly provided in the same procedure and will missthose whose targets are not deterministic statically Howeverwe find that over 86 of reflections in our dataset can behandled by applying this heuristic and it also helps identifysignificantly more vulnerable paths as shown in sect45

Java layer taint analysis is used to examine the depen-dency among remote input and sensitive APIs We definea notion to describe the explicit and implicit dependencyrelationships among statements The notion is further usedto categorize usage

Notion 1 The dependency relationship between two state-

ments along the same usage path is either implicit orexplicit and transitivity applies

stmt1Eminusrarr stmt2 if stmt2 is explicitly tainted by

the return value of stmt1

stmt1Iminusrarr stmt2 if stmt2 is implicitly tainted by

the return value of stmt1

stmt1Iminusrarr stmt2

Eminusrarr stmt3 if stmt3 is explic-

itly tainted by the return value of stmt2 and bothstmt2 and stmt3 are implicitly tainted by the returnvalue of stmt1

Explicit taint describes the data dependency relationshippropagated by assignment expressions while implicit taintreflects the ldquotriggeringrdquo relationship in which the source ispresented in the conditional statements Shown in Figure 4the first taint source comes from the remote input and flagis explicitly tainted by the remote_input since it is de-rived from it All the statements in the if block are implic-itly tainted by the flag since they are control-dependenton the if statement Specifically another taint source isidentified as the getSharedPreferences which readsdata from an asynchronous source The password readfrom the shared preferences is written to the socket identi-fied as an explicit taint relationship between statements inline 5 and line 6 Thus the dependency relationship alongthis usage path is expressed as

accept()Iminusrarr getSharedPreferences()

Eminusrarr write()

To further narrow down the potential vulnerable path listand provide insights to identify the vulnerability OPAna-lyzer integrates both constraints analysis and reachabilityanalysis to help analyst prioritize paths output by OPAna-lyzer to reduce human efforts

Constraints analyzer examines all the conditional state-ments along the usage path to which the sensitive APIis control dependent on Shown in Figure 5 the remoteinput is separated into two substrings and put into a MapThe sensitive API SendSMS is control dependent on twoconstraints Constraint C1 defined in line 8 checks whetherthe Map is empty while the constraint C2 in line 9 checkswhether the command passed in from remote input isldquoSEND SMSrdquo Both checks are easy to bypass an arbitraryremote attacker can construct the input string to bypassthe checks and trigger the malicious payload to be sentvia SMS which results in a remote privilege redelegationattack [30] OPAnalyzer annotates a constraint as weak if itis either (1) comparison with constants or (2) comparisonwith a predefined set of trivial API (eg Mapsize()SetisEmpty()) The heuristic reduces human effortsby prioritizing usage paths that are obviously easy to becontrolled but could introduce false negatives(sect 45)

Reachability analyzer characterizes the reachability ofa path using both static and dynamic approaches First thestatic analysis models the app Activity lifecycle andfilters those usage paths unreachable from the program entryset The dynamic approach identifies those usage paths thatstart with a port that is open by default at app launching

6

OPAnalyzer

Categorization

apk

usage path

No

Usage families

Pattern matches

Yes

open port usage family

Convert to

Notation 1

Generalize

usage pattern

Figure 6 Usage categorization methodology

time These paths are annotated as highly insecure sinceremote attacker has a large timing window to exploit themNote that ports that are not open by default are still vulner-able to the on-device malware in our threat model sincethe malware can monitor the proc file and exploit thevulnerable paths as long as it detects the port is open Thedynamic analysis is implemented using function hookingbased on Xposed framework [17] and combined with deviceautomation the analyzer automatically annotates reachabil-ity results on the usage paths

Usage categorization methodology Shown in Figure 6OPAnalyzer aggregates usage paths with similar open portusage into one family based on the sensitive APIs theycontain and the notion It extracts usage paths and convertsthem to Notion 1 The categorization approach matches thenotion of new paths with those already identified patternsIf an incoming path cannot be categorized into any of theexisting families we manually generalize its usage to apattern and add a new family to the existing usage familyset Following this approach OPAnalyzer categorizes mostof the usage paths except a few that cannot be converted toNotion 1(sect52)

Vulnerability discovery methodology Considering anattacker in our threat model to exploit a usage path andtrigger the sensitive functionality he needs to (1) find theright timing when the port is open (2) bypass all the checksalong the path to execute the sensitive API The usagepaths output from OPAnalyzer come with the reachabilityinformation sensitive functionality and strengths of predi-cates all annotated help human analyst efficiently examinethese two prerequisites for an attack and identify vulnera-bility Specifically OPAnalyzer prioritize ldquoweak pathsrdquo andldquohighly insecurerdquo paths for manual inspection And notethat we also selectively examined the other usages paths inthe OPAnalyzer output since they may also be vulnerableto remote exploits Some of the interesting vulnerabilities(eg AirDroid exploit) in our case study(sect6) are actuallyidentified in those non-weak usage paths

45 Evaluation

We obtain 24000 apps from the PlayDrone dataset [45]to evaluate our tool which contains top 1000 popular apps

from each of the 24 categories in the Google Play includingentertainment tools etc Our evaluation focuses on thevulnerability discovery of OPAnalyzer which is the mostsecurity critical functionality

Discovery accuracy To evaluate the false positives(FPs) of the weak path detection we first define the FPsas ldquoweakrdquo paths that are verified to be not exploitablethrough manual inspection We examined the weak usagepaths output by OPAnalyzer and constructed remote inputto see if the sensitive functionality could be triggered Wecall these weak paths that are verified to be exploitablevulnerable paths and the rest of them are considered asFPs Among the 24000 apps 68 of them (1632) haveopen-port functionality and 133 weak paths are identifiedto be reachable at app launching time by OPAnalyzer Wemanually identified 113 vulnerable paths that can be easilyexploited by constructing remote input (FP rate 151)The FPs mainly come from paths that contain checks on theruntime property of the app As an example a usage path isguarded by the constraint if (debugMode == True)

will not be triggered when the app is in release mode butwill be output falsely as weak path

Due to the lack of any publicly accessible study of openport vulnerabilities on mobile platform we run OPAnalyzeron the recently-reported Wormhole apps from the Chineseapp market to evaluate the false negatives (FNs) of OP-Analyzer To the best of our knowledge they are the onlyreported instances that contain confirmed open port exploitswhich are usable as ground truth in the FN evaluation TheFNs of the weak path detection are those paths that are notannotated as ldquoweakrdquo but are verified to be exploitable withour manual inspection Wormhole apps are vulnerable dueto their integrations of vulnerable SDKs including BaiduQihoo360 AMap and Tencent [12] and thus we choosethe most popular apps in each SDK category We do nottest on Qihoo360 library since the problem only affects anold beta version which can no longer be found in apps onmajor app markets

As shown in Table 1 OPAnalyzer discovers usage pathsthat contain sensitive functionality in all of the three appswith some of them reported as weak paths Unfortunatelythe report has no detailed path information that can be usedas ground truth for evaluation we do our best to manuallyanalyze the decompiled app to find exploitable paths ForBaidu SDK OPAnalyzer detects all the exploitable pathsthat we manually discovered and even discovers new ex-ploits that have not been reported in the report such asstealing the WiFi BSSID For AMap OPAnalyzer reportsfour usage paths while none of them are recognized as weakpaths However three exploits (FNs) from those non-weakpaths are identified We find that one of the conditionalstatement shared by all 4 usage paths depends on valuethat is defined beyond the IDFG of the remote entry pointOPAnalyzer thus does not consider the check as ldquoweakrdquosince its value cannot be determined while it turns out to beconstant in the run time It is due to the limitation of lackingof backward analysis support so that OPAnalyzer doesnrsquothave enough visibility into how a variable encountered on

7

Wormhole family Sample app Version Entry points Usage path Weak path Not weak path

total exploitable total exploitable

Baidu combaiduBaiduMap 850 1 15 8 8 7 0

Tencent comtencentandroidqqdownloader 570 4 16 1 1 15 1

AMap comautonaviminimap 734 1 4 0 0 4 3

TABLE 1 OPAnalyzer output for three popular ldquoWormholerdquo apps that are reported vulnerable

Feature of usage

Improv Featured applibpaths captured

none 636 NA WiFi file transfer

+ reflection 804 +26 OpenVPN

+ API 1472 +131 AMap

+ native 845 +33 Tencent XG

+ all 1934 +204 Baidu wormhole

TABLE 2 Evaluation of accumulative improvement broughtby (1) handling explicit Java reflection and (2) adding open-port specific sensitive API (3) capturing native code jump

the usage path is propagated to this procedure if it isdefined beyond the IDFG of the entry point This affects theaccuracy of the information leakage tracking and constraintsanalysis and can be solved by integrating backward slicingtechnique [20] [48] We plan to add that to the OPAnalyzerin the future

False negatives may also be introduced by the na-tive code analyzer due to a limitation inherited from theIDA-PRO front end ARM processor supports multiple in-teraction sets mixed in one segment in the runtime whilethe disassembler can interpret one type at the same time inthe static analysis [3] And when the 16-bit ldquoThumbrdquo and32-bit ldquoARMrdquo instructions coexist within one segment dueto optimization the disassembling result may be incorrectAdditionally the native code analysis of OPAnalyzer doesnot cover all possible types of interactions between nativecode and Java code Combining native code and Java codeanalysis is a fundamental challenge of Android app analy-sis [38] and we leave it as future work to accurately modelall the control- and data-flow transitions between native andJava layers

We also evaluate the improvement on the effectiveness ofOPAnalyzerrsquos path discovery brought by three of our engi-neering efforts namely (1) adding open-port specific APIs tothe sensitive API set (2) handling explicit Java reflectionsand (3) capturing native code jump Shown in Table 2integrating these features greatly improves the coverage ofOPAnalyzer by 204 while completing the sensitive APIset turns out to be the most effective engineering effort wespent These improvements reduce false negatives which iscrucial to our system

Performance The most compute-intensive step in OP-Analyzer is the taint analysis which includes building theIDFG and DDG and running the Dijkstrarsquos algorithm on theDDG to find all the usage paths We measure the time toperform the taint analysis for the top 1000 popular apps fromour dataset The experiment runs on a machine with IntelCore i5-3470 CPU and 8GB of RAM For apps with at least

one entry point the median processing time for OPAnalyzerto finish the taint analysis is 615 seconds with standarddeviation of 1272

5 Usage and Vulnerability

With the usage paths output from OPAnalyzer we sys-tematically study open port usage and their security impli-cations in the top 1000 popular apps from each of the 24different categories on Google play

51 Popularity and Permission Usage

Among the 24000 apps we identified open port func-tionality in 68 (1632) while 50 of these open port appshave more than 500K downloads

Sensitive permission usage To understand the mostcommon functionality triggered by remote input we usethe API to permission mappings constructed in sect43 to getthe set of sensitive permissions Figure 7 shows the topsecurity-sensitive permissions involved in open port usageSurprisingly we find that in open port apps a rich set ofhighly-sensitive OS-level functions in Android can be in-voked remotely ranging from accessing private data such ascontacts and location to performing sensitive actions such asusing camera and sending SMS If not protected sufficientlythis usage can be remotely exploited to cause severe dam-ages such as privacy leakage and privileged code executionsjust like the recently reported Wormhole exploits [12] Inaddition we find that the pseudo permission DATA_LEAK

(defined in sect43) which indicates that data is read fromasynchronous sources such as internal storage or contentproviders and sent to the remote end has top popularity inopen-port apps This shows that open port usage commonlyhas potential risk of exposing internal application data to theremote attacker which typically involves plenty of sensitivedata such as credentials and conversation history [51]

52 Usage Family Categorization

Using OPAnalyzer we categorize usage paths into differ-ent usage families defined by code patterns Table 3 showsthe 5 major usage families we identified in our datasettogether with the path categorization results and the typesof potentially-exposed vulnerabilities As shown 99 ofreachable usage paths of open port apps are categorized intoone of the five families which are described in detail asfollows

Data sharing path a usage path through which data readfrom the device is sent to the remote host In this category

8

0

5

10

15

20

25

WRITE_EXTERNAL_STORAGE

C2DM_RECEIVE

DATA_LEAK

ACCESS_COARSE_LOCATION

ACCESS_FINE_LOCATION

GET_TASK

CAMERA

READ_CONTACTS

DISABLE_KEY_GUARD

WRITE_SETTING

RECORD_AUDIO

CALL_PHONE

SEND_SMS

o

f o

pe

n p

ort

ap

ps

Sensitive permissions

Figure 7 Permission protected APIs triggered by remote input

Usage category Pattern Usage path Perc App Weak path Vulnerability

Data sharing accept()Iminusrarr APIdata read

Eminusrarr write() 1340 693 425 775 V1

Proxy accept()Eminusrarr APIout connection 122 63 59 101 V1V3

Remote execution accept()I or Eminusminusminusminusrarr APIexecution 127 65 41 69 V2V3

VoIP call accept()Iminusrarr APIaudio setting 45 23 27 11 V3

PhoneGap Categorized using code signature 282 146 141 0 NA

Uncategorized NA 18 09 10 0 NA

TABLE 3 Open port usage and potential vulnerability V1sensitive data leakage V2 privileged remote execution V3 DoS

the most commonly used protocol for data sharing is HTTPwhile HTTPS FTP UPnP [15] and some customized proto-cols are also observed As shown nearly 60 of the pathsin this category are found to be weakly protected withoutany client authentication leaving them easily exploitable(examples in sect6) By examining the apps in this category wealso identified a mobile-specific open port usage scenariodata sharing in physical proximity eg allowing a userto transfer photo to her PC nearby This usage turns tobring most exploits in this family as shown later in sect624 out of 26 exploits in data sharing are associated withthis particular usage Also worth noting is that in this usagefamily sensitive data can be leaked without invoking anypermission-protected APIs along the tainted path Due toour improvement in sensitive API selection (sect43) our toolcan successfully capture these cases

Proxy path is defined as forwarding requests in remoteinput to other destinations We find that all the paths in theseapps are used as local proxy eg for advertising and contentfiltering For example to overcome the content modificationrestrictions in Android WebView a web browsing app startsas background service a local web proxy so that it can insertits own ads into the fetched web pages If exposed to remoteattackers such local proxy can be used as a reflector intargeted DDoS attacks Also if it is configured to cachepages or store cookies attackers can access personalizedpages to harvest user privacy or even hijack victimrsquos emailor social network accounts for spear phishing attacks

Remote execution path refers to usage paths that cantrigger certain actions on the device such as sending SMS

and writing to storage Besides common use cases suchas push notification we also observe interesting usage inphysical proximity which allows the same user to use mo-bile device functionality through PC interface eg textingSMS using keyboard However there are also sensitive func-tionality that can be executed remotely and are beyond thedeclared functionality of the app which we suspect to beldquobackdoorsrdquo left by app developers

VoIP call paths are used in apps to listen on incomingcall requests based on the Session Initiation Protocol (SIP)After accepting a SIP invite message from the port theapp extracts information such as caller ID and starts thering tone to notify the user Remote attackers in theory cansend spoofed packet to ring the phone and spoof the callerID However due to the IPSec support in SIP such off-pathattack is unlikely to be practical

PhoneGap paths belong to apps developed by Phone-GapCordova a hybrid app development framework al-lowing developers to quickly build apps using JavaScriptand HTML5 It uses open ports to serve requests fromthe JavaScript client and handle the API calls The resultwritten to the incoming socket is not defined in the IDFGof the remote entry point making it difficult for OPAna-lyzer to capture sensitive APIs To address this we usethe presence of several PhoneGap-specific classes such asCallbackServer as the code signatures to identify theseusage paths The port intended for IPC is falsely openedto the Internet However we find that the usage paths ofPhoneGap are protected by strong security checks whichverifies whether the request contains a 128-bit token derived

9

Open port intention Vulnerability description Featured attacks Vulnerable app example App 1

Usage of the app userLack of authentication to verify that Data theft WiFi file transfer 24connections come from the app user Privilege escalation AirDroid PhonePal 10

Communication with Lack of authentication to verify the requests Data theft Lenjoy 15backend are from authentic app backend server Privileged escalation KindeeExpress 5

Local communicationPort used for on-device communication DoS VGet Fast secure VPN 12falsely opened to the network Data theft CachedProxy 1

1 Number of vulnerable apps in the same category An app may be vulnerable to both attacks in each category

TABLE 4 Case study of verified exploitable app categorized by the intended usage of open port

from the devicersquos Universally Unique Identifier (UUID) [1]Thus we consider the open service of PhoneGap as well-protected

53 Security Implications

Usage paths in different families if not well protectedcan lead to different security breaches As shown in table3 OPAnalyzer outputs 956 weak paths We find that nearlyhalf of the total usage paths are considered ldquoweakrdquo In theproxy category over 80 of the paths are not protectedFrom these weak paths we identify three vulnerabilitycategories sensitive data leakage (V1) privileged remoteexecution (V2) and DoS (V3) Besides we also discovera new problem that any open port on smartphones can beexploited to harvest cellular IPv6 addresses which allowsattacker to collect victim IPs without scanning the huge IPv6address space and further launch attack to exploit vulnerableports The vulnerability is detailed in the Appendix A

V1 Sensitive data leakage Sensitive data of a mobiledevice can be retrieved from many sources such as SD Cardsensor etc If these paths are not well protected remoteattacker can exploit them to steal sensitive data that areeven protected by Android permission or UNIX uidgid

check More importantly if the victim IP is public suchvulnerabilities can be easily revealed using fast Internet-wide scanning tools such as ZMap [26] causing large scaledata theft

V2 Privileged remote execution Vulnerable paths thattrigger native actions can be leveraged by remote attackersto execute privileged functionality such as sending SMS andmodifying contacts Moreover by exploiting the broadcast-ing Intent mechanism provided by Android attackers caneven execute functionality beyond the vulnerable app Forexample an unprotected usage path that sends Intent

based on remote input can be leveraged to launch YouTubeapp to play the video from the URL passed by the remoteattacker By uploading a maliciously crafted MP4 file to theURL attacker can gain full control of the device exploitingthe Stagefright vulnerability [6]

V3 Denial of service Most remote execution paths arevulnerable to DoS attack against the device user For thelocal proxy usage paths they can also be used by attackersas reflectors in targeted DDoS attack against victims inthe Internet to hidden their IP addresses Other securityproblems of open proxies such as leaking internal networkdata and IP spoofing based attack also apply

6 Exploits Case Studies

To broaden the scope of our vulnerable study and dis-cover more exploitable open port usage we extended ourdata set to include all the 78K apps from the Tools cate-gory of the PlayDrone dataset to our vulnerability analysisbased on the observation that the percentage of open-portapps in the Tools(109) is significantly higher than theaverage (68) Furthermore we also crawled the top 3000most popular apps from a Chinese app market [2] wherethe Wormhole problem was reported from

By analyzing the annotated usage paths from the OPAna-lyzer output we successfully discover several new exploitsof sensitive data leakage and privileged remote execution inboth apps and third-party libraries including some high-profile ones with millions of downloads and even pre-installed apps Moreover we classify these vulnerable appsinto 3 categories based on the intended usage scenario of theopen port inferred from the manual analysis (1) intendedfor use by app users (2) intended for communication withthe backend and (3) intended for local communicationSuch categorization helps better understand the challengesin securing the port opened for different purposes Table 4shows an overview of the 57 exploitable apps that are man-ually verified from the OPAnalyzer output A case study ofinteresting vulnerability in each category is presented belowThe video demos for some of the implemented attacks areshown on our website [11]

61 Intended for Use by App Users

Such apps open ports for different purposes intendedfor the app users such as transferring file from the phoneto another device of the same user However essentialchecks are found missing in many apps in this category thusexposing the sensitive data and also privileged functionalityof the device to attackers

Virtual data cable is a popular app on China marketthat helps user transfer their photos to PC by opening a webserver on the phone The server port opens by default at applaunch time and silently runs in the background It does notauthenticate clients nor notify incoming connections thuscan be easily scanned and exploited by remote attackersMoreover it does not check the requested file path so thatattacker can access files beyond the photo folder on SD cardby adding ldquordquo to the path and steal sensitive data fromapp cache and system directory Similarly a popular file

10

sharing app WiFi file transfer with 10 million installs doesnot authenticate clients while it opens the server port onlywhen user presses a toggle button However an on-devicemalware that only has Internet permission in our threatmodel can listen on the status of the port by monitoring theproc file system and steal data from the port as long asit is open

PhonePal allows a user to remotely control hisherdevice with a web-browser which contains highly sensitiveusage paths such as open URLs in the Android browserand open videos in the YouTube app All these usage pathsare found unprotected which puts the device at the riskof phishing attack and even compromise [6] Moreovervulnerabilities such as allowing attacker to remotely installapps on the victim device are identified in the high-profileapp AirDroid pre-installed on Samsung Chromebook andSmartisan phone [13] We present a case study of this appin the mitigation strategy section (sect7)

62 Intended for Communication with Backend

Open ports in these apps are intended to communicatewith the app developerrsquos backend server for various pur-poses If the open port service does not authenticate theidentity of the remote server attackers can spoof the appserver Interestingly by manually examining the apps wefind that open port usage of some apps are beyond the appsrsquodeclared functionality implying potentially covert maliciousbehavior

KindeExpress is the most popular mailpackage trackingapp on a China market with 1 million downloads whosefunctionality is to provide tracking information from manydelivery service providers One of its usage path is able tostart an Activity of the app and display the data fromremote input on the apprsquos UI which also brings the app tothe front even when it is running in the background Weverified that none of the declared functionality of the appdepends on this usage path and we suspect it to be usedfor advertising Unfortunately this path is not protected byany authentication mechanism and remote attacker can sendcommand to the app pretending as it comes from the appserver to display deceptive content on the app UI

Huang CheatMaker is a game modifier app that helpsusers cheat when playing mobile games We identified ausage path that accepts data pushed from the app serverstores the data as a shared object (so) file and loadsit at run-time The authentication along the path is weakand the app dynamically loads the code without verifyingwhere it comes from nor its integrity which enables remoteattackers to inject malicious payload to the app to that willbe executed thus compromising the device

63 Intended for Local Communication

Usage paths in Proxy and PhoneGap families are in-tended for on-device communication which can be eitherIPC among different components of an app or proxy fordifferent apps on the device to use However open ports

in some apps that are intended for local usage are falselyexposed to the network and thus lead to security breaches

OpenVPN is an open-source VPN implementation thatis integrated by several popular VPN apps on Google PlayMultiple interfaces are provided by OpenVPN for the appto configure the local VPN settings while the open TCPport interface is identified to be the least secure one Aremote attacker can DoS the victim user by changing proxysettings such as port number on the device Fortunatelysome app developers paid extra attention when integratingOpenVPN and closed the insecure configuration interfacefrom the open TCP port but VPN apps vulnerable to thisproblem still remain (eg Fast secure VPN)

CacheProxy is an app that opens local proxy with thecapability of caching the web page content Upon receivinga request the proxy first checks whether the request can beserved using cached content before fetching the page withno authentication performed on the source of the incomingrequest Remote attackers can thus easily access sensitiveinformation of the victim such as e-mails by requesting thee-mail page since the page is retrieved from the cache forthe attacker

To get an initial estimate on the severity of open portvulnerabilities in the wild we performed a small scale portscan in a subnet of a campus network The ports scannedare those opened by the most popular vulnerable apps inour dataset whose port number needs to be static andunique Note that we only scanned for the existence ofthe open ports but did not send any data to the ports toverify the vulnerability for ethical concerns We performedonly one scan using a scanning tool [26] which finished intwo minutes Surprisingly 40 hosts identified to be mobiledevices open such ports Although different apps that usethe same port number may introduce false positives thescanning result indicates that immediately exploitable openports exist in the wild

7 Mitigation Strategy

Traditional solutions to protect an open port fromInternet attackers are through firewall which monitors andcontrols incoming and outgoing traffic based on prede-termined security policies However the firewall solutionsuffers from usability in the mobile context since it ishard for individual users to configure suitable firewall rulesfor each app installed on the device and coordinate bothapp functionality and security assurance Moreover in thephysical proximity use scenario since users can initiateconnections from arbitrary hosts it is hard to configure rulesin advance

Despite a variety of open port usage described thefundamental problem is the lack of proper client authen-tications However we find that it is non-trivial to provide ageneral solution to patch the security problems for all usagecases while preserving usability We discuss the major chal-lenges in different scenarios and propose countermeasures

Intended for communication with backend For theopen port mobile app to verify that the incoming connection

11

is from the authentic server we suggest using secure tokensto perform authentication Although tokens are already usedin some open port apps implementation flaws are commonlyseen For example a third-party push notification servicethat distributes token to app developers for them to embedin the app is vulnerable because the token can be extractedfrom the released app binary by attacker to exploit the vul-nerable app installed on other victim devices We suggest theapp and server negotiate a shared token using mechanismssuch as Diffie-Hellman [7] at app launching time And openport app uses the token to authenticate further incomingconnections

Intended for use by app users Compared to theprevious usage scenario open port apps in this case do notknow in advance the legitimate remote hosts that shouldconnect to them Depending on the usage of the app userthe trusted remote hosts can be userrsquos desktop or even hisfriendrsquos laptop A general solution is to use password or pincode to authenticate incoming connections however somesecurity issues are raised in practice As an example allthe apps we examined that use password provide hard-codedefault password that does not require users to change beforeusing the app leading to the potential use of the defaultpassword and degrading app security Randomly generatedpin codes in the open port apps we examined are usuallyno longer than 4 characters which is trivial to enumerateExperiment in our local WiFi network indicates that it takesless than 5 minutes to send probing requests that enumerateall the 4-character strings

Another authentication solution adopted by the toptrending apps for this usage scenario is the incoming con-nection notification which pops up a window when a newhost connects to the open port and displays the IP addressof the host And the request is not served until user explic-itly accepts the client by clicking the ldquoallowrdquo button Forordinary users the timing of the pop-up window is also animportant indicator for them to make the decision of whetherto allow or deny the request However on-device malwarecan infer the timing when there is an incoming connection tothe port by monitoring procnet[tcp][tcp6] andsend request immediately to trick user into also allowing itsconnection by overlaying the pop-up window We furtherfind that even the most popular apps in this category hasimplementation flaws that can be practically exploited byattackers in our threat model

AirDroid1 is a top-ranked app on the market that allowsusers to access and manage their Android device wirelesslyfrom desktop by opening a server on the phone It providesa rich set of functionality to users such as access cameraand install apps remotely and uses the incoming connectionnotification schema to authenticate client However if thetiming of user initiated connection is inferred by the attackerwith the help of an on-device malware and attacker sendsrequest to the open port before the user accepts the previousconnection the app wonrsquot pop up another window Insteadthe attacker connection silently replaces the previous legit-

1 AirDroid httpswwwairdroidcom

ServerSocket

SecureServerSocket Remote client

Requestfrom IP0

Return IP0

as QR code

Scan

Trust IP0

Requestfrom IP0

Return

Socket Socket

Display

Check IP0

Figure 8 SecureServerSocket design

imate connection in the waiting queue without changingthe IP address displayed on the pop-up window And whena user clicks the button to allow the legitimate connectionthe attacker client is allowed instead and numerous sensitivecapabilities of AirDroid are granted to the attacker

Usage in this category is usually for the cable-less com-munication with nearby hosts of the user We confirmed that24 out of the 26 vulnerable apps in this category are intendedfor the use in physical proximity We demonstrate a transpar-ent socket-level solution that addresses the security and us-ability challenges in this usage scenario Shown in Figure 8we provide SecureServerSocket which encapsulatesthe Android ServerSocket API to accept incoming sock-ets When a remote client the userrsquos desktop for exampletries to connect to the port the SecureServerSocket

first puts the connection on hold and then encodes the IPaddress of the client into a QR code and returns to theremote client The remote client is required to display theQR code and let the user scan it using the mobile device inorder to get access

Once the QR code is scanned the decoded IP addressis returned to the SecureServerSocket and the con-nection from this IP is allowed It then returns the incom-ing socket to the upper application layer to be handledThis approach authenticates clients on the IP layer andensures that the open port only serves clients in physicalproximity of the device user and it achieves both securityand usability We provide SecureServerSocket as alibrary that app developers can simply use as a replacementof ServerSocket No changes on the client side arerequired if the client is a web browser which is the commoncase in our app dataset For other client types that cannotdisplay QR code we suggest using one-time pin code to dothe authentication instead Demo of the SecureServerSocketimplementation can also be found on our website [11] Andfor future work we plan to conduct a user study to evaluatethe effectiveness of this approach

Intended for local communication For the local usageof on-device proxy the best practice is to bind the proxy tothe loopback address of the device which makes the serviceunreachable from the network For another local usage

12

v0 = accept( sockampaddrampaddr_len)

accept a remote incoming socket

if (v0 == ldquoactionrdquo)

system(ldquoam broadcast comexampleactionrdquo)

broadcast an intent in Java layer

else

system(ldquoam startservice comexampleUploadServicerdquo)

start an application service in Java layer

ltreceiver androidname=ldquocomexampleActionReceiverrdquogt

ltintent-filtergt

ltaction androidname=ldquocomexampleactionrdquo gt

specify that action will be handled by receiver

ltintent-filtergt

ltreceivergt

ltservice androidname=ldquocomexampleUploadServicerdquo

androidprocess=ldquouploadServicerdquo gt

an upload service that runs in separate process

1

2

3

4

5

6

7

8

9

10

Figure 3 Snippet from real app showing control-flow jump from the native code layer (Left) to the application layer (Right)

in Figure 3 are not directly tainted by the source butare control-dependent on the tainted conditional statementas an example of implicit taint The taint analysis handlesinter-procedure calls as well as asynchronous IO Tohandle many clients simultaneously in native code appcan perform non-blocking IO using Linuxrsquos epoll fa-cility [8] which provides readiness notification to simulateIO multiplexing To serve multiple requests the threaduses epoll_wait to get tasks from event queue andepoll_ctl to add new connections waiting to be handledinto the event queue The taint analysis propagates taintvalues accurately through such asynchronous function callsby keeping track of each event queue We show how thenative code analyzer improves the effectiveness of our toolin sect45

The native code analyzer is implemented as a plug-infor IDAPro written in Python It uses IDAPro [10] asthe front-end and performs the inter-procedural data-flowanalysis on the CFG of the assembly code The time it takesfor analyzing an app depends on the number of shared objectfiles contained in the app The mean analyzing time is 800seconds with the interquartile range of 749 seconds

43 Sensitive API Selection

OPAnalyzer aims at characterizing all the sensitive func-tionality triggered by remote input To define the sensitiveAPI set and categorize their functionality we need an ac-curate mapping from Android APIs to the permissions theyrequire However constructing such mapping for our usecase is non-trivial because our analysis is performed on thecomponent level We detail the challenges and our solutionsbelow

PScout [21] provides a static analysis approach to findthe mappings between API calls and permissions Howeverwe find that it suffers from some completeness problemsTaking the ServerSocket as an example which re-quires Android Internet permission In the mappingsgenerated by PScout we only find the constructor ofthe ServerSocket mapped to the Internet permis-sion while other sensitive APIs such as accept() andgetOutputStream() are missing We suspect that itis because Android enforces some permission checks atthe class level instead of API level Although enforcing

the permission check at the constructor implies that allthe member functions of this class are also protected theincompleteness of the lt API permission gt mappingsrestricts its usability for program analysis especially whenthe analysis is performed on the component level To addressthis problem we design a static analysis tool to automati-cally add such missing APIs to the mappings For every classconstructor presented in the original PScout output the tooltakes the AOSP source code as input and extracts all themember functions of the class to complete the mappings

In addition we find that some APIs are not protectedby Android permissions however when used together arealso considered sensitive in the mobile service context Forexample an app retrieves the device location and stores it inthe application data cache Once a remote connection comesin it reads the location data from the cache and sends it tothe remote attacker In this scenario the incoming socketdoes not trigger any permission check except INTERNETwhich we think is granted by default but the sensitivelocation data is stolen and leaked asynchronously To capturesuch sensitive functionality in the mobile service context wemanually collect all the sources that an app can retrieve dataasynchronously that do not require permission includingapp cache database shared preference etc We define apseudo permission called DATA_LEAK If the data writtento the incoming socket is dependent on the data retrievedfrom these asynchronous sources we consider it as invokingthe DATA_LEAK permission check The pseudo permissiontogether with the associated API pairs are added to thesensitive API set

44 Usage Path Analysis

To identify program dependency OPAnalyzer performstaint analysis on the DDG rooted from remote entry pointstaking the remote input as source and sensitive API setas sink It outputs all the usage paths that the remote inputcan trigger together with all the constraints that guard thesinks which are useful for open port usage categorizationand vulnerability discovery

IDFG and DDG are built for each remote entrypoint using Amandroid which include all those Inter-Component Communication (ICC) edges and are both flow-and context-sensitive However the control-flow jumps in-

5

socket = ServerSocketaccept()

socket = Source1()

remote_input = socketgetInputStream()

flag = remote_input[0]

if (flag == ldquoTruerdquo)

password = getSharedPreferences(ldquopasswordrdquo0)

password = Source2()

outStream = socketgetOutputStream()

outStreamwrite(password)

Sink()

1

2

3

4

5

6

7

8

9

10

11

Figure 4 An example for implicit and explicit taint logic

Socket socket = ServerSocketaccept()

InputStream in = socketgetInputStream()

String input = inreadLine()

String command = inputsplit(ldquo=ldquo)[0]

String value = inputsplit(ldquo=ldquo)[1]

Map map = new HashMapltStringStringgt()

mapput (commandvalue)

if (mapsize() gt 0) C1

if (command == ldquoSEND_SMSrdquo) C2

SendSMS(value) Sink()

1

2

3

4

5

6

7

8

9

10

11

12

Figure 5 Sample app code showing that sensitive API isprotected by constraints

troduced by Java reflection cannot be captured by this ap-proach Since we find that reflections are heavily used in ourdataset and also are found in those well-known Wormhole

apps we add reflection support to the taint analysis engine

Java reflection is used by programs to examine ormodify the runtime behavior of apps running in Java virtualmachine We have seen reflections used in apps for bothlegitimate purpose (eg bypass some API-level restrictions)and malicious purpose (eg disguise the entry to maliciouscode) Handling reflection accurately is impossible for staticanalysis and remains challenging even combining runtimeanalysis [43] To capture the control-flow jumps of reflectionto our best effort we implement a handler in the IDFGbuilder similar to the one used in FlowDroid [20] whichcan link the target class or method invoked by reflectionto the calling function and add the missing edges to theIDFG Currently it only handles reflection calls with targetsexplicitly provided in the same procedure and will missthose whose targets are not deterministic statically Howeverwe find that over 86 of reflections in our dataset can behandled by applying this heuristic and it also helps identifysignificantly more vulnerable paths as shown in sect45

Java layer taint analysis is used to examine the depen-dency among remote input and sensitive APIs We definea notion to describe the explicit and implicit dependencyrelationships among statements The notion is further usedto categorize usage

Notion 1 The dependency relationship between two state-

ments along the same usage path is either implicit orexplicit and transitivity applies

stmt1Eminusrarr stmt2 if stmt2 is explicitly tainted by

the return value of stmt1

stmt1Iminusrarr stmt2 if stmt2 is implicitly tainted by

the return value of stmt1

stmt1Iminusrarr stmt2

Eminusrarr stmt3 if stmt3 is explic-

itly tainted by the return value of stmt2 and bothstmt2 and stmt3 are implicitly tainted by the returnvalue of stmt1

Explicit taint describes the data dependency relationshippropagated by assignment expressions while implicit taintreflects the ldquotriggeringrdquo relationship in which the source ispresented in the conditional statements Shown in Figure 4the first taint source comes from the remote input and flagis explicitly tainted by the remote_input since it is de-rived from it All the statements in the if block are implic-itly tainted by the flag since they are control-dependenton the if statement Specifically another taint source isidentified as the getSharedPreferences which readsdata from an asynchronous source The password readfrom the shared preferences is written to the socket identi-fied as an explicit taint relationship between statements inline 5 and line 6 Thus the dependency relationship alongthis usage path is expressed as

accept()Iminusrarr getSharedPreferences()

Eminusrarr write()

To further narrow down the potential vulnerable path listand provide insights to identify the vulnerability OPAna-lyzer integrates both constraints analysis and reachabilityanalysis to help analyst prioritize paths output by OPAna-lyzer to reduce human efforts

Constraints analyzer examines all the conditional state-ments along the usage path to which the sensitive APIis control dependent on Shown in Figure 5 the remoteinput is separated into two substrings and put into a MapThe sensitive API SendSMS is control dependent on twoconstraints Constraint C1 defined in line 8 checks whetherthe Map is empty while the constraint C2 in line 9 checkswhether the command passed in from remote input isldquoSEND SMSrdquo Both checks are easy to bypass an arbitraryremote attacker can construct the input string to bypassthe checks and trigger the malicious payload to be sentvia SMS which results in a remote privilege redelegationattack [30] OPAnalyzer annotates a constraint as weak if itis either (1) comparison with constants or (2) comparisonwith a predefined set of trivial API (eg Mapsize()SetisEmpty()) The heuristic reduces human effortsby prioritizing usage paths that are obviously easy to becontrolled but could introduce false negatives(sect 45)

Reachability analyzer characterizes the reachability ofa path using both static and dynamic approaches First thestatic analysis models the app Activity lifecycle andfilters those usage paths unreachable from the program entryset The dynamic approach identifies those usage paths thatstart with a port that is open by default at app launching

6

OPAnalyzer

Categorization

apk

usage path

No

Usage families

Pattern matches

Yes

open port usage family

Convert to

Notation 1

Generalize

usage pattern

Figure 6 Usage categorization methodology

time These paths are annotated as highly insecure sinceremote attacker has a large timing window to exploit themNote that ports that are not open by default are still vulner-able to the on-device malware in our threat model sincethe malware can monitor the proc file and exploit thevulnerable paths as long as it detects the port is open Thedynamic analysis is implemented using function hookingbased on Xposed framework [17] and combined with deviceautomation the analyzer automatically annotates reachabil-ity results on the usage paths

Usage categorization methodology Shown in Figure 6OPAnalyzer aggregates usage paths with similar open portusage into one family based on the sensitive APIs theycontain and the notion It extracts usage paths and convertsthem to Notion 1 The categorization approach matches thenotion of new paths with those already identified patternsIf an incoming path cannot be categorized into any of theexisting families we manually generalize its usage to apattern and add a new family to the existing usage familyset Following this approach OPAnalyzer categorizes mostof the usage paths except a few that cannot be converted toNotion 1(sect52)

Vulnerability discovery methodology Considering anattacker in our threat model to exploit a usage path andtrigger the sensitive functionality he needs to (1) find theright timing when the port is open (2) bypass all the checksalong the path to execute the sensitive API The usagepaths output from OPAnalyzer come with the reachabilityinformation sensitive functionality and strengths of predi-cates all annotated help human analyst efficiently examinethese two prerequisites for an attack and identify vulnera-bility Specifically OPAnalyzer prioritize ldquoweak pathsrdquo andldquohighly insecurerdquo paths for manual inspection And notethat we also selectively examined the other usages paths inthe OPAnalyzer output since they may also be vulnerableto remote exploits Some of the interesting vulnerabilities(eg AirDroid exploit) in our case study(sect6) are actuallyidentified in those non-weak usage paths

45 Evaluation

We obtain 24000 apps from the PlayDrone dataset [45]to evaluate our tool which contains top 1000 popular apps

from each of the 24 categories in the Google Play includingentertainment tools etc Our evaluation focuses on thevulnerability discovery of OPAnalyzer which is the mostsecurity critical functionality

Discovery accuracy To evaluate the false positives(FPs) of the weak path detection we first define the FPsas ldquoweakrdquo paths that are verified to be not exploitablethrough manual inspection We examined the weak usagepaths output by OPAnalyzer and constructed remote inputto see if the sensitive functionality could be triggered Wecall these weak paths that are verified to be exploitablevulnerable paths and the rest of them are considered asFPs Among the 24000 apps 68 of them (1632) haveopen-port functionality and 133 weak paths are identifiedto be reachable at app launching time by OPAnalyzer Wemanually identified 113 vulnerable paths that can be easilyexploited by constructing remote input (FP rate 151)The FPs mainly come from paths that contain checks on theruntime property of the app As an example a usage path isguarded by the constraint if (debugMode == True)

will not be triggered when the app is in release mode butwill be output falsely as weak path

Due to the lack of any publicly accessible study of openport vulnerabilities on mobile platform we run OPAnalyzeron the recently-reported Wormhole apps from the Chineseapp market to evaluate the false negatives (FNs) of OP-Analyzer To the best of our knowledge they are the onlyreported instances that contain confirmed open port exploitswhich are usable as ground truth in the FN evaluation TheFNs of the weak path detection are those paths that are notannotated as ldquoweakrdquo but are verified to be exploitable withour manual inspection Wormhole apps are vulnerable dueto their integrations of vulnerable SDKs including BaiduQihoo360 AMap and Tencent [12] and thus we choosethe most popular apps in each SDK category We do nottest on Qihoo360 library since the problem only affects anold beta version which can no longer be found in apps onmajor app markets

As shown in Table 1 OPAnalyzer discovers usage pathsthat contain sensitive functionality in all of the three appswith some of them reported as weak paths Unfortunatelythe report has no detailed path information that can be usedas ground truth for evaluation we do our best to manuallyanalyze the decompiled app to find exploitable paths ForBaidu SDK OPAnalyzer detects all the exploitable pathsthat we manually discovered and even discovers new ex-ploits that have not been reported in the report such asstealing the WiFi BSSID For AMap OPAnalyzer reportsfour usage paths while none of them are recognized as weakpaths However three exploits (FNs) from those non-weakpaths are identified We find that one of the conditionalstatement shared by all 4 usage paths depends on valuethat is defined beyond the IDFG of the remote entry pointOPAnalyzer thus does not consider the check as ldquoweakrdquosince its value cannot be determined while it turns out to beconstant in the run time It is due to the limitation of lackingof backward analysis support so that OPAnalyzer doesnrsquothave enough visibility into how a variable encountered on

7

Wormhole family Sample app Version Entry points Usage path Weak path Not weak path

total exploitable total exploitable

Baidu combaiduBaiduMap 850 1 15 8 8 7 0

Tencent comtencentandroidqqdownloader 570 4 16 1 1 15 1

AMap comautonaviminimap 734 1 4 0 0 4 3

TABLE 1 OPAnalyzer output for three popular ldquoWormholerdquo apps that are reported vulnerable

Feature of usage

Improv Featured applibpaths captured

none 636 NA WiFi file transfer

+ reflection 804 +26 OpenVPN

+ API 1472 +131 AMap

+ native 845 +33 Tencent XG

+ all 1934 +204 Baidu wormhole

TABLE 2 Evaluation of accumulative improvement broughtby (1) handling explicit Java reflection and (2) adding open-port specific sensitive API (3) capturing native code jump

the usage path is propagated to this procedure if it isdefined beyond the IDFG of the entry point This affects theaccuracy of the information leakage tracking and constraintsanalysis and can be solved by integrating backward slicingtechnique [20] [48] We plan to add that to the OPAnalyzerin the future

False negatives may also be introduced by the na-tive code analyzer due to a limitation inherited from theIDA-PRO front end ARM processor supports multiple in-teraction sets mixed in one segment in the runtime whilethe disassembler can interpret one type at the same time inthe static analysis [3] And when the 16-bit ldquoThumbrdquo and32-bit ldquoARMrdquo instructions coexist within one segment dueto optimization the disassembling result may be incorrectAdditionally the native code analysis of OPAnalyzer doesnot cover all possible types of interactions between nativecode and Java code Combining native code and Java codeanalysis is a fundamental challenge of Android app analy-sis [38] and we leave it as future work to accurately modelall the control- and data-flow transitions between native andJava layers

We also evaluate the improvement on the effectiveness ofOPAnalyzerrsquos path discovery brought by three of our engi-neering efforts namely (1) adding open-port specific APIs tothe sensitive API set (2) handling explicit Java reflectionsand (3) capturing native code jump Shown in Table 2integrating these features greatly improves the coverage ofOPAnalyzer by 204 while completing the sensitive APIset turns out to be the most effective engineering effort wespent These improvements reduce false negatives which iscrucial to our system

Performance The most compute-intensive step in OP-Analyzer is the taint analysis which includes building theIDFG and DDG and running the Dijkstrarsquos algorithm on theDDG to find all the usage paths We measure the time toperform the taint analysis for the top 1000 popular apps fromour dataset The experiment runs on a machine with IntelCore i5-3470 CPU and 8GB of RAM For apps with at least

one entry point the median processing time for OPAnalyzerto finish the taint analysis is 615 seconds with standarddeviation of 1272

5 Usage and Vulnerability

With the usage paths output from OPAnalyzer we sys-tematically study open port usage and their security impli-cations in the top 1000 popular apps from each of the 24different categories on Google play

51 Popularity and Permission Usage

Among the 24000 apps we identified open port func-tionality in 68 (1632) while 50 of these open port appshave more than 500K downloads

Sensitive permission usage To understand the mostcommon functionality triggered by remote input we usethe API to permission mappings constructed in sect43 to getthe set of sensitive permissions Figure 7 shows the topsecurity-sensitive permissions involved in open port usageSurprisingly we find that in open port apps a rich set ofhighly-sensitive OS-level functions in Android can be in-voked remotely ranging from accessing private data such ascontacts and location to performing sensitive actions such asusing camera and sending SMS If not protected sufficientlythis usage can be remotely exploited to cause severe dam-ages such as privacy leakage and privileged code executionsjust like the recently reported Wormhole exploits [12] Inaddition we find that the pseudo permission DATA_LEAK

(defined in sect43) which indicates that data is read fromasynchronous sources such as internal storage or contentproviders and sent to the remote end has top popularity inopen-port apps This shows that open port usage commonlyhas potential risk of exposing internal application data to theremote attacker which typically involves plenty of sensitivedata such as credentials and conversation history [51]

52 Usage Family Categorization

Using OPAnalyzer we categorize usage paths into differ-ent usage families defined by code patterns Table 3 showsthe 5 major usage families we identified in our datasettogether with the path categorization results and the typesof potentially-exposed vulnerabilities As shown 99 ofreachable usage paths of open port apps are categorized intoone of the five families which are described in detail asfollows

Data sharing path a usage path through which data readfrom the device is sent to the remote host In this category

8

0

5

10

15

20

25

WRITE_EXTERNAL_STORAGE

C2DM_RECEIVE

DATA_LEAK

ACCESS_COARSE_LOCATION

ACCESS_FINE_LOCATION

GET_TASK

CAMERA

READ_CONTACTS

DISABLE_KEY_GUARD

WRITE_SETTING

RECORD_AUDIO

CALL_PHONE

SEND_SMS

o

f o

pe

n p

ort

ap

ps

Sensitive permissions

Figure 7 Permission protected APIs triggered by remote input

Usage category Pattern Usage path Perc App Weak path Vulnerability

Data sharing accept()Iminusrarr APIdata read

Eminusrarr write() 1340 693 425 775 V1

Proxy accept()Eminusrarr APIout connection 122 63 59 101 V1V3

Remote execution accept()I or Eminusminusminusminusrarr APIexecution 127 65 41 69 V2V3

VoIP call accept()Iminusrarr APIaudio setting 45 23 27 11 V3

PhoneGap Categorized using code signature 282 146 141 0 NA

Uncategorized NA 18 09 10 0 NA

TABLE 3 Open port usage and potential vulnerability V1sensitive data leakage V2 privileged remote execution V3 DoS

the most commonly used protocol for data sharing is HTTPwhile HTTPS FTP UPnP [15] and some customized proto-cols are also observed As shown nearly 60 of the pathsin this category are found to be weakly protected withoutany client authentication leaving them easily exploitable(examples in sect6) By examining the apps in this category wealso identified a mobile-specific open port usage scenariodata sharing in physical proximity eg allowing a userto transfer photo to her PC nearby This usage turns tobring most exploits in this family as shown later in sect624 out of 26 exploits in data sharing are associated withthis particular usage Also worth noting is that in this usagefamily sensitive data can be leaked without invoking anypermission-protected APIs along the tainted path Due toour improvement in sensitive API selection (sect43) our toolcan successfully capture these cases

Proxy path is defined as forwarding requests in remoteinput to other destinations We find that all the paths in theseapps are used as local proxy eg for advertising and contentfiltering For example to overcome the content modificationrestrictions in Android WebView a web browsing app startsas background service a local web proxy so that it can insertits own ads into the fetched web pages If exposed to remoteattackers such local proxy can be used as a reflector intargeted DDoS attacks Also if it is configured to cachepages or store cookies attackers can access personalizedpages to harvest user privacy or even hijack victimrsquos emailor social network accounts for spear phishing attacks

Remote execution path refers to usage paths that cantrigger certain actions on the device such as sending SMS

and writing to storage Besides common use cases suchas push notification we also observe interesting usage inphysical proximity which allows the same user to use mo-bile device functionality through PC interface eg textingSMS using keyboard However there are also sensitive func-tionality that can be executed remotely and are beyond thedeclared functionality of the app which we suspect to beldquobackdoorsrdquo left by app developers

VoIP call paths are used in apps to listen on incomingcall requests based on the Session Initiation Protocol (SIP)After accepting a SIP invite message from the port theapp extracts information such as caller ID and starts thering tone to notify the user Remote attackers in theory cansend spoofed packet to ring the phone and spoof the callerID However due to the IPSec support in SIP such off-pathattack is unlikely to be practical

PhoneGap paths belong to apps developed by Phone-GapCordova a hybrid app development framework al-lowing developers to quickly build apps using JavaScriptand HTML5 It uses open ports to serve requests fromthe JavaScript client and handle the API calls The resultwritten to the incoming socket is not defined in the IDFGof the remote entry point making it difficult for OPAna-lyzer to capture sensitive APIs To address this we usethe presence of several PhoneGap-specific classes such asCallbackServer as the code signatures to identify theseusage paths The port intended for IPC is falsely openedto the Internet However we find that the usage paths ofPhoneGap are protected by strong security checks whichverifies whether the request contains a 128-bit token derived

9

Open port intention Vulnerability description Featured attacks Vulnerable app example App 1

Usage of the app userLack of authentication to verify that Data theft WiFi file transfer 24connections come from the app user Privilege escalation AirDroid PhonePal 10

Communication with Lack of authentication to verify the requests Data theft Lenjoy 15backend are from authentic app backend server Privileged escalation KindeeExpress 5

Local communicationPort used for on-device communication DoS VGet Fast secure VPN 12falsely opened to the network Data theft CachedProxy 1

1 Number of vulnerable apps in the same category An app may be vulnerable to both attacks in each category

TABLE 4 Case study of verified exploitable app categorized by the intended usage of open port

from the devicersquos Universally Unique Identifier (UUID) [1]Thus we consider the open service of PhoneGap as well-protected

53 Security Implications

Usage paths in different families if not well protectedcan lead to different security breaches As shown in table3 OPAnalyzer outputs 956 weak paths We find that nearlyhalf of the total usage paths are considered ldquoweakrdquo In theproxy category over 80 of the paths are not protectedFrom these weak paths we identify three vulnerabilitycategories sensitive data leakage (V1) privileged remoteexecution (V2) and DoS (V3) Besides we also discovera new problem that any open port on smartphones can beexploited to harvest cellular IPv6 addresses which allowsattacker to collect victim IPs without scanning the huge IPv6address space and further launch attack to exploit vulnerableports The vulnerability is detailed in the Appendix A

V1 Sensitive data leakage Sensitive data of a mobiledevice can be retrieved from many sources such as SD Cardsensor etc If these paths are not well protected remoteattacker can exploit them to steal sensitive data that areeven protected by Android permission or UNIX uidgid

check More importantly if the victim IP is public suchvulnerabilities can be easily revealed using fast Internet-wide scanning tools such as ZMap [26] causing large scaledata theft

V2 Privileged remote execution Vulnerable paths thattrigger native actions can be leveraged by remote attackersto execute privileged functionality such as sending SMS andmodifying contacts Moreover by exploiting the broadcast-ing Intent mechanism provided by Android attackers caneven execute functionality beyond the vulnerable app Forexample an unprotected usage path that sends Intent

based on remote input can be leveraged to launch YouTubeapp to play the video from the URL passed by the remoteattacker By uploading a maliciously crafted MP4 file to theURL attacker can gain full control of the device exploitingthe Stagefright vulnerability [6]

V3 Denial of service Most remote execution paths arevulnerable to DoS attack against the device user For thelocal proxy usage paths they can also be used by attackersas reflectors in targeted DDoS attack against victims inthe Internet to hidden their IP addresses Other securityproblems of open proxies such as leaking internal networkdata and IP spoofing based attack also apply

6 Exploits Case Studies

To broaden the scope of our vulnerable study and dis-cover more exploitable open port usage we extended ourdata set to include all the 78K apps from the Tools cate-gory of the PlayDrone dataset to our vulnerability analysisbased on the observation that the percentage of open-portapps in the Tools(109) is significantly higher than theaverage (68) Furthermore we also crawled the top 3000most popular apps from a Chinese app market [2] wherethe Wormhole problem was reported from

By analyzing the annotated usage paths from the OPAna-lyzer output we successfully discover several new exploitsof sensitive data leakage and privileged remote execution inboth apps and third-party libraries including some high-profile ones with millions of downloads and even pre-installed apps Moreover we classify these vulnerable appsinto 3 categories based on the intended usage scenario of theopen port inferred from the manual analysis (1) intendedfor use by app users (2) intended for communication withthe backend and (3) intended for local communicationSuch categorization helps better understand the challengesin securing the port opened for different purposes Table 4shows an overview of the 57 exploitable apps that are man-ually verified from the OPAnalyzer output A case study ofinteresting vulnerability in each category is presented belowThe video demos for some of the implemented attacks areshown on our website [11]

61 Intended for Use by App Users

Such apps open ports for different purposes intendedfor the app users such as transferring file from the phoneto another device of the same user However essentialchecks are found missing in many apps in this category thusexposing the sensitive data and also privileged functionalityof the device to attackers

Virtual data cable is a popular app on China marketthat helps user transfer their photos to PC by opening a webserver on the phone The server port opens by default at applaunch time and silently runs in the background It does notauthenticate clients nor notify incoming connections thuscan be easily scanned and exploited by remote attackersMoreover it does not check the requested file path so thatattacker can access files beyond the photo folder on SD cardby adding ldquordquo to the path and steal sensitive data fromapp cache and system directory Similarly a popular file

10

sharing app WiFi file transfer with 10 million installs doesnot authenticate clients while it opens the server port onlywhen user presses a toggle button However an on-devicemalware that only has Internet permission in our threatmodel can listen on the status of the port by monitoring theproc file system and steal data from the port as long asit is open

PhonePal allows a user to remotely control hisherdevice with a web-browser which contains highly sensitiveusage paths such as open URLs in the Android browserand open videos in the YouTube app All these usage pathsare found unprotected which puts the device at the riskof phishing attack and even compromise [6] Moreovervulnerabilities such as allowing attacker to remotely installapps on the victim device are identified in the high-profileapp AirDroid pre-installed on Samsung Chromebook andSmartisan phone [13] We present a case study of this appin the mitigation strategy section (sect7)

62 Intended for Communication with Backend

Open ports in these apps are intended to communicatewith the app developerrsquos backend server for various pur-poses If the open port service does not authenticate theidentity of the remote server attackers can spoof the appserver Interestingly by manually examining the apps wefind that open port usage of some apps are beyond the appsrsquodeclared functionality implying potentially covert maliciousbehavior

KindeExpress is the most popular mailpackage trackingapp on a China market with 1 million downloads whosefunctionality is to provide tracking information from manydelivery service providers One of its usage path is able tostart an Activity of the app and display the data fromremote input on the apprsquos UI which also brings the app tothe front even when it is running in the background Weverified that none of the declared functionality of the appdepends on this usage path and we suspect it to be usedfor advertising Unfortunately this path is not protected byany authentication mechanism and remote attacker can sendcommand to the app pretending as it comes from the appserver to display deceptive content on the app UI

Huang CheatMaker is a game modifier app that helpsusers cheat when playing mobile games We identified ausage path that accepts data pushed from the app serverstores the data as a shared object (so) file and loadsit at run-time The authentication along the path is weakand the app dynamically loads the code without verifyingwhere it comes from nor its integrity which enables remoteattackers to inject malicious payload to the app to that willbe executed thus compromising the device

63 Intended for Local Communication

Usage paths in Proxy and PhoneGap families are in-tended for on-device communication which can be eitherIPC among different components of an app or proxy fordifferent apps on the device to use However open ports

in some apps that are intended for local usage are falselyexposed to the network and thus lead to security breaches

OpenVPN is an open-source VPN implementation thatis integrated by several popular VPN apps on Google PlayMultiple interfaces are provided by OpenVPN for the appto configure the local VPN settings while the open TCPport interface is identified to be the least secure one Aremote attacker can DoS the victim user by changing proxysettings such as port number on the device Fortunatelysome app developers paid extra attention when integratingOpenVPN and closed the insecure configuration interfacefrom the open TCP port but VPN apps vulnerable to thisproblem still remain (eg Fast secure VPN)

CacheProxy is an app that opens local proxy with thecapability of caching the web page content Upon receivinga request the proxy first checks whether the request can beserved using cached content before fetching the page withno authentication performed on the source of the incomingrequest Remote attackers can thus easily access sensitiveinformation of the victim such as e-mails by requesting thee-mail page since the page is retrieved from the cache forthe attacker

To get an initial estimate on the severity of open portvulnerabilities in the wild we performed a small scale portscan in a subnet of a campus network The ports scannedare those opened by the most popular vulnerable apps inour dataset whose port number needs to be static andunique Note that we only scanned for the existence ofthe open ports but did not send any data to the ports toverify the vulnerability for ethical concerns We performedonly one scan using a scanning tool [26] which finished intwo minutes Surprisingly 40 hosts identified to be mobiledevices open such ports Although different apps that usethe same port number may introduce false positives thescanning result indicates that immediately exploitable openports exist in the wild

7 Mitigation Strategy

Traditional solutions to protect an open port fromInternet attackers are through firewall which monitors andcontrols incoming and outgoing traffic based on prede-termined security policies However the firewall solutionsuffers from usability in the mobile context since it ishard for individual users to configure suitable firewall rulesfor each app installed on the device and coordinate bothapp functionality and security assurance Moreover in thephysical proximity use scenario since users can initiateconnections from arbitrary hosts it is hard to configure rulesin advance

Despite a variety of open port usage described thefundamental problem is the lack of proper client authen-tications However we find that it is non-trivial to provide ageneral solution to patch the security problems for all usagecases while preserving usability We discuss the major chal-lenges in different scenarios and propose countermeasures

Intended for communication with backend For theopen port mobile app to verify that the incoming connection

11

is from the authentic server we suggest using secure tokensto perform authentication Although tokens are already usedin some open port apps implementation flaws are commonlyseen For example a third-party push notification servicethat distributes token to app developers for them to embedin the app is vulnerable because the token can be extractedfrom the released app binary by attacker to exploit the vul-nerable app installed on other victim devices We suggest theapp and server negotiate a shared token using mechanismssuch as Diffie-Hellman [7] at app launching time And openport app uses the token to authenticate further incomingconnections

Intended for use by app users Compared to theprevious usage scenario open port apps in this case do notknow in advance the legitimate remote hosts that shouldconnect to them Depending on the usage of the app userthe trusted remote hosts can be userrsquos desktop or even hisfriendrsquos laptop A general solution is to use password or pincode to authenticate incoming connections however somesecurity issues are raised in practice As an example allthe apps we examined that use password provide hard-codedefault password that does not require users to change beforeusing the app leading to the potential use of the defaultpassword and degrading app security Randomly generatedpin codes in the open port apps we examined are usuallyno longer than 4 characters which is trivial to enumerateExperiment in our local WiFi network indicates that it takesless than 5 minutes to send probing requests that enumerateall the 4-character strings

Another authentication solution adopted by the toptrending apps for this usage scenario is the incoming con-nection notification which pops up a window when a newhost connects to the open port and displays the IP addressof the host And the request is not served until user explic-itly accepts the client by clicking the ldquoallowrdquo button Forordinary users the timing of the pop-up window is also animportant indicator for them to make the decision of whetherto allow or deny the request However on-device malwarecan infer the timing when there is an incoming connection tothe port by monitoring procnet[tcp][tcp6] andsend request immediately to trick user into also allowing itsconnection by overlaying the pop-up window We furtherfind that even the most popular apps in this category hasimplementation flaws that can be practically exploited byattackers in our threat model

AirDroid1 is a top-ranked app on the market that allowsusers to access and manage their Android device wirelesslyfrom desktop by opening a server on the phone It providesa rich set of functionality to users such as access cameraand install apps remotely and uses the incoming connectionnotification schema to authenticate client However if thetiming of user initiated connection is inferred by the attackerwith the help of an on-device malware and attacker sendsrequest to the open port before the user accepts the previousconnection the app wonrsquot pop up another window Insteadthe attacker connection silently replaces the previous legit-

1 AirDroid httpswwwairdroidcom

ServerSocket

SecureServerSocket Remote client

Requestfrom IP0

Return IP0

as QR code

Scan

Trust IP0

Requestfrom IP0

Return

Socket Socket

Display

Check IP0

Figure 8 SecureServerSocket design

imate connection in the waiting queue without changingthe IP address displayed on the pop-up window And whena user clicks the button to allow the legitimate connectionthe attacker client is allowed instead and numerous sensitivecapabilities of AirDroid are granted to the attacker

Usage in this category is usually for the cable-less com-munication with nearby hosts of the user We confirmed that24 out of the 26 vulnerable apps in this category are intendedfor the use in physical proximity We demonstrate a transpar-ent socket-level solution that addresses the security and us-ability challenges in this usage scenario Shown in Figure 8we provide SecureServerSocket which encapsulatesthe Android ServerSocket API to accept incoming sock-ets When a remote client the userrsquos desktop for exampletries to connect to the port the SecureServerSocket

first puts the connection on hold and then encodes the IPaddress of the client into a QR code and returns to theremote client The remote client is required to display theQR code and let the user scan it using the mobile device inorder to get access

Once the QR code is scanned the decoded IP addressis returned to the SecureServerSocket and the con-nection from this IP is allowed It then returns the incom-ing socket to the upper application layer to be handledThis approach authenticates clients on the IP layer andensures that the open port only serves clients in physicalproximity of the device user and it achieves both securityand usability We provide SecureServerSocket as alibrary that app developers can simply use as a replacementof ServerSocket No changes on the client side arerequired if the client is a web browser which is the commoncase in our app dataset For other client types that cannotdisplay QR code we suggest using one-time pin code to dothe authentication instead Demo of the SecureServerSocketimplementation can also be found on our website [11] Andfor future work we plan to conduct a user study to evaluatethe effectiveness of this approach

Intended for local communication For the local usageof on-device proxy the best practice is to bind the proxy tothe loopback address of the device which makes the serviceunreachable from the network For another local usage

12

socket = ServerSocketaccept()

socket = Source1()

remote_input = socketgetInputStream()

flag = remote_input[0]

if (flag == ldquoTruerdquo)

password = getSharedPreferences(ldquopasswordrdquo0)

password = Source2()

outStream = socketgetOutputStream()

outStreamwrite(password)

Sink()

1

2

3

4

5

6

7

8

9

10

11

Figure 4 An example for implicit and explicit taint logic

Socket socket = ServerSocketaccept()

InputStream in = socketgetInputStream()

String input = inreadLine()

String command = inputsplit(ldquo=ldquo)[0]

String value = inputsplit(ldquo=ldquo)[1]

Map map = new HashMapltStringStringgt()

mapput (commandvalue)

if (mapsize() gt 0) C1

if (command == ldquoSEND_SMSrdquo) C2

SendSMS(value) Sink()

1

2

3

4

5

6

7

8

9

10

11

12

Figure 5 Sample app code showing that sensitive API isprotected by constraints

troduced by Java reflection cannot be captured by this ap-proach Since we find that reflections are heavily used in ourdataset and also are found in those well-known Wormhole

apps we add reflection support to the taint analysis engine

Java reflection is used by programs to examine ormodify the runtime behavior of apps running in Java virtualmachine We have seen reflections used in apps for bothlegitimate purpose (eg bypass some API-level restrictions)and malicious purpose (eg disguise the entry to maliciouscode) Handling reflection accurately is impossible for staticanalysis and remains challenging even combining runtimeanalysis [43] To capture the control-flow jumps of reflectionto our best effort we implement a handler in the IDFGbuilder similar to the one used in FlowDroid [20] whichcan link the target class or method invoked by reflectionto the calling function and add the missing edges to theIDFG Currently it only handles reflection calls with targetsexplicitly provided in the same procedure and will missthose whose targets are not deterministic statically Howeverwe find that over 86 of reflections in our dataset can behandled by applying this heuristic and it also helps identifysignificantly more vulnerable paths as shown in sect45

Java layer taint analysis is used to examine the depen-dency among remote input and sensitive APIs We definea notion to describe the explicit and implicit dependencyrelationships among statements The notion is further usedto categorize usage

Notion 1 The dependency relationship between two state-

ments along the same usage path is either implicit orexplicit and transitivity applies

stmt1Eminusrarr stmt2 if stmt2 is explicitly tainted by

the return value of stmt1

stmt1Iminusrarr stmt2 if stmt2 is implicitly tainted by

the return value of stmt1

stmt1Iminusrarr stmt2

Eminusrarr stmt3 if stmt3 is explic-

itly tainted by the return value of stmt2 and bothstmt2 and stmt3 are implicitly tainted by the returnvalue of stmt1

Explicit taint describes the data dependency relationshippropagated by assignment expressions while implicit taintreflects the ldquotriggeringrdquo relationship in which the source ispresented in the conditional statements Shown in Figure 4the first taint source comes from the remote input and flagis explicitly tainted by the remote_input since it is de-rived from it All the statements in the if block are implic-itly tainted by the flag since they are control-dependenton the if statement Specifically another taint source isidentified as the getSharedPreferences which readsdata from an asynchronous source The password readfrom the shared preferences is written to the socket identi-fied as an explicit taint relationship between statements inline 5 and line 6 Thus the dependency relationship alongthis usage path is expressed as

accept()Iminusrarr getSharedPreferences()

Eminusrarr write()

To further narrow down the potential vulnerable path listand provide insights to identify the vulnerability OPAna-lyzer integrates both constraints analysis and reachabilityanalysis to help analyst prioritize paths output by OPAna-lyzer to reduce human efforts

Constraints analyzer examines all the conditional state-ments along the usage path to which the sensitive APIis control dependent on Shown in Figure 5 the remoteinput is separated into two substrings and put into a MapThe sensitive API SendSMS is control dependent on twoconstraints Constraint C1 defined in line 8 checks whetherthe Map is empty while the constraint C2 in line 9 checkswhether the command passed in from remote input isldquoSEND SMSrdquo Both checks are easy to bypass an arbitraryremote attacker can construct the input string to bypassthe checks and trigger the malicious payload to be sentvia SMS which results in a remote privilege redelegationattack [30] OPAnalyzer annotates a constraint as weak if itis either (1) comparison with constants or (2) comparisonwith a predefined set of trivial API (eg Mapsize()SetisEmpty()) The heuristic reduces human effortsby prioritizing usage paths that are obviously easy to becontrolled but could introduce false negatives(sect 45)

Reachability analyzer characterizes the reachability ofa path using both static and dynamic approaches First thestatic analysis models the app Activity lifecycle andfilters those usage paths unreachable from the program entryset The dynamic approach identifies those usage paths thatstart with a port that is open by default at app launching

6

OPAnalyzer

Categorization

apk

usage path

No

Usage families

Pattern matches

Yes

open port usage family

Convert to

Notation 1

Generalize

usage pattern

Figure 6 Usage categorization methodology

time These paths are annotated as highly insecure sinceremote attacker has a large timing window to exploit themNote that ports that are not open by default are still vulner-able to the on-device malware in our threat model sincethe malware can monitor the proc file and exploit thevulnerable paths as long as it detects the port is open Thedynamic analysis is implemented using function hookingbased on Xposed framework [17] and combined with deviceautomation the analyzer automatically annotates reachabil-ity results on the usage paths

Usage categorization methodology Shown in Figure 6OPAnalyzer aggregates usage paths with similar open portusage into one family based on the sensitive APIs theycontain and the notion It extracts usage paths and convertsthem to Notion 1 The categorization approach matches thenotion of new paths with those already identified patternsIf an incoming path cannot be categorized into any of theexisting families we manually generalize its usage to apattern and add a new family to the existing usage familyset Following this approach OPAnalyzer categorizes mostof the usage paths except a few that cannot be converted toNotion 1(sect52)

Vulnerability discovery methodology Considering anattacker in our threat model to exploit a usage path andtrigger the sensitive functionality he needs to (1) find theright timing when the port is open (2) bypass all the checksalong the path to execute the sensitive API The usagepaths output from OPAnalyzer come with the reachabilityinformation sensitive functionality and strengths of predi-cates all annotated help human analyst efficiently examinethese two prerequisites for an attack and identify vulnera-bility Specifically OPAnalyzer prioritize ldquoweak pathsrdquo andldquohighly insecurerdquo paths for manual inspection And notethat we also selectively examined the other usages paths inthe OPAnalyzer output since they may also be vulnerableto remote exploits Some of the interesting vulnerabilities(eg AirDroid exploit) in our case study(sect6) are actuallyidentified in those non-weak usage paths

45 Evaluation

We obtain 24000 apps from the PlayDrone dataset [45]to evaluate our tool which contains top 1000 popular apps

from each of the 24 categories in the Google Play includingentertainment tools etc Our evaluation focuses on thevulnerability discovery of OPAnalyzer which is the mostsecurity critical functionality

Discovery accuracy To evaluate the false positives(FPs) of the weak path detection we first define the FPsas ldquoweakrdquo paths that are verified to be not exploitablethrough manual inspection We examined the weak usagepaths output by OPAnalyzer and constructed remote inputto see if the sensitive functionality could be triggered Wecall these weak paths that are verified to be exploitablevulnerable paths and the rest of them are considered asFPs Among the 24000 apps 68 of them (1632) haveopen-port functionality and 133 weak paths are identifiedto be reachable at app launching time by OPAnalyzer Wemanually identified 113 vulnerable paths that can be easilyexploited by constructing remote input (FP rate 151)The FPs mainly come from paths that contain checks on theruntime property of the app As an example a usage path isguarded by the constraint if (debugMode == True)

will not be triggered when the app is in release mode butwill be output falsely as weak path

Due to the lack of any publicly accessible study of openport vulnerabilities on mobile platform we run OPAnalyzeron the recently-reported Wormhole apps from the Chineseapp market to evaluate the false negatives (FNs) of OP-Analyzer To the best of our knowledge they are the onlyreported instances that contain confirmed open port exploitswhich are usable as ground truth in the FN evaluation TheFNs of the weak path detection are those paths that are notannotated as ldquoweakrdquo but are verified to be exploitable withour manual inspection Wormhole apps are vulnerable dueto their integrations of vulnerable SDKs including BaiduQihoo360 AMap and Tencent [12] and thus we choosethe most popular apps in each SDK category We do nottest on Qihoo360 library since the problem only affects anold beta version which can no longer be found in apps onmajor app markets

As shown in Table 1 OPAnalyzer discovers usage pathsthat contain sensitive functionality in all of the three appswith some of them reported as weak paths Unfortunatelythe report has no detailed path information that can be usedas ground truth for evaluation we do our best to manuallyanalyze the decompiled app to find exploitable paths ForBaidu SDK OPAnalyzer detects all the exploitable pathsthat we manually discovered and even discovers new ex-ploits that have not been reported in the report such asstealing the WiFi BSSID For AMap OPAnalyzer reportsfour usage paths while none of them are recognized as weakpaths However three exploits (FNs) from those non-weakpaths are identified We find that one of the conditionalstatement shared by all 4 usage paths depends on valuethat is defined beyond the IDFG of the remote entry pointOPAnalyzer thus does not consider the check as ldquoweakrdquosince its value cannot be determined while it turns out to beconstant in the run time It is due to the limitation of lackingof backward analysis support so that OPAnalyzer doesnrsquothave enough visibility into how a variable encountered on

7

Wormhole family Sample app Version Entry points Usage path Weak path Not weak path

total exploitable total exploitable

Baidu combaiduBaiduMap 850 1 15 8 8 7 0

Tencent comtencentandroidqqdownloader 570 4 16 1 1 15 1

AMap comautonaviminimap 734 1 4 0 0 4 3

TABLE 1 OPAnalyzer output for three popular ldquoWormholerdquo apps that are reported vulnerable

Feature of usage

Improv Featured applibpaths captured

none 636 NA WiFi file transfer

+ reflection 804 +26 OpenVPN

+ API 1472 +131 AMap

+ native 845 +33 Tencent XG

+ all 1934 +204 Baidu wormhole

TABLE 2 Evaluation of accumulative improvement broughtby (1) handling explicit Java reflection and (2) adding open-port specific sensitive API (3) capturing native code jump

the usage path is propagated to this procedure if it isdefined beyond the IDFG of the entry point This affects theaccuracy of the information leakage tracking and constraintsanalysis and can be solved by integrating backward slicingtechnique [20] [48] We plan to add that to the OPAnalyzerin the future

False negatives may also be introduced by the na-tive code analyzer due to a limitation inherited from theIDA-PRO front end ARM processor supports multiple in-teraction sets mixed in one segment in the runtime whilethe disassembler can interpret one type at the same time inthe static analysis [3] And when the 16-bit ldquoThumbrdquo and32-bit ldquoARMrdquo instructions coexist within one segment dueto optimization the disassembling result may be incorrectAdditionally the native code analysis of OPAnalyzer doesnot cover all possible types of interactions between nativecode and Java code Combining native code and Java codeanalysis is a fundamental challenge of Android app analy-sis [38] and we leave it as future work to accurately modelall the control- and data-flow transitions between native andJava layers

We also evaluate the improvement on the effectiveness ofOPAnalyzerrsquos path discovery brought by three of our engi-neering efforts namely (1) adding open-port specific APIs tothe sensitive API set (2) handling explicit Java reflectionsand (3) capturing native code jump Shown in Table 2integrating these features greatly improves the coverage ofOPAnalyzer by 204 while completing the sensitive APIset turns out to be the most effective engineering effort wespent These improvements reduce false negatives which iscrucial to our system

Performance The most compute-intensive step in OP-Analyzer is the taint analysis which includes building theIDFG and DDG and running the Dijkstrarsquos algorithm on theDDG to find all the usage paths We measure the time toperform the taint analysis for the top 1000 popular apps fromour dataset The experiment runs on a machine with IntelCore i5-3470 CPU and 8GB of RAM For apps with at least

one entry point the median processing time for OPAnalyzerto finish the taint analysis is 615 seconds with standarddeviation of 1272

5 Usage and Vulnerability

With the usage paths output from OPAnalyzer we sys-tematically study open port usage and their security impli-cations in the top 1000 popular apps from each of the 24different categories on Google play

51 Popularity and Permission Usage

Among the 24000 apps we identified open port func-tionality in 68 (1632) while 50 of these open port appshave more than 500K downloads

Sensitive permission usage To understand the mostcommon functionality triggered by remote input we usethe API to permission mappings constructed in sect43 to getthe set of sensitive permissions Figure 7 shows the topsecurity-sensitive permissions involved in open port usageSurprisingly we find that in open port apps a rich set ofhighly-sensitive OS-level functions in Android can be in-voked remotely ranging from accessing private data such ascontacts and location to performing sensitive actions such asusing camera and sending SMS If not protected sufficientlythis usage can be remotely exploited to cause severe dam-ages such as privacy leakage and privileged code executionsjust like the recently reported Wormhole exploits [12] Inaddition we find that the pseudo permission DATA_LEAK

(defined in sect43) which indicates that data is read fromasynchronous sources such as internal storage or contentproviders and sent to the remote end has top popularity inopen-port apps This shows that open port usage commonlyhas potential risk of exposing internal application data to theremote attacker which typically involves plenty of sensitivedata such as credentials and conversation history [51]

52 Usage Family Categorization

Using OPAnalyzer we categorize usage paths into differ-ent usage families defined by code patterns Table 3 showsthe 5 major usage families we identified in our datasettogether with the path categorization results and the typesof potentially-exposed vulnerabilities As shown 99 ofreachable usage paths of open port apps are categorized intoone of the five families which are described in detail asfollows

Data sharing path a usage path through which data readfrom the device is sent to the remote host In this category

8

0

5

10

15

20

25

WRITE_EXTERNAL_STORAGE

C2DM_RECEIVE

DATA_LEAK

ACCESS_COARSE_LOCATION

ACCESS_FINE_LOCATION

GET_TASK

CAMERA

READ_CONTACTS

DISABLE_KEY_GUARD

WRITE_SETTING

RECORD_AUDIO

CALL_PHONE

SEND_SMS

o

f o

pe

n p

ort

ap

ps

Sensitive permissions

Figure 7 Permission protected APIs triggered by remote input

Usage category Pattern Usage path Perc App Weak path Vulnerability

Data sharing accept()Iminusrarr APIdata read

Eminusrarr write() 1340 693 425 775 V1

Proxy accept()Eminusrarr APIout connection 122 63 59 101 V1V3

Remote execution accept()I or Eminusminusminusminusrarr APIexecution 127 65 41 69 V2V3

VoIP call accept()Iminusrarr APIaudio setting 45 23 27 11 V3

PhoneGap Categorized using code signature 282 146 141 0 NA

Uncategorized NA 18 09 10 0 NA

TABLE 3 Open port usage and potential vulnerability V1sensitive data leakage V2 privileged remote execution V3 DoS

the most commonly used protocol for data sharing is HTTPwhile HTTPS FTP UPnP [15] and some customized proto-cols are also observed As shown nearly 60 of the pathsin this category are found to be weakly protected withoutany client authentication leaving them easily exploitable(examples in sect6) By examining the apps in this category wealso identified a mobile-specific open port usage scenariodata sharing in physical proximity eg allowing a userto transfer photo to her PC nearby This usage turns tobring most exploits in this family as shown later in sect624 out of 26 exploits in data sharing are associated withthis particular usage Also worth noting is that in this usagefamily sensitive data can be leaked without invoking anypermission-protected APIs along the tainted path Due toour improvement in sensitive API selection (sect43) our toolcan successfully capture these cases

Proxy path is defined as forwarding requests in remoteinput to other destinations We find that all the paths in theseapps are used as local proxy eg for advertising and contentfiltering For example to overcome the content modificationrestrictions in Android WebView a web browsing app startsas background service a local web proxy so that it can insertits own ads into the fetched web pages If exposed to remoteattackers such local proxy can be used as a reflector intargeted DDoS attacks Also if it is configured to cachepages or store cookies attackers can access personalizedpages to harvest user privacy or even hijack victimrsquos emailor social network accounts for spear phishing attacks

Remote execution path refers to usage paths that cantrigger certain actions on the device such as sending SMS

and writing to storage Besides common use cases suchas push notification we also observe interesting usage inphysical proximity which allows the same user to use mo-bile device functionality through PC interface eg textingSMS using keyboard However there are also sensitive func-tionality that can be executed remotely and are beyond thedeclared functionality of the app which we suspect to beldquobackdoorsrdquo left by app developers

VoIP call paths are used in apps to listen on incomingcall requests based on the Session Initiation Protocol (SIP)After accepting a SIP invite message from the port theapp extracts information such as caller ID and starts thering tone to notify the user Remote attackers in theory cansend spoofed packet to ring the phone and spoof the callerID However due to the IPSec support in SIP such off-pathattack is unlikely to be practical

PhoneGap paths belong to apps developed by Phone-GapCordova a hybrid app development framework al-lowing developers to quickly build apps using JavaScriptand HTML5 It uses open ports to serve requests fromthe JavaScript client and handle the API calls The resultwritten to the incoming socket is not defined in the IDFGof the remote entry point making it difficult for OPAna-lyzer to capture sensitive APIs To address this we usethe presence of several PhoneGap-specific classes such asCallbackServer as the code signatures to identify theseusage paths The port intended for IPC is falsely openedto the Internet However we find that the usage paths ofPhoneGap are protected by strong security checks whichverifies whether the request contains a 128-bit token derived

9

Open port intention Vulnerability description Featured attacks Vulnerable app example App 1

Usage of the app userLack of authentication to verify that Data theft WiFi file transfer 24connections come from the app user Privilege escalation AirDroid PhonePal 10

Communication with Lack of authentication to verify the requests Data theft Lenjoy 15backend are from authentic app backend server Privileged escalation KindeeExpress 5

Local communicationPort used for on-device communication DoS VGet Fast secure VPN 12falsely opened to the network Data theft CachedProxy 1

1 Number of vulnerable apps in the same category An app may be vulnerable to both attacks in each category

TABLE 4 Case study of verified exploitable app categorized by the intended usage of open port

from the devicersquos Universally Unique Identifier (UUID) [1]Thus we consider the open service of PhoneGap as well-protected

53 Security Implications

Usage paths in different families if not well protectedcan lead to different security breaches As shown in table3 OPAnalyzer outputs 956 weak paths We find that nearlyhalf of the total usage paths are considered ldquoweakrdquo In theproxy category over 80 of the paths are not protectedFrom these weak paths we identify three vulnerabilitycategories sensitive data leakage (V1) privileged remoteexecution (V2) and DoS (V3) Besides we also discovera new problem that any open port on smartphones can beexploited to harvest cellular IPv6 addresses which allowsattacker to collect victim IPs without scanning the huge IPv6address space and further launch attack to exploit vulnerableports The vulnerability is detailed in the Appendix A

V1 Sensitive data leakage Sensitive data of a mobiledevice can be retrieved from many sources such as SD Cardsensor etc If these paths are not well protected remoteattacker can exploit them to steal sensitive data that areeven protected by Android permission or UNIX uidgid

check More importantly if the victim IP is public suchvulnerabilities can be easily revealed using fast Internet-wide scanning tools such as ZMap [26] causing large scaledata theft

V2 Privileged remote execution Vulnerable paths thattrigger native actions can be leveraged by remote attackersto execute privileged functionality such as sending SMS andmodifying contacts Moreover by exploiting the broadcast-ing Intent mechanism provided by Android attackers caneven execute functionality beyond the vulnerable app Forexample an unprotected usage path that sends Intent

based on remote input can be leveraged to launch YouTubeapp to play the video from the URL passed by the remoteattacker By uploading a maliciously crafted MP4 file to theURL attacker can gain full control of the device exploitingthe Stagefright vulnerability [6]

V3 Denial of service Most remote execution paths arevulnerable to DoS attack against the device user For thelocal proxy usage paths they can also be used by attackersas reflectors in targeted DDoS attack against victims inthe Internet to hidden their IP addresses Other securityproblems of open proxies such as leaking internal networkdata and IP spoofing based attack also apply

6 Exploits Case Studies

To broaden the scope of our vulnerable study and dis-cover more exploitable open port usage we extended ourdata set to include all the 78K apps from the Tools cate-gory of the PlayDrone dataset to our vulnerability analysisbased on the observation that the percentage of open-portapps in the Tools(109) is significantly higher than theaverage (68) Furthermore we also crawled the top 3000most popular apps from a Chinese app market [2] wherethe Wormhole problem was reported from

By analyzing the annotated usage paths from the OPAna-lyzer output we successfully discover several new exploitsof sensitive data leakage and privileged remote execution inboth apps and third-party libraries including some high-profile ones with millions of downloads and even pre-installed apps Moreover we classify these vulnerable appsinto 3 categories based on the intended usage scenario of theopen port inferred from the manual analysis (1) intendedfor use by app users (2) intended for communication withthe backend and (3) intended for local communicationSuch categorization helps better understand the challengesin securing the port opened for different purposes Table 4shows an overview of the 57 exploitable apps that are man-ually verified from the OPAnalyzer output A case study ofinteresting vulnerability in each category is presented belowThe video demos for some of the implemented attacks areshown on our website [11]

61 Intended for Use by App Users

Such apps open ports for different purposes intendedfor the app users such as transferring file from the phoneto another device of the same user However essentialchecks are found missing in many apps in this category thusexposing the sensitive data and also privileged functionalityof the device to attackers

Virtual data cable is a popular app on China marketthat helps user transfer their photos to PC by opening a webserver on the phone The server port opens by default at applaunch time and silently runs in the background It does notauthenticate clients nor notify incoming connections thuscan be easily scanned and exploited by remote attackersMoreover it does not check the requested file path so thatattacker can access files beyond the photo folder on SD cardby adding ldquordquo to the path and steal sensitive data fromapp cache and system directory Similarly a popular file

10

sharing app WiFi file transfer with 10 million installs doesnot authenticate clients while it opens the server port onlywhen user presses a toggle button However an on-devicemalware that only has Internet permission in our threatmodel can listen on the status of the port by monitoring theproc file system and steal data from the port as long asit is open

PhonePal allows a user to remotely control hisherdevice with a web-browser which contains highly sensitiveusage paths such as open URLs in the Android browserand open videos in the YouTube app All these usage pathsare found unprotected which puts the device at the riskof phishing attack and even compromise [6] Moreovervulnerabilities such as allowing attacker to remotely installapps on the victim device are identified in the high-profileapp AirDroid pre-installed on Samsung Chromebook andSmartisan phone [13] We present a case study of this appin the mitigation strategy section (sect7)

62 Intended for Communication with Backend

Open ports in these apps are intended to communicatewith the app developerrsquos backend server for various pur-poses If the open port service does not authenticate theidentity of the remote server attackers can spoof the appserver Interestingly by manually examining the apps wefind that open port usage of some apps are beyond the appsrsquodeclared functionality implying potentially covert maliciousbehavior

KindeExpress is the most popular mailpackage trackingapp on a China market with 1 million downloads whosefunctionality is to provide tracking information from manydelivery service providers One of its usage path is able tostart an Activity of the app and display the data fromremote input on the apprsquos UI which also brings the app tothe front even when it is running in the background Weverified that none of the declared functionality of the appdepends on this usage path and we suspect it to be usedfor advertising Unfortunately this path is not protected byany authentication mechanism and remote attacker can sendcommand to the app pretending as it comes from the appserver to display deceptive content on the app UI

Huang CheatMaker is a game modifier app that helpsusers cheat when playing mobile games We identified ausage path that accepts data pushed from the app serverstores the data as a shared object (so) file and loadsit at run-time The authentication along the path is weakand the app dynamically loads the code without verifyingwhere it comes from nor its integrity which enables remoteattackers to inject malicious payload to the app to that willbe executed thus compromising the device

63 Intended for Local Communication

Usage paths in Proxy and PhoneGap families are in-tended for on-device communication which can be eitherIPC among different components of an app or proxy fordifferent apps on the device to use However open ports

in some apps that are intended for local usage are falselyexposed to the network and thus lead to security breaches

OpenVPN is an open-source VPN implementation thatis integrated by several popular VPN apps on Google PlayMultiple interfaces are provided by OpenVPN for the appto configure the local VPN settings while the open TCPport interface is identified to be the least secure one Aremote attacker can DoS the victim user by changing proxysettings such as port number on the device Fortunatelysome app developers paid extra attention when integratingOpenVPN and closed the insecure configuration interfacefrom the open TCP port but VPN apps vulnerable to thisproblem still remain (eg Fast secure VPN)

CacheProxy is an app that opens local proxy with thecapability of caching the web page content Upon receivinga request the proxy first checks whether the request can beserved using cached content before fetching the page withno authentication performed on the source of the incomingrequest Remote attackers can thus easily access sensitiveinformation of the victim such as e-mails by requesting thee-mail page since the page is retrieved from the cache forthe attacker

To get an initial estimate on the severity of open portvulnerabilities in the wild we performed a small scale portscan in a subnet of a campus network The ports scannedare those opened by the most popular vulnerable apps inour dataset whose port number needs to be static andunique Note that we only scanned for the existence ofthe open ports but did not send any data to the ports toverify the vulnerability for ethical concerns We performedonly one scan using a scanning tool [26] which finished intwo minutes Surprisingly 40 hosts identified to be mobiledevices open such ports Although different apps that usethe same port number may introduce false positives thescanning result indicates that immediately exploitable openports exist in the wild

7 Mitigation Strategy

Traditional solutions to protect an open port fromInternet attackers are through firewall which monitors andcontrols incoming and outgoing traffic based on prede-termined security policies However the firewall solutionsuffers from usability in the mobile context since it ishard for individual users to configure suitable firewall rulesfor each app installed on the device and coordinate bothapp functionality and security assurance Moreover in thephysical proximity use scenario since users can initiateconnections from arbitrary hosts it is hard to configure rulesin advance

Despite a variety of open port usage described thefundamental problem is the lack of proper client authen-tications However we find that it is non-trivial to provide ageneral solution to patch the security problems for all usagecases while preserving usability We discuss the major chal-lenges in different scenarios and propose countermeasures

Intended for communication with backend For theopen port mobile app to verify that the incoming connection

11

is from the authentic server we suggest using secure tokensto perform authentication Although tokens are already usedin some open port apps implementation flaws are commonlyseen For example a third-party push notification servicethat distributes token to app developers for them to embedin the app is vulnerable because the token can be extractedfrom the released app binary by attacker to exploit the vul-nerable app installed on other victim devices We suggest theapp and server negotiate a shared token using mechanismssuch as Diffie-Hellman [7] at app launching time And openport app uses the token to authenticate further incomingconnections

Intended for use by app users Compared to theprevious usage scenario open port apps in this case do notknow in advance the legitimate remote hosts that shouldconnect to them Depending on the usage of the app userthe trusted remote hosts can be userrsquos desktop or even hisfriendrsquos laptop A general solution is to use password or pincode to authenticate incoming connections however somesecurity issues are raised in practice As an example allthe apps we examined that use password provide hard-codedefault password that does not require users to change beforeusing the app leading to the potential use of the defaultpassword and degrading app security Randomly generatedpin codes in the open port apps we examined are usuallyno longer than 4 characters which is trivial to enumerateExperiment in our local WiFi network indicates that it takesless than 5 minutes to send probing requests that enumerateall the 4-character strings

Another authentication solution adopted by the toptrending apps for this usage scenario is the incoming con-nection notification which pops up a window when a newhost connects to the open port and displays the IP addressof the host And the request is not served until user explic-itly accepts the client by clicking the ldquoallowrdquo button Forordinary users the timing of the pop-up window is also animportant indicator for them to make the decision of whetherto allow or deny the request However on-device malwarecan infer the timing when there is an incoming connection tothe port by monitoring procnet[tcp][tcp6] andsend request immediately to trick user into also allowing itsconnection by overlaying the pop-up window We furtherfind that even the most popular apps in this category hasimplementation flaws that can be practically exploited byattackers in our threat model

AirDroid1 is a top-ranked app on the market that allowsusers to access and manage their Android device wirelesslyfrom desktop by opening a server on the phone It providesa rich set of functionality to users such as access cameraand install apps remotely and uses the incoming connectionnotification schema to authenticate client However if thetiming of user initiated connection is inferred by the attackerwith the help of an on-device malware and attacker sendsrequest to the open port before the user accepts the previousconnection the app wonrsquot pop up another window Insteadthe attacker connection silently replaces the previous legit-

1 AirDroid httpswwwairdroidcom

ServerSocket

SecureServerSocket Remote client

Requestfrom IP0

Return IP0

as QR code

Scan

Trust IP0

Requestfrom IP0

Return

Socket Socket

Display

Check IP0

Figure 8 SecureServerSocket design

imate connection in the waiting queue without changingthe IP address displayed on the pop-up window And whena user clicks the button to allow the legitimate connectionthe attacker client is allowed instead and numerous sensitivecapabilities of AirDroid are granted to the attacker

Usage in this category is usually for the cable-less com-munication with nearby hosts of the user We confirmed that24 out of the 26 vulnerable apps in this category are intendedfor the use in physical proximity We demonstrate a transpar-ent socket-level solution that addresses the security and us-ability challenges in this usage scenario Shown in Figure 8we provide SecureServerSocket which encapsulatesthe Android ServerSocket API to accept incoming sock-ets When a remote client the userrsquos desktop for exampletries to connect to the port the SecureServerSocket

first puts the connection on hold and then encodes the IPaddress of the client into a QR code and returns to theremote client The remote client is required to display theQR code and let the user scan it using the mobile device inorder to get access

Once the QR code is scanned the decoded IP addressis returned to the SecureServerSocket and the con-nection from this IP is allowed It then returns the incom-ing socket to the upper application layer to be handledThis approach authenticates clients on the IP layer andensures that the open port only serves clients in physicalproximity of the device user and it achieves both securityand usability We provide SecureServerSocket as alibrary that app developers can simply use as a replacementof ServerSocket No changes on the client side arerequired if the client is a web browser which is the commoncase in our app dataset For other client types that cannotdisplay QR code we suggest using one-time pin code to dothe authentication instead Demo of the SecureServerSocketimplementation can also be found on our website [11] Andfor future work we plan to conduct a user study to evaluatethe effectiveness of this approach

Intended for local communication For the local usageof on-device proxy the best practice is to bind the proxy tothe loopback address of the device which makes the serviceunreachable from the network For another local usage

12

OPAnalyzer

Categorization

apk

usage path

No

Usage families

Pattern matches

Yes

open port usage family

Convert to

Notation 1

Generalize

usage pattern

Figure 6 Usage categorization methodology

time These paths are annotated as highly insecure sinceremote attacker has a large timing window to exploit themNote that ports that are not open by default are still vulner-able to the on-device malware in our threat model sincethe malware can monitor the proc file and exploit thevulnerable paths as long as it detects the port is open Thedynamic analysis is implemented using function hookingbased on Xposed framework [17] and combined with deviceautomation the analyzer automatically annotates reachabil-ity results on the usage paths

Usage categorization methodology Shown in Figure 6OPAnalyzer aggregates usage paths with similar open portusage into one family based on the sensitive APIs theycontain and the notion It extracts usage paths and convertsthem to Notion 1 The categorization approach matches thenotion of new paths with those already identified patternsIf an incoming path cannot be categorized into any of theexisting families we manually generalize its usage to apattern and add a new family to the existing usage familyset Following this approach OPAnalyzer categorizes mostof the usage paths except a few that cannot be converted toNotion 1(sect52)

Vulnerability discovery methodology Considering anattacker in our threat model to exploit a usage path andtrigger the sensitive functionality he needs to (1) find theright timing when the port is open (2) bypass all the checksalong the path to execute the sensitive API The usagepaths output from OPAnalyzer come with the reachabilityinformation sensitive functionality and strengths of predi-cates all annotated help human analyst efficiently examinethese two prerequisites for an attack and identify vulnera-bility Specifically OPAnalyzer prioritize ldquoweak pathsrdquo andldquohighly insecurerdquo paths for manual inspection And notethat we also selectively examined the other usages paths inthe OPAnalyzer output since they may also be vulnerableto remote exploits Some of the interesting vulnerabilities(eg AirDroid exploit) in our case study(sect6) are actuallyidentified in those non-weak usage paths

45 Evaluation

We obtain 24000 apps from the PlayDrone dataset [45]to evaluate our tool which contains top 1000 popular apps

from each of the 24 categories in the Google Play includingentertainment tools etc Our evaluation focuses on thevulnerability discovery of OPAnalyzer which is the mostsecurity critical functionality

Discovery accuracy To evaluate the false positives(FPs) of the weak path detection we first define the FPsas ldquoweakrdquo paths that are verified to be not exploitablethrough manual inspection We examined the weak usagepaths output by OPAnalyzer and constructed remote inputto see if the sensitive functionality could be triggered Wecall these weak paths that are verified to be exploitablevulnerable paths and the rest of them are considered asFPs Among the 24000 apps 68 of them (1632) haveopen-port functionality and 133 weak paths are identifiedto be reachable at app launching time by OPAnalyzer Wemanually identified 113 vulnerable paths that can be easilyexploited by constructing remote input (FP rate 151)The FPs mainly come from paths that contain checks on theruntime property of the app As an example a usage path isguarded by the constraint if (debugMode == True)

will not be triggered when the app is in release mode butwill be output falsely as weak path

Due to the lack of any publicly accessible study of openport vulnerabilities on mobile platform we run OPAnalyzeron the recently-reported Wormhole apps from the Chineseapp market to evaluate the false negatives (FNs) of OP-Analyzer To the best of our knowledge they are the onlyreported instances that contain confirmed open port exploitswhich are usable as ground truth in the FN evaluation TheFNs of the weak path detection are those paths that are notannotated as ldquoweakrdquo but are verified to be exploitable withour manual inspection Wormhole apps are vulnerable dueto their integrations of vulnerable SDKs including BaiduQihoo360 AMap and Tencent [12] and thus we choosethe most popular apps in each SDK category We do nottest on Qihoo360 library since the problem only affects anold beta version which can no longer be found in apps onmajor app markets

As shown in Table 1 OPAnalyzer discovers usage pathsthat contain sensitive functionality in all of the three appswith some of them reported as weak paths Unfortunatelythe report has no detailed path information that can be usedas ground truth for evaluation we do our best to manuallyanalyze the decompiled app to find exploitable paths ForBaidu SDK OPAnalyzer detects all the exploitable pathsthat we manually discovered and even discovers new ex-ploits that have not been reported in the report such asstealing the WiFi BSSID For AMap OPAnalyzer reportsfour usage paths while none of them are recognized as weakpaths However three exploits (FNs) from those non-weakpaths are identified We find that one of the conditionalstatement shared by all 4 usage paths depends on valuethat is defined beyond the IDFG of the remote entry pointOPAnalyzer thus does not consider the check as ldquoweakrdquosince its value cannot be determined while it turns out to beconstant in the run time It is due to the limitation of lackingof backward analysis support so that OPAnalyzer doesnrsquothave enough visibility into how a variable encountered on

7

Wormhole family Sample app Version Entry points Usage path Weak path Not weak path

total exploitable total exploitable

Baidu combaiduBaiduMap 850 1 15 8 8 7 0

Tencent comtencentandroidqqdownloader 570 4 16 1 1 15 1

AMap comautonaviminimap 734 1 4 0 0 4 3

TABLE 1 OPAnalyzer output for three popular ldquoWormholerdquo apps that are reported vulnerable

Feature of usage

Improv Featured applibpaths captured

none 636 NA WiFi file transfer

+ reflection 804 +26 OpenVPN

+ API 1472 +131 AMap

+ native 845 +33 Tencent XG

+ all 1934 +204 Baidu wormhole

TABLE 2 Evaluation of accumulative improvement broughtby (1) handling explicit Java reflection and (2) adding open-port specific sensitive API (3) capturing native code jump

the usage path is propagated to this procedure if it isdefined beyond the IDFG of the entry point This affects theaccuracy of the information leakage tracking and constraintsanalysis and can be solved by integrating backward slicingtechnique [20] [48] We plan to add that to the OPAnalyzerin the future

False negatives may also be introduced by the na-tive code analyzer due to a limitation inherited from theIDA-PRO front end ARM processor supports multiple in-teraction sets mixed in one segment in the runtime whilethe disassembler can interpret one type at the same time inthe static analysis [3] And when the 16-bit ldquoThumbrdquo and32-bit ldquoARMrdquo instructions coexist within one segment dueto optimization the disassembling result may be incorrectAdditionally the native code analysis of OPAnalyzer doesnot cover all possible types of interactions between nativecode and Java code Combining native code and Java codeanalysis is a fundamental challenge of Android app analy-sis [38] and we leave it as future work to accurately modelall the control- and data-flow transitions between native andJava layers

We also evaluate the improvement on the effectiveness ofOPAnalyzerrsquos path discovery brought by three of our engi-neering efforts namely (1) adding open-port specific APIs tothe sensitive API set (2) handling explicit Java reflectionsand (3) capturing native code jump Shown in Table 2integrating these features greatly improves the coverage ofOPAnalyzer by 204 while completing the sensitive APIset turns out to be the most effective engineering effort wespent These improvements reduce false negatives which iscrucial to our system

Performance The most compute-intensive step in OP-Analyzer is the taint analysis which includes building theIDFG and DDG and running the Dijkstrarsquos algorithm on theDDG to find all the usage paths We measure the time toperform the taint analysis for the top 1000 popular apps fromour dataset The experiment runs on a machine with IntelCore i5-3470 CPU and 8GB of RAM For apps with at least

one entry point the median processing time for OPAnalyzerto finish the taint analysis is 615 seconds with standarddeviation of 1272

5 Usage and Vulnerability

With the usage paths output from OPAnalyzer we sys-tematically study open port usage and their security impli-cations in the top 1000 popular apps from each of the 24different categories on Google play

51 Popularity and Permission Usage

Among the 24000 apps we identified open port func-tionality in 68 (1632) while 50 of these open port appshave more than 500K downloads

Sensitive permission usage To understand the mostcommon functionality triggered by remote input we usethe API to permission mappings constructed in sect43 to getthe set of sensitive permissions Figure 7 shows the topsecurity-sensitive permissions involved in open port usageSurprisingly we find that in open port apps a rich set ofhighly-sensitive OS-level functions in Android can be in-voked remotely ranging from accessing private data such ascontacts and location to performing sensitive actions such asusing camera and sending SMS If not protected sufficientlythis usage can be remotely exploited to cause severe dam-ages such as privacy leakage and privileged code executionsjust like the recently reported Wormhole exploits [12] Inaddition we find that the pseudo permission DATA_LEAK

(defined in sect43) which indicates that data is read fromasynchronous sources such as internal storage or contentproviders and sent to the remote end has top popularity inopen-port apps This shows that open port usage commonlyhas potential risk of exposing internal application data to theremote attacker which typically involves plenty of sensitivedata such as credentials and conversation history [51]

52 Usage Family Categorization

Using OPAnalyzer we categorize usage paths into differ-ent usage families defined by code patterns Table 3 showsthe 5 major usage families we identified in our datasettogether with the path categorization results and the typesof potentially-exposed vulnerabilities As shown 99 ofreachable usage paths of open port apps are categorized intoone of the five families which are described in detail asfollows

Data sharing path a usage path through which data readfrom the device is sent to the remote host In this category

8

0

5

10

15

20

25

WRITE_EXTERNAL_STORAGE

C2DM_RECEIVE

DATA_LEAK

ACCESS_COARSE_LOCATION

ACCESS_FINE_LOCATION

GET_TASK

CAMERA

READ_CONTACTS

DISABLE_KEY_GUARD

WRITE_SETTING

RECORD_AUDIO

CALL_PHONE

SEND_SMS

o

f o

pe

n p

ort

ap

ps

Sensitive permissions

Figure 7 Permission protected APIs triggered by remote input

Usage category Pattern Usage path Perc App Weak path Vulnerability

Data sharing accept()Iminusrarr APIdata read

Eminusrarr write() 1340 693 425 775 V1

Proxy accept()Eminusrarr APIout connection 122 63 59 101 V1V3

Remote execution accept()I or Eminusminusminusminusrarr APIexecution 127 65 41 69 V2V3

VoIP call accept()Iminusrarr APIaudio setting 45 23 27 11 V3

PhoneGap Categorized using code signature 282 146 141 0 NA

Uncategorized NA 18 09 10 0 NA

TABLE 3 Open port usage and potential vulnerability V1sensitive data leakage V2 privileged remote execution V3 DoS

the most commonly used protocol for data sharing is HTTPwhile HTTPS FTP UPnP [15] and some customized proto-cols are also observed As shown nearly 60 of the pathsin this category are found to be weakly protected withoutany client authentication leaving them easily exploitable(examples in sect6) By examining the apps in this category wealso identified a mobile-specific open port usage scenariodata sharing in physical proximity eg allowing a userto transfer photo to her PC nearby This usage turns tobring most exploits in this family as shown later in sect624 out of 26 exploits in data sharing are associated withthis particular usage Also worth noting is that in this usagefamily sensitive data can be leaked without invoking anypermission-protected APIs along the tainted path Due toour improvement in sensitive API selection (sect43) our toolcan successfully capture these cases

Proxy path is defined as forwarding requests in remoteinput to other destinations We find that all the paths in theseapps are used as local proxy eg for advertising and contentfiltering For example to overcome the content modificationrestrictions in Android WebView a web browsing app startsas background service a local web proxy so that it can insertits own ads into the fetched web pages If exposed to remoteattackers such local proxy can be used as a reflector intargeted DDoS attacks Also if it is configured to cachepages or store cookies attackers can access personalizedpages to harvest user privacy or even hijack victimrsquos emailor social network accounts for spear phishing attacks

Remote execution path refers to usage paths that cantrigger certain actions on the device such as sending SMS

and writing to storage Besides common use cases suchas push notification we also observe interesting usage inphysical proximity which allows the same user to use mo-bile device functionality through PC interface eg textingSMS using keyboard However there are also sensitive func-tionality that can be executed remotely and are beyond thedeclared functionality of the app which we suspect to beldquobackdoorsrdquo left by app developers

VoIP call paths are used in apps to listen on incomingcall requests based on the Session Initiation Protocol (SIP)After accepting a SIP invite message from the port theapp extracts information such as caller ID and starts thering tone to notify the user Remote attackers in theory cansend spoofed packet to ring the phone and spoof the callerID However due to the IPSec support in SIP such off-pathattack is unlikely to be practical

PhoneGap paths belong to apps developed by Phone-GapCordova a hybrid app development framework al-lowing developers to quickly build apps using JavaScriptand HTML5 It uses open ports to serve requests fromthe JavaScript client and handle the API calls The resultwritten to the incoming socket is not defined in the IDFGof the remote entry point making it difficult for OPAna-lyzer to capture sensitive APIs To address this we usethe presence of several PhoneGap-specific classes such asCallbackServer as the code signatures to identify theseusage paths The port intended for IPC is falsely openedto the Internet However we find that the usage paths ofPhoneGap are protected by strong security checks whichverifies whether the request contains a 128-bit token derived

9

Open port intention Vulnerability description Featured attacks Vulnerable app example App 1

Usage of the app userLack of authentication to verify that Data theft WiFi file transfer 24connections come from the app user Privilege escalation AirDroid PhonePal 10

Communication with Lack of authentication to verify the requests Data theft Lenjoy 15backend are from authentic app backend server Privileged escalation KindeeExpress 5

Local communicationPort used for on-device communication DoS VGet Fast secure VPN 12falsely opened to the network Data theft CachedProxy 1

1 Number of vulnerable apps in the same category An app may be vulnerable to both attacks in each category

TABLE 4 Case study of verified exploitable app categorized by the intended usage of open port

from the devicersquos Universally Unique Identifier (UUID) [1]Thus we consider the open service of PhoneGap as well-protected

53 Security Implications

Usage paths in different families if not well protectedcan lead to different security breaches As shown in table3 OPAnalyzer outputs 956 weak paths We find that nearlyhalf of the total usage paths are considered ldquoweakrdquo In theproxy category over 80 of the paths are not protectedFrom these weak paths we identify three vulnerabilitycategories sensitive data leakage (V1) privileged remoteexecution (V2) and DoS (V3) Besides we also discovera new problem that any open port on smartphones can beexploited to harvest cellular IPv6 addresses which allowsattacker to collect victim IPs without scanning the huge IPv6address space and further launch attack to exploit vulnerableports The vulnerability is detailed in the Appendix A

V1 Sensitive data leakage Sensitive data of a mobiledevice can be retrieved from many sources such as SD Cardsensor etc If these paths are not well protected remoteattacker can exploit them to steal sensitive data that areeven protected by Android permission or UNIX uidgid

check More importantly if the victim IP is public suchvulnerabilities can be easily revealed using fast Internet-wide scanning tools such as ZMap [26] causing large scaledata theft

V2 Privileged remote execution Vulnerable paths thattrigger native actions can be leveraged by remote attackersto execute privileged functionality such as sending SMS andmodifying contacts Moreover by exploiting the broadcast-ing Intent mechanism provided by Android attackers caneven execute functionality beyond the vulnerable app Forexample an unprotected usage path that sends Intent

based on remote input can be leveraged to launch YouTubeapp to play the video from the URL passed by the remoteattacker By uploading a maliciously crafted MP4 file to theURL attacker can gain full control of the device exploitingthe Stagefright vulnerability [6]

V3 Denial of service Most remote execution paths arevulnerable to DoS attack against the device user For thelocal proxy usage paths they can also be used by attackersas reflectors in targeted DDoS attack against victims inthe Internet to hidden their IP addresses Other securityproblems of open proxies such as leaking internal networkdata and IP spoofing based attack also apply

6 Exploits Case Studies

To broaden the scope of our vulnerable study and dis-cover more exploitable open port usage we extended ourdata set to include all the 78K apps from the Tools cate-gory of the PlayDrone dataset to our vulnerability analysisbased on the observation that the percentage of open-portapps in the Tools(109) is significantly higher than theaverage (68) Furthermore we also crawled the top 3000most popular apps from a Chinese app market [2] wherethe Wormhole problem was reported from

By analyzing the annotated usage paths from the OPAna-lyzer output we successfully discover several new exploitsof sensitive data leakage and privileged remote execution inboth apps and third-party libraries including some high-profile ones with millions of downloads and even pre-installed apps Moreover we classify these vulnerable appsinto 3 categories based on the intended usage scenario of theopen port inferred from the manual analysis (1) intendedfor use by app users (2) intended for communication withthe backend and (3) intended for local communicationSuch categorization helps better understand the challengesin securing the port opened for different purposes Table 4shows an overview of the 57 exploitable apps that are man-ually verified from the OPAnalyzer output A case study ofinteresting vulnerability in each category is presented belowThe video demos for some of the implemented attacks areshown on our website [11]

61 Intended for Use by App Users

Such apps open ports for different purposes intendedfor the app users such as transferring file from the phoneto another device of the same user However essentialchecks are found missing in many apps in this category thusexposing the sensitive data and also privileged functionalityof the device to attackers

Virtual data cable is a popular app on China marketthat helps user transfer their photos to PC by opening a webserver on the phone The server port opens by default at applaunch time and silently runs in the background It does notauthenticate clients nor notify incoming connections thuscan be easily scanned and exploited by remote attackersMoreover it does not check the requested file path so thatattacker can access files beyond the photo folder on SD cardby adding ldquordquo to the path and steal sensitive data fromapp cache and system directory Similarly a popular file

10

sharing app WiFi file transfer with 10 million installs doesnot authenticate clients while it opens the server port onlywhen user presses a toggle button However an on-devicemalware that only has Internet permission in our threatmodel can listen on the status of the port by monitoring theproc file system and steal data from the port as long asit is open

PhonePal allows a user to remotely control hisherdevice with a web-browser which contains highly sensitiveusage paths such as open URLs in the Android browserand open videos in the YouTube app All these usage pathsare found unprotected which puts the device at the riskof phishing attack and even compromise [6] Moreovervulnerabilities such as allowing attacker to remotely installapps on the victim device are identified in the high-profileapp AirDroid pre-installed on Samsung Chromebook andSmartisan phone [13] We present a case study of this appin the mitigation strategy section (sect7)

62 Intended for Communication with Backend

Open ports in these apps are intended to communicatewith the app developerrsquos backend server for various pur-poses If the open port service does not authenticate theidentity of the remote server attackers can spoof the appserver Interestingly by manually examining the apps wefind that open port usage of some apps are beyond the appsrsquodeclared functionality implying potentially covert maliciousbehavior

KindeExpress is the most popular mailpackage trackingapp on a China market with 1 million downloads whosefunctionality is to provide tracking information from manydelivery service providers One of its usage path is able tostart an Activity of the app and display the data fromremote input on the apprsquos UI which also brings the app tothe front even when it is running in the background Weverified that none of the declared functionality of the appdepends on this usage path and we suspect it to be usedfor advertising Unfortunately this path is not protected byany authentication mechanism and remote attacker can sendcommand to the app pretending as it comes from the appserver to display deceptive content on the app UI

Huang CheatMaker is a game modifier app that helpsusers cheat when playing mobile games We identified ausage path that accepts data pushed from the app serverstores the data as a shared object (so) file and loadsit at run-time The authentication along the path is weakand the app dynamically loads the code without verifyingwhere it comes from nor its integrity which enables remoteattackers to inject malicious payload to the app to that willbe executed thus compromising the device

63 Intended for Local Communication

Usage paths in Proxy and PhoneGap families are in-tended for on-device communication which can be eitherIPC among different components of an app or proxy fordifferent apps on the device to use However open ports

in some apps that are intended for local usage are falselyexposed to the network and thus lead to security breaches

OpenVPN is an open-source VPN implementation thatis integrated by several popular VPN apps on Google PlayMultiple interfaces are provided by OpenVPN for the appto configure the local VPN settings while the open TCPport interface is identified to be the least secure one Aremote attacker can DoS the victim user by changing proxysettings such as port number on the device Fortunatelysome app developers paid extra attention when integratingOpenVPN and closed the insecure configuration interfacefrom the open TCP port but VPN apps vulnerable to thisproblem still remain (eg Fast secure VPN)

CacheProxy is an app that opens local proxy with thecapability of caching the web page content Upon receivinga request the proxy first checks whether the request can beserved using cached content before fetching the page withno authentication performed on the source of the incomingrequest Remote attackers can thus easily access sensitiveinformation of the victim such as e-mails by requesting thee-mail page since the page is retrieved from the cache forthe attacker

To get an initial estimate on the severity of open portvulnerabilities in the wild we performed a small scale portscan in a subnet of a campus network The ports scannedare those opened by the most popular vulnerable apps inour dataset whose port number needs to be static andunique Note that we only scanned for the existence ofthe open ports but did not send any data to the ports toverify the vulnerability for ethical concerns We performedonly one scan using a scanning tool [26] which finished intwo minutes Surprisingly 40 hosts identified to be mobiledevices open such ports Although different apps that usethe same port number may introduce false positives thescanning result indicates that immediately exploitable openports exist in the wild

7 Mitigation Strategy

Traditional solutions to protect an open port fromInternet attackers are through firewall which monitors andcontrols incoming and outgoing traffic based on prede-termined security policies However the firewall solutionsuffers from usability in the mobile context since it ishard for individual users to configure suitable firewall rulesfor each app installed on the device and coordinate bothapp functionality and security assurance Moreover in thephysical proximity use scenario since users can initiateconnections from arbitrary hosts it is hard to configure rulesin advance

Despite a variety of open port usage described thefundamental problem is the lack of proper client authen-tications However we find that it is non-trivial to provide ageneral solution to patch the security problems for all usagecases while preserving usability We discuss the major chal-lenges in different scenarios and propose countermeasures

Intended for communication with backend For theopen port mobile app to verify that the incoming connection

11

is from the authentic server we suggest using secure tokensto perform authentication Although tokens are already usedin some open port apps implementation flaws are commonlyseen For example a third-party push notification servicethat distributes token to app developers for them to embedin the app is vulnerable because the token can be extractedfrom the released app binary by attacker to exploit the vul-nerable app installed on other victim devices We suggest theapp and server negotiate a shared token using mechanismssuch as Diffie-Hellman [7] at app launching time And openport app uses the token to authenticate further incomingconnections

Intended for use by app users Compared to theprevious usage scenario open port apps in this case do notknow in advance the legitimate remote hosts that shouldconnect to them Depending on the usage of the app userthe trusted remote hosts can be userrsquos desktop or even hisfriendrsquos laptop A general solution is to use password or pincode to authenticate incoming connections however somesecurity issues are raised in practice As an example allthe apps we examined that use password provide hard-codedefault password that does not require users to change beforeusing the app leading to the potential use of the defaultpassword and degrading app security Randomly generatedpin codes in the open port apps we examined are usuallyno longer than 4 characters which is trivial to enumerateExperiment in our local WiFi network indicates that it takesless than 5 minutes to send probing requests that enumerateall the 4-character strings

Another authentication solution adopted by the toptrending apps for this usage scenario is the incoming con-nection notification which pops up a window when a newhost connects to the open port and displays the IP addressof the host And the request is not served until user explic-itly accepts the client by clicking the ldquoallowrdquo button Forordinary users the timing of the pop-up window is also animportant indicator for them to make the decision of whetherto allow or deny the request However on-device malwarecan infer the timing when there is an incoming connection tothe port by monitoring procnet[tcp][tcp6] andsend request immediately to trick user into also allowing itsconnection by overlaying the pop-up window We furtherfind that even the most popular apps in this category hasimplementation flaws that can be practically exploited byattackers in our threat model

AirDroid1 is a top-ranked app on the market that allowsusers to access and manage their Android device wirelesslyfrom desktop by opening a server on the phone It providesa rich set of functionality to users such as access cameraand install apps remotely and uses the incoming connectionnotification schema to authenticate client However if thetiming of user initiated connection is inferred by the attackerwith the help of an on-device malware and attacker sendsrequest to the open port before the user accepts the previousconnection the app wonrsquot pop up another window Insteadthe attacker connection silently replaces the previous legit-

1 AirDroid httpswwwairdroidcom

ServerSocket

SecureServerSocket Remote client

Requestfrom IP0

Return IP0

as QR code

Scan

Trust IP0

Requestfrom IP0

Return

Socket Socket

Display

Check IP0

Figure 8 SecureServerSocket design

imate connection in the waiting queue without changingthe IP address displayed on the pop-up window And whena user clicks the button to allow the legitimate connectionthe attacker client is allowed instead and numerous sensitivecapabilities of AirDroid are granted to the attacker

Usage in this category is usually for the cable-less com-munication with nearby hosts of the user We confirmed that24 out of the 26 vulnerable apps in this category are intendedfor the use in physical proximity We demonstrate a transpar-ent socket-level solution that addresses the security and us-ability challenges in this usage scenario Shown in Figure 8we provide SecureServerSocket which encapsulatesthe Android ServerSocket API to accept incoming sock-ets When a remote client the userrsquos desktop for exampletries to connect to the port the SecureServerSocket

first puts the connection on hold and then encodes the IPaddress of the client into a QR code and returns to theremote client The remote client is required to display theQR code and let the user scan it using the mobile device inorder to get access

Once the QR code is scanned the decoded IP addressis returned to the SecureServerSocket and the con-nection from this IP is allowed It then returns the incom-ing socket to the upper application layer to be handledThis approach authenticates clients on the IP layer andensures that the open port only serves clients in physicalproximity of the device user and it achieves both securityand usability We provide SecureServerSocket as alibrary that app developers can simply use as a replacementof ServerSocket No changes on the client side arerequired if the client is a web browser which is the commoncase in our app dataset For other client types that cannotdisplay QR code we suggest using one-time pin code to dothe authentication instead Demo of the SecureServerSocketimplementation can also be found on our website [11] Andfor future work we plan to conduct a user study to evaluatethe effectiveness of this approach

Intended for local communication For the local usageof on-device proxy the best practice is to bind the proxy tothe loopback address of the device which makes the serviceunreachable from the network For another local usage

12

Wormhole family Sample app Version Entry points Usage path Weak path Not weak path

total exploitable total exploitable

Baidu combaiduBaiduMap 850 1 15 8 8 7 0

Tencent comtencentandroidqqdownloader 570 4 16 1 1 15 1

AMap comautonaviminimap 734 1 4 0 0 4 3

TABLE 1 OPAnalyzer output for three popular ldquoWormholerdquo apps that are reported vulnerable

Feature of usage

Improv Featured applibpaths captured

none 636 NA WiFi file transfer

+ reflection 804 +26 OpenVPN

+ API 1472 +131 AMap

+ native 845 +33 Tencent XG

+ all 1934 +204 Baidu wormhole

TABLE 2 Evaluation of accumulative improvement broughtby (1) handling explicit Java reflection and (2) adding open-port specific sensitive API (3) capturing native code jump

the usage path is propagated to this procedure if it isdefined beyond the IDFG of the entry point This affects theaccuracy of the information leakage tracking and constraintsanalysis and can be solved by integrating backward slicingtechnique [20] [48] We plan to add that to the OPAnalyzerin the future

False negatives may also be introduced by the na-tive code analyzer due to a limitation inherited from theIDA-PRO front end ARM processor supports multiple in-teraction sets mixed in one segment in the runtime whilethe disassembler can interpret one type at the same time inthe static analysis [3] And when the 16-bit ldquoThumbrdquo and32-bit ldquoARMrdquo instructions coexist within one segment dueto optimization the disassembling result may be incorrectAdditionally the native code analysis of OPAnalyzer doesnot cover all possible types of interactions between nativecode and Java code Combining native code and Java codeanalysis is a fundamental challenge of Android app analy-sis [38] and we leave it as future work to accurately modelall the control- and data-flow transitions between native andJava layers

We also evaluate the improvement on the effectiveness ofOPAnalyzerrsquos path discovery brought by three of our engi-neering efforts namely (1) adding open-port specific APIs tothe sensitive API set (2) handling explicit Java reflectionsand (3) capturing native code jump Shown in Table 2integrating these features greatly improves the coverage ofOPAnalyzer by 204 while completing the sensitive APIset turns out to be the most effective engineering effort wespent These improvements reduce false negatives which iscrucial to our system

Performance The most compute-intensive step in OP-Analyzer is the taint analysis which includes building theIDFG and DDG and running the Dijkstrarsquos algorithm on theDDG to find all the usage paths We measure the time toperform the taint analysis for the top 1000 popular apps fromour dataset The experiment runs on a machine with IntelCore i5-3470 CPU and 8GB of RAM For apps with at least

one entry point the median processing time for OPAnalyzerto finish the taint analysis is 615 seconds with standarddeviation of 1272

5 Usage and Vulnerability

With the usage paths output from OPAnalyzer we sys-tematically study open port usage and their security impli-cations in the top 1000 popular apps from each of the 24different categories on Google play

51 Popularity and Permission Usage

Among the 24000 apps we identified open port func-tionality in 68 (1632) while 50 of these open port appshave more than 500K downloads

Sensitive permission usage To understand the mostcommon functionality triggered by remote input we usethe API to permission mappings constructed in sect43 to getthe set of sensitive permissions Figure 7 shows the topsecurity-sensitive permissions involved in open port usageSurprisingly we find that in open port apps a rich set ofhighly-sensitive OS-level functions in Android can be in-voked remotely ranging from accessing private data such ascontacts and location to performing sensitive actions such asusing camera and sending SMS If not protected sufficientlythis usage can be remotely exploited to cause severe dam-ages such as privacy leakage and privileged code executionsjust like the recently reported Wormhole exploits [12] Inaddition we find that the pseudo permission DATA_LEAK

(defined in sect43) which indicates that data is read fromasynchronous sources such as internal storage or contentproviders and sent to the remote end has top popularity inopen-port apps This shows that open port usage commonlyhas potential risk of exposing internal application data to theremote attacker which typically involves plenty of sensitivedata such as credentials and conversation history [51]

52 Usage Family Categorization

Using OPAnalyzer we categorize usage paths into differ-ent usage families defined by code patterns Table 3 showsthe 5 major usage families we identified in our datasettogether with the path categorization results and the typesof potentially-exposed vulnerabilities As shown 99 ofreachable usage paths of open port apps are categorized intoone of the five families which are described in detail asfollows

Data sharing path a usage path through which data readfrom the device is sent to the remote host In this category

8

0

5

10

15

20

25

WRITE_EXTERNAL_STORAGE

C2DM_RECEIVE

DATA_LEAK

ACCESS_COARSE_LOCATION

ACCESS_FINE_LOCATION

GET_TASK

CAMERA

READ_CONTACTS

DISABLE_KEY_GUARD

WRITE_SETTING

RECORD_AUDIO

CALL_PHONE

SEND_SMS

o

f o

pe

n p

ort

ap

ps

Sensitive permissions

Figure 7 Permission protected APIs triggered by remote input

Usage category Pattern Usage path Perc App Weak path Vulnerability

Data sharing accept()Iminusrarr APIdata read

Eminusrarr write() 1340 693 425 775 V1

Proxy accept()Eminusrarr APIout connection 122 63 59 101 V1V3

Remote execution accept()I or Eminusminusminusminusrarr APIexecution 127 65 41 69 V2V3

VoIP call accept()Iminusrarr APIaudio setting 45 23 27 11 V3

PhoneGap Categorized using code signature 282 146 141 0 NA

Uncategorized NA 18 09 10 0 NA

TABLE 3 Open port usage and potential vulnerability V1sensitive data leakage V2 privileged remote execution V3 DoS

the most commonly used protocol for data sharing is HTTPwhile HTTPS FTP UPnP [15] and some customized proto-cols are also observed As shown nearly 60 of the pathsin this category are found to be weakly protected withoutany client authentication leaving them easily exploitable(examples in sect6) By examining the apps in this category wealso identified a mobile-specific open port usage scenariodata sharing in physical proximity eg allowing a userto transfer photo to her PC nearby This usage turns tobring most exploits in this family as shown later in sect624 out of 26 exploits in data sharing are associated withthis particular usage Also worth noting is that in this usagefamily sensitive data can be leaked without invoking anypermission-protected APIs along the tainted path Due toour improvement in sensitive API selection (sect43) our toolcan successfully capture these cases

Proxy path is defined as forwarding requests in remoteinput to other destinations We find that all the paths in theseapps are used as local proxy eg for advertising and contentfiltering For example to overcome the content modificationrestrictions in Android WebView a web browsing app startsas background service a local web proxy so that it can insertits own ads into the fetched web pages If exposed to remoteattackers such local proxy can be used as a reflector intargeted DDoS attacks Also if it is configured to cachepages or store cookies attackers can access personalizedpages to harvest user privacy or even hijack victimrsquos emailor social network accounts for spear phishing attacks

Remote execution path refers to usage paths that cantrigger certain actions on the device such as sending SMS

and writing to storage Besides common use cases suchas push notification we also observe interesting usage inphysical proximity which allows the same user to use mo-bile device functionality through PC interface eg textingSMS using keyboard However there are also sensitive func-tionality that can be executed remotely and are beyond thedeclared functionality of the app which we suspect to beldquobackdoorsrdquo left by app developers

VoIP call paths are used in apps to listen on incomingcall requests based on the Session Initiation Protocol (SIP)After accepting a SIP invite message from the port theapp extracts information such as caller ID and starts thering tone to notify the user Remote attackers in theory cansend spoofed packet to ring the phone and spoof the callerID However due to the IPSec support in SIP such off-pathattack is unlikely to be practical

PhoneGap paths belong to apps developed by Phone-GapCordova a hybrid app development framework al-lowing developers to quickly build apps using JavaScriptand HTML5 It uses open ports to serve requests fromthe JavaScript client and handle the API calls The resultwritten to the incoming socket is not defined in the IDFGof the remote entry point making it difficult for OPAna-lyzer to capture sensitive APIs To address this we usethe presence of several PhoneGap-specific classes such asCallbackServer as the code signatures to identify theseusage paths The port intended for IPC is falsely openedto the Internet However we find that the usage paths ofPhoneGap are protected by strong security checks whichverifies whether the request contains a 128-bit token derived

9

Open port intention Vulnerability description Featured attacks Vulnerable app example App 1

Usage of the app userLack of authentication to verify that Data theft WiFi file transfer 24connections come from the app user Privilege escalation AirDroid PhonePal 10

Communication with Lack of authentication to verify the requests Data theft Lenjoy 15backend are from authentic app backend server Privileged escalation KindeeExpress 5

Local communicationPort used for on-device communication DoS VGet Fast secure VPN 12falsely opened to the network Data theft CachedProxy 1

1 Number of vulnerable apps in the same category An app may be vulnerable to both attacks in each category

TABLE 4 Case study of verified exploitable app categorized by the intended usage of open port

from the devicersquos Universally Unique Identifier (UUID) [1]Thus we consider the open service of PhoneGap as well-protected

53 Security Implications

Usage paths in different families if not well protectedcan lead to different security breaches As shown in table3 OPAnalyzer outputs 956 weak paths We find that nearlyhalf of the total usage paths are considered ldquoweakrdquo In theproxy category over 80 of the paths are not protectedFrom these weak paths we identify three vulnerabilitycategories sensitive data leakage (V1) privileged remoteexecution (V2) and DoS (V3) Besides we also discovera new problem that any open port on smartphones can beexploited to harvest cellular IPv6 addresses which allowsattacker to collect victim IPs without scanning the huge IPv6address space and further launch attack to exploit vulnerableports The vulnerability is detailed in the Appendix A

V1 Sensitive data leakage Sensitive data of a mobiledevice can be retrieved from many sources such as SD Cardsensor etc If these paths are not well protected remoteattacker can exploit them to steal sensitive data that areeven protected by Android permission or UNIX uidgid

check More importantly if the victim IP is public suchvulnerabilities can be easily revealed using fast Internet-wide scanning tools such as ZMap [26] causing large scaledata theft

V2 Privileged remote execution Vulnerable paths thattrigger native actions can be leveraged by remote attackersto execute privileged functionality such as sending SMS andmodifying contacts Moreover by exploiting the broadcast-ing Intent mechanism provided by Android attackers caneven execute functionality beyond the vulnerable app Forexample an unprotected usage path that sends Intent

based on remote input can be leveraged to launch YouTubeapp to play the video from the URL passed by the remoteattacker By uploading a maliciously crafted MP4 file to theURL attacker can gain full control of the device exploitingthe Stagefright vulnerability [6]

V3 Denial of service Most remote execution paths arevulnerable to DoS attack against the device user For thelocal proxy usage paths they can also be used by attackersas reflectors in targeted DDoS attack against victims inthe Internet to hidden their IP addresses Other securityproblems of open proxies such as leaking internal networkdata and IP spoofing based attack also apply

6 Exploits Case Studies

To broaden the scope of our vulnerable study and dis-cover more exploitable open port usage we extended ourdata set to include all the 78K apps from the Tools cate-gory of the PlayDrone dataset to our vulnerability analysisbased on the observation that the percentage of open-portapps in the Tools(109) is significantly higher than theaverage (68) Furthermore we also crawled the top 3000most popular apps from a Chinese app market [2] wherethe Wormhole problem was reported from

By analyzing the annotated usage paths from the OPAna-lyzer output we successfully discover several new exploitsof sensitive data leakage and privileged remote execution inboth apps and third-party libraries including some high-profile ones with millions of downloads and even pre-installed apps Moreover we classify these vulnerable appsinto 3 categories based on the intended usage scenario of theopen port inferred from the manual analysis (1) intendedfor use by app users (2) intended for communication withthe backend and (3) intended for local communicationSuch categorization helps better understand the challengesin securing the port opened for different purposes Table 4shows an overview of the 57 exploitable apps that are man-ually verified from the OPAnalyzer output A case study ofinteresting vulnerability in each category is presented belowThe video demos for some of the implemented attacks areshown on our website [11]

61 Intended for Use by App Users

Such apps open ports for different purposes intendedfor the app users such as transferring file from the phoneto another device of the same user However essentialchecks are found missing in many apps in this category thusexposing the sensitive data and also privileged functionalityof the device to attackers

Virtual data cable is a popular app on China marketthat helps user transfer their photos to PC by opening a webserver on the phone The server port opens by default at applaunch time and silently runs in the background It does notauthenticate clients nor notify incoming connections thuscan be easily scanned and exploited by remote attackersMoreover it does not check the requested file path so thatattacker can access files beyond the photo folder on SD cardby adding ldquordquo to the path and steal sensitive data fromapp cache and system directory Similarly a popular file

10

sharing app WiFi file transfer with 10 million installs doesnot authenticate clients while it opens the server port onlywhen user presses a toggle button However an on-devicemalware that only has Internet permission in our threatmodel can listen on the status of the port by monitoring theproc file system and steal data from the port as long asit is open

PhonePal allows a user to remotely control hisherdevice with a web-browser which contains highly sensitiveusage paths such as open URLs in the Android browserand open videos in the YouTube app All these usage pathsare found unprotected which puts the device at the riskof phishing attack and even compromise [6] Moreovervulnerabilities such as allowing attacker to remotely installapps on the victim device are identified in the high-profileapp AirDroid pre-installed on Samsung Chromebook andSmartisan phone [13] We present a case study of this appin the mitigation strategy section (sect7)

62 Intended for Communication with Backend

Open ports in these apps are intended to communicatewith the app developerrsquos backend server for various pur-poses If the open port service does not authenticate theidentity of the remote server attackers can spoof the appserver Interestingly by manually examining the apps wefind that open port usage of some apps are beyond the appsrsquodeclared functionality implying potentially covert maliciousbehavior

KindeExpress is the most popular mailpackage trackingapp on a China market with 1 million downloads whosefunctionality is to provide tracking information from manydelivery service providers One of its usage path is able tostart an Activity of the app and display the data fromremote input on the apprsquos UI which also brings the app tothe front even when it is running in the background Weverified that none of the declared functionality of the appdepends on this usage path and we suspect it to be usedfor advertising Unfortunately this path is not protected byany authentication mechanism and remote attacker can sendcommand to the app pretending as it comes from the appserver to display deceptive content on the app UI

Huang CheatMaker is a game modifier app that helpsusers cheat when playing mobile games We identified ausage path that accepts data pushed from the app serverstores the data as a shared object (so) file and loadsit at run-time The authentication along the path is weakand the app dynamically loads the code without verifyingwhere it comes from nor its integrity which enables remoteattackers to inject malicious payload to the app to that willbe executed thus compromising the device

63 Intended for Local Communication

Usage paths in Proxy and PhoneGap families are in-tended for on-device communication which can be eitherIPC among different components of an app or proxy fordifferent apps on the device to use However open ports

in some apps that are intended for local usage are falselyexposed to the network and thus lead to security breaches

OpenVPN is an open-source VPN implementation thatis integrated by several popular VPN apps on Google PlayMultiple interfaces are provided by OpenVPN for the appto configure the local VPN settings while the open TCPport interface is identified to be the least secure one Aremote attacker can DoS the victim user by changing proxysettings such as port number on the device Fortunatelysome app developers paid extra attention when integratingOpenVPN and closed the insecure configuration interfacefrom the open TCP port but VPN apps vulnerable to thisproblem still remain (eg Fast secure VPN)

CacheProxy is an app that opens local proxy with thecapability of caching the web page content Upon receivinga request the proxy first checks whether the request can beserved using cached content before fetching the page withno authentication performed on the source of the incomingrequest Remote attackers can thus easily access sensitiveinformation of the victim such as e-mails by requesting thee-mail page since the page is retrieved from the cache forthe attacker

To get an initial estimate on the severity of open portvulnerabilities in the wild we performed a small scale portscan in a subnet of a campus network The ports scannedare those opened by the most popular vulnerable apps inour dataset whose port number needs to be static andunique Note that we only scanned for the existence ofthe open ports but did not send any data to the ports toverify the vulnerability for ethical concerns We performedonly one scan using a scanning tool [26] which finished intwo minutes Surprisingly 40 hosts identified to be mobiledevices open such ports Although different apps that usethe same port number may introduce false positives thescanning result indicates that immediately exploitable openports exist in the wild

7 Mitigation Strategy

Traditional solutions to protect an open port fromInternet attackers are through firewall which monitors andcontrols incoming and outgoing traffic based on prede-termined security policies However the firewall solutionsuffers from usability in the mobile context since it ishard for individual users to configure suitable firewall rulesfor each app installed on the device and coordinate bothapp functionality and security assurance Moreover in thephysical proximity use scenario since users can initiateconnections from arbitrary hosts it is hard to configure rulesin advance

Despite a variety of open port usage described thefundamental problem is the lack of proper client authen-tications However we find that it is non-trivial to provide ageneral solution to patch the security problems for all usagecases while preserving usability We discuss the major chal-lenges in different scenarios and propose countermeasures

Intended for communication with backend For theopen port mobile app to verify that the incoming connection

11

is from the authentic server we suggest using secure tokensto perform authentication Although tokens are already usedin some open port apps implementation flaws are commonlyseen For example a third-party push notification servicethat distributes token to app developers for them to embedin the app is vulnerable because the token can be extractedfrom the released app binary by attacker to exploit the vul-nerable app installed on other victim devices We suggest theapp and server negotiate a shared token using mechanismssuch as Diffie-Hellman [7] at app launching time And openport app uses the token to authenticate further incomingconnections

Intended for use by app users Compared to theprevious usage scenario open port apps in this case do notknow in advance the legitimate remote hosts that shouldconnect to them Depending on the usage of the app userthe trusted remote hosts can be userrsquos desktop or even hisfriendrsquos laptop A general solution is to use password or pincode to authenticate incoming connections however somesecurity issues are raised in practice As an example allthe apps we examined that use password provide hard-codedefault password that does not require users to change beforeusing the app leading to the potential use of the defaultpassword and degrading app security Randomly generatedpin codes in the open port apps we examined are usuallyno longer than 4 characters which is trivial to enumerateExperiment in our local WiFi network indicates that it takesless than 5 minutes to send probing requests that enumerateall the 4-character strings

Another authentication solution adopted by the toptrending apps for this usage scenario is the incoming con-nection notification which pops up a window when a newhost connects to the open port and displays the IP addressof the host And the request is not served until user explic-itly accepts the client by clicking the ldquoallowrdquo button Forordinary users the timing of the pop-up window is also animportant indicator for them to make the decision of whetherto allow or deny the request However on-device malwarecan infer the timing when there is an incoming connection tothe port by monitoring procnet[tcp][tcp6] andsend request immediately to trick user into also allowing itsconnection by overlaying the pop-up window We furtherfind that even the most popular apps in this category hasimplementation flaws that can be practically exploited byattackers in our threat model

AirDroid1 is a top-ranked app on the market that allowsusers to access and manage their Android device wirelesslyfrom desktop by opening a server on the phone It providesa rich set of functionality to users such as access cameraand install apps remotely and uses the incoming connectionnotification schema to authenticate client However if thetiming of user initiated connection is inferred by the attackerwith the help of an on-device malware and attacker sendsrequest to the open port before the user accepts the previousconnection the app wonrsquot pop up another window Insteadthe attacker connection silently replaces the previous legit-

1 AirDroid httpswwwairdroidcom

ServerSocket

SecureServerSocket Remote client

Requestfrom IP0

Return IP0

as QR code

Scan

Trust IP0

Requestfrom IP0

Return

Socket Socket

Display

Check IP0

Figure 8 SecureServerSocket design

imate connection in the waiting queue without changingthe IP address displayed on the pop-up window And whena user clicks the button to allow the legitimate connectionthe attacker client is allowed instead and numerous sensitivecapabilities of AirDroid are granted to the attacker

Usage in this category is usually for the cable-less com-munication with nearby hosts of the user We confirmed that24 out of the 26 vulnerable apps in this category are intendedfor the use in physical proximity We demonstrate a transpar-ent socket-level solution that addresses the security and us-ability challenges in this usage scenario Shown in Figure 8we provide SecureServerSocket which encapsulatesthe Android ServerSocket API to accept incoming sock-ets When a remote client the userrsquos desktop for exampletries to connect to the port the SecureServerSocket

first puts the connection on hold and then encodes the IPaddress of the client into a QR code and returns to theremote client The remote client is required to display theQR code and let the user scan it using the mobile device inorder to get access

Once the QR code is scanned the decoded IP addressis returned to the SecureServerSocket and the con-nection from this IP is allowed It then returns the incom-ing socket to the upper application layer to be handledThis approach authenticates clients on the IP layer andensures that the open port only serves clients in physicalproximity of the device user and it achieves both securityand usability We provide SecureServerSocket as alibrary that app developers can simply use as a replacementof ServerSocket No changes on the client side arerequired if the client is a web browser which is the commoncase in our app dataset For other client types that cannotdisplay QR code we suggest using one-time pin code to dothe authentication instead Demo of the SecureServerSocketimplementation can also be found on our website [11] Andfor future work we plan to conduct a user study to evaluatethe effectiveness of this approach

Intended for local communication For the local usageof on-device proxy the best practice is to bind the proxy tothe loopback address of the device which makes the serviceunreachable from the network For another local usage

12

0

5

10

15

20

25

WRITE_EXTERNAL_STORAGE

C2DM_RECEIVE

DATA_LEAK

ACCESS_COARSE_LOCATION

ACCESS_FINE_LOCATION

GET_TASK

CAMERA

READ_CONTACTS

DISABLE_KEY_GUARD

WRITE_SETTING

RECORD_AUDIO

CALL_PHONE

SEND_SMS

o

f o

pe

n p

ort

ap

ps

Sensitive permissions

Figure 7 Permission protected APIs triggered by remote input

Usage category Pattern Usage path Perc App Weak path Vulnerability

Data sharing accept()Iminusrarr APIdata read

Eminusrarr write() 1340 693 425 775 V1

Proxy accept()Eminusrarr APIout connection 122 63 59 101 V1V3

Remote execution accept()I or Eminusminusminusminusrarr APIexecution 127 65 41 69 V2V3

VoIP call accept()Iminusrarr APIaudio setting 45 23 27 11 V3

PhoneGap Categorized using code signature 282 146 141 0 NA

Uncategorized NA 18 09 10 0 NA

TABLE 3 Open port usage and potential vulnerability V1sensitive data leakage V2 privileged remote execution V3 DoS

the most commonly used protocol for data sharing is HTTPwhile HTTPS FTP UPnP [15] and some customized proto-cols are also observed As shown nearly 60 of the pathsin this category are found to be weakly protected withoutany client authentication leaving them easily exploitable(examples in sect6) By examining the apps in this category wealso identified a mobile-specific open port usage scenariodata sharing in physical proximity eg allowing a userto transfer photo to her PC nearby This usage turns tobring most exploits in this family as shown later in sect624 out of 26 exploits in data sharing are associated withthis particular usage Also worth noting is that in this usagefamily sensitive data can be leaked without invoking anypermission-protected APIs along the tainted path Due toour improvement in sensitive API selection (sect43) our toolcan successfully capture these cases

Proxy path is defined as forwarding requests in remoteinput to other destinations We find that all the paths in theseapps are used as local proxy eg for advertising and contentfiltering For example to overcome the content modificationrestrictions in Android WebView a web browsing app startsas background service a local web proxy so that it can insertits own ads into the fetched web pages If exposed to remoteattackers such local proxy can be used as a reflector intargeted DDoS attacks Also if it is configured to cachepages or store cookies attackers can access personalizedpages to harvest user privacy or even hijack victimrsquos emailor social network accounts for spear phishing attacks

Remote execution path refers to usage paths that cantrigger certain actions on the device such as sending SMS

and writing to storage Besides common use cases suchas push notification we also observe interesting usage inphysical proximity which allows the same user to use mo-bile device functionality through PC interface eg textingSMS using keyboard However there are also sensitive func-tionality that can be executed remotely and are beyond thedeclared functionality of the app which we suspect to beldquobackdoorsrdquo left by app developers

VoIP call paths are used in apps to listen on incomingcall requests based on the Session Initiation Protocol (SIP)After accepting a SIP invite message from the port theapp extracts information such as caller ID and starts thering tone to notify the user Remote attackers in theory cansend spoofed packet to ring the phone and spoof the callerID However due to the IPSec support in SIP such off-pathattack is unlikely to be practical

PhoneGap paths belong to apps developed by Phone-GapCordova a hybrid app development framework al-lowing developers to quickly build apps using JavaScriptand HTML5 It uses open ports to serve requests fromthe JavaScript client and handle the API calls The resultwritten to the incoming socket is not defined in the IDFGof the remote entry point making it difficult for OPAna-lyzer to capture sensitive APIs To address this we usethe presence of several PhoneGap-specific classes such asCallbackServer as the code signatures to identify theseusage paths The port intended for IPC is falsely openedto the Internet However we find that the usage paths ofPhoneGap are protected by strong security checks whichverifies whether the request contains a 128-bit token derived

9

Open port intention Vulnerability description Featured attacks Vulnerable app example App 1

Usage of the app userLack of authentication to verify that Data theft WiFi file transfer 24connections come from the app user Privilege escalation AirDroid PhonePal 10

Communication with Lack of authentication to verify the requests Data theft Lenjoy 15backend are from authentic app backend server Privileged escalation KindeeExpress 5

Local communicationPort used for on-device communication DoS VGet Fast secure VPN 12falsely opened to the network Data theft CachedProxy 1

1 Number of vulnerable apps in the same category An app may be vulnerable to both attacks in each category

TABLE 4 Case study of verified exploitable app categorized by the intended usage of open port

from the devicersquos Universally Unique Identifier (UUID) [1]Thus we consider the open service of PhoneGap as well-protected

53 Security Implications

Usage paths in different families if not well protectedcan lead to different security breaches As shown in table3 OPAnalyzer outputs 956 weak paths We find that nearlyhalf of the total usage paths are considered ldquoweakrdquo In theproxy category over 80 of the paths are not protectedFrom these weak paths we identify three vulnerabilitycategories sensitive data leakage (V1) privileged remoteexecution (V2) and DoS (V3) Besides we also discovera new problem that any open port on smartphones can beexploited to harvest cellular IPv6 addresses which allowsattacker to collect victim IPs without scanning the huge IPv6address space and further launch attack to exploit vulnerableports The vulnerability is detailed in the Appendix A

V1 Sensitive data leakage Sensitive data of a mobiledevice can be retrieved from many sources such as SD Cardsensor etc If these paths are not well protected remoteattacker can exploit them to steal sensitive data that areeven protected by Android permission or UNIX uidgid

check More importantly if the victim IP is public suchvulnerabilities can be easily revealed using fast Internet-wide scanning tools such as ZMap [26] causing large scaledata theft

V2 Privileged remote execution Vulnerable paths thattrigger native actions can be leveraged by remote attackersto execute privileged functionality such as sending SMS andmodifying contacts Moreover by exploiting the broadcast-ing Intent mechanism provided by Android attackers caneven execute functionality beyond the vulnerable app Forexample an unprotected usage path that sends Intent

based on remote input can be leveraged to launch YouTubeapp to play the video from the URL passed by the remoteattacker By uploading a maliciously crafted MP4 file to theURL attacker can gain full control of the device exploitingthe Stagefright vulnerability [6]

V3 Denial of service Most remote execution paths arevulnerable to DoS attack against the device user For thelocal proxy usage paths they can also be used by attackersas reflectors in targeted DDoS attack against victims inthe Internet to hidden their IP addresses Other securityproblems of open proxies such as leaking internal networkdata and IP spoofing based attack also apply

6 Exploits Case Studies

To broaden the scope of our vulnerable study and dis-cover more exploitable open port usage we extended ourdata set to include all the 78K apps from the Tools cate-gory of the PlayDrone dataset to our vulnerability analysisbased on the observation that the percentage of open-portapps in the Tools(109) is significantly higher than theaverage (68) Furthermore we also crawled the top 3000most popular apps from a Chinese app market [2] wherethe Wormhole problem was reported from

By analyzing the annotated usage paths from the OPAna-lyzer output we successfully discover several new exploitsof sensitive data leakage and privileged remote execution inboth apps and third-party libraries including some high-profile ones with millions of downloads and even pre-installed apps Moreover we classify these vulnerable appsinto 3 categories based on the intended usage scenario of theopen port inferred from the manual analysis (1) intendedfor use by app users (2) intended for communication withthe backend and (3) intended for local communicationSuch categorization helps better understand the challengesin securing the port opened for different purposes Table 4shows an overview of the 57 exploitable apps that are man-ually verified from the OPAnalyzer output A case study ofinteresting vulnerability in each category is presented belowThe video demos for some of the implemented attacks areshown on our website [11]

61 Intended for Use by App Users

Such apps open ports for different purposes intendedfor the app users such as transferring file from the phoneto another device of the same user However essentialchecks are found missing in many apps in this category thusexposing the sensitive data and also privileged functionalityof the device to attackers

Virtual data cable is a popular app on China marketthat helps user transfer their photos to PC by opening a webserver on the phone The server port opens by default at applaunch time and silently runs in the background It does notauthenticate clients nor notify incoming connections thuscan be easily scanned and exploited by remote attackersMoreover it does not check the requested file path so thatattacker can access files beyond the photo folder on SD cardby adding ldquordquo to the path and steal sensitive data fromapp cache and system directory Similarly a popular file

10

sharing app WiFi file transfer with 10 million installs doesnot authenticate clients while it opens the server port onlywhen user presses a toggle button However an on-devicemalware that only has Internet permission in our threatmodel can listen on the status of the port by monitoring theproc file system and steal data from the port as long asit is open

PhonePal allows a user to remotely control hisherdevice with a web-browser which contains highly sensitiveusage paths such as open URLs in the Android browserand open videos in the YouTube app All these usage pathsare found unprotected which puts the device at the riskof phishing attack and even compromise [6] Moreovervulnerabilities such as allowing attacker to remotely installapps on the victim device are identified in the high-profileapp AirDroid pre-installed on Samsung Chromebook andSmartisan phone [13] We present a case study of this appin the mitigation strategy section (sect7)

62 Intended for Communication with Backend

Open ports in these apps are intended to communicatewith the app developerrsquos backend server for various pur-poses If the open port service does not authenticate theidentity of the remote server attackers can spoof the appserver Interestingly by manually examining the apps wefind that open port usage of some apps are beyond the appsrsquodeclared functionality implying potentially covert maliciousbehavior

KindeExpress is the most popular mailpackage trackingapp on a China market with 1 million downloads whosefunctionality is to provide tracking information from manydelivery service providers One of its usage path is able tostart an Activity of the app and display the data fromremote input on the apprsquos UI which also brings the app tothe front even when it is running in the background Weverified that none of the declared functionality of the appdepends on this usage path and we suspect it to be usedfor advertising Unfortunately this path is not protected byany authentication mechanism and remote attacker can sendcommand to the app pretending as it comes from the appserver to display deceptive content on the app UI

Huang CheatMaker is a game modifier app that helpsusers cheat when playing mobile games We identified ausage path that accepts data pushed from the app serverstores the data as a shared object (so) file and loadsit at run-time The authentication along the path is weakand the app dynamically loads the code without verifyingwhere it comes from nor its integrity which enables remoteattackers to inject malicious payload to the app to that willbe executed thus compromising the device

63 Intended for Local Communication

Usage paths in Proxy and PhoneGap families are in-tended for on-device communication which can be eitherIPC among different components of an app or proxy fordifferent apps on the device to use However open ports

in some apps that are intended for local usage are falselyexposed to the network and thus lead to security breaches

OpenVPN is an open-source VPN implementation thatis integrated by several popular VPN apps on Google PlayMultiple interfaces are provided by OpenVPN for the appto configure the local VPN settings while the open TCPport interface is identified to be the least secure one Aremote attacker can DoS the victim user by changing proxysettings such as port number on the device Fortunatelysome app developers paid extra attention when integratingOpenVPN and closed the insecure configuration interfacefrom the open TCP port but VPN apps vulnerable to thisproblem still remain (eg Fast secure VPN)

CacheProxy is an app that opens local proxy with thecapability of caching the web page content Upon receivinga request the proxy first checks whether the request can beserved using cached content before fetching the page withno authentication performed on the source of the incomingrequest Remote attackers can thus easily access sensitiveinformation of the victim such as e-mails by requesting thee-mail page since the page is retrieved from the cache forthe attacker

To get an initial estimate on the severity of open portvulnerabilities in the wild we performed a small scale portscan in a subnet of a campus network The ports scannedare those opened by the most popular vulnerable apps inour dataset whose port number needs to be static andunique Note that we only scanned for the existence ofthe open ports but did not send any data to the ports toverify the vulnerability for ethical concerns We performedonly one scan using a scanning tool [26] which finished intwo minutes Surprisingly 40 hosts identified to be mobiledevices open such ports Although different apps that usethe same port number may introduce false positives thescanning result indicates that immediately exploitable openports exist in the wild

7 Mitigation Strategy

Traditional solutions to protect an open port fromInternet attackers are through firewall which monitors andcontrols incoming and outgoing traffic based on prede-termined security policies However the firewall solutionsuffers from usability in the mobile context since it ishard for individual users to configure suitable firewall rulesfor each app installed on the device and coordinate bothapp functionality and security assurance Moreover in thephysical proximity use scenario since users can initiateconnections from arbitrary hosts it is hard to configure rulesin advance

Despite a variety of open port usage described thefundamental problem is the lack of proper client authen-tications However we find that it is non-trivial to provide ageneral solution to patch the security problems for all usagecases while preserving usability We discuss the major chal-lenges in different scenarios and propose countermeasures

Intended for communication with backend For theopen port mobile app to verify that the incoming connection

11

is from the authentic server we suggest using secure tokensto perform authentication Although tokens are already usedin some open port apps implementation flaws are commonlyseen For example a third-party push notification servicethat distributes token to app developers for them to embedin the app is vulnerable because the token can be extractedfrom the released app binary by attacker to exploit the vul-nerable app installed on other victim devices We suggest theapp and server negotiate a shared token using mechanismssuch as Diffie-Hellman [7] at app launching time And openport app uses the token to authenticate further incomingconnections

Intended for use by app users Compared to theprevious usage scenario open port apps in this case do notknow in advance the legitimate remote hosts that shouldconnect to them Depending on the usage of the app userthe trusted remote hosts can be userrsquos desktop or even hisfriendrsquos laptop A general solution is to use password or pincode to authenticate incoming connections however somesecurity issues are raised in practice As an example allthe apps we examined that use password provide hard-codedefault password that does not require users to change beforeusing the app leading to the potential use of the defaultpassword and degrading app security Randomly generatedpin codes in the open port apps we examined are usuallyno longer than 4 characters which is trivial to enumerateExperiment in our local WiFi network indicates that it takesless than 5 minutes to send probing requests that enumerateall the 4-character strings

Another authentication solution adopted by the toptrending apps for this usage scenario is the incoming con-nection notification which pops up a window when a newhost connects to the open port and displays the IP addressof the host And the request is not served until user explic-itly accepts the client by clicking the ldquoallowrdquo button Forordinary users the timing of the pop-up window is also animportant indicator for them to make the decision of whetherto allow or deny the request However on-device malwarecan infer the timing when there is an incoming connection tothe port by monitoring procnet[tcp][tcp6] andsend request immediately to trick user into also allowing itsconnection by overlaying the pop-up window We furtherfind that even the most popular apps in this category hasimplementation flaws that can be practically exploited byattackers in our threat model

AirDroid1 is a top-ranked app on the market that allowsusers to access and manage their Android device wirelesslyfrom desktop by opening a server on the phone It providesa rich set of functionality to users such as access cameraand install apps remotely and uses the incoming connectionnotification schema to authenticate client However if thetiming of user initiated connection is inferred by the attackerwith the help of an on-device malware and attacker sendsrequest to the open port before the user accepts the previousconnection the app wonrsquot pop up another window Insteadthe attacker connection silently replaces the previous legit-

1 AirDroid httpswwwairdroidcom

ServerSocket

SecureServerSocket Remote client

Requestfrom IP0

Return IP0

as QR code

Scan

Trust IP0

Requestfrom IP0

Return

Socket Socket

Display

Check IP0

Figure 8 SecureServerSocket design

imate connection in the waiting queue without changingthe IP address displayed on the pop-up window And whena user clicks the button to allow the legitimate connectionthe attacker client is allowed instead and numerous sensitivecapabilities of AirDroid are granted to the attacker

Usage in this category is usually for the cable-less com-munication with nearby hosts of the user We confirmed that24 out of the 26 vulnerable apps in this category are intendedfor the use in physical proximity We demonstrate a transpar-ent socket-level solution that addresses the security and us-ability challenges in this usage scenario Shown in Figure 8we provide SecureServerSocket which encapsulatesthe Android ServerSocket API to accept incoming sock-ets When a remote client the userrsquos desktop for exampletries to connect to the port the SecureServerSocket

first puts the connection on hold and then encodes the IPaddress of the client into a QR code and returns to theremote client The remote client is required to display theQR code and let the user scan it using the mobile device inorder to get access

Once the QR code is scanned the decoded IP addressis returned to the SecureServerSocket and the con-nection from this IP is allowed It then returns the incom-ing socket to the upper application layer to be handledThis approach authenticates clients on the IP layer andensures that the open port only serves clients in physicalproximity of the device user and it achieves both securityand usability We provide SecureServerSocket as alibrary that app developers can simply use as a replacementof ServerSocket No changes on the client side arerequired if the client is a web browser which is the commoncase in our app dataset For other client types that cannotdisplay QR code we suggest using one-time pin code to dothe authentication instead Demo of the SecureServerSocketimplementation can also be found on our website [11] Andfor future work we plan to conduct a user study to evaluatethe effectiveness of this approach

Intended for local communication For the local usageof on-device proxy the best practice is to bind the proxy tothe loopback address of the device which makes the serviceunreachable from the network For another local usage

12

Open port intention Vulnerability description Featured attacks Vulnerable app example App 1

Usage of the app userLack of authentication to verify that Data theft WiFi file transfer 24connections come from the app user Privilege escalation AirDroid PhonePal 10

Communication with Lack of authentication to verify the requests Data theft Lenjoy 15backend are from authentic app backend server Privileged escalation KindeeExpress 5

Local communicationPort used for on-device communication DoS VGet Fast secure VPN 12falsely opened to the network Data theft CachedProxy 1

1 Number of vulnerable apps in the same category An app may be vulnerable to both attacks in each category

TABLE 4 Case study of verified exploitable app categorized by the intended usage of open port

from the devicersquos Universally Unique Identifier (UUID) [1]Thus we consider the open service of PhoneGap as well-protected

53 Security Implications

Usage paths in different families if not well protectedcan lead to different security breaches As shown in table3 OPAnalyzer outputs 956 weak paths We find that nearlyhalf of the total usage paths are considered ldquoweakrdquo In theproxy category over 80 of the paths are not protectedFrom these weak paths we identify three vulnerabilitycategories sensitive data leakage (V1) privileged remoteexecution (V2) and DoS (V3) Besides we also discovera new problem that any open port on smartphones can beexploited to harvest cellular IPv6 addresses which allowsattacker to collect victim IPs without scanning the huge IPv6address space and further launch attack to exploit vulnerableports The vulnerability is detailed in the Appendix A

V1 Sensitive data leakage Sensitive data of a mobiledevice can be retrieved from many sources such as SD Cardsensor etc If these paths are not well protected remoteattacker can exploit them to steal sensitive data that areeven protected by Android permission or UNIX uidgid

check More importantly if the victim IP is public suchvulnerabilities can be easily revealed using fast Internet-wide scanning tools such as ZMap [26] causing large scaledata theft

V2 Privileged remote execution Vulnerable paths thattrigger native actions can be leveraged by remote attackersto execute privileged functionality such as sending SMS andmodifying contacts Moreover by exploiting the broadcast-ing Intent mechanism provided by Android attackers caneven execute functionality beyond the vulnerable app Forexample an unprotected usage path that sends Intent

based on remote input can be leveraged to launch YouTubeapp to play the video from the URL passed by the remoteattacker By uploading a maliciously crafted MP4 file to theURL attacker can gain full control of the device exploitingthe Stagefright vulnerability [6]

V3 Denial of service Most remote execution paths arevulnerable to DoS attack against the device user For thelocal proxy usage paths they can also be used by attackersas reflectors in targeted DDoS attack against victims inthe Internet to hidden their IP addresses Other securityproblems of open proxies such as leaking internal networkdata and IP spoofing based attack also apply

6 Exploits Case Studies

To broaden the scope of our vulnerable study and dis-cover more exploitable open port usage we extended ourdata set to include all the 78K apps from the Tools cate-gory of the PlayDrone dataset to our vulnerability analysisbased on the observation that the percentage of open-portapps in the Tools(109) is significantly higher than theaverage (68) Furthermore we also crawled the top 3000most popular apps from a Chinese app market [2] wherethe Wormhole problem was reported from

By analyzing the annotated usage paths from the OPAna-lyzer output we successfully discover several new exploitsof sensitive data leakage and privileged remote execution inboth apps and third-party libraries including some high-profile ones with millions of downloads and even pre-installed apps Moreover we classify these vulnerable appsinto 3 categories based on the intended usage scenario of theopen port inferred from the manual analysis (1) intendedfor use by app users (2) intended for communication withthe backend and (3) intended for local communicationSuch categorization helps better understand the challengesin securing the port opened for different purposes Table 4shows an overview of the 57 exploitable apps that are man-ually verified from the OPAnalyzer output A case study ofinteresting vulnerability in each category is presented belowThe video demos for some of the implemented attacks areshown on our website [11]

61 Intended for Use by App Users

Such apps open ports for different purposes intendedfor the app users such as transferring file from the phoneto another device of the same user However essentialchecks are found missing in many apps in this category thusexposing the sensitive data and also privileged functionalityof the device to attackers

Virtual data cable is a popular app on China marketthat helps user transfer their photos to PC by opening a webserver on the phone The server port opens by default at applaunch time and silently runs in the background It does notauthenticate clients nor notify incoming connections thuscan be easily scanned and exploited by remote attackersMoreover it does not check the requested file path so thatattacker can access files beyond the photo folder on SD cardby adding ldquordquo to the path and steal sensitive data fromapp cache and system directory Similarly a popular file

10

sharing app WiFi file transfer with 10 million installs doesnot authenticate clients while it opens the server port onlywhen user presses a toggle button However an on-devicemalware that only has Internet permission in our threatmodel can listen on the status of the port by monitoring theproc file system and steal data from the port as long asit is open

PhonePal allows a user to remotely control hisherdevice with a web-browser which contains highly sensitiveusage paths such as open URLs in the Android browserand open videos in the YouTube app All these usage pathsare found unprotected which puts the device at the riskof phishing attack and even compromise [6] Moreovervulnerabilities such as allowing attacker to remotely installapps on the victim device are identified in the high-profileapp AirDroid pre-installed on Samsung Chromebook andSmartisan phone [13] We present a case study of this appin the mitigation strategy section (sect7)

62 Intended for Communication with Backend

Open ports in these apps are intended to communicatewith the app developerrsquos backend server for various pur-poses If the open port service does not authenticate theidentity of the remote server attackers can spoof the appserver Interestingly by manually examining the apps wefind that open port usage of some apps are beyond the appsrsquodeclared functionality implying potentially covert maliciousbehavior

KindeExpress is the most popular mailpackage trackingapp on a China market with 1 million downloads whosefunctionality is to provide tracking information from manydelivery service providers One of its usage path is able tostart an Activity of the app and display the data fromremote input on the apprsquos UI which also brings the app tothe front even when it is running in the background Weverified that none of the declared functionality of the appdepends on this usage path and we suspect it to be usedfor advertising Unfortunately this path is not protected byany authentication mechanism and remote attacker can sendcommand to the app pretending as it comes from the appserver to display deceptive content on the app UI

Huang CheatMaker is a game modifier app that helpsusers cheat when playing mobile games We identified ausage path that accepts data pushed from the app serverstores the data as a shared object (so) file and loadsit at run-time The authentication along the path is weakand the app dynamically loads the code without verifyingwhere it comes from nor its integrity which enables remoteattackers to inject malicious payload to the app to that willbe executed thus compromising the device

63 Intended for Local Communication

Usage paths in Proxy and PhoneGap families are in-tended for on-device communication which can be eitherIPC among different components of an app or proxy fordifferent apps on the device to use However open ports

in some apps that are intended for local usage are falselyexposed to the network and thus lead to security breaches

OpenVPN is an open-source VPN implementation thatis integrated by several popular VPN apps on Google PlayMultiple interfaces are provided by OpenVPN for the appto configure the local VPN settings while the open TCPport interface is identified to be the least secure one Aremote attacker can DoS the victim user by changing proxysettings such as port number on the device Fortunatelysome app developers paid extra attention when integratingOpenVPN and closed the insecure configuration interfacefrom the open TCP port but VPN apps vulnerable to thisproblem still remain (eg Fast secure VPN)

CacheProxy is an app that opens local proxy with thecapability of caching the web page content Upon receivinga request the proxy first checks whether the request can beserved using cached content before fetching the page withno authentication performed on the source of the incomingrequest Remote attackers can thus easily access sensitiveinformation of the victim such as e-mails by requesting thee-mail page since the page is retrieved from the cache forthe attacker

To get an initial estimate on the severity of open portvulnerabilities in the wild we performed a small scale portscan in a subnet of a campus network The ports scannedare those opened by the most popular vulnerable apps inour dataset whose port number needs to be static andunique Note that we only scanned for the existence ofthe open ports but did not send any data to the ports toverify the vulnerability for ethical concerns We performedonly one scan using a scanning tool [26] which finished intwo minutes Surprisingly 40 hosts identified to be mobiledevices open such ports Although different apps that usethe same port number may introduce false positives thescanning result indicates that immediately exploitable openports exist in the wild

7 Mitigation Strategy

Traditional solutions to protect an open port fromInternet attackers are through firewall which monitors andcontrols incoming and outgoing traffic based on prede-termined security policies However the firewall solutionsuffers from usability in the mobile context since it ishard for individual users to configure suitable firewall rulesfor each app installed on the device and coordinate bothapp functionality and security assurance Moreover in thephysical proximity use scenario since users can initiateconnections from arbitrary hosts it is hard to configure rulesin advance

Despite a variety of open port usage described thefundamental problem is the lack of proper client authen-tications However we find that it is non-trivial to provide ageneral solution to patch the security problems for all usagecases while preserving usability We discuss the major chal-lenges in different scenarios and propose countermeasures

Intended for communication with backend For theopen port mobile app to verify that the incoming connection

11

is from the authentic server we suggest using secure tokensto perform authentication Although tokens are already usedin some open port apps implementation flaws are commonlyseen For example a third-party push notification servicethat distributes token to app developers for them to embedin the app is vulnerable because the token can be extractedfrom the released app binary by attacker to exploit the vul-nerable app installed on other victim devices We suggest theapp and server negotiate a shared token using mechanismssuch as Diffie-Hellman [7] at app launching time And openport app uses the token to authenticate further incomingconnections

Intended for use by app users Compared to theprevious usage scenario open port apps in this case do notknow in advance the legitimate remote hosts that shouldconnect to them Depending on the usage of the app userthe trusted remote hosts can be userrsquos desktop or even hisfriendrsquos laptop A general solution is to use password or pincode to authenticate incoming connections however somesecurity issues are raised in practice As an example allthe apps we examined that use password provide hard-codedefault password that does not require users to change beforeusing the app leading to the potential use of the defaultpassword and degrading app security Randomly generatedpin codes in the open port apps we examined are usuallyno longer than 4 characters which is trivial to enumerateExperiment in our local WiFi network indicates that it takesless than 5 minutes to send probing requests that enumerateall the 4-character strings

Another authentication solution adopted by the toptrending apps for this usage scenario is the incoming con-nection notification which pops up a window when a newhost connects to the open port and displays the IP addressof the host And the request is not served until user explic-itly accepts the client by clicking the ldquoallowrdquo button Forordinary users the timing of the pop-up window is also animportant indicator for them to make the decision of whetherto allow or deny the request However on-device malwarecan infer the timing when there is an incoming connection tothe port by monitoring procnet[tcp][tcp6] andsend request immediately to trick user into also allowing itsconnection by overlaying the pop-up window We furtherfind that even the most popular apps in this category hasimplementation flaws that can be practically exploited byattackers in our threat model

AirDroid1 is a top-ranked app on the market that allowsusers to access and manage their Android device wirelesslyfrom desktop by opening a server on the phone It providesa rich set of functionality to users such as access cameraand install apps remotely and uses the incoming connectionnotification schema to authenticate client However if thetiming of user initiated connection is inferred by the attackerwith the help of an on-device malware and attacker sendsrequest to the open port before the user accepts the previousconnection the app wonrsquot pop up another window Insteadthe attacker connection silently replaces the previous legit-

1 AirDroid httpswwwairdroidcom

ServerSocket

SecureServerSocket Remote client

Requestfrom IP0

Return IP0

as QR code

Scan

Trust IP0

Requestfrom IP0

Return

Socket Socket

Display

Check IP0

Figure 8 SecureServerSocket design

imate connection in the waiting queue without changingthe IP address displayed on the pop-up window And whena user clicks the button to allow the legitimate connectionthe attacker client is allowed instead and numerous sensitivecapabilities of AirDroid are granted to the attacker

Usage in this category is usually for the cable-less com-munication with nearby hosts of the user We confirmed that24 out of the 26 vulnerable apps in this category are intendedfor the use in physical proximity We demonstrate a transpar-ent socket-level solution that addresses the security and us-ability challenges in this usage scenario Shown in Figure 8we provide SecureServerSocket which encapsulatesthe Android ServerSocket API to accept incoming sock-ets When a remote client the userrsquos desktop for exampletries to connect to the port the SecureServerSocket

first puts the connection on hold and then encodes the IPaddress of the client into a QR code and returns to theremote client The remote client is required to display theQR code and let the user scan it using the mobile device inorder to get access

Once the QR code is scanned the decoded IP addressis returned to the SecureServerSocket and the con-nection from this IP is allowed It then returns the incom-ing socket to the upper application layer to be handledThis approach authenticates clients on the IP layer andensures that the open port only serves clients in physicalproximity of the device user and it achieves both securityand usability We provide SecureServerSocket as alibrary that app developers can simply use as a replacementof ServerSocket No changes on the client side arerequired if the client is a web browser which is the commoncase in our app dataset For other client types that cannotdisplay QR code we suggest using one-time pin code to dothe authentication instead Demo of the SecureServerSocketimplementation can also be found on our website [11] Andfor future work we plan to conduct a user study to evaluatethe effectiveness of this approach

Intended for local communication For the local usageof on-device proxy the best practice is to bind the proxy tothe loopback address of the device which makes the serviceunreachable from the network For another local usage

12

sharing app WiFi file transfer with 10 million installs doesnot authenticate clients while it opens the server port onlywhen user presses a toggle button However an on-devicemalware that only has Internet permission in our threatmodel can listen on the status of the port by monitoring theproc file system and steal data from the port as long asit is open

PhonePal allows a user to remotely control hisherdevice with a web-browser which contains highly sensitiveusage paths such as open URLs in the Android browserand open videos in the YouTube app All these usage pathsare found unprotected which puts the device at the riskof phishing attack and even compromise [6] Moreovervulnerabilities such as allowing attacker to remotely installapps on the victim device are identified in the high-profileapp AirDroid pre-installed on Samsung Chromebook andSmartisan phone [13] We present a case study of this appin the mitigation strategy section (sect7)

62 Intended for Communication with Backend

Open ports in these apps are intended to communicatewith the app developerrsquos backend server for various pur-poses If the open port service does not authenticate theidentity of the remote server attackers can spoof the appserver Interestingly by manually examining the apps wefind that open port usage of some apps are beyond the appsrsquodeclared functionality implying potentially covert maliciousbehavior

KindeExpress is the most popular mailpackage trackingapp on a China market with 1 million downloads whosefunctionality is to provide tracking information from manydelivery service providers One of its usage path is able tostart an Activity of the app and display the data fromremote input on the apprsquos UI which also brings the app tothe front even when it is running in the background Weverified that none of the declared functionality of the appdepends on this usage path and we suspect it to be usedfor advertising Unfortunately this path is not protected byany authentication mechanism and remote attacker can sendcommand to the app pretending as it comes from the appserver to display deceptive content on the app UI

Huang CheatMaker is a game modifier app that helpsusers cheat when playing mobile games We identified ausage path that accepts data pushed from the app serverstores the data as a shared object (so) file and loadsit at run-time The authentication along the path is weakand the app dynamically loads the code without verifyingwhere it comes from nor its integrity which enables remoteattackers to inject malicious payload to the app to that willbe executed thus compromising the device

63 Intended for Local Communication

Usage paths in Proxy and PhoneGap families are in-tended for on-device communication which can be eitherIPC among different components of an app or proxy fordifferent apps on the device to use However open ports

in some apps that are intended for local usage are falselyexposed to the network and thus lead to security breaches

OpenVPN is an open-source VPN implementation thatis integrated by several popular VPN apps on Google PlayMultiple interfaces are provided by OpenVPN for the appto configure the local VPN settings while the open TCPport interface is identified to be the least secure one Aremote attacker can DoS the victim user by changing proxysettings such as port number on the device Fortunatelysome app developers paid extra attention when integratingOpenVPN and closed the insecure configuration interfacefrom the open TCP port but VPN apps vulnerable to thisproblem still remain (eg Fast secure VPN)

CacheProxy is an app that opens local proxy with thecapability of caching the web page content Upon receivinga request the proxy first checks whether the request can beserved using cached content before fetching the page withno authentication performed on the source of the incomingrequest Remote attackers can thus easily access sensitiveinformation of the victim such as e-mails by requesting thee-mail page since the page is retrieved from the cache forthe attacker

To get an initial estimate on the severity of open portvulnerabilities in the wild we performed a small scale portscan in a subnet of a campus network The ports scannedare those opened by the most popular vulnerable apps inour dataset whose port number needs to be static andunique Note that we only scanned for the existence ofthe open ports but did not send any data to the ports toverify the vulnerability for ethical concerns We performedonly one scan using a scanning tool [26] which finished intwo minutes Surprisingly 40 hosts identified to be mobiledevices open such ports Although different apps that usethe same port number may introduce false positives thescanning result indicates that immediately exploitable openports exist in the wild

7 Mitigation Strategy

Traditional solutions to protect an open port fromInternet attackers are through firewall which monitors andcontrols incoming and outgoing traffic based on prede-termined security policies However the firewall solutionsuffers from usability in the mobile context since it ishard for individual users to configure suitable firewall rulesfor each app installed on the device and coordinate bothapp functionality and security assurance Moreover in thephysical proximity use scenario since users can initiateconnections from arbitrary hosts it is hard to configure rulesin advance

Despite a variety of open port usage described thefundamental problem is the lack of proper client authen-tications However we find that it is non-trivial to provide ageneral solution to patch the security problems for all usagecases while preserving usability We discuss the major chal-lenges in different scenarios and propose countermeasures

Intended for communication with backend For theopen port mobile app to verify that the incoming connection

11

is from the authentic server we suggest using secure tokensto perform authentication Although tokens are already usedin some open port apps implementation flaws are commonlyseen For example a third-party push notification servicethat distributes token to app developers for them to embedin the app is vulnerable because the token can be extractedfrom the released app binary by attacker to exploit the vul-nerable app installed on other victim devices We suggest theapp and server negotiate a shared token using mechanismssuch as Diffie-Hellman [7] at app launching time And openport app uses the token to authenticate further incomingconnections

Intended for use by app users Compared to theprevious usage scenario open port apps in this case do notknow in advance the legitimate remote hosts that shouldconnect to them Depending on the usage of the app userthe trusted remote hosts can be userrsquos desktop or even hisfriendrsquos laptop A general solution is to use password or pincode to authenticate incoming connections however somesecurity issues are raised in practice As an example allthe apps we examined that use password provide hard-codedefault password that does not require users to change beforeusing the app leading to the potential use of the defaultpassword and degrading app security Randomly generatedpin codes in the open port apps we examined are usuallyno longer than 4 characters which is trivial to enumerateExperiment in our local WiFi network indicates that it takesless than 5 minutes to send probing requests that enumerateall the 4-character strings

Another authentication solution adopted by the toptrending apps for this usage scenario is the incoming con-nection notification which pops up a window when a newhost connects to the open port and displays the IP addressof the host And the request is not served until user explic-itly accepts the client by clicking the ldquoallowrdquo button Forordinary users the timing of the pop-up window is also animportant indicator for them to make the decision of whetherto allow or deny the request However on-device malwarecan infer the timing when there is an incoming connection tothe port by monitoring procnet[tcp][tcp6] andsend request immediately to trick user into also allowing itsconnection by overlaying the pop-up window We furtherfind that even the most popular apps in this category hasimplementation flaws that can be practically exploited byattackers in our threat model

AirDroid1 is a top-ranked app on the market that allowsusers to access and manage their Android device wirelesslyfrom desktop by opening a server on the phone It providesa rich set of functionality to users such as access cameraand install apps remotely and uses the incoming connectionnotification schema to authenticate client However if thetiming of user initiated connection is inferred by the attackerwith the help of an on-device malware and attacker sendsrequest to the open port before the user accepts the previousconnection the app wonrsquot pop up another window Insteadthe attacker connection silently replaces the previous legit-

1 AirDroid httpswwwairdroidcom

ServerSocket

SecureServerSocket Remote client

Requestfrom IP0

Return IP0

as QR code

Scan

Trust IP0

Requestfrom IP0

Return

Socket Socket

Display

Check IP0

Figure 8 SecureServerSocket design

imate connection in the waiting queue without changingthe IP address displayed on the pop-up window And whena user clicks the button to allow the legitimate connectionthe attacker client is allowed instead and numerous sensitivecapabilities of AirDroid are granted to the attacker

Usage in this category is usually for the cable-less com-munication with nearby hosts of the user We confirmed that24 out of the 26 vulnerable apps in this category are intendedfor the use in physical proximity We demonstrate a transpar-ent socket-level solution that addresses the security and us-ability challenges in this usage scenario Shown in Figure 8we provide SecureServerSocket which encapsulatesthe Android ServerSocket API to accept incoming sock-ets When a remote client the userrsquos desktop for exampletries to connect to the port the SecureServerSocket

first puts the connection on hold and then encodes the IPaddress of the client into a QR code and returns to theremote client The remote client is required to display theQR code and let the user scan it using the mobile device inorder to get access

Once the QR code is scanned the decoded IP addressis returned to the SecureServerSocket and the con-nection from this IP is allowed It then returns the incom-ing socket to the upper application layer to be handledThis approach authenticates clients on the IP layer andensures that the open port only serves clients in physicalproximity of the device user and it achieves both securityand usability We provide SecureServerSocket as alibrary that app developers can simply use as a replacementof ServerSocket No changes on the client side arerequired if the client is a web browser which is the commoncase in our app dataset For other client types that cannotdisplay QR code we suggest using one-time pin code to dothe authentication instead Demo of the SecureServerSocketimplementation can also be found on our website [11] Andfor future work we plan to conduct a user study to evaluatethe effectiveness of this approach

Intended for local communication For the local usageof on-device proxy the best practice is to bind the proxy tothe loopback address of the device which makes the serviceunreachable from the network For another local usage

12

is from the authentic server we suggest using secure tokensto perform authentication Although tokens are already usedin some open port apps implementation flaws are commonlyseen For example a third-party push notification servicethat distributes token to app developers for them to embedin the app is vulnerable because the token can be extractedfrom the released app binary by attacker to exploit the vul-nerable app installed on other victim devices We suggest theapp and server negotiate a shared token using mechanismssuch as Diffie-Hellman [7] at app launching time And openport app uses the token to authenticate further incomingconnections

Intended for use by app users Compared to theprevious usage scenario open port apps in this case do notknow in advance the legitimate remote hosts that shouldconnect to them Depending on the usage of the app userthe trusted remote hosts can be userrsquos desktop or even hisfriendrsquos laptop A general solution is to use password or pincode to authenticate incoming connections however somesecurity issues are raised in practice As an example allthe apps we examined that use password provide hard-codedefault password that does not require users to change beforeusing the app leading to the potential use of the defaultpassword and degrading app security Randomly generatedpin codes in the open port apps we examined are usuallyno longer than 4 characters which is trivial to enumerateExperiment in our local WiFi network indicates that it takesless than 5 minutes to send probing requests that enumerateall the 4-character strings

Another authentication solution adopted by the toptrending apps for this usage scenario is the incoming con-nection notification which pops up a window when a newhost connects to the open port and displays the IP addressof the host And the request is not served until user explic-itly accepts the client by clicking the ldquoallowrdquo button Forordinary users the timing of the pop-up window is also animportant indicator for them to make the decision of whetherto allow or deny the request However on-device malwarecan infer the timing when there is an incoming connection tothe port by monitoring procnet[tcp][tcp6] andsend request immediately to trick user into also allowing itsconnection by overlaying the pop-up window We furtherfind that even the most popular apps in this category hasimplementation flaws that can be practically exploited byattackers in our threat model

AirDroid1 is a top-ranked app on the market that allowsusers to access and manage their Android device wirelesslyfrom desktop by opening a server on the phone It providesa rich set of functionality to users such as access cameraand install apps remotely and uses the incoming connectionnotification schema to authenticate client However if thetiming of user initiated connection is inferred by the attackerwith the help of an on-device malware and attacker sendsrequest to the open port before the user accepts the previousconnection the app wonrsquot pop up another window Insteadthe attacker connection silently replaces the previous legit-

1 AirDroid httpswwwairdroidcom

ServerSocket

SecureServerSocket Remote client

Requestfrom IP0

Return IP0

as QR code

Scan

Trust IP0

Requestfrom IP0

Return

Socket Socket

Display

Check IP0

Figure 8 SecureServerSocket design

imate connection in the waiting queue without changingthe IP address displayed on the pop-up window And whena user clicks the button to allow the legitimate connectionthe attacker client is allowed instead and numerous sensitivecapabilities of AirDroid are granted to the attacker

Usage in this category is usually for the cable-less com-munication with nearby hosts of the user We confirmed that24 out of the 26 vulnerable apps in this category are intendedfor the use in physical proximity We demonstrate a transpar-ent socket-level solution that addresses the security and us-ability challenges in this usage scenario Shown in Figure 8we provide SecureServerSocket which encapsulatesthe Android ServerSocket API to accept incoming sock-ets When a remote client the userrsquos desktop for exampletries to connect to the port the SecureServerSocket

first puts the connection on hold and then encodes the IPaddress of the client into a QR code and returns to theremote client The remote client is required to display theQR code and let the user scan it using the mobile device inorder to get access

Once the QR code is scanned the decoded IP addressis returned to the SecureServerSocket and the con-nection from this IP is allowed It then returns the incom-ing socket to the upper application layer to be handledThis approach authenticates clients on the IP layer andensures that the open port only serves clients in physicalproximity of the device user and it achieves both securityand usability We provide SecureServerSocket as alibrary that app developers can simply use as a replacementof ServerSocket No changes on the client side arerequired if the client is a web browser which is the commoncase in our app dataset For other client types that cannotdisplay QR code we suggest using one-time pin code to dothe authentication instead Demo of the SecureServerSocketimplementation can also be found on our website [11] Andfor future work we plan to conduct a user study to evaluatethe effectiveness of this approach

Intended for local communication For the local usageof on-device proxy the best practice is to bind the proxy tothe loopback address of the device which makes the serviceunreachable from the network For another local usage

12

scenario where different components of an app communicateusing open port we suggest using other IPC mechanismssuch as Intent Binder and LocalSocket insteadAnd application layer authentications are required when us-ing them For example uidgid check should be enabledwhen using LocalSocket to ensure that the connectionsare from the same app

8 Related Work

Security implications of open port usage The securityimplications of using open ports on the network serviceshave been studied using Internet-wide scanning tools such asZMap [26] revealing various vulnerabilities [9] [14] [27][41] However the open port usage and security concernson mobile platform remain under-explored Understandingthis problem in the mobile context is non-trivial since boththe current usage and the existing defense solutions are notapplicable to the mobile scenario We design and implementOPAnalyzer to bridge this gap

Static analysis on Android Static analysis has beenused extensively in vulnerability discoveries Specificallyon Android platform many tools have been built to identifysystem vulnerability [18] [23] [39] [42] [44] and mali-cious apps [20] [22] [28] [29] [32] [40] [46] Amongthese work TriggerScope [32] is most closely related toour work which focuses on detecting malicious activitiesembedded in narrow conditions using static analysis OP-Analyzer serves a different goal which is detecting openport related vulnerabilities However the trigger analysis

proposed by TriggerScope can be potentially integrated byOPAnalyzer to improve its accuracy of weak constraintsanalysis FlowDroid [20] and Amandroid [46] are two staticanalysis tools similar to OPAnalyzer both of which modelthe Android Activity lifecycle [20] and capture inter-component communications Compared to these generic appanalysis tools that evaluate the app as a whole our toolfocuses on examining the part that contains open port func-tionality Another difference is that we integrate native codeanalysis for high accuracy and coverage of our analysiswhich is commonly excluded in these tools due to highengineering effort

Android app security Mobile app security issues havegained much attention recently and research efforts weremade on detecting repackaged apps [19] [22] [36] [50]apps with malicious behavior [24] [31] [32] [35] [47][52] or apps with vulnerability [25] [30] [37] Differentfrom these prior studies we investigate the vulnerabilityin open port apps which is not covered by related workand has a new threat model not previously explored Ouranalysis results shed important light on the common designand implementation flaws in these apps and we also proposesolutions to some mobile-specific usage scenarios

9 Conclusion

In this paper we develop a tool called OPAnalyzerwhich can systematically characterize open port usage in

Android apps and effectively detect exploitable vulnerabili-ties Using this tool on 24K popular Android apps we areable to classify 99 of the mobile usage into 5 families andidentify some unique usage scenarios on mobile platformFrom the vulnerability analysis performed we find that suchusage is generally unprotected We are able to discover abunch of new exploits causing vulnerabilities such as infor-mation leakage denial of service and privileged executionWe also propose countermeasures and improved practicesto mitigate these problems in different usage scenariosAs a potential future work we want to apply OPAnalyzerto analyze Android system applications to discover morecritical vulnerabilities

References

[1] Android Universally Unique Identifier httpdeveloperandroidcomreferencejavautilUUIDhtml

[2] Anzhi app market httpwwwanzhicom

[3] ARM processor specifications httpswwwhex-rayscomproductsidasupportidadoc1350shtml

[4] Arp-scan httplinuxdienetman1arp-scan

[5] Common Vulnerabilities and Exposures (CVE) httpscvemitreorg

[6] CVE-2015-6602 httpcvemitreorgcgi-bincvenamecginame=CVE-2015-6602

[7] Diffie-Hellman Key Agreement httpswwwietforgrfcrfc2631txt

[8] Epoll IO notification httplinuxdienetman4epoll

[9] Heartbleed httpheartbleedcom

[10] IDA-Pro httpswwwhex-rayscomindexshtml

[11] Mobile Open Port Security Project httpssitesgooglecomsiteopenportsec

[12] One hundred days before and after Baidu Wormholersquos Dis-covery httpwwwinforsecorgwpwp-contentuploads201601wormhole external finalpdf

[13] Smartisan technology httpwwwsmartisancom

[14] The Conficker Worm httpswww2sansorgsecurity-resourcesmalwarefaqconficker-wormphp

[15] UPnP Universal Plug and Play httpstoolsietforghtmlrfc6970

[16] US-CERT httpswwwus-certgov

[17] Xposed Module Repository httprepoxposedinfo

[18] Y Aafer N Zhang Z Zhang X Zhang K Chen X Wang X ZhouW Du and M Grace Hare hunting in the wild android A study onthe threat of hanging attribute references In ACM CCS ACM 2015

[19] Y Acar M Backes S Bugiel S Fahl P McDaniel and M SmithSok Lessons learned from android security research for appifiedsoftware platforms 2016

[20] S Arzt S Rasthofer C Fritz E Bodden A Bartel J KleinY Le Traon D Octeau and P McDaniel Flowdroid Precisecontext flow field object-sensitive and lifecycle-aware taint analysisfor android apps In ACM SIGPLAN Notices ACM 2014

[21] K W Y Au Y F Zhou Z Huang and D Lie Pscout analyzingthe android permission specification In ACM CCS 2012

[22] K Chen P Wang Y Lee X Wang N Zhang H Huang W Zouand P Liu Finding unknown malice in 10 seconds Mass vetting fornew threats at the google-play scale In USENIX Security 2015

[23] Q A Chen Z Qian Y Jia Y Shao and Z M Mao Static Detectionof Packet Injection Vulnerabilities ndash A Case for Identifying Attacker-controlled Implicit Information Leaks In ACM CCS 2015

13

[24] Q A Chen Z Qian and Z M Mao Peeking into Your App withoutActually Seeing It UI State Inference and Novel Android AttacksIn USENIX Security 2014

[25] E Chin A P Felt K Greenwood and D Wagner Analyzing inter-application communication in Android In ACM Mobisys 2011

[26] Z Durumeric E Wustrow and J A Halderman ZMap Fast Internet-wide scanning and its security applications In USENIX Security2013

[27] W M Eddy TCP SYN Flooding Attacks and Common Mitigationsrfc4987 2007

[28] W Enck P Gilbert B-G Chun L P Cox J Jung P McDanieland A Sheth TaintDroid An Information Flow Tracking System forReal-Time Privacy Monitoring on Smartphones In OSDI 2010

[29] S Fahl M Harbach T Muders L Baumgartner B Freisleben andM Smith Why Eve and Mallory love Android An analysis ofAndroid SSL (in) security In ACM CCS 2012

[30] A P Felt H J Wang A Moshchuk S Hanna and E ChinPermission Re-delegation Attacks and Defenses In USENIX Security

Symposium 2011

[31] E Fernandes Q A Chen J Paupore G Essl J A Halderman Z MMao and A Prakash Android UI Deception Revisited Attacks andDefenses In FC 2016

[32] Y Fratantonio A Bianchi W Robertson E Kirda C Kruegel andG Vigna TriggerScope Towards Detecting Logic Bombs in AndroidApplications In IEEE Security amp Privacy 2016

[33] C Gibler J Crussell J Erickson and H Chen AndroidLeaks Auto-matically Detecting Potential Privacy Leaks in Android Applicationson a Large Scale In TRUST 2012

[34] M I Gordon D Kim J Perkins L Gilham N Nguyen andM Rinard Information-flow Analysis of Android Applications inDroidSafe In NDSS 2015

[35] M C Grace Y Zhou Z Wang and X Jiang Systematic detectionof capability leaks in stock android smartphones In NDSS 2012

[36] H Huang S Zhu P Liu and D Wu A framework for evaluatingmobile app repackaging detection algorithms In TRUST 2013

[37] Y Z X Jiang Detecting passive content leaks and pollution inandroid applications In NDSS 2013

[38] P Lantz and B Johansson Towards bridging the gap betweendalvik bytecode and native code during static analysis of androidapplications In Wireless Communications and Mobile Computing

Conference 2015

[39] L Li A Bartel T F Bissyande J Klein Y Le Traon S ArztS Rasthofer E Bodden D Octeau and P McDaniel Iccta Detectinginter-component privacy leaks in android apps In Proceedings of the

37th International Conference on Software Engineering-Volume 1pages 280ndash291 IEEE Press 2015

[40] L Lu Z Li Z Wu W Lee and G Jiang Chex statically vettingandroid apps for component hijacking vulnerabilities In ACM CCS2012

[41] D Moore V Paxson S Savage C Shannon S Staniford andN Weaver Inside the Slammer Worm IEEE Security amp Privacy2003

[42] D Octeau P McDaniel S Jha A Bartel E Bodden J Klein andY Le Traon Effective inter-component communication mappingin android An essential step towards holistic security analysis InPresented as part of the 22nd USENIX Security Symposium (USENIX

Security 13) pages 543ndash558 2013

[43] V Rastogi Y Chen and X Jiang Droidchameleon evaluating an-droid anti-malware against transformation attacks In ACM ASIACCS2013

[44] Y Shao J Ott Q A Chen Z Qian and Z M Mao KratosDiscovering Inconsistent Security Policy Enforcement in the AndroidFramework In NDSS 2016

[45] N Viennot E Garcia and J Nieh A measurement study of googleplay In ACM SIGMETRICS Performance Evaluation Review 2014

[46] F Wei S Roy X Ou et al Amandroid A precise and generalinter-component data flow analysis framework for security vetting ofandroid apps In ACM CCS 2014

[47] W Yang X Xiao B Andow S Li T Xie and W Enck AppcontextDifferentiating malicious and benign mobile app behaviors usingcontext In 2015 IEEEACM 37th IEEE International Conference

on Software Engineering volume 1 pages 303ndash313 IEEE 2015

[48] K Zhang Z Li R Wang X Wang and S Chen SidebusterAutomated Detection and Quantification of Side-channel Leaks inWeb Application Development In CCS 2010

[49] L Zhang M Gordon R Dick Z M Mao P Dinda and L YangADEL An Automatic Detector of Energy Leaks for SmartphoneApplications In Proc of International Conference on Hardware-

Software Codesign and System Synthesis 2012

[50] Y Zhou and X Jiang Dissecting Android malware Characterizationand evolution In IEEE Symposium on Security and Privacy 2012

[51] Y Zhou and X Jiang Detecting Passive Content Leaks and Pollutionin Android Applications In NDSS 2013

[52] Y Zhou Z Wang W Zhou and X Jiang Hey You Get Off ofMy Market Detecting Malicious Apps in Official and AlternativeAndroid Markets In NDSS 2012

14

• Introduction
• Background and Threat Model
• Design Pattern of Open Port Apps
• OPAnalyzer Approach
• • Entry Point Analysis
  • Native Code Analyzer
  • Sensitive API Selection
  • Usage Path Analysis
  • Evaluation
  • • Usage and Vulnerability
    • • Popularity and Permission Usage
      • Usage Family Categorization
      • Security Implications
      • • Exploits Case Studies
        • • Intended for Use by App Users
          • Intended for Communication with Backend
          • Intended for Local Communication
          • • Mitigation Strategy
            • Related Work
            • Conclusion
            • References