Credit card numbers, third parties and you

One part of the preparation for my upcoming talk at BSides RI involved shuffling some cash from my bank account to make it available on my credit card. While in this process, something struck me as rather odd, as seen on the following Burp output:

Request containing credit card number

Request containing credit card number

As we can see, the URL query string contains a parameter identified as “KortNo”. And this just so happens to contain what is in fact my credit card number. So the question becomes, is this a big deal? Well, this had me wondering and looking at it from a PCI perspective; I think there may be some cause for concern.

Access logs, browser history

It’s of course common practice for companies to keep access logs for all HTTP servers in the event of a system breach for forensic purposes. PCI has a mandate for companies to retain at least 1 year worth of “logs”. Because PCI mandates logs are kept, you are 99% likely as a bank to keep your HTTP logs, including the URL requested. In this instance, we make a request with data that PCI has a strong view upon the storage of, including the very explicit requirement of encrypting the PAN(Primary account number), CVV2, expiration date, and any other personally identifiable information if you store the 3 former.

So what happens when you make a HTTP GET request containing data which PCI mandates the encryption of, and it goes into a standard IIS log? Well, you are storing data in violation of PCI compliance. You will only need to get your hands on the access logs from the server to now access a lot of credit card data. This is rather unfortunate.

Even more likely, is that your personal browser history will now contain your credit card number and hang on to it. Of course, this requires some social engineering to be relevant. However, if this is not made known to the user, then this is a cause for concern.

Third parties

Of course, when you run a web site, you like to track user behavior on your site. Who doesn’t? Banks do, and in this case, the above concerns are amplified when I noticed this request having been made by my browser at the same time:

Request to google analytics

Request to google analytics

What you see here is a standard Google analytics callback. We see that our query string containing data that PCI mandates that you must ensure is stored correctly is now sent off to a third-party. That is Google in this case. Ok, we may trust Google, but it also means that anybody with access to the Google analytics account now can view this credit card data. That means that this bank will now have to explicitly have made a contract with Google to verify that they will safe-keep this PCI data.

Is that likely? Not really. This is just an unfortunate side-effect of the bad practice of using the straight up PAN(Credit card number) as a part of the request through a query-string.

Putting it into perspective

When I discovered this, I rushed over to my other bank account(with a different back) to check if a similar problem existed over there. I observed that they had made the seemingly explicit design decision of not using the credit card number. Rather, they used a hash and a GUID to identify my credit card. While they were using a third-party analytics service, it did not contain personal information to the extent the above did as a result, which mitigates potential concerns in this regard.


  • 13/05/2013 – Advisory sent to CERT
  • 13/05/2013 – CERT confirms receipt of advisory, promises to provide contact at vendor
  • 14/05/2013 – CERT still searching for appropriate vendor point of contact
  • 15/05/2013 – CERT provides point of contact
  • 15/05/2013 – Advisory sent to vendor
  • 15/05/2013 – Vendor response confirming issue
  • 15/05/2013 – Vendor deploys fix
  • 16/05/2013 – Advisory published

It should be noted that the bank in question was quick to respond and fix the privacy concern in a professional manner. I’ve redacted the name of the bank as the goal of this was to highlight a potential pitfall that others may fall into, and hopefully this may encourage other banks to ensure that this is not a concern in their systems as well.

Firefox sessionstore.js and privacy

Firefox, much like other browsers, has been allowing you to restore browser “sessions”, which will restore the state of any page loaded, url, referrer, tab location, title, form data, the size of the rendering, font zooming, scrolling done on the page, closed tabs, and other fun things.

Personally, I find this to be an extremely neat feature. I use it on a regular basis, since I’ll often be trigger-happy on my close tab hotkeys. So it’s all nice and dandy, right? Well, the problem is that Firefox obviously can’t tell what data is sensitive and what isn’t. It will assume a form field marked as password type to be bad to include, but could there be other concerns? The answer is: Yes. And unless users are aware, this could be potentially bad. Here we’ll take a look at what is stored by the browser, and how we can observe this.

To test this, I had my VM with Procmon and a clean copy of the latest Firefox. Here are the steps taken to showcase this feature:

  • Open procmon, filter by firefox.exe
  • Open firefox
  • Browse to (This was *entirely* random, as it was the first page I found with a Paypal donate button)
  • Click on the “Donate” Paypal button
  • Fill out some random information in the Paypal form for making a transaction (Note that I had not previously logged into Paypal from this machine, thus getting a form to do the full transaction)
  • Open a new empty tab
  • Close the Paypal tab which contains the sensitive information, such as credit card number
  • Close Firefox
  • Search Procmon for sessionstore.js

At this point we check out what is contained in the sessionstore.js file.

Contents of sessionstore.js
The sessionstore.js is a simple JSON file, hence the .js extension (It contains no actual JavaScript code). It is a serialized state of the windows, closed windows, tabs, history, and closed tabs which is persisted on a regular basis. Here are the contents, having followed the above mentioned steps:

Here are some things we can notice that the file contains:

  • A list of open windows
    • A list of tabs
      • Tab entries
    • Index of selected tab
    • Closed tabs
      • Tab entries
    • Width
    • Height
    • Screen X
    • Screen Y
    • Size mode
    • Title of window
    • Flag for if the window should restore
  • Index of window selected
  • A list of closed windows
    • A list of tabs
      • Tab entries
    • Index of selected tab
    • Closed tabs
      • Tab entries
  • Session information
    • State of the session
    • Time stamp for last update
    • Time stamp for when the session started
    • A flag for if the session crashed
  • Scratch pads (A developer tool)

We notice that the structure is two lists of windows(Open and closed), which contains two lists of tabs (Open and closed), and then a bit of extra data. Each tab then has a whole substructure to itself that is duplicated. If the page is no longer active (It may have been browsed away from), it will contain this:

  • URL
  • Title
  • ID
  • Document shell ID
  • Document identifier

But if it is active, it will contain a bunch more:

  • URL
  • Title
  • ID
  • Document Shell ID
  • Referrer
  • Document identifier
  • A list of children
    • URL
    • ID
    • Document Shell ID
    • Owner(base64)
    • Documentation identifier
    • Scroll state
  • Form data
  • Scroll state

All this will of course be a lot more complex to look at when more complex tab setups and browser history is present. This is by far the most simple I could make it by only just browsing enough to show the major aspects of it.

Private information in the file
What you may have noticed by now, if you look at the big bit of JSON above, is that form data is included in the file. This is something to be aware of, if you type sensitive information in.

Specifically, this is the bit where you have to be careful:

As you can tell, the full form I was presented with at Paypal has been stored in clear-text on my drive despite closing the tab and the window. An unaware user could think at this point that because they can’t see the window, that the inputted data is gone for good. That is however not the case.

I’ve tested this with password fields. These are not stored, for good reasons. But it is clear that non-password fields may and will often contain information which you may not want to

Mitigation options
If you’re concerned with data that may be present inadvertently in this file, you have a few options for dealing with this

Using private browsing mode
The private browsing mode is probably overkill for many. The danger with this feature is that it is not made explicitly clear to the user what is being stored. But if you have sensitive information you want to hide from the local machine, you should be using this anyway.

This flag can be changed from the default value of true to ensure that if the browser crashes or otherwise unexpectedly closes, that it does not commit the sessionstore with this information. But this doesn’t disable the feature entirely.

browser.sessionstore.max_tabs_undo and browser.sessionstore.max_windows_undo
These two flags allow you to specifically set how many tabs and windows respectively are stored in cache. By setting these to 0, you can entirely disable this feature, causing no potentially sensitive information to be stored.

The manual approach
Another thing you can do, while not as foolproof, is to remove any information in form fields before closing a tab, which you do not want to be cached. While this works, it should be remembered that the possibility is still there if not careful! You can also clear private data from Firefox through the built-in options, which will clear this out. Again the problem becomes the fact it requires manual interaction, which depends on the user being aware of this information being cached.

Analysis of iOS Games tracking traffic

A little while ago, I spent a weekend analyzing a wide cross-section of applications from the iOS app store across all categories. You can read that right here. One specific topic that I had comments and questions about specifically was the games. The iPad, as an example, is not a bad gaming platform. And I know a lot of people who play free iPad games, and let their kids play them. So I figured I’d do a bit of a bigger dive into that specific category of applications and see what sort of information they track about you and your device.

I downloaded the top 25 applications on the games section of the iOS application store as of July 20th, 19:00 GMT. The list goes as following, with the number of outbound connections to different sites the application makes:

  • Fish with Attitude            14
  • CSR Racing                          8
  • Water? Free                        7
  • Battle Bears Royale         6
  • Ice Age Village                  5
  • Mutant Roadkill                5
  • Angry Birds Space Free 4
  • Fix-It Felix                          4
  • Shark Dash                           4
  • The Sandbox                       4
  • Flick Kick Football           3
  • Magic Puzzles                     3
  • SongPop Free                     3
  • Flow                                       3
  • Arms Cartel                        2
  • Betrayal HD                        2
  • My School Dance             2
  • Pyramid Run                     2
  • Super Pretzle Factory   2
  • Temple Run                       2
  • Bakery Store                     1
  • Bubble Mania                   1
  • Guess!                                  1
  • Subway Surf                     1
  • Major Mayhem               0

Here are some quick stats:

  • 25 applications
  • 48 different urls were used to track different information about the device
  • The application to communicate with the most servers was Fish with Attitude, talking to 14 different sites
  • The application to communicate with the least servers was Major Mayhem, being the only to not send any tracking information about the device
  • 11 of the servers were contacted over HTTPS (23%)
  • 37 of the servers were contacted over HTTP (77%)

Tracking sites top 10
Here is the top 10 of the different URLs that were observed to track information about the device:

-                         15
-              9
-                           4
-                     4
-                               3
-                  3
-       2
-                     2
-   2
-  2

As we can see, there are a lot of similarities between this data and that of the Overview of iOS tracking traffic analysis. Flurry, Chartboost, and Tapjoy are again back, being extremely popular. Please see the previous article for analysis of the requests made by these.

Analysis of the other sites
Between the top 10 sites as listed above, here is what is being tracked by them.

  • Specific events in the game
  • OS version
  • Device version
  • Mac Address
  • Local IP Address
  • Mobile carrier
  • Unique identifiers
  • Radio type (WiFi or 3G)
  • Timezone
  • OS locale
  • Application identifier
  • Application version
  • Screen resolution and orientation
  • Time stamp

The big pictures is owned by the company “Burstly”. It is used for developers to sell applications to be shown in their applications. It communicates over plain HTTP, and will track a lot of different values about your device.

There are two hashed/encrypted fields, seemingly being related to the mac address of the device. Also it seems to be carrying across, or at least have keys allocated for, the IP address and carrier of the device. Neither were sent across for my device, possibly because it’s a WiFi iPad. But I found that very interesting. Beyond that:

  • Platform
  • Carrier
  • Device type
  • OS Version
  • OS Locale
  • Screen resolution
  • Application build
  • Device Family
  • Unique Identifier
  • Application identifier
  • Location country
  • Radio type (WiFi/3G)
  • encMAC(Encrypted mac?)
  • IP Address
  • mac(Hashed mac address?)
Apsalar is a “mobile app analytics” platform, specifically focused as measuring “engagement”. It communicates over HTTP as well, and is very chatty. For instance, Battle Bears Royal made 13 requests over a period of 9 seconds. It specifically will also call back on specific events, such as game opened and other developer-specified events.

There appears to be a lot of encoded data sent across by this particular system. So we can’t see that much from this, but we can tell a few times:

  • Application identifier
  • Locale date
  • Radio type (WiFi in this case)
  • Platform
  • And then a lot of seemingly hashed data I can’t make very much out of.
Playhaven is a marketing platform for mobile games. It communicates over HTTP, and passes over the device UDID and a mac address.

We see that this sends across a nonce, which is quite interesting. These are generally used to prevent Cross-Site Request Forgery. It also transmits:

  • Mac Address
  • Device version
  • Unique identifier
  • A nonce
  • OS version
  • Application identifier
  • Connection (Radio type?)
  • A token
  • A signature
  • Application version
Gameloft is a game developer which develops, publishes and distributes games for smartphones. Their games all talk to a couple of different domains. All of them are HTTP, but one application communicated with the livewebapp subdomain over both HTTP and HTTPS.

What is interesting in this case is that the first request, which says that the application is loading, has all data in plain text. The second request is sending across an “id”. But this ID is in fact simply a base64 encoded string of the very same data as that above. But we can tell it sends:

  • Application identifier
  • Country
  • Language
  • Application version
  • Device version
  • OS version
  • Mac Address (Unique identifier)
  • A timestamp
Openfeint is probably the biggest social networking component used by major games. It adds features such as leaderboards, friends lists, and such thing. It communicates over HTTPS, as you’d expect from any sort of application that communicates large amount of data about your device.

## ##
Doubleclick is your standard Google advertising platform. No sort of magic here. But for whatever reason, Google has opted to use HTTP here over HTTPS, which is very interesting.

It has a bit of seemingly hashed/encrypted content. And then a bunch of the normal content:

  • Language
  • Screen resolution
  • Device model
  • Application identifier
This one is a bit tricky. I was unable to easily locate a privacy policy for this service specifically. The domain it uses redirects directly to the Tap Tap Revenge Facebook page, which was the first game made by Tapulous. The company was acquired by Disney Interactive Studios in 2010, which explains why it is being used by a Disney application. But it communicates over HTTP, and is extremely verbose due to the use of POST forms rather than query-string parameters.

This tracks these values at specific events, much like Apsalar.

  • Method called
  • A signature
  • OS version
  • A token
  • Time stamp
  • Device version
  • API Key, but that seems to be a dummy one
  • Time Zone
  • Application version

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)[]. 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

Dissecting traffic from SpringPad for iOS

My research over the last couple of months has focused on the security ghetto of WordPress plugins. But recently @arnimarhardar turned me to the subject of mobile applications. As they often use HTTP, I felt right at home. I decided to download a few random applications onto my iPad and then go to town. I personally use my iPhone on a daily basis, so what I’m about to describe to you was quite the eye-opener for me in terms of what sort of data is sent about you to third-parties and such. Let me present to you, an extremely popular application: SpringPad.

Note: I’ve masked out parts of requests since they may contain unique identifiers and such things.

Dissecting Springpad
Armed with my recently acquired copy of Burp Pro, I booted up the application for the very first time. I was greeted with an authentication screen, asking me to sign up. Already at this point, Springpad has contacted a number of very interesting domains. There’s a few calls to Twitter and Facebook and such, but I’ve left those out since they offer no insights into what Springpad does.


Of these 4 requests, only one of them is actually related to the application at all. That seemed very odd to me. So let’s look at what they did in order listed.

Third-party requests

RedLaser is a “RedLaser is a free shopping app for iPhone, Windows Phones, and Android that has been downloaded over 19 million times.”. Ok, interesting. How that is used by a note-taking application is a mystery to me. But from what we can tell from the request, is that they sent the name of the application making the request, an unique identifier, the platform, hardware versions, sdk version, the build number, locale, application version and OS version. Of course, sending across an unique identifier is a bit questionable, given that I as an end-user have no idea what redlaser is, but let’s move on!

This one is fun, because it seems to be sending across an actual data-structure, null-byte padding and everything. But it’s sending across a couple of (unique) identifiers, resolution, model, and version information. That’s nice. Not only does there seem to be one piece of identifying information in this request like to redlaser, there’s several.

Before getting into the actual request to springpad, we need a last stop over to!

The third request to a third party consists of a lot of fun information, such as country, device type, carrier name, language, iOS version, and your devices’ mac address.

Springpad requests
And now, for the main course, Springpad. Let’s see what it’s got in store for us!

This is the first request it makes, and the very first thing that greeted me was that this communication didn’t go over HTTPS, which is a concern. But onto the request, we see some OAuth fun, and then a device identifier, which is again your mac address. Ok, not the biggest of deals, let’s now sign up!

At this point, we post our credentials to the site(Over HTTP, mind you. Ooops) with the addition of a sessionID in our cookie. Again we see the transmission of your mac address.

Hold on a minute, what is that being sent across the wire? At this point, all I’ve clicked on is for me to sign up and just finish registration. I’ve not been requested to submit all of my contacts which are stored in my iOS contact list. Huh, that’s odd! I thought maybe I missed something, so I checked again. Nope, I’m not asked if I want to upload this.

Note that these emails were a part of the HTTP request

The fine-print part of the story
So let’s go consult our privacy policy as for what information the application will automatically upload from me:

Oh, how odd. Not a word about contacts! This isn’t really what I’d expect. There’s another bit of the privacy policy which states:

Thinking that I could now log into their web-site and see which information they have obtained from me, I logged in and started reviewing it. To my surprise, not a single mention of contacts was to be found. This is starting to smell. So let’s consult the iOS Application Guidelines as put forward by Apple:

I am no lawyer, but I don’t see that this application should have, as per Apples application guidelines, taken this information from my device without permission.

Does this remind anybody else about Path?

Response from vendor
When I contacted Springpad about my concerns in regards to the lack of HTTPS and their use of contact information, they were very prompt in a reply to my concerns, specifically in regards to the lack of HTTPS and the use of contact informations. They explained that the lack of HTTPS was a result of a bug in the build process. A fix for this was being fast-tracked for submission to Apple by the end of the day.

They acknowledged that the application uploaded the emails from the contact book of the device. They noted that the data wasn’t stored, only kept in memory to see if anybody you know uses SpringPad as well. They plan to request for explicit permission in version 3.0.7, which at the time of writing is being tested by their QA.

Overall, they were extremely quick to reply and addressed my concerns quite well, despite having a bad time all at the same time.