1451943 - Social site timing attacks potentially preventable with Same-site cookies

Status: RESOLVED FIXED

(Core :: DOM: Security, enhancement, P1)

Description

[Daniel Veditz [:dveditz]]

Attachment: paper (CONFIDENTIAL until April 25)

A paper will be presented April 25 2018 at the IEEE conference in London about an efficient deanonymization attack on social service users because timing and size information leak across origins. Twitter thinks they can use SameSite cookies to prevent the attack on their service except only chromium-based browsers support them at this time.

Since we want to support SameSite cookies anyway as a general anti-CSRF mechanism we should definitely finish that work. We should also investigate whether there's any practical way to prevent the side-channel timing attacks used here

The paper is provided by Twitter with the permission of the paper's authors. It is CONFIDENTIAL until it is published on April 25.

===
Abstract—This paper presents a practical side-channel attack that identifies the social web service account of a visitor to an attacker’s website. Our attack leverages the widely adopted user-blocking mechanism, abusing its inherent property that certain pages return different web content depending on whether a user is blocked from another user. Our key insight is that an account prepared by an attacker can hold an attacker- controllable binary state of blocking/non-blocking with respect to an arbitrary user on the same service; provided that the user is logged in to the service, this state can be retrieved as one-bit data through the conventional cross-site timing attack when a user visits the attacker’s website. We generalize and refer to such a property as visibility control, which we consider as the fundamental assumption of our attack. Building on this primitive, we show that an attacker with a set of controlled accounts can gain a complete and flexible control over the data leaked through the side channel. Using this mechanism, we show that it is possible to design and implement a robust, large- scale user identification attack on a wide variety of social web services. To verify the feasibility of our attack, we perform an extensive empirical study using 16 popular social web services and demonstrate that at least 12 of these are vulnerable to our attack. Vulnerable services include not only popular social networking sites such as Twitter and Facebook, but also other types of web services that provide social features, e.g., eBay and Xbox Live. We also demonstrate that the attack can achieve nearly 100% accuracy and can finish within a sufficiently short time in a practical setting. We discuss the fundamental principles, practical aspects, and limitations of the attack as well as possible defenses.

Comment 1

[Daniel Veditz [:dveditz]]

Privacy-aware Firefox users could prevent these attacks through various methods
 * block all 3rd party cookies
 * use First-party isolation
 * use Containers for their social accounts

For some of the more popular social services (e.g. Facebook) it's possible Tracking Protection would prevent the attack. We are only theorizing and have not tested this.

Because all these techniques cause various kinds of web-compatibility problems they are not a general-purpose protection we can impose on all users as a fix, but they would work fine for many more users than have discovered these features on their own.

Comment 2

[Eric Rescorla (:ekr)]

BTW, this abstract is on the IEEE Euro S&P Web site.

Comment 3

[Daniel Veditz [:dveditz]]

The quoted bit is a question from me to Twitter. The reply after is from Greg Baker at Twitter:

> ​What were the timing techniques? the Origin: header shouldn't be present
> on a navigation so it seems like that would be a pretty reliable distinction
> between navigation and an xhr/fetch. Does timing via <img> tag work? In
> Firefox we should bail out equally fast when the returned Content-Type
> is not image/*. If the response really is an image (a profile picture?)
> there won't be an Origin header, but then it seems reasonable to bail
> if the Referer is not Twitter itself.​

The timing can be done in a variety of ways.  The researchers used img tags.  Some browsers (e.g. Chrome) wait for the full response before firing the error event on the img element.  Even if the browser does not wait for the full content to be downloaded, this can still be used to measure the server latency.  

image = new Image();
start = new Date();
image.onerror = function() { console.log(new Date() - start) };
image.src = "https://twitter.com/equanimityhow?" + Math.floor(Math.random() * 10000);

I've also found it possible using iframes and script tags.  Like the img approach, these both error out (iframe due to CSP and x-frame-options: SAMEORIGIN, and script because the content is not actually script), however the timing of that error can be used to measure the latency.

start = new Date();
script = document.createElement('script');
script.src = 'https://twitter.com/equanimityhow';
script.onerror = () => console.log(new Date() - start);
document.body.appendChild(script); 

start = new Date();
csrfFrame = document.createElement('iframe');
csrfFrame.src = 'https://twitter.com/equanimityhow';

csrfFrame.onload = () => console.log(new Date() - start);

document.body.appendChild(csrfFrame)

Script, img and iframe request do not set Origin.  There are some tells for script and img in the accept header (they don't include text/html, they do include */*) however this is very dependent on UserAgent.  In addition the iframe requests, as far as I can tell, are indistinguishable server side from top level navigations.

Comment 4

[Daniel Veditz [:dveditz]]

We can call this fixed. There are still some edge cases to work out before closing bug 795346, but the essential feature--more than enough to resolve this attack--is complete.