GPS-based user tracking using mobile apps

Transcription

1 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 by exploiting geographical GPS-data leakages of applications which support or require GPS usage. In this report the focus is on the network traffic which is generated by the apps and on the APIs of the servers with which these applications communicate. Nine applications were researched and the results reveal that in many cases GPS coordinates of the mobile device of the user are being sent over the network in plain text. Those coordinates are sent along with a lot of other device specification parameters like application version, OS version and type, device type, preferred language, build version, etc. Those parameters could be useful for identifying a unique device. Sometimes specifically identifying information like IMEI of the SIM card is also being sent in plain text. The API tests did not reveal any leakage of sensitive information for the apps that were tested. In conclusion, tracking of mobile application users is possible if the attacker can intercept the traffic which is being sent from the application to the back-end server. 1

2 Contents 1 Introduction 4 2 Background information Android GPS Architecture APIs and HTTP REST Calls Related work 5 4 Scope 5 5 Approach App selection Experimental work Experiments and attacks Man in the Middle Attack: Plain text Man in the Middle Attack: SSL sniffing API communication Results Countermeasures Disabling GPS Deleting GPS data Location spoofers Use HTTPS Conclusion 16 9 Future work 16 A DNS requests 18 B Detailed log communication for the tested applications 19 2

3 List of Figures 1 Android GPS architecture Typical operating environment Man in the Middle attack Applications using spoofed location List of Tables 1 Tested applications MitM attack: Plain text analysis 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 case no Allow header is present in the response, its HTTP code is shown. Also URL parameters are not shown. URLs related to mobile adds are also included) List of APIs

4 1 Introduction We live in an era when mobile software applications are widely used by people all around the world. Big part of those applications ask for access to the GPS data from the device on which they are installed. In most of the cases this data is being reported to a back-end server. This can 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 owner of that particular device and should be treated as sensitive information which should not be able to leak and become available to third parties. This research focuses on the possibility to exploit an Android mobile application in such a way that the attacker will be able to retrieve the GPS location 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 information was useful when investigating how some Android applications work, what kind of technology is 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 to user 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 and reads the data coming from it. This data is then processed by the GL Engine, which also stores relevant data in the /data/gps/gldata.sto (NVRAM) file. The GL Engine works by using configuration parameters to provide the intended functionality, as well as by using the location provided by the network or cellphone provider. The Android Location Services, is the service that communicates with the GL Engine to retrieve location data, and this information is then passed to the user level application, that is gps-based applications in general [1]. 4

5 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 mobile application sends an HTTP request, an HTTP response is sent back from the server to the client. The implementation of this kind of communication, which is used by HTTP, is called Representational State Transfer (REST) [2]. A REST request consists of an URL which identifies the 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 have headers which are passed along with the request. For example, if a cookie needs to be passed, it will be set as a header [3]. Another important part is the body, where larger data chunks can be passed along. There are also different types of requests based on their purpose. Some examples are: 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 that the 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 applications. However every application is is different and should be investigated separately. There are many reports stating the concern about privacy issues on some applications that may be leaking private or sensitive information across the network [4]. Many of these applications require the user to grant permissions on his/her device in order to access this information, but there are applications that should be able to work properly without accessing this kind of sensitive information. Therefore, investigating the communication of some of these applications is relevant in order 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 determine if GPS-data and other user sensitive information is being leaked. A relevant scenario for this research, is having an attacker tracking the geographical location of a person that uses a mobile 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 since he could retrieve the GPS data stored on the device directly. Therefore, this research includes only network traffic investigation and communication with related back-end servers. 5

6 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 be found. Interact with the APIs that the applications are using to try to retrieve relevant information. 5.1 App selection Interesting applications to be researched in this project, are the ones that have large installed base 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] Buienradar [6] v4.8.1 NS Reisplanner Xtra [7] Schiphol Amsterdam Airport [8] Maps [9] Shazam [10] JB85854 Soundhound [11] Speedtest [12] TuneIn Radio [13] Experimental work In order to find a way to extract GPS-data from the selected applications, four different scenarios will be defined. First we will investigate the traffic between the application itself and the server and check if there is no encryption used. If this is the case, we are going to investigate the message format and extract useful information, that is, information that can be used to track a user. In case TLS/SSL is used for encrypting traffic, we will attempt to conduct a Man in the Middle Attack and use a self signed certificate to install it on the mobile device in order to be able to decrypt the generated traffic. If those two attempts are not successful, we will try to exploit an API that the back-end may provide and try to extract sensitive information by interacting with that API. And finally we will investigate if the server leaks information in responses outside of the encrypted channel. 6

7 6 Experiments and attacks The typical operating environment for an Android application, is shown in Figure 2. In this environment, the application connects to the Internet through a wireless access point to further interact 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 from other applications, we used a firewall application called Droidwall, which blocks traffic from specific 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 traffic that is generated from the application and retrieve relevant information. The setup environment is shown in Figure 3. Here, all the traffic generated by the application is redirected to the attacker, and then it is forwarded to the Internet. That way, the attacker can analyze all traffic coming from the application. To be able to redirect the traffic from the applications, we used the tool Arpspoof which fools the device to send traffic to a spoofed gateway, and that is the attacker s device. arpspoof i wlan0 t arpspoof i wlan0 t 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 IP address is the victim, and the IP address is the router s address. Every application was tested, and not all of them are sending information in plain text. The results are shown in Table 2. All applications use the GPS data, and for most of them, this information 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 self signed certificate that was installed on the victim s device. All traffic generated by the application is sent to the attacker s machine which is running SSLsplit, a tool to perform Man in the Middle attacks on TLS/SSL traffic. The following script was used to perform the attack: #!/ bin / sh s y s c t l w net. ipv4. i p f o r w a r d=1 i p t a b l e s F 7

8 Figure 3: Man in the Middle attack Table 2: MitM attack: Plain text analysis Application Visible GPS data available HTTPS/HTTPS 9292 Yes HTTP Buienradar Yes HTTP NS Reisplanner Xtra Yes HTTP Schipol Amsterdam Airport No HTTP Maps No HTTPS Shazam Yes HTTP Soundhound Yes HTTPS Speedtest Yes HTTP TuneIn Radio Yes HTTPS i p t a b l e s t a b l e nat F i p t a b l e s d e l e t e c hain i p t a b l e s t a b l e nat d e l e t e c hain i p t a b l e s t a b l e nat append POSTROUTING out i n t e r f a c e wlan0 j MASQUERADE i p t a b l e s t nat A PREROUTING p tcp dport 80 j REDIRECT to p o r t s 8080 i p t a b l e s t nat A PREROUTING p tcp dport 443 j REDIRECT to p o r t s 8443 mkdir mkdir /tmp/ s s l s p l i t /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 c o n n e c t i o n s. l o g j /tmp/ s s l s p l i t / S l o g d i r / \ k ca. key c ca. c r t s s l tcp The script sets the forwarding option to 1 in order to allow forwarding packets from the victim to the Internet. The iptable rules, basically allow to redirect all the specified traffic to specific ports that the attacker will listen to, in this experiment, we are interested in HTTP and HTTPS traffic. The SSLsplit command generates the connection logs and will save them in the file specified with the same name. It also uses a previously generated key, which is the private key of the server (ca.key), and the self signed certificate (ca.crt) which also needs to be installed in the victim s device. In this scenario, the attacker redirects all the traffic coming from the victim and sniffs it by using the SSLsplit tool. 8

9 6.3 API communication The communication between the investigated applications and their back-end servers, is done using predefined and implemented APIs. The conversation with those APIs is done in the form of 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 able to 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 that the private information should be contained only in the response and not in the request. In order to test that, we are going to investigate two scenarios. The first one tries to find publicly accessible APIs which receive identifying information about a user or a device and respond with some private information about that user or device. And the second scenario consists of sending spoofed GPS location in the request to the server, in order to get data which should not be accessible to the attacker in the response. Since the traffic generated throughout the conducted experiments was dumped and decrypted whenever needed, the APIs used by the tested applications were visible. Mainly GET and POST methods are being used for the communication. In order to reveal publicly exposed APIs which may be of interest, two approach were used. For the first approach all of the URLs which were used for API calls were listed and OPTIONS call was issued for every one of those URL. Whenever the OPTIONS call is enabled on the server side, it reveals what type of methods are available for this specific URL, they should be listed in the Allow header of the response (See Table 3.), so methods which are not being used by the applications could be potentially revealed. The second approach looks at URLs for which the OPTIONS methods were disabled. Since we are trying to retrieve data from the server, GET methods are of interest. Therefore for every POST or PUT method that was used by a given mobile application, also a GET methods was attempted. The downside for both approaches, however, is that hidden methods can only be discovered for the already known URLs. This means that if a hidden method uses a URL which is not being used by the application, then it will not be discovered. For the other scenario related to the API investigation, parameters passed along with the HTTP requests to the server were spoofed or omitted. The aim of this scenario was to trigger a response which will contain data which should not be accessible to that specific user, or in our case, the attacker. There are applications for Android like Fake GPS location for example, which are able to change the GPS parameters which are being stored on the mobile device, therefore allowing the other mobile applications to access the spoofed GPS location and include it in the HTTP request to the server. The GPS spoofing was successful for all of the investigated applications and their back-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 that the spoofed location is not supported for this application. Finally, in order to trigger unexpected responses from the server side, which may contain sensitive information that is not included in the request, valid requests used by the application were replayed and some of their parameters were omitted. Most of the investigated applications include a lot of parameters in their HTTP requests, but not all of them relate to the functionality of the given application. For tested apps, by skipping noncritical parameters the server still creates a valid response. Skipping parameters which are needed for the functionality of the app generated either an error of malformed request, or it generated a valid response, according to that data that the server had. 9

10 Table 3: 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 case no Allow header is present in the response, its HTTP code is shown. Also URL parameters are not shown. URLs related to mobile adds are also included) URL nl.sitestat.com/schiphol/schipholmob/ nl.sitestat.com/schiphol/ nl.sitestat.com ews-rpx.ns.nl/mobile-api-planner ews-rpx.ns.nl clients4.google.com lbs.buienradar.nl lbs.buienradar.nl/forecast/xml api.9292.nl/0.1/journeys api.9292.nl data.flurry.com/aap.do data.flurry.com mediation.adnxs.com pubads.g.doubleclick.net/gampad/ads pubads.g.doubleclick.net opml.radiotime.com/browse.ashx ads.mopub.com Server Response Allow - GET,HEAD,POST,OPTIONS Allow - GET,HEAD,POST,OPTIONS Allow - GET,HEAD,POST,OPTIONS 501 Not Implemented 501 Not Implemented 405 Method Not Allowed Allow - OPTIONS, TRACE, GET, HEAD, POST 200 OK 500 Internal Server Error Allow - OPTIONS, TRACE, GET, HEAD, POST 400 Bad Request Allow - GET, HEAD, POST, TRACE, OPTIONS 501 Not Implemented 405 Method Not Allowed 405 Method Not Allowed 500 Internal Server Error 200 OK 200 OK 200 OK Allow - OPTIONS, TRACE, GET, HEAD, POST 405 Method Not Allowed The Speedtest application is sending the IMEI number in their GET calls, this is supposed to be a unique identifier for every mobile device. By omitting the IMEI parameter from the request generated 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 still being included in the requests to the server by the application. All the tested applications are trying to communicate with an API to retrieve the requested information. 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

11 Table 4: List of APIs Application Host Authentication required 9292 api.9292.nl No Buienradar lbs.buienradar.nl No NS Reisplanner Xtra ews-rpx.ns.nl Yes Schipol Amsterdam Airport nl.sitestat.com No Maps clients4.google.com No Shazam spike.shazamid.com Yes Soundhound secureapi.midomi.com:443 No Speedtest No TuneIn 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 the IMEI (International Mobile Equipment Identity) number was found to be sent by the Speedtest application. Some applications such as 9292 and Reisplanner, in order to work, they require have exact 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 current location by hand, the application will still work, by using the information submitted. Only if the user uses the option Use current location, GPS data needs to be available in order for the 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 in order to work, but still, they send GPS information. It was found that they send stored GPS information 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 communication of the applications 1 : Used method: GET GPS data: 16 digits accuracy after the floating point for the latitude and the longitude values GET / 0. 1 / j o u r n e y s? l a n g=en GB&from =52.369%2C4.932& to=amsterdam c e n t r a a l HTTP/ 1. 1 User Agent : Dalvik / ( Linux ; U; Android ; SGH I897 Build /JZO54K) Host : a p i n l Connection : Keep Alive Accept Encoding : g z i p Buienradar Used method: GET GPS data: 6 digits accuracy after the floating point for the latitude and the longitude values 1 Some details like IMEI number, and GPS data length have been omitted for privacy reasons, and this is for all the applications 11

12 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 = & l o n = & r=4 HTTP/ 1. 1 User Agent : Dalvik / ( Linux ; U; Android ; SGH I897 Build /JZO54K) Host : l b s. b u i e n r a d a r. n l Connection : Keep Alive Accept Encoding : g z i p NS Reisplanner Xtra Used method: GET GPS data: 7 digits accuracy after the floating point for the latitude and the longitude values The information that is being sent by the application is shown below: GET / mobile api planner? fromlatlong=52.369%2c4.932& t o S t a t i o n=amsterdam+centraal HTTP/ 1. 1 Authorization : Basic YW5kcm9pZDptdmR6aWc= User Agent : R e i s p l a n n e r X t r a / 3. 1 ( Android ; l e v e l : 1 6 ) Host : ews rpx. ns. n l Connection : Keep Alive Accept Encoding : gzip, d e f l a t e This application alse requires basic authentication which is provided in the GET call, and is encoded in base 64. The username and password decoded are: android:mvdzig, respectively. Schipol Amsterdam Airport Used method: GET GPS data: not visible Type of network used (wifi in the experimental case) The information that is being sent by the application is shown below: GET / s c h i p h o 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=s c h i p h o l&n s r a d i o=w i f i HTTP/ 1. 1 User Agent : Dalvik / ( Linux ; U; Android ; SGH I897 Build /JZO54K) Host : n l. s i t e s t a t. com Connection : Keep Alive Accept Encoding : g z i p Shazam Used method: GET GPS data: 14 digits accuracy after the floating point for the latitude and the longitude values Cell phone provider Root check Connection type (wifi) OS version 12

13 The information that is being sent by the application is shown below: GET /mob? id = & c a r r i e r=vodafone&geolocation=52.369%2c4.933& osv = HTTP/ 1. 1 User Agent : Mozilla / 5. 0 ( Linux ; U; Android ; es es ; SGH I897 ; CyanogenMod ) Host : mediation. adnxs. com Connection : Keep Alive Soundhound Used method: GET GPS data: 7 digits accuracy after the floating point for the latitude and the longitude values, sent in the User agent header. Cell phone provider Root check Connection type (wifi) The information that is being sent by the application is shown below: GET /v2/ s s l t e s t. php HTTP/ 1. 1 Host : s e c u r e a p i. midomi. com : Connection : Keep Alive Cookie2 : $Version=1 User Agent : AppNumber=31 APIVersion =2.0.0 FIRMWARE=4.1.2 eng COUNTRY=n l NETWORK=WIFI LAT= LON=4.932 HACC= MAPS=1 Accept Encoding : gzip, d e f l a t e Speedtest Used method: GET GPS data: 5 digits accuracy after the floating point for the latitude and the longitude values GSM cell ID IMEI Root check The information that is being sent by the application is shown below: GET / a p i / android / c o n f i g. php? c t=2&i m e i =351 & l a t =52.369& l o n =4.932 HTTP/ 1. 1 User Agent : Dalvik / ( Linux ; U; Android ; SGH I897 Build /JZO54K) Host : www. s p e e d t e s t. net Connection : Keep Alive Accept Encoding : g z i p 13

14 TuneIn Radio Used method: GET GPS data: 6 digits accuracy after the floating point for the latitude and the longitude values The information that is being sent by the application is shown below: GET / Config. ashx? p a r t n e r I d=xwhzkvki&l a t l o n =52.369%2C4.932& r e n d e r=j s o n HTTP/ 1. 1 User Agent : TuneIn Radio / ( Android 1 6 ; SGH I897 ; Java ) Accept Encoding : gzip, d e f l a t e Accept Language : es ES Accept Charset : utf 8, Host : opml. r a d i o t i m e. com Connection : Keep Alive 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 be found 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 request is recorded, and some details about the hosts. By analyzing the requests from the applications such as Soundhound, we can see that this application is sending geolocation data to pubads.g.doubleclick.net which is a domain used by Google to send advertisement based on the location of the user. Shazam, in the other hand, communicates with the domain mediation.adnxs.com, which is a domain that is related to marketing purposes [15]. As well as the previously mentioned apps, TuneIn Radio also communicates with domains 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, googletagmanager.com, ads.mp.mydas.mobi that are domains related to marketing purposes. The weather app, Buienradar, also connects to a domain ticks2.bugsense.com, which is used for big data analysis. A detailed log about all connections made the by the applications can be found in the Appendix B. The API discovery approach, on the other hand did not reveal any hidden APIs which are leaking interesting data. Also spoofing the parameters which are being sent along to the back-end servers did not trigger any unpredictable behavior. 7 Countermeasures In this section, we discuss some techniques that can be used by the user as countermeasures to avoid 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 requires valid 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 being sent, is the previously recorded location. 14

15 7.2 Deleting GPS data Deleting GPS information from the device might seem like a solution in order to prevent applications using this information. Several attempts to erase this kind of data were made, like erasing the content of the /data/gps folder, which requires root access, and erasing the cache files for the applications, but none of these attempts prevented the applications to send the GPS information, 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 are openly available to download, but they require a rooted device in order to work properly. What these applications do, is they enable the ACCESS MOCK LOCATION [16] setting, that is used to test applications using fake location data. For this research, we tested the Location Spoofer application [17]. Some applications were tested 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 error message that states that the current location is not supported, see Figure 4a. Other applications like Soundhound, Shazam and Speedtest keep working perfectly fine, and the communication between 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 increased compared to the latency of the same test using real location. And that is because the application is 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 is shown below, where the values for latitude and longitude are provided by the location spoofer application. As shown below, we can see that the application is using as parameters the latitude as and the longitude as , which is the location specified in the location spoofer application. GET / a p i / android / c o n f i g. php? l a t = & l o n = HTTP/

16 User Agent : Dalvik / ( Linux ; U; Android ; SGH I897 Build /JZO54K) Host : www. s p e e d t e s t. net Connection : Keep Alive Accept Encoding : g z i p Based on these results we can conclude that by spoofing the location of the device, we can convince 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 critically depend on the GPS location of the device. However this is not always the case. Navigation applications for example require real GPS data in order to function properly. The solution for such applications would be to only use the ones that communicate with their servers over secure connection. There is a big variety of applications on the market and some of them do implement HTTPS. 8 Conclusion From the captured traffic and API investigation, it is clear that GPS location data is being reported from mobile application to their back-end servers and in a lot of the cases this is done in plain text. Some applications also send along user identifying information, which can be used to link users with geographical locations. The investigated applications did not reveal to leak any sensitive information from the server side via the implemented APIs, however there are a lot other applications on the market, that may do that. In conclusion, it is possible to track users who make use of mobile application that access GPS data from the device on which they are running. However in order to do that, one must intercept the traffic between the device and the server used by the mobile app. This makes the attack unfeasible for most attackers. Governmental organizations, ISPs and other parties which keep taps on Internet traffic on the other hand can easily catch the plane text requests that the mobile apps are generating and extract geographical location data, sometimes accompanied with user 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 more other applications on the market, that make use of GPS-data. Every single one of them could potentially leak sensitive information in a different way. Therefore investigating other applications with large installed base will always be interesting. Another approach that that might reveal interesting insides on how a certain application handles and makes use of GPS information would be reverse engineering the applications by decompiling and investigating the functions that handle sensitive data. 16

17 References [1] Xda Developers. Understanding Android GPS Architecture. xda-developers.com/showthread.php?t= , [2] Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures. University of California, Irvine, [3] Andrew van der Stock Erlend Oftedal. REST Security Cheat Sheet. org/index.php/rest_security_cheat_sheet, [4] Tech Republic. Probing Android permissions. it-security/does-your-flashlight-app-know-where-you-are-probing-android-permissions/, [5] travel planner. [6] Buienradar - weather application. [7] Reisplanner - travel planner. [8] Amsterdam airport schiphol application. [9] Google maps - navigation application. [10] Shazam - music recognition application. [11] Soundhound - music recognition application. [12] Speedtest - connection speed test. [13] Tunein radio - access to world wide radio stations. [14] Blake Dournaee. Data Leak Prevention and APIs. application-security/2012/03/26/data-leak-prevention-and-apis/, [15] Whois. WHOIS: ADNX [16] Android Developers. Testing Using Mock Locations. training/location/location-testing.html, [17] Trackdroid. Location Spoofer

18 A DNS requests This appendix shows every DNS request that was made from the applications. Application IP address DNS name Description nl REISinformatiegroep B.V N/A RTL-Netherlands rtl.nl RTL-Netherlands N/A Buienradar BV N/A Buienradar BV N/A Buienradar N/A N/A Nedstat Application and Service Network N/A comscore Application and Service Network N/A N/A Buienradar BV N/A Buienradar BV N/A Akamai Technologies Maps google.com Google Inc google.com Google Inc N/A Akamai International, BV Reisplanner google.com Google Inc facebook.com Facebook Ireland Ltd Schipol Airport N/A comscore Application and Service Network N/A M2Mobi BV Fastly Amsterdam 1 Operations Fastly Frankfurt 1 Operations Shazam Entertainment Limited Peer 1 Dedicated Hosting Shazam Peer 1 Dedicated Hosting Facebook Ireland Ltd AMS1 IB Net - Public VIPs FRA1 IB Net - Public VIPs Flurry, Inc Akamai Technologies google.com Google Inc. Soundhound data.midomi.com Level 3 Communications, Inc data.midomi.com Level 3 Communications, Inc Akamai Technologies google.com Google Inc. Speedtest NForce Entertainment B.V NETBLK-03-EU Voxel Dot Net, Inc Voxel Dot Net, Inc google.com Google Inc try.crashlytics.com Amazon.com, Inc. TuneIn Radio SoftLayer Technologies Inc Peer 1 Dedicated Hosting PSINet, Inc PSINet, Inc Amazon Technologies Inc. 18

19 B Detailed log communication for the tested applications This appendix shows a detailed log for all connections made by every tested application :41:51 UTC ssl [ ]:42930 [ ]:443 sni:api.9292.nl crt: / /api.9292.nl/api-acc.9292.nl /reisadvies-api-ast.9292.nl /reisadvies-api.9292.nl /labs.9292.nl /9292.nl origcrt: / /api.9292.nl /api-acc.9292.nl /reisadvies-api-ast.9292.nl /reisadvies-api.9292.nl /labs.9292.nl /9292.nl Buienradar :42:41 UTC tcp [ ]:35419 [ ]: :42:41 UTC ssl [ ]:49184 [ ]:443 sni:- crt:ticks2.bugsense.com origcrt:ticks2.bugsense.com :42:43 UTC tcp [ ]:47311 [ ]: :42:45 UTC tcp [ ]:57439 [ ]:80 Google Maps :19:26 UTC ssl [ ]:36138 [ ]:443 sni:- 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

20 /*.ytimg.com/android.com/g.co/goo.gl/google-analytics.com/google.com /googlecommerce.com/urchin.com/youtu.be/youtube.com/youtubeeducation.com Reisplanner :34:34 UTC tcp [ ]:39903 [ ]: :34:37 UTC tcp [ ]:57717 [ ]: :34:49 UTC tcp [ ]:56069 [ ]: :40:17 UTC tcp [ ]:55045 [ ]:80 Schipol Amsterdam Airport :33:30 UTC tcp [ ]:38054 [ ]: :33:48 UTC tcp [ ]:54066 [ ]: :34:12 UTC tcp [ ]:35815 [ ]: :34:13 UTC ssl [ ]:37742 [ ]:443 sni:- crt:scripts.schipholmobile.com/scripts.schipholmobile.com origcrt:scripts.schipholmobile.com/scripts.schipholmobile.com Shazam :49:01 UTC ssl [ ]:59195 [ ]:443 sni:graph.facebook.com crt:*.facebook.com/*.facebook.com/facebook.com /*.fbsbx.com/*.fbcdn.net/*.xx.fbcdn.net/*.xy.fbcdn.net origcrt:*.facebook.com/*.facebook.com/facebook.com/*.fbsbx.com /*.fbcdn.net/*.xx.fbcdn.net/*.xy.fbcdn.net :49:21 UTC tcp [ ]:49115 [ ]: :49:21 UTC tcp [ ]:57133 [ ]: :49:22 UTC tcp [ ]:36740 [ ]: :49:50 UTC tcp [ ]:34919 [ ]: :50:12 UTC ssl [ ]:54954 [ ]:443 sni:beacon.shazam.com crt:beacon.shazam.com/ beacon.shazam.com origcrt:beacon.shazam.com/beacon.shazam.com :50:13 UTC ssl [ ]:36649 [ ]:443 sni:beacon.shazam.com crt:beacon.shazam.com/beacon.shazam.com origcrt:beacon.shazam.com/beacon.shazam.com :50:24 UTC tcp [ ]:49397 [ ]: :50:24 UTC ssl [ ]:39023 [ ]:443 sni: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/ /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 / /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 / /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