gps-based user tracking using mobile apps

GPS-based user tracking using mobile apps

Hristo Dimitrov & Guido Pineda

May 2014

Abstract

This research investigates the possibility of mobile application users being tracked byexploiting geographical GPS-data leakages of applications which support or require GPSusage. In this report the focus is on the network traffic which is generated by the apps andon the APIs of the servers with which these applications communicate. Nine applicationswere researched and the results reveal that in many cases GPS coordinates of the mobiledevice of the user are being sent over the network in plain text. Those coordinates are sentalong with a lot of other device specification parameters like application version, OS versionand type, device type, preferred language, build version, etc. Those parameters could beuseful for identifying a unique device. Sometimes specifically identifying information likeIMEI of the SIM card is also being sent in plain text. The API tests did not reveal anyleakage of sensitive information for the apps that were tested. In conclusion, tracking ofmobile application users is possible if the attacker can intercept the traffic which is beingsent from the application to the back-end server.

1

Contents

1 Introduction 4

2 Background information 42.1 Android GPS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 APIs and HTTP REST Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Related work 5

4 Scope 5

5 Approach 65.1 App selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65.2 Experimental work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

6 Experiments and attacks 76.1 Man in the Middle Attack: Plain text . . . . . . . . . . . . . . . . . . . . . . . . 76.2 Man in the Middle Attack: SSL sniffing . . . . . . . . . . . . . . . . . . . . . . . 76.3 API communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7 Countermeasures 147.1 Disabling GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147.2 Deleting GPS data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157.3 Location spoofers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157.4 Use HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8 Conclusion 16

9 Future work 16

A DNS requests 18

B Detailed log communication for the tested applications 19

2

List of Figures

1 Android GPS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Typical operating environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Man in the Middle attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Applications using spoofed location . . . . . . . . . . . . . . . . . . . . . . . . . . 15

List of Tables

1 Tested applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 MitM attack: Plain text analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 This table shows the server response for an OPTIONS call to the URLs used for

HTTP and HTTPS communication by the tested mobile applications. (In caseno Allow header is present in the response, its HTTP code is shown. Also URLparameters are not shown. URLs related to mobile adds are also included) . . . . 10

4 List of APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3

1 Introduction

We live in an era when mobile software applications are widely used by people all around theworld. Big part of those applications ask for access to the GPS data from the device on whichthey are installed. In most of the cases this data is being reported to a back-end server. Thiscan be the case, because the functionality of the application depends on the location of the user.The coordinates or geographical location of a mobile device can be used for tracking the ownerof that particular device and should be treated as sensitive information which should not be ableto leak and become available to third parties. This research focuses on the possibility to exploitan Android mobile application in such a way that the attacker will be able to retrieve the GPSlocation of the device and respectively be able to track the position of the user.

2 Background information

In this section we briefly describe the background information used in this project. This informa-tion was useful when investigating how some Android applications work, what kind of technologyis being used when sending geo-location data and how it is processed.

2.1 Android GPS Architecture

The Android GPS architecture consists of some key components that provide location service touser level applications. The components of the architecture are shown on Figure 1.

Figure 1: Android GPS architecture

Incoming data, is read by the GPS driver, which communicates with the GPS device andreads the data coming from it. This data is then processed by the GL Engine, which alsostores relevant data in the /data/gps/gldata.sto (NVRAM) file. The GL Engine works by usingconfiguration parameters to provide the intended functionality, as well as by using the locationprovided by the network or cellphone provider.

The Android Location Services, is the service that communicates with the GL Engine toretrieve location data, and this information is then passed to the user level application, that isgps-based applications in general [1].

4

2.2 APIs and HTTP REST Calls

Most of the mobile applications communicate with their back-end served using HTTP or HTTPS.This is done by issuing requests to implemented APIs on the server side. After the mobileapplication sends an HTTP request, an HTTP response is sent back from the server to theclient. The implementation of this kind of communication, which is used by HTTP, is calledRepresentational State Transfer (REST) [2]. A REST request consists of an URL which identifiesthe location where the called API methods reside. The URL consists of host part, path and also,if needed, some parameters which can be passed in the URL. A REST request can also haveheaders which are passed along with the request. For example, if a cookie needs to be passed, itwill be set as a header [3]. Another important part is the body, where larger data chunks can bepassed along. There are also different types of requests based on their purpose. Some examplesare:

• GET - this request is used to retrieve needed information from the server.

• HEAD - this request is similar to GET, however no body is returned, only the headers.

• PUT - this request is used to store some information from the client on the server side.

• POST - this request is also used to store data on the server side with the difference thatthe server is in control of the storing.

• DELETE - this request is used to remove data from the server.

• OPTIONS - this request lists what request types are implemented for this particular URL.

3 Related work

There is a lot of research already done on leakage of sensitive information from mobile applica-tions. However every application is is different and should be investigated separately. There aremany reports stating the concern about privacy issues on some applications that may be leakingprivate or sensitive information across the network [4]. Many of these applications require theuser to grant permissions on his/her device in order to access this information, but there areapplications that should be able to work properly without accessing this kind of sensitive infor-mation. Therefore, investigating the communication of some of these applications is relevant inorder to determine what kind of sensitive information is being sent across the network.

4 Scope

The scope of this research includes investigating multiple mobile applications in order to deter-mine if GPS-data and other user sensitive information is being leaked. A relevant scenario forthis research, is having an attacker tracking the geographical location of a person that uses amobile application. If the attacker already has access to the mobile device of the user, then,tracking the location of the device using mobile applications is not very relevant anymore sincehe could retrieve the GPS data stored on the device directly. Therefore, this research includesonly network traffic investigation and communication with related back-end servers.

5

5 Approach

The approach of this project is determined by the following outline:

• Test applications for Android devices only.

• Choose well known applications with large installed base, that use GPS information.

• Perform a man in the middle attack to analyze what kind of relevant information can befound.

• Interact with the APIs that the applications are using to try to retrieve relevant informa-tion.

5.1 App selection

Interesting applications to be researched in this project, are the ones that have large installedbase and access GPS-data from the mobile device. The chosen applications are shown in Table 1.

Table 1: Tested applications

Application Install Base Tested version

9292 [5] 1.000.000 - 5.000.000 1.2.3

Buienradar [6] 1.000.000 - 5.000.000 v4.8.1

NS Reisplanner Xtra [7] 1.000.000 - 5.000.000 3.1

Schiphol Amsterdam Airport [8] 100.000 - 500.000 3.3

Maps [9] 500.000.000 - 1.000.000.000 8.0

Shazam [10] 100.000.000 - 500.000.000 4.6.1-JB85854

Soundhound [11] 50.000.000 - 100.000.000 5.9.1

Speedtest [12] 10.000.000 - 50.000.000 3.1.1

TuneIn Radio [13] 50.000.000 - 100.000.000 12.0

5.2 Experimental work

In order to find a way to extract GPS-data from the selected applications, four different scenarioswill be defined. First we will investigate the traffic between the application itself and the serverand check if there is no encryption used. If this is the case, we are going to investigate themessage format and extract useful information, that is, information that can be used to tracka user. In case TLS/SSL is used for encrypting traffic, we will attempt to conduct a Man inthe Middle Attack and use a self signed certificate to install it on the mobile device in orderto be able to decrypt the generated traffic. If those two attempts are not successful, we willtry to exploit an API that the back-end may provide and try to extract sensitive informationby interacting with that API. And finally we will investigate if the server leaks information inresponses outside of the encrypted channel.

6

6 Experiments and attacks

The typical operating environment for an Android application, is shown in Figure 2. In thisenvironment, the application connects to the Internet through a wireless access point to furtherinteract with the application server.

Figure 2: Typical operating environment

To be sure that we only capture traffic from the application we are testing, and not fromother applications, we used a firewall application called “Droidwall”, which blocks traffic fromspecific applications.

Before capturing any data from the applications, we made sure that GPS location was used,for that, we turned on the GPS receiver and made sure the location service was used.

6.1 Man in the Middle Attack: Plain text

The first attacking scenario is to perform a Man in the Middle attack, in order to sniff the trafficthat is generated from the application and retrieve relevant information. The setup environmentis shown in Figure 3. Here, all the traffic generated by the application is redirected to theattacker, and then it is forwarded to the Internet. That way, the attacker can analyze all trafficcoming from the application.

To be able to redirect the traffic from the applications, we used the tool Arpspoof which foolsthe device to send traffic to a spoofed gateway, and that is the attacker’s device.

arpspoo f − i wlan0 −t 1 9 2 . 1 6 8 . 0 . 2 1 9 2 . 1 6 8 . 0 . 1arpspoo f − i wlan0 −t 1 9 2 . 1 6 8 . 0 . 1 1 9 2 . 1 6 8 . 0 . 2

The option -i is to specify the interface in which the attacker’s device is listening. The option-t is to specify the target, where the 192.168.0.2 IP address is the victim, and the 192.168.0.1 IPaddress is the router’s address.

Every application was tested, and not all of them are sending information in plain text. Theresults are shown in Table 2. All applications use the GPS data, and for most of them, thisinformation is sent in GET calls by using HTTP.

6.2 Man in the Middle Attack: SSL sniffing

Since there are two applications that are using TLS/SSL to encrypt traffic, we generated a selfsigned certificate that was installed on the victim’s device. All traffic generated by the applicationis sent to the attacker’s machine which is running SSLsplit, a tool to perform Man in the Middleattacks on TLS/SSL traffic. The following script was used to perform the attack:

#!/bin /shs y s c t l −w net . ipv4 . ip fo rward=1

i p t a b l e s −F

7

Figure 3: Man in the Middle attack

Table 2: MitM attack: Plain text analysis

Application Visible GPS data available HTTPS/HTTPS9292 Yes HTTPBuienradar Yes HTTPNS Reisplanner Xtra Yes HTTPSchipol Amsterdam Airport No HTTPMaps No HTTPSShazam Yes HTTPSoundhound Yes HTTPSSpeedtest Yes HTTPTuneIn Radio Yes HTTPS

i p t a b l e s −−t ab l e nat −Fi p t a b l e s −−de l e t e−chaini p t a b l e s −−t ab l e nat −−de l e t e−chaini p t a b l e s −−t ab l e nat −−append POSTROUTING −−out−i n t e r f a c e wlan0 −j MASQUERADEip t ab l e s −t nat −A PREROUTING −p tcp −−dport 80 −j REDIRECT −−to−port s 8080i p t a b l e s −t nat −A PREROUTING −p tcp −−dport 443 −j REDIRECT −−to−port s 8443

mkdir /tmp/ s s l s p l i tmkdir /tmp/ s s l s p l i t / l o g d i r

s s l s p l i t −D − l connect ions . l og −j /tmp/ s s l s p l i t / −S l o gd i r / \−k ca . key −c ca . c r t s s l 0 . 0 . 0 . 0 8443 tcp 0 . 0 . 0 . 0 8080

The script sets the forwarding option to 1 in order to allow forwarding packets from thevictim to the Internet. The iptable rules, basically allow to redirect all the specified traffic tospecific ports that the attacker will listen to, in this experiment, we are interested in HTTP andHTTPS traffic.

The SSLsplit command generates the connection logs and will save them in the file specifiedwith the same name. It also uses a previously generated key, which is the private key of theserver (ca.key), and the self signed certificate (ca.crt) which also needs to be installed in thevictim’s device.

In this scenario, the attacker redirects all the traffic coming from the victim and sniffs it byusing the SSLsplit tool.

8

6.3 API communication

The communication between the investigated applications and their back-end servers, is doneusing predefined and implemented APIs. The conversation with those APIs is done in the formof HTTP REST calls. Since the communication itself has been reviewed in the previous sections,the next thing to look at is the implemented APIs on the server side. So far, we were only ableto leak GPS data from the requests that were being sent from the mobile apps to the server.However it is possible that information leaks from the server-side as well[14]. This means thatthe private information should be contained only in the response and not in the request. Inorder to test that, we are going to investigate two scenarios. The first one tries to find publiclyaccessible APIs which receive identifying information about a user or a device and respond withsome private information about that user or device. And the second scenario consists of sendingspoofed GPS location in the request to the server, in order to get data which should not beaccessible to the attacker in the response.

Since the traffic generated throughout the conducted experiments was dumped and decryptedwhenever needed, the APIs used by the tested applications were visible. Mainly GET and POSTmethods are being used for the communication. In order to reveal publicly exposed APIs whichmay be of interest, two approach were used.

For the first approach all of the URLs which were used for API calls were listed and OPTIONScall was issued for every one of those URL. Whenever the OPTIONS call is enabled on the serverside, it reveals what type of methods are available for this specific URL, they should be listedin the Allow header of the response (See Table 3.), so methods which are not being used by theapplications could be potentially revealed.

The second approach looks at URLs for which the OPTIONS methods were disabled. Sincewe are trying to retrieve data from the server, GET methods are of interest. Therefore for everyPOST or PUT method that was used by a given mobile application, also a GET methods wasattempted.

The downside for both approaches, however, is that hidden methods can only be discoveredfor the already known URLs. This means that if a hidden method uses a URL which is not beingused by the application, then it will not be discovered.

For the other scenario related to the API investigation, parameters passed along with theHTTP requests to the server were spoofed or omitted. The aim of this scenario was to trigger aresponse which will contain data which should not be accessible to that specific user, or in ourcase, the attacker.

There are applications for Android like “Fake GPS location” for example, which are able tochange the GPS parameters which are being stored on the mobile device, therefore allowing theother mobile applications to access the spoofed GPS location and include it in the HTTP requestto the server. The GPS spoofing was successful for all of the investigated applications and theirback-end servers responded according to the fake GPS location. The responses were, however,either valid and containing public information, or an error message was returned, stating thatthe spoofed location is not supported for this application.

Finally, in order to trigger unexpected responses from the server side, which may containsensitive information that is not included in the request, valid requests used by the applicationwere replayed and some of their parameters were omitted. Most of the investigated applicationsinclude a lot of parameters in their HTTP requests, but not all of them relate to the functionalityof the given application. For tested apps, by skipping noncritical parameters the server stillcreates a valid response. Skipping parameters which are needed for the functionality of the appgenerated either an error of malformed request, or it generated a valid response, according tothat data that the server had.

9

Table 3: This table shows the server response for an OPTIONS call to the URLs used for HTTPand HTTPS communication by the tested mobile applications. (In case no Allow header ispresent in the response, its HTTP code is shown. Also URL parameters are not shown. URLsrelated to mobile adds are also included)

URL Server Response

nl.sitestat.com/schiphol/schipholmob/ Allow - GET,HEAD,POST,OPTIONS

nl.sitestat.com/schiphol/ Allow - GET,HEAD,POST,OPTIONS

nl.sitestat.com Allow - GET,HEAD,POST,OPTIONS

ews-rpx.ns.nl/mobile-api-planner 501 Not Implemented

ews-rpx.ns.nl 501 Not Implemented

clients4.google.com 405 Method Not Allowed

lbs.buienradar.nl Allow - OPTIONS, TRACE, GET, HEAD, POST

lbs.buienradar.nl/forecast/xml 200 OK

api.9292.nl/0.1/journeys 500 Internal Server Error

api.9292.nl Allow - OPTIONS, TRACE, GET, HEAD, POST

data.flurry.com/aap.do 400 Bad Request

data.flurry.com Allow - GET, HEAD, POST, TRACE, OPTIONS

mediation.adnxs.com 501 Not Implemented

pubads.g.doubleclick.net/gampad/ads 405 Method Not Allowed

pubads.g.doubleclick.net 405 Method Not Allowed

https://secureapi.midomi.com 500 Internal Server Error

https://secureapi.midomi.com/v2/ 200 OK

www.speedtest.net 200 OK

www.speedtest.net/api/android/config.php 200 OK

opml.radiotime.com/Browse.ashx Allow - OPTIONS, TRACE, GET, HEAD, POST

ads.mopub.com 405 Method Not Allowed

The Speedtest application is sending the IMEI number in their GET calls, this is supposed tobe a unique identifier for every mobile device. By omitting the IMEI parameter from the requestgenerated by the Speedtest application, the server still generated a valid response. Therefore,that user identifying parameter is not critical for the functionality of the app, however it is stillbeing included in the requests to the server by the application.

All the tested applications are trying to communicate with an API to retrieve the requestedinformation. Some APIs require authentication from the application in order to communicate.The list of hosts for the APIs used by the applications is shown in Table 4.

10

Table 4: List of APIs

Application Host Authentication required9292 api.9292.nl NoBuienradar lbs.buienradar.nl NoNS Reisplanner Xtra ews-rpx.ns.nl YesSchipol Amsterdam Airport nl.sitestat.com NoMaps clients4.google.com NoShazam spike.shazamid.com YesSoundhound secureapi.midomi.com:443 NoSpeedtest www.speedtest.net/api NoTuneIn Radio opml.radiotime.com No

6.4 Results

Relevant information that can be used by an attacker is sent in plain text. Information such as theIMEI (International Mobile Equipment Identity) number was found to be sent by the Speedtestapplication. Some applications such as 9292 and Reisplanner, in order to work, they require haveexact GPS information retrieved by the GPS receiver at the moment the application is started.Although, if the user does not use the option ”Use current location”, and inputs the currentlocation by hand, the application will still work, by using the information submitted. Only ifthe user uses the option ”Use current location”, GPS data needs to be available in order forthe application to work properly. Other applications such as TuneIn Radio, Maps, Soundhound,Shazam, Schipol Amsterdam Airport and Speedtest do not require to have the GPS receiver inorder to work, but still, they send GPS information. It was found that they send stored GPSinformation from a previous location point if they do not have the GPS receiver enabled.

In the following section we show the relevant information that was extracted from the com-munication of the applications1:.

9292

• Used method: GET

• GPS data: 16 digits accuracy after the floating point for the latitude and the longitudevalues

GET /0.1/ journeys ? lang=en−GB&from=52.369%2C4.932& to=amsterdam−c en t r aa l HTTP/1.1User−Agent : Dalvik / 1 . 6 . 0 ( Linux ; U; Android 4 . 1 . 2 ; SGH−I897 Build /JZO54K)Host : api . 9 2 9 2 . n lConnection : Keep−Al iveAccept−Encoding : gz ip

Buienradar



1Some details like IMEI number, and GPS data length have been omitted for privacy reasons, and this is forall the applications

11

The information that is being sent by the application is shown below:

GET / f o r e c a s t /xml? l a t =51.692900& lon=4.994200& r=4 HTTP/1.1User−Agent : Dalvik / 1 . 6 . 0 ( Linux ; U; Android 4 . 1 . 2 ; SGH−I897 Build /JZO54K)Host : l b s . buienradar . n lConnection : Keep−Al iveAccept−Encoding : gz ip

NS Reisplanner Xtra




GET /mobile−api−planner ? fromLatLong=52.369%2C4.932& toSta t i on=Amsterdam+Centraal HTTP/1.1Author i zat ion : Bas ic YW5kcm9pZDptdmR6aWc=User−Agent : Reisp lannerXtra /3 .1 ( Android ; l e v e l : 1 6 )Host : ews−rpx . ns . n lConnection : Keep−Al iveAccept−Encoding : gzip , d e f l a t e

This application alse requires basic authentication which is provided in the GET call, and isencoded in base 64. The username and password decoded are: android:mvdzig, respectively.

Schipol Amsterdam Airport


• GPS data: not visible

• Type of network used (wifi in the experimental case)


GET / sch ipho l / schipholmob/ s ? f l i g h t s . f l i g h t d e t a i l s . index&c1=19&c4=Schiphol&ns rad i o=w i f i HTTP/1.1User−Agent : Dalvik / 1 . 6 . 0 ( Linux ; U; Android 4 . 1 . 2 ; SGH−I897 Build /JZO54K)Host : n l . s i t e s t a t . comConnection : Keep−Al iveAccept−Encoding : gz ip

Shazam



• Cell phone provider

• Root check

• Connection type (wifi)

• OS version

12


GET /mob? id=2127298& c a r r i e r=vodafone&GEOLOCATION=52.369%2C4.933&osv =4.1.2 HTTP/1.1User−Agent : Moz i l l a /5 .0 ( Linux ; U; Android 4 . 1 . 2 ; es−es ; SGH−I897 ; CyanogenMod−10.0 .0)Host : mediat ion . adnxs . comConnection : Keep−Al ive

Soundhound


• GPS data: 7 digits accuracy after the floating point for the latitude and the longitudevalues, sent in the User agent header.

• Cell phone provider

• Root check

• Connection type (wifi)


GET /v2/ s s l t e s t . php HTTP/1.1Host : s e cu r eap i . midomi . com:443Connection : Keep−Al iveCookie2 : $Vers ion=1User−Agent : AppNumber=31 APIVersion =2.0.0 FIRMWARE=4.1.2 eng . . 20121113 .043634

COUNTRY=nl NETWORK=WIFI LAT=52.369 LON=4.932 HACC=45.081 MAPS=1Accept−Encoding : gzip , d e f l a t e

Speedtest



• GSM cell ID

• IMEI

• Root check


GET /api / android / con f i g . php? ct=2&imei=351∗∗∗∗∗∗∗∗∗∗∗∗& l a t =52.369& lon =4.932 HTTP/1.1User−Agent : Dalvik / 1 . 6 . 0 ( Linux ; U; Android 4 . 1 . 2 ; SGH−I897 Build /JZO54K)Host : www. spe ed t e s t . netConnection : Keep−Al iveAccept−Encoding : gz ip

13

TuneIn Radio




GET /Config . ashx ? partner Id=xwhZkVKi&l a t l o n =52.369%2C4.932& render=json HTTP/1.1User−Agent : TuneIn Radio /12 .0 ( Android 16 ; SGH−I897 ; Java )Accept−Encoding : gzip , d e f l a t eAccept−Language : es−ESAccept−Charset : utf −8,∗Host : opml . rad iot ime . comConnection : Keep−Al ive

The response for every GET call that was sent is an HTTP or HTTPS was a 200 code (OK).The information is often encoded in gzip format, but there is no interesting data that can befound there, since it is just the response from the server to the application’s call.

The DNS requests that every application makes is shown in appendix A, where every requestis recorded, and some details about the hosts.

By analyzing the requests from the applications such as Soundhound, we can see that this ap-plication is sending geolocation data to pubads.g.doubleclick.net which is a domain used by Googleto send advertisement based on the location of the user. Shazam, in the other hand, commu-nicates with the domain mediation.adnxs.com, which is a domain that is related to marketingpurposes [15]. As well as the previously mentioned apps, TuneIn Radio also communicates withdomains that are related to advertising, this domains are ads.tunein.com and ads.mopub.com.This application also communicates with domains such as google-analytics.com, googletagman-ager.com, ads.mp.mydas.mobi that are domains related to marketing purposes. The weatherapp, Buienradar, also connects to a domain ticks2.bugsense.com, which is used for big dataanalysis.

A detailed log about all connections made the by the applications can be found in the Ap-pendix B.

The API discovery approach, on the other hand did not reveal any hidden APIs which areleaking interesting data. Also spoofing the parameters which are being sent along to the back-endservers did not trigger any unpredictable behavior.

7 Countermeasures

In this section, we discuss some techniques that can be used by the user as countermeasures toavoid sending geolocation data when using this type of applications.

7.1 Disabling GPS

When disabling the GPS receiver, an application like 9292 simply will not work because it requiresvalid GPS location data in order to function properly.

Applications like Soundhound, Shazam, Speedtest, TuneIn Radio, even when disabling GPS,it was found that they send GPS data over the network. The GPS information that is beingsent, is the previously recorded location.

14

7.2 Deleting GPS data

Deleting GPS information from the device might seem like a solution in order to prevent ap-plications using this information. Several attempts to erase this kind of data were made, likeerasing the content of the /data/gps folder, which requires root access, and erasing the cachefiles for the applications, but none of these attempts prevented the applications to send the GPSinformation, because it was found that they still use previous location points.

7.3 Location spoofers

Existing applications to prevent using real location data can be used. This applications areopenly available to download, but they require a rooted device in order to work properly. Whatthese applications do, is they enable the ACCESS MOCK LOCATION [16] setting, that is used to testapplications using “fake” location data.

For this research, we tested the Location Spoofer application [17]. Some applications weretested in order to check what kind of location data is being used.

Applications such as 9292 and Reisplanner see the spoofed location data and they give an errormessage that states that the current location is not supported, see Figure 4a. Other applicationslike Soundhound, Shazam and Speedtest keep working perfectly fine, and the communicationbetween the app and the server sends as parameters the spoofed location. As an example,the Speedtest application, see Figure 4b, shows that the latency of the ping test has increasedcompared to the latency of the same test using real location. And that is because the applicationis connecting to the closest servers based on the spoofed location.

(a) 9292 application (b) Speedtest application

Figure 4: Applications using spoofed location

The geolocation data is sent in the GET method. For the Speedtest application, this data isshown below, where the values for latitude and longitude are provided by the location spooferapplication. As shown below, we can see that the application is using as parameters the latitudeas -0.127 and the longitude as -78.468, which is the location specified in the location spooferapplication.

GET /api / android / con f i g . php? l a t =−0.12700& lon=−78.46800 HTTP/1.1

15

User−Agent : Dalvik / 1 . 6 . 0 ( Linux ; U; Android 4 . 1 . 2 ; SGH−I897 Build /JZO54K)Host : www. spe ed t e s t . netConnection : Keep−Al iveAccept−Encoding : gz ip

Based on these results we can conclude that by spoofing the location of the device, we canconvince the application to use the fake location instead of the real one.

7.4 Use HTTPS

The above discussed methods are suitable for applications which functionality does not criticallydepend on the GPS location of the device. However this is not always the case. Navigationapplications for example require real GPS data in order to function properly. The solution forsuch applications would be to only use the ones that communicate with their servers over secureconnection. There is a big variety of applications on the market and some of them do implementHTTPS.

8 Conclusion

From the captured traffic and API investigation, it is clear that GPS location data is beingreported from mobile application to their back-end servers and in a lot of the cases this is donein plain text. Some applications also send along user identifying information, which can be usedto link users with geographical locations. The investigated applications did not reveal to leakany sensitive information from the server side via the implemented APIs, however there are a lotother applications on the market, that may do that.

In conclusion, it is possible to track users who make use of mobile application that accessGPS data from the device on which they are running. However in order to do that, one mustintercept the traffic between the device and the server used by the mobile app. This makes theattack unfeasible for most attackers. Governmental organizations, ISPs and other parties whichkeep taps on Internet traffic on the other hand can easily catch the plane text requests that themobile apps are generating and extract geographical location data, sometimes accompanied withuser identifying data. Making location user tracking by attackers with big resources, easy.

9 Future work

In this research only nine mobile applications were investigated, however there are a lot moreother applications on the market, that make use of GPS-data. Every single one of them could po-tentially leak sensitive information in a different way. Therefore investigating other applicationswith large installed base will always be interesting.

Another approach that that might reveal interesting insides on how a certain applicationhandles and makes use of GPS information would be reverse engineering the applications bydecompiling and investigating the functions that handle sensitive data.

16

References

[1] Xda Developers. Understanding Android GPS Architecture. http://forum.

xda-developers.com/showthread.php?t=2063295, 2012.

[2] Roy Thomas Fielding. Architectural Styles and the Design of Network-based SoftwareArchitectures. University of California, Irvine, 2000.

[3] Andrew van der Stock Erlend Oftedal. REST Security Cheat Sheet. https://www.owasp.

org/index.php/REST_Security_Cheat_Sheet, 2014.

[4] Tech Republic. Probing Android permissions. http://www.techrepublic.com/blog/

it-security/does-your-flashlight-app-know-where-you-are-probing-android-permissions/,2012.

[5] 9292 - travel planner. http://9292.nl.

[6] Buienradar - weather application. http://www.buienradar.nl/.

[7] Reisplanner - travel planner. http://www.ns.nl/.

[8] Amsterdam airport schiphol application. http://www.schiphol.nl/.

[9] Google maps - navigation application. http://www.google.com/maps/about.

[10] Shazam - music recognition application. http://www.shazam.com/.

[11] Soundhound - music recognition application. http://www.soundhound.com.

[12] Speedtest - connection speed test. http://www.speedtest.net/mobile/.

[13] Tunein radio - access to world wide radio stations. http://tunein.com/.

[14] Blake Dournaee. Data Leak Prevention and APIs. http://blogs.intel.com/

application-security/2012/03/26/data-leak-prevention-and-apis/, 2012.

[15] Whois. WHOIS: ADNX. http://whois.domaintools.com/adnxs.com, 2014.

[16] Android Developers. Testing Using Mock Locations. http://developer.android.com/

training/location/location-testing.html, 2014.

[17] Trackdroid. Location Spoofer. http://www.trackdroid.org/, 2014.

17

http://forum.xda-developers.com/showthread.php?t=2063295

http://forum.xda-developers.com/showthread.php?t=2063295

https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

http://www.techrepublic.com/blog/it-security/does-your-flashlight-app-know-where-you-are-probing-android-permissions/

http://www.techrepublic.com/blog/it-security/does-your-flashlight-app-know-where-you-are-probing-android-permissions/

http://9292.nl

http://www.buienradar.nl/

http://www.ns.nl/

http://www.schiphol.nl/

http://www.google.com/maps/about

http://www.shazam.com/

http://www.soundhound.com

http://www.speedtest.net/mobile/

http://tunein.com/

http://blogs.intel.com/application-security/2012/03/26/data-leak-prevention-and-apis/

http://blogs.intel.com/application-security/2012/03/26/data-leak-prevention-and-apis/

http://whois.domaintools.com/adnxs.com

http://developer.android.com/training/location/location-testing.html

http://developer.android.com/training/location/location-testing.html

http://www.trackdroid.org/

A DNS requests

This appendix shows every DNS request that was made from the applications.

Application IP address DNS name Description9292 87.213.37.14 9292.nl REISinformatiegroep B.V.

Buienradar

217.118.160.113 N/A RTL-Netherlands217.118.160.21 rtl.nl RTL-Netherlands217.118.167.135 N/A Buienradar BV217.118.167.200 N/A Buienradar BV54.193.121.17 N/A54.193.63.135 N/A77.72.112.154 N/A Nedstat Application and Service Network77.72.116.154 N/A comScore Application and Service Network77.72.118.154 N/A82.94.174.142 N/A Buienradar BV82.94.174.30 N/A Buienradar BV95.100.97.27 N/A Akamai Technologies

Maps74.125.136.101 google.com Google Inc.74.125.136.102 google.com Google Inc.

Reisplanner23.206.89.169 N/A Akamai International, BV74.125.136.102 google.com Google Inc.

Schipol Airport31.13.64.65 facebook.com Facebook Ireland Ltd77.72.118.154 N/A comScore Application and Service Network93.186.185.171 N/A M2Mobi BV

Shazam

185.31.16.192 Fastly Amsterdam 1 Operations185.31.17.129 Fastly Frankfurt 1 Operations194.126.240.3 Shazam Entertainment Limited209.15.194.214 Peer 1 Dedicated Hosting209.15.194.251 Peer 1 Dedicated Hosting31.13.64.145 Facebook Ireland Ltd37.252.162.35 AMS1 IB Net - Public VIPs37.252.170.77 FRA1 IB Net - Public VIPs74.217.75.7 Flurry, Inc.95.100.97.24 Akamai Technologies

Soundhound

173.194.65.155 google.com Google Inc.8.25.217.14 data.midomi.com Level 3 Communications, Inc.8.25.217.24 data.midomi.com Level 3 Communications, Inc.95.100.97.27 Akamai Technologies

Speedtest173.194.65.113 google.com Google Inc.85.159.239.121 NForce Entertainment B.V.93.184.219.82 NETBLK-03-EU-93-184-219-0-24

TuneIn Radio

107.6.111.235 Voxel Dot Net, Inc.162.217.102.229 Voxel Dot Net, Inc.173.194.113.190 google.com Google Inc.184.72.219.169 try.crashlytics.com Amazon.com, Inc.208.43.117.131 SoftLayer Technologies Inc.216.157.12.18 Peer 1 Dedicated Hosting38.102.159.20 PSINet, Inc.38.102.159.5 PSINet, Inc.54.247.89.208 Amazon Technologies Inc.

18

B Detailed log communication for the tested applications

This appendix shows a detailed log for all connections made by every tested application.

9292

2014-05-11 00:41:51 UTC ssl [192.168.0.102]:42930 [87.213.37.14]:443sni:api.9292.nl crt:www.9292.nl/www.9292.nl/api.9292.nl/api-acc.9292.nl/reisadvies-api-ast.9292.nl/reisadvies-api.9292.nl/labs.9292.nl/9292.nl origcrt:www.9292.nl/www.9292.nl/api.9292.nl/api-acc.9292.nl/reisadvies-api-ast.9292.nl/reisadvies-api.9292.nl/labs.9292.nl/9292.nl

Buienradar

2014-05-11 13:42:41 UTC tcp [192.168.0.102]:35419 [217.118.160.21]:802014-05-11 13:42:41 UTC ssl [192.168.0.102]:49184 [54.193.121.17]:443sni:- crt:ticks2.bugsense.com origcrt:ticks2.bugsense.com2014-05-11 13:42:43 UTC tcp [192.168.0.102]:47311 [82.94.174.30]:802014-05-11 13:42:45 UTC tcp [192.168.0.102]:57439 [77.72.116.154]:80

Google Maps

2014-05-11 11:19:26 UTC ssl [192.168.0.102]:36138 [74.125.136.101]:443sni:- crt:*.google.com/*.google.com/*.android.com/*.appengine.google.com/*.cloud.google.com/*.google-analytics.com/*.google.ca/*.google.cl/*.google.co.in/*.google.co.jp/*.google.co.uk/*.google.com.ar/*.google.com.au/*.google.com.br/*.google.com.co/*.google.com.mx/*.google.com.tr/*.google.com.vn/*.google.de/*.google.es/*.google.fr/*.google.hu/*.google.it/*.google.nl/*.google.pl/*.google.pt/*.googleapis.cn/*.googlecommerce.com/*.googlevideo.com/*.gstatic.com/*.gvt1.com/*.urchin.com/*.url.google.com/*.youtube-nocookie.com/*.youtube.com/*.youtubeeducation.com/*.ytimg.com/android.com/g.co/goo.gl/google-analytics.com/google.com/googlecommerce.com/urchin.com/youtu.be/youtube.com/youtubeeducation.com origcrt:*.google.com/*.google.com/*.android.com/*.appengine.google.com/*.cloud.google.com/*.google-analytics.com/*.google.ca/*.google.cl/*.google.co.in/*.google.co.jp/*.google.co.uk/*.google.com.ar/*.google.com.au/*.google.com.br/*.google.com.co/*.google.com.mx/*.google.com.tr/*.google.com.vn/*.google.de/*.google.es/*.google.fr/*.google.hu/*.google.it/*.google.nl/*.google.pl/*.google.pt/*.googleapis.cn/*.googlecommerce.com/*.googlevideo.com/*.gstatic.com/*.gvt1.com/*.urchin.com/*.url.google.com/*.youtube-nocookie.com/*.youtube.com/*.youtubeeducation.com

19

/*.ytimg.com/android.com/g.co/goo.gl/google-analytics.com/google.com/googlecommerce.com/urchin.com/youtu.be/youtube.com/youtubeeducation.com

Reisplanner

2014-05-11 09:34:34 UTC tcp [192.168.0.102]:39903 [23.206.89.169]:802014-05-11 09:34:37 UTC tcp [192.168.0.102]:57717 [74.125.136.102]:802014-05-11 09:34:49 UTC tcp [192.168.0.102]:56069 [23.206.89.169]:802014-05-11 09:40:17 UTC tcp [192.168.0.102]:55045 [74.125.136.113]:80

Schipol Amsterdam Airport

2014-05-11 10:33:30 UTC tcp [192.168.0.102]:38054 [93.186.185.171]:802014-05-11 10:33:48 UTC tcp [192.168.0.102]:54066 [77.72.118.154]:802014-05-11 10:34:12 UTC tcp [192.168.0.102]:35815 [93.186.185.171]:802014-05-11 10:34:13 UTC ssl [192.168.0.102]:37742 [93.186.185.171]:443sni:- crt:scripts.schipholmobile.com/scripts.schipholmobile.comorigcrt:scripts.schipholmobile.com/scripts.schipholmobile.com

Shazam

2014-05-11 19:49:01 UTC ssl [192.168.0.102]:59195 [31.13.64.145]:443sni:graph.facebook.com crt:*.facebook.com/*.facebook.com/facebook.com/*.fbsbx.com/*.fbcdn.net/*.xx.fbcdn.net/*.xy.fbcdn.netorigcrt:*.facebook.com/*.facebook.com/facebook.com/*.fbsbx.com/*.fbcdn.net/*.xx.fbcdn.net/*.xy.fbcdn.net2014-05-11 19:49:21 UTC tcp [192.168.0.102]:49115 [95.100.97.24]:802014-05-11 19:49:21 UTC tcp [192.168.0.102]:57133 [74.217.75.7]:802014-05-11 19:49:22 UTC tcp [192.168.0.102]:36740 [194.126.240.3]:802014-05-11 19:49:50 UTC tcp [192.168.0.102]:34919 [185.31.16.192]:802014-05-11 19:50:12 UTC ssl [192.168.0.102]:54954 [209.15.194.251]:443sni:beacon.shazam.com crt:beacon.shazam.com/beacon.shazam.com origcrt:beacon.shazam.com/beacon.shazam.com2014-05-11 19:50:13 UTC ssl [192.168.0.102]:36649 [209.15.194.251]:443sni:beacon.shazam.com crt:beacon.shazam.com/beacon.shazam.comorigcrt:beacon.shazam.com/beacon.shazam.com2014-05-11 19:50:24 UTC tcp [192.168.0.102]:49397 [37.252.162.35]:802014-05-11 19:50:24 UTC ssl [192.168.0.102]:39023 [185.31.17.129]:443sni:cdn.shazam.com crt:*.a.ssl.fastly.net/*.a.ssl.fastly.net/a.ssl.fastly.net/*.fastly.com/fast.wistia.com/purge.fastly.net/mirrors.fastly.net/*.imgix.net/signin.epek.com/*.parsecdn.com/*.fastssl.net/voxer.com/www.voxer.com/*.firebase.com/sites.yammer.com/sites.staging.yammer.com/*.skimlinks.com/*.skimresources.com/assets.wantful.com/cdn.thinglink.me/*.fitbit.com/*.hosts.fastly.net/control.fastly.net/*.perfectaudience.com/*.wikia-inc.com/*.wikia.com/f.cloud.github.com/*.digitalscirocco.net/*.etsy.com/*.etsystatic.com/*.addthis.com/*.addthiscdn.com/fast.wistia.net/raw.github.com/www.userfox.com/*.assets-yammer.com/*.staging.assets-yammer.com/assets.huggies-cdn.net/api.kinja.com/orbit.shazamid.com/about.jstor.org/*.global.ssl.fastly.net/web.voxer.com/pypi.python.org/*.12wbt.com/www.holderdeord.no/secured.resources.infolinks.com/secured.indn.infolinks.com/play.vidyard.com/play-staging.vidyard.com/secure.img.wfrcdn.com/secure.img.josscdn.com/*.gocardless.com/widgets.pinterest.com/*.7digital.com/*.7static.com/p.datadoghq.com

20

/*.plan3.se/new.mulberry.com/www.safariflow.com/*.stelladot.com/*.stelladotstg.com/api.altmetric.com/cdn.contentful.com/tools.fastly.net/*.huevosbuenos.com/*.goodeggs.com/www.onelogin.com/*.fastly.picmonkey.com/*.cdn.whipplehill.net/*.whipplehill.net/cdn.media34.whipplehill.net/cdn.media56.whipplehill.net/cdn.media78.whipplehill.net/cdn.media910.whipplehill.net/*.modcloth.com/*.disquscdn.com/*.jstor.org/www.flinto.com/*.dreamhost.com/*.chartbeat.com/*.hipmunk.com/content.beaverbrooks.co.uk/*.vsco.co/secure.common.csnstores.com/www.joinos.com/staging-mobile-collector.newrelic.com/*.modcloth.net/*.foursquare.com/images.12wbtpreview.com/*.shazam.com/*.4sqi.net/*.metacpan.org origcrt:*.a.ssl.fastly.net/*.a.ssl.fastly.net/a.ssl.fastly.net/*.fastly.com/fast.wistia.com/purge.fastly.net/mirrors.fastly.net/*.imgix.net/signin.epek.com/*.parsecdn.com/*.fastssl.net/voxer.com/www.voxer.com/*.firebase.com/sites.yammer.com/sites.staging.yammer.com/*.skimlinks.com/*.skimresources.com/assets.wantful.com/cdn.thinglink.me/*.fitbit.com/*.hosts.fastly.net/control.fastly.net/*.perfectaudience.com/*.wikia-inc.com/*.wikia.com/f.cloud.github.com/*.digitalscirocco.net/*.etsy.com/*.etsystatic.com/*.addthis.com/*.addthiscdn.com/fast.wistia.net/raw.github.com/www.userfox.com/*.assets-yammer.com/*.staging.assets-yammer.com/assets.huggies-cdn.net/api.kinja.com/orbit.shazamid.com/about.jstor.org/*.global.ssl.fastly.net/web.voxer.com/pypi.python.org/*.12wbt.com/www.holderdeord.no/secured.resources.infolinks.com/secured.indn.infolinks.com/play.vidyard.com/play-staging.vidyard.com/secure.img.wfrcdn.com/secure.img.josscdn.com/*.gocardless.com/widgets.pinterest.com/*.7digital.com/*.7static.com/p.datadoghq.com/*.plan3.se/new.mulberry.com/www.safariflow.com/*.stelladot.com/*.stelladotstg.com/api.altmetric.com/cdn.contentful.com/tools.fastly.net/*.huevosbuenos.com/*.goodeggs.com/www.onelogin.com/*.fastly.picmonkey.com/*.cdn.whipplehill.net/*.whipplehill.net/cdn.media34.whipplehill.net/cdn.media56.whipplehill.net/cdn.media78.whipplehill.net/cdn.media910.whipplehill.net/*.modcloth.com/*.disquscdn.com/*.jstor.org/www.flinto.com/*.dreamhost.com/*.chartbeat.com/*.hipmunk.com/content.beaverbrooks.co.uk/*.vsco.co/secure.common.csnstores.com/www.joinos.com/staging-mobile-collector.newrelic.com/*.modcloth.net/*.foursquare.com/images.12wbtpreview.com/*.shazam.com/*.4sqi.net/*.metacpan.org2014-05-11 19:50:39 UTC tcp [192.168.0.102]:53802 [209.15.194.214]:802014-05-11 19:50:40 UTC tcp [192.168.0.102]:57504 [209.15.194.214]:802014-05-11 19:50:59 UTC tcp [192.168.0.102]:50143 [37.252.170.77]:802014-05-11 19:51:04 UTC tcp [192.168.0.102]:57042 [185.31.17.129]:80

Soundhound

2014-05-11 10:57:44 UTC ssl [192.168.0.102]:34607 [8.25.217.14]:443sni:- crt:secureapi.midomi.com/secureapi.midomi.com/www.secureapi.midomi.comorigcrt:secureapi.midomi.com/secureapi.midomi.com/www.secureapi.midomi.com2014-05-11 10:58:16 UTC tcp [192.168.0.102]:36332 [95.100.97.27]:802014-05-11 10:58:20 UTC tcp [192.168.0.102]:40401 [173.194.65.155]:802014-05-11 10:58:20 UTC tcp [192.168.0.102]:45197 [74.125.136.105]:802014-05-11 10:58:59 UTC tcp [192.168.0.102]:47260 [173.194.65.155]:802014-05-11 10:59:20 UTC tcp [192.168.0.102]:45456 [74.125.136.154]:802014-05-11 10:59:45 UTC tcp [192.168.0.102]:50682 [74.125.143.94]:80

21

Speedtest

2014-05-11 10:20:09 UTC tcp [192.168.0.102]:45443 [74.125.136.154]:802014-05-11 10:20:10 UTC tcp [192.168.0.102]:35016 [74.125.136.99]:802014-05-11 10:20:11 UTC tcp [192.168.0.102]:53044 [93.184.219.82]:802014-05-11 10:20:30 UTC tcp [192.168.0.102]:57042 [173.194.65.157]:802014-05-11 10:20:34 UTC tcp [192.168.0.102]:57818 [85.159.239.121]:802014-05-11 10:21:05 UTC tcp [192.168.0.102]:35136 [173.194.65.113]:80

TuneIn Radio

2014-05-11 11:37:52 UTC ssl [192.168.0.102]:57818 [173.194.39.30]:443sni:- crt:*.google-analytics.com/*.google-analytics.com/google-analytics.com/googletagmanager.com/service.urchin.com/ssl.google-analytics.com/urchin.com/www.google-analytics.com/www.googletagmanager.com origcrt:*.google-analytics.com/*.google-analytics.com/google-analytics.com/googletagmanager.com/service.urchin.com/ssl.google-analytics.com/urchin.com/www.google-analytics.com/www.googletagmanager.com2014-05-11 11:38:04 UTC ssl [192.168.0.102]:33075 [184.72.219.169]:443sni:settings.crashlytics.comcrt:*.crashlytics.com/*.crashlytics.com/crashlytics.com origcrt:*.crashlytics.com/*.crashlytics.co/crashlytics.com2014-05-11 11:38:04 UTC ssl [192.168.0.102]:51605 [38.102.159.5]:443 sni:opml.radiotime.comcrt:*.radiotime.com/*.radiotime.com/radiotime.com origcrt:*.radiotime.com/*.radiotime.com/radiotime.com2014-05-11 11:38:08 UTC tcp [192.168.0.102]:39454 [38.102.159.5]:802014-05-11 11:38:13 UTC ssl [192.168.0.102]:38856 [173.194.113.190]:443sni:- crt:*.google-analytics.com/*.google-analytics.com/google-analytics.com/googletagmanager.com/service.urchin.com/ssl.google-analytics.com/urchin.com/www.google-analytics.com/www.googletagmanager.com origcrt:*.google-analytics.com/*.google-analytics.com/google-analytics.com/googletagmanager.com/service.urchin.com/ssl.google-analytics.com/urchin.com/www.google-analytics.com/www.googletagmanager.com2014-05-11 11:38:27 UTC tcp [192.168.0.102]:47694 [54.247.89.208]:802014-05-11 11:38:27 UTC ssl [192.168.0.102]:43056 [38.102.159.20]:443sni:api.radiotime.com crt:*.radiotime.com/*.radiotime.com/radiotime.com origcrt:*.radiotime.com/*.radiotime.com/radiotime.com 2014-05-11 11:40:17 UTC ssl [192.168.0.102]:40731 [216.157.12.18]:443sni:- crt:*.ads.mp.mydas.mobi/*.ads.mp.mydas.mobi/ads.mp.mydas.mobi origcrt:*.ads.mp.mydas.mobi/*.ads.mp.mydas.mobi/ads.mp.mydas.mobi

22

gps-based user tracking using mobile apps

Documents