Device Fingerprinting

Size: px

Start display at page:

Download "Device Fingerprinting"

Juliet Boone
5 years ago
Views:

1 Device Fingerprinting Report 1 Contents 1 Project and Functional Aspects Overview Assessment Technical Aspects Exploits Implementations Fingerprinting methods Delivery methods Code reuse Entropy CKO Cross-browser device fingerprinting Fit Checkout device fingeprinting Works Cited Version control V1 V2 Added 1.3. Updated 1.2 and 2.1 V3 Current Updated 1.2 and 2.1. Added and Author: Aris Papadopoulos

2 1 Project and Functional Aspects 1.1 Overview Device fingerprinting (DF) refers to the extraction of various device environment attributes that can uniquely identify a device or, more accurately, attributes of a specific device setup. More specifically data are collected from the following layers:! HTTP! Browser! Operating System! Network! Hardware There is a variety of attributes that can be exploited to this aim and therefore there exists a tradeoff between diversity (referring to the number of different/unique setups that can be possibly fingerprinted) and stability (referring to the extent that each such fingerprint is indicative of a unique device). For example, adding more tracked attributes to a fingerprint (especially ones prone to user preference changes) increases the probability that the setup may soon change as the user changes various preferences on her device. On the other hand, not including enough attributes one cannot fingerprint many distinctive device setups. In both cases identification fails and therefore DF needs fine-tuning. In brief, device fingerprinting exploits client side technologies, namely JavaScript (AJAX), Flash, HTML/CSS and HTML5 (but the JVM may also be used), to extract device setup attributes on multiple layers (an overview of how this is achieved as well as overviews of specific implementations are discussed in the rest of the document). These attributes are then packaged together in a device fingerprint and sent to the server for storage. Next time the device visits the website, the fingerprint is regenerated, sent to the server and tried to be matched. In this sense we can flag fingerprints that are known to have been used in fraudulent activity (more as to how we can use it in section 1.3). Some methods, instead of regenerating store the fingerprint in a cookie on the client and in subsequent visits examine the cookie. However, this is obviously an unreliable method, since cookies can be easily deleted. To overcome this problem, more recent methods use certain exploits for persistent client side storage (see section 2.1). 1.2 Assessment We can quantify the amount of information each additional attribute contributes to the fingerprint (see section 2.3 of this document). However each additional attribute makes the fingerprint potentially more prone to change, each to a different degree, due to the diversity/stability tradeoff described previously. This implies that we may need to explore which attributes produce the best predictions in practice, testing fingerprints with different attributes and methods against known cases in our dataset. We could alternatively allow for custom 2

sensitivity (inside reasonable ranges), scoring the device etc. An obvious way to control our software is to compare against the results of a commercially available product.

3 sensitivity (inside reasonable ranges), scoring the device etc. An obvious way to control our software is to compare against the results of a commercially available product. Overall, to develop a DF feature one needs to employ good knowledge of clientside technologies (mainly the ones mentioned previously) and more specifically on their underlying mechanics. A front-end developer will typically be familiar with some of them, depending on seniority. It is front-end hacking to a certain degree but the latest techniques that are used are well understood and Intentionally hidden implementation code for many of them is available and free to use for commercial purposes as well (see section 2.2.3). On the server side, one needs to represent fingerprints in a consistent way, deal with updates (e.g. browser new versions etc.) that produce different footprints so as to avoid false positives, weigh how important observed differences are between DFs to classify as actually different or potentially same. To this aim, one may employ more sophisticated techniques like Fuzzy Matching, to allow for a controlled tolerance and match fingerprints that are not identical with some known probability of creating a false positive. There are a few reasons why a DF implementation would need continuous updates:! First, the typical front-end challenge of cross-browser support exists in the form of the respective exploits and continuous updates may be needed as browsers evolve.! In addition, changes may occasionally happen on other layers of the stack, presenting with more opportunities to fingerprint or blocking previously available methods. For example advancements on the TCP and the appearance of HTML5 allowed new exploits on the network and presentation layer respectively.! Last but not least, DF is not yet a widely known practice and therefore countermeasures may become more effective in the future when there will potentially be more awareness. Concrete first steps to develop a DF product:! Select a set of features, based on this report and further research if needed. The following should be taken into consideration for selecting this set: o The features should be well positioned in the diversity/stability tradeoff. o Certain novel advanced/methods (discussed in section 2.1) may be blocked in the future Intentionally by the relevant hidden technologies, due to increased awareness of the privacy exploits. We may need to implement a core of safe methods as the basis and then enhance it with more elaborate ones.! Evaluate the effort to implement each of the selected features.! Examine and evaluate possible reusability of open source DF projects (see section 2.2.3). 3

4 2 Technical Aspects 2.1 Exploits DF is generally categorized into passive and active, the first referring to exploiting information that is typically revealed by any browser and the second to scripting with the explicit intention to fingerprint a device. Next the technologies and their specific data/methods that are mainly used for DF are briefly presented. A brief explanation is also given, when the information is not self-explanatory. HTTP headers:! Accept: Accepted data types! Accept-Language! Accept-Encoding! Accept-Charset! Connection: action after request completed (keep alive or close)! User-Agent: Browser and OS info. JavaScript:! JavaScript version: consistent for each vendor! Platform: OS! Charset: Browser s encoding settings! Cookie support! Java support! Timezone! Screen resolution! Plugin versions: Except IE Flash:! Fonts: Entire list installed in the system! Proxy piercing (explained below)! Flash cookies (explained below) Next, some particularly interesting findings and latest advancements of the DF literature are summarised:! The Flash API can be exploited to bypass proxies ( proxy piercing ). The following mechanism was reverse engineered in 2 out of the 3 commercial products presented in section 2.2.1: A token is shared between Flash and JavaScript. A request with the shared token is then initiated by Flash and AJAX and if the same token comes from different IPs, the one coming from Flash is the true IP.! Flash cookies: In (Soltani, 2010) the authors show how to abuse Flash cookies to regenerate previously removed HTTP cookies. In (Kamkar, 2010) the authors employ a vector of Flash cookies in combination with localstorage, sessionstorage and ETags.! Canvas fingerprinting: In (Mowery, 2012) the authors present an HTML5 exploit according to which, upon a user visiting a website, the site first draws a text, then calls the todataurl method to get canvas pixel data in 4

5 a base-64 pixel representation. Finally the information is hashed to produce a unique fingerprint. More about canvas fingerprinting towards the end of this section.! To identify the browser, the User-Agent HTTP header attribute is typically used, as mentioned previously. Motivated by the fact that this is a client generated information which could be altered, the authors in (Mulazzani, 2013) present a JavaScript based method for reliable browser identification.! There are extensions/addons (terminology depends on the browser) that attempt to hide certain bowser properties to protect privacy, however this makes the particular setups even more distinguishable, a situation called in (Broenink, 2012) the Fingerprinting paradox.! Other extensions selectively whitelist certain sites to allow scripting privileges. In (Yilek, 2011) the authors exploit this whitelist to devise a fingerprint. They also present a mechanism to identify the browser, operating system and microarchitecture of the device using the innate performance signature of each browser s JavaScript engine.! ios devices have more uniform setups and are thus more difficult to distinguish, however there are several solutions, and both Fiksu and Augur open source projects claim to be able to do so (see section 2.2.3). Two particularly interesting DF techniques mentioned above are Canvas fingerprinting and Evercookies, the first known for producing unique fingerprints and the second for being very resilient. To ensure diversity and therefore minimize false positives with canvas fingerprinting, the following techniques are used:! Call both ToDataURL and filltext (or stroketext) from the same URL.! Use more than one colors in the same canvas image.! The size should be more than 16x16 pixels.! Don t request the image in lossy compression format (JPEG etc.) Canvas fingerprinting from AddThis.com is heavily used among other implementations. The AddThis.com script uses the following techniques in addition to canvas fingerprinting:! Use different colors.! Trigger the default fallback font by requesting a fake font name.! Use a pangram as the text string.! Check support of Unicode by printing the big smile face.! Draw two rectangles and check if a specicific point is in the path by calling the ispointinpath method.! Check for canvas globalcompositesupport. 5

2.2 Implementations 2.2.1 Fingerprinting methods In (Nikiforakis, 2013) the authors reverse engineered three commercial (BlueCava, Iovation and ThreatMetrix) and one academic

6 2.2 Implementations Fingerprinting methods In (Nikiforakis, 2013) the authors reverse engineered three commercial (BlueCava, Iovation and ThreatMetrix) and one academic (Panopticlick) DF applications. In the following table they present the several layers that these applications track and what technologies are used in each case for each layer. 6

In addition to the above applications, this is what Oracle Adaptive Access Manager tracks: Http: Flash: Mobile: 2.

7 In addition to the above applications, this is what Oracle Adaptive Access Manager tracks: Http: Flash: Mobile: Delivery methods Both BlueCava and ThreatMetrix hide the fingerprint content information from their clients, the first by encrypting it and the second by using a session ID, as follows. In principle this obscures data that could potentially be useful for our analytics in the future. This may be an additional motivation for an in-house implementation. BlueCava: Fingerprinting features are gathered and sent (probably AJAX) to BlueCava. BlueCava combines them on the server side to create the fingerprint. It encrypts it with DES and includes it in a hidden form element on the first party s site. When the form is submitted by the visitor, the encrypted fingerprint is sent to the first party servers which then query BlueCava by submitting the fingerprint to it in turn. 7

ThreatMetrix: Instead of encrypting and including the fingerprint in the first party s website, ThreatMetrix includes a session identifier in a predetermined div element and all queries to it are

8 ThreatMetrix: Instead of encrypting and including the fingerprint in the first party s website, ThreatMetrix includes a session identifier in a predetermined div element and all queries to it are identified by this session ID Code reuse There is a substantial amount of available DF code on the web either in the form of open source projects or projects that are available and exploitable on the web for demonstration, educational or other purposes and do not prohibit reuse or commercial use. Either way, DF code is front-end heavy so even a big part of the commercial code is easy to get hold of and examine. A list of projects includes:! Darkwave (Open Source): An array of JavaScript methods, including Canvas fingerprinting and much more. Clicking on any link on the list, you get the code and a live demo output of the relevant function. Pretty clean and sorted with comments on each method: Code and demo: Valve Fingerprintjs (Open Source): (Acar, 2014) found that several websites use this code for fingerprinting purposes (and also leave the drawn text of the original code unaltered). Info: Code: MIT license (commercial use allowed)! Fiksu (Open Source): Intentionally hidden This is specific to ios fingerprinting, which as discussed is a particular task because Apple devices tend to be uniformly set up and closed. Code: MIT license (commercial use allowed) (Site: Evercookie (Open Source): Persistent cookies as explained in section 2.1. Info: Code: Panopticlick: An open source reimplementation of Panopticlick which is often mentioned as open source or soon to be open sourced, but is actually unavailable. Code: BrowserSpy: An array of various exploits including JavaScript, CSS, ActiveX etc etc. Clicking on the list menu on the left, you get a demo output of the relevant function and it therefore is easy to extract the code. No explicit restriction of extracting, examining and using the code as far as I can see. Demo: 8

9 ! Browserleaks: As in BrowserSpy. Demo: jquery plugin Code: NOC: Demo: Code: (educational purposes, commercial use not authorized)! Augur: Info: Intentionally hidden! A Propublica demo: Canvas fingerprinting demo that created different fingerprints for two macbooks in the Office Demo: BlueCava (Copyrighted): Code: Entropy DF implementations are typically assessed using a quantity known as Entropy. Entropy is a quantification of the amount of information contained in a message and it is useful to quantify the tradeoff calibration discussed in section 1 of this document. In simple terms, if a parameter can take only one value, transmitting this value contains no information, since the receiver already knew the value (there was only one possible value), and thus entropy is low. In contrast, the more values a parameter may assume, the more information is contained in a message carrying such a value. This intuition is quantified as follows (Shannon): Where H is the entropy, n is the parameter s allowed values and p(i) is the probability of each value for the particular cariable. In the DF context, each of the parameters used in a DF algorithm contains an entropy value depending on how many setups (values) it may take. In Browser properties for DF the authors have quantified the entropy for the parameters described in section 2 of this document. The combined entropy for a fingerprint 9

10 signature is expected to be lower than the sum of the entropy of each contained parameter, as not all combinations exist in practice while others are very common. Http: Javascript: 10

Browser fingerprinting

Browser fingerprinting (how did we get here) SecAppDev February 2014 Nick Nikiforakis www.securitee.org echo `whoami` Postdoctoral researcher at KU Leuven Working, mainly, on web security and privacy Identify