Overview of iOS tracking traffic

When I started reviewing a few iOS applications for privacy concerns, such as the SpringPad application which used your email addresses without permission, I noticed that many applications would contact third-party sites with information about your device, often including a unique identifier. At the time I didn’t have much data to back it up. But I decided to undertake a small project to study this more in depth. Here was my game plan:

  1. Download top 6 applications in each category on the App Store
  2. Launch each application, click few to no buttons at all, and close down the application
  3. Analyze the requests made by the application
  4. Note down all requests that somehow appears to have information enough to track your device
  5. Study the results

With this in mind, I went to work. It was quite a boring task, since I did it all manually. But quite quickly I noticed some trends. And this is what I want to share with everybody, since I couldn’t find any previous research done like this.

The tl;dr
Here are some very quick stats:

  • I downloaded apps from 22 categories
  • I downloaded and executed a total of 115 applications
  • They contacted 128 different servers and sent data about your device
  • Each application contacted between 0 and 10 servers with data about your device
  • 85 of the servers were contacted over HTTP (67%)
  • 42 of the servers were contacted over HTTPS (33%)
  • The applications that tracks you the most is USA TODAY, which communications information about you to 10 servers
  • The most used service is used by 29 applications (25%) of the ones tested, second most used was observed from 11 applications (9.5%)

Here are the requests contained about your device:

  • Unique identifier
  • Mac Address
  • Local IP address
  • GPS Coordinates
  • Time zone/location
  • Device type
  • Device version
  • OS type
  • OS version
  • OS locale
  • Application identifier
  • Application version
  • Screen resolution and orientation
  • Radio type (Wifi or 3G)

My method for collecting this data involved using the proxy and target mapping function of Burp Pro. By installing a MITM certificate on my iPad, I can intercept most, if not all, of the traffic going out of the device over HTTP(S). I analyzed each request, and determined whether or not this request would track your device in any way, and added it to my Maltego document. I then saved the requests, cleared out Burp and went onto the next application.

The applications are the top 6 applications of each category from the iOS application store. I used the American app store for this, since it presumably has the biggest sample of users, and thus the top 6 applications would with the most likelihood be of interest to the most users. The applications had not been launched from the device before, so there were a lot of “first startup” requests observed.

The setup used can be replicated with the free version of the excellent tool Burp. Here are the steps I used:

  • Start up burp
  • Configure a browser (Example here being Firefox) to proxy through Burp, by default localhost on port 8080
  • Go to a HTTPS site through the configured browser, which should give you a SSL warning
  • Click “Add Exception”
  • Click “View”
  • Go to the “Details” tab
  • Click on the “PortSwigger CA” tree item in the Certificate Hierarchy
  • Click export
  • Save it as burp.cer
  • Using a command line, browse to where you saved the certificate.
  • Run python.exe -m SimpleHTTPServer
  • Now pick up your iDevice and browse to port 8000 on the machine used to extract the cert
  • You’ll now get a directory listing, pick out the cert you exported and download it
  • Now you’ll be taken to your System preferences, and can install the certificate. Job done

The big pictures

Breakdown by provider top 7 (Technical!)
Flurry comes in at the top of our list, with a total of 29 applications in our sample which uses this. Their site claims that (more than 190.000 applications use it)[http://www.flurry.com/product/analytics/index.html]. It makes a lot of requests with a lot of data. For instance, it appears to be making a request at both startup and shutdown of an application. And there’s a lot of seemingly random information. This traffic takes place over plain HTTP without SSL.

There are a few trends that we can see.

  • A unique identifier is sent across, 38XEJT2XRT2I9H9BFB29. This is seemingly unique to the application
  • The version number of the application, in this case 1.0.6
  • A unique identifier of the device, de5381e09b10d93043b50f43153f3aeeb4dcc589
  • Another seemingly unique value to the device, ID1BDCEF03-F55E-439D-BA2A-C0AAC6B7BF6B
  • Screen height, width, OS version, device model, locale, time zone
  • Followed by what seems like some application-specific information


This request looks, much like Flurry, to be tracking of the device and events taking place from the application, such as startup. It sends this content over plain HTTP, and was used by 11 of the tested applications.

Between these 4 requests, we see a number of information being transmitted:

  • The resolution of the device
  • Device type, version and locale
  • Application version
  • The connectivity of the device (Wifi or 3G)
  • Number of times the application has been started
  • Name of the application
  • The event that triggered the request (Such as starting up)

Admob is a Google service, which is used to track downloads of an application. It does so by making requests with a MD5 hash of the unique identifier of the device, and the application ID. It communicates exclusively over HTTP, and was used by 9 applications tested.

This is done by this piece of code that Google provides.

Tapjoy is another run of the mill marketing network that has had a bit of a past. It appears to be also tied to a virtual currency, which can be obtained and used in applications using this service. It tracks the user on the application startup like most other services. The interesting thing to notice here is that one application is communicating with it across HTTP, while five are doing so over HTTPS.

From these two requests, we can see that it transmits:

  • A country code
  • Device type
  • Application ID
  • OS version
  • A library version
  • Language
  • Timestamp
  • Mac Address
  • Display multiplier
  • Application version
  • A verification value

2o7 is an “online marketing and web analytics business unit owned by Adobe Systems”. All communication takes place over HTTPS, and was used by 6 applications tested

These are the items that the request contains:

  • The local time
  • VID, an unique identifier
  • Device type and model
  • OS version
  • Locale
  • Day of the week
  • Time of week (In this case, weekend)
  • Screen orientation
  • Screen resolution

ChartBoost is a system for cross-promoting applications, used by 5 of the tested applications. They are basically another marketing network. They make a request on first start over HTTPS, which looks like:

The interesting thing is that some of the applications sent across an “identity” value. I’ve yet to trace down what that value exactly means yet however.

  • OS Version
  • Unique identifier
  • An identity
  • Application ID
  • A signature of some sort
  • Country
  • Application version
  • Device language
  • Device model

Medialytics is a “rich media ad platform for mobile”. It communicates solely over HTTP, and was used by 5 of the tested applications.

The interesting thing is that it contains parameters for latitude and longitude, as well as mcc, mnc, and c which were empty during my testing. My iPad does not have GPS, which is most likely why this information was missing.

  • An application ID
  • Application version
  • Device type
  • OS version
  • Unique identifier
  • Latitude and Longitude
  • Screen resolution

Crittercism is a telemetry platform for tracking crashes and performance metrics. It is used by 5 applications which was tested and communicates over HTTPS.

From the looks of things, it collects:

  • Device model
  • OS version
  • Application version
  • Timestamp
  • OS Type
  • Locale
  • Device type
  • If the application was pirated or not
  • If the application was allowed remote notifications
  • A unique ID of some sort
  • Device name
  • Application ID
  • A key
  • Library version
  • Whether or not the request was sent through an application launch

Leave a Reply