
Timing attack against HSTS to sniff browser history in Chrome and Firefox - bretthopper
https://zyan.scripts.mit.edu/sniffly/
======
ejcx
Mitigation, get your site added to the HSTS Preload list.

Most of the advanced webappsec security features leak information. CSP, HPKP,
HSTS, etc, which was all 100% known.

This talk is excellent because it puts together the attacks into real PoCs,
real attacks, and great information on how it all works. These attacks in the
talk are quality too, instead of being 'mostly' theoretical.

This wasn't really documented all in one place, or as high quality in the
past. Way to go @bcrypt. High quality work.

~~~
toomuchtodo
Can anyone who runs a high trafficked site and isn't on the HSTS preload list
explain why not? I am genuinely interested.

~~~
ejcx
There's a lot of pressure to turn the includeSubdomains flag on, with the new
Google Submission Process (submit a form to hstspreload.appspot.com).

Not all businesses are in a situation where they can just turn on HTTPS across
all subdomains. I'm sure agl will make exceptions if you reach out and are a
high traffic site.

------
hobs
Probably a good idea to edit the title to indicate that this is an example
attack site as well, not my favorite thing in general to land on without
warning.

No js seems to mean no worries though.

~~~
kentonv
The results never leave your browser, though, so there's not much to worry
about.

~~~
desdiv
The JS code sent to kentonv's browser might be safe, but you can't really
meaningfully comment on hobs' situation, since you don't have a copy of the JS
code that was sent to hobs' browser.

~~~
kentonv
Actually I can. The author of this code is a friend of mine who works with the
EFF, and the idea that she's secretly sending malicious scripts to some people
but not others from her MIT web hosting space under her own name is simply not
plausible.

~~~
e12e
Unless, she's already compromised your browser and the two previous comments
are in fact placed by her!

In all seriousness, I appreciate the added context your (particularly this
last clarifying comment) add to the discussion.

------
zmanian
The site attacks seems to fail in Tor Browser. It returns a list of sites that
have nothing to do with my browser history. Probably because Tor Browser
reduces the time precision.[1]

It seems like it would be nice to require some sort of user privilege
escalation like accessing location, or webcam to access high precision timing.
This would close off a huge class of time related side channels.

[1][https://trac.torproject.org/projects/tor/ticket/1517](https://trac.torproject.org/projects/tor/ticket/1517)

~~~
bcrypt
Tor Browser restricts js timing precision to 100 milliseconds, which makes
this way harder. HTTPS Everywhere also creates a lot of false positives,
although those can be subtracted out.

See discussion at
[https://trac.torproject.org/projects/tor/ticket/17423](https://trac.torproject.org/projects/tor/ticket/17423)

------
markbnj
I hit the page from Chrome 45.0.2454.101 and it literally did not get a single
site that I regularly visit. It did make a hit on Reddit, I guess, but I have
only visited the site two or three times, and you could probably say that
about 2/3 of the population.

~~~
bcrypt
interesting, are you using any browser addons? please file a bug at
[https://github.com/diracdeltas/sniffly](https://github.com/diracdeltas/sniffly),
thanks

~~~
PepeGomez
Same here. Most sites are those that I visited shortly a long time ago.

~~~
cm2187
Same here. The only addon I use is uBlock origin. I also had to activate
javascript on the page which I normally don't.

------
devit
The root problem seems to be that the web security model is broken because you
can get onload AND onerror callbacks from img coming from 3rd party sources
regardless of CORS.

You are not allowed to read the content of those resources for security
reasons, and the fact that you can detect whether they have been loaded seems
just as broken (although obviously this usually only has privacy impact, while
reading the contents easily allows impersonating the user or stealing
secrets).

This attack abuses this by using HTTP URLs and causing HTTPS to trigger
onerror by using a content security policy that disallow HTTPS, which allows
to measure timing of the HTTP->HTTPS redirection, which is instantaneous if
the site had already been visited due to HSTS caching.

So I think two changes are needed:

1\. The browser should never fire onerror on non-CORS-allowed 3rd party
resources, but instead fire onload even if an error happens

2\. The onload event should ideally be triggered 1 second after the resource
has been seen regardless of whether it has been loaded or not. If that breaks
too many websites, the timing granularity should be rounded to the greatest
period possible.

There is also the problem of lots websites having CORS policies that allow * ,
so should probably also fix browsers to not allow sites to have CORS *
policies, at least for this purpose.

Alternatively, it might be possible to load those resources normally, but
effectively consider them to be a "3rd party origin from 1st party origin"
that is different from "3rd party origin" and from other 1st party origins for
all caching purposes.

However, this seems risky because if the 3rd party site manages to somehow
fingerprint the user (e.g. because the IP address is whitelisted) then that
information is potentially leaked to the 1st party site. For example, it would
be possible to detect whether your IP is whitelisted by a domain that
otherwise returns errors to everyone.

~~~
codedokode
You still can insert external image into a page and poll its size either
directly or detect it via layout changes.

Maybe the root problem lies in HSTS and browsers using HTTP by default
(because that is why we need HSTS)?

~~~
devit
Indeed, should disallow that as well, e.g. give such external images and
videos an intrinsic size of 1/3 the browser window size regardless of their
actual size.

And disallow (non-CORS-allowed) cross-domain JavaScript and CSS.

~~~
codedokode
It would be easier to disallow http-only CSP though.

~~~
dgoldstein0
this sounds like a good idea. I do have to wonder if you use CSP & https for
your own site (because what site deploys CSP without deploying https first?),
what sort of http-only directives would even be legal (i.e could successfully
load content) under mixed-content rules.

But I don't think this solves the whole problem, as the time to "redirect +
load https image" v. "HSTS redirect + load https image" is probably
significant enough of a difference to timing attack. In which case you just
need to time the onload of an image (or similar resource).

~~~
codedokode
CSP can be useful on HTTP-only sites to prevent and log XSS attacks (e.g.
somebody trying to insert a script on a page via vulnerable server script).
That is SCP primary purpose IIRC.

------
peteretep
Having disabled NoScript, Privacy Badger, HTTPS Everywhere, and AdBlock Pro,
it can tell I've been to npmjs.com. I'm not immediately worried.

Maybe too obvious to point out, but as far as I can tell, it looks for entries
in the browser cache, rather than looking at the history per-se. If you have
the browser cache empty when you close the browser (gotta watch those
evercookies!), that's also not an issue.

~~~
bcrypt
sort of. the hsts cache gets cleared when a private browsing session is closed
or when you clear it manually in browser settings. it takes a long time (up to
a year) to expire on its own.

------
SanPilot
This approach is rather interesting. But I'm wondering whether a similar
attack could be made by placing links on a web page and using the CSS :visited
selector to change the style of visited web pages. Couldn't you then check
which links have that formatting and which don't via JS?

~~~
bzbarsky
This used to be possible, but browsers put into place various mitigations:
restricting which properties a :visited selector can affect, always computing
both the visited and non-visited style to avoid timing attacks, etc.
[http://dbaron.org/mozilla/visited-privacy](http://dbaron.org/mozilla/visited-
privacy) has a writeup describing the issues and the solutions that were
adopted.

------
hoverbear
One nice thing is that it is quite inaccurate, I've visited a large number of
the sites it tells me I haven't.

~~~
chrismarlow9
It's accurate depending on what you're looking for. Saying you didn't visit a
site means you either did, or did not, but saying you did visit a site means
you 100% did for sure. In the case of a negative the results are meaningless,
but in the case of a positive they are accurate. Similar to a bloom filter

~~~
lysium
I've just checked my history and the sites I thought I have not visited do not
show (2/14). Maybe 85%?

~~~
bcrypt
Yeah, I think the accuracy so far has been like 75-80% among my friends (once
httpseverywhere is disabled). PS: you can check whether sites are in your HSTS
cache in chrome at chrome://net-internals#hsts

------
woogley
I think many popular sites will be a false positive because some browsers ship
with a list of HSTS domains.. visiting them in HTTP first wouldn't happen.
[https://code.google.com/p/chromium/codesearch#chromium/src/n...](https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json)

~~~
runesoerensen
Preloaded HSTS entries are filtered out
[https://github.com/diracdeltas/sniffly/blob/c645af76cb53a21a...](https://github.com/diracdeltas/sniffly/blob/c645af76cb53a21a8eba449d766d25da18d3db54/util/process.py#L65)

------
jpdus
Strange. I disabled "scripts from 3rd party sites" and "frames from 3rd party
sites" by default in ublock origin and this site successfully loads 329
external JS ressources from other sites (none are manually enabled). Does
anyone have the same problem? Is this a bug of ublock origin or expected
behaviour?

~~~
detaro
It loads images, not JS, if I understand correctly.

~~~
jpdus
Ah, thanks! That why these external ressources are shown but not blocked.
Interesting attack vector!

------
lifthrasiir
A slide discussing HSTS+CSP attack (this one) and also HPKP attack:
[https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf](https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf)

------
michaelmior
This was wildly inaccurate for me. I think it was wrong far more than it was
right.

------
bobedybobbob
The core issue is the same that leads to cross domain search timing attacks
[1] (which can be prevented with CSRF tokens)

With timing HTTP->HTTPS redirections maybe the issue is not that the response
can be timed but that HTTP exists in the first place? There are other similar
timing attacks that can easily be used to identify if a user is logged in to a
specific website [2].

[1]
[https://news.ycombinator.com/item?id=10211306](https://news.ycombinator.com/item?id=10211306)
[2]
[http://crypto.stanford.edu/~dabo/papers/webtiming.pdf](http://crypto.stanford.edu/~dabo/papers/webtiming.pdf)

------
EngineerBetter
Completely inaccurate for me.

------
dgoldstein0
Hm, tried this on my Android phone first and it didn't seem accurate - might
have found 1 or 2 sites I actually visited, a few I wasn't sure of, and would
randomly change between reloads. Seems to work much better on desktop Chrome
(win 7). Wonder why there's a discrepancy.

------
mirages
I'm using Chrome 46.0.2490.80 without HTTPS Everywhere and it couldn't find
any site I visited (tells me I visited none). I tried to visit a few and
restart the test, it didn't found anything either

Edit : retried in Firefox 41.0.2, it's giving accurate results

------
Tinyyy
How much of this is accurate, and how much of this is simply the top XXX sites
that people visit?

~~~
bcrypt
I pulled the list of domains out of the Alexa Top 1M plus some domains that my
friends run. But I'm not biasing results towards showing up as visited by
popularity or anything like that.

I didn't set up analytics to figure out how accurate results are for the
average person; having manually checked with a few people's browsers, I'd say
the accuracy rate is ~75%.

~~~
elangelcentral
At a glance, looks about 75% accurate for me. But what really freaked me out
is that it correctly flagged a financial institution (not a major one) where I
have an account yet feel pretty sure I haven't visited the website in months.

~~~
bcrypt
Yeah, part of the nice/scary thing about HSTS is that it is a highly
persistent cache. The browser is reluctant to clear it because it's a security
feature. So HSTS pins can be stored for up to a year in FF/Chrome, even if you
are deleting cookies regularly.

------
gergles
Thankfully, this particular attack does not work with a running µmatrix. I do
see a bunch of image requests to all these domains, but it shows that I
haven't visited any (except for the ones that are blocked completely by hosts
files, amusingly enough).

~~~
bcrypt
adblocked domains are indistinguishable from hsts blocked domains in terms of
timing. so they show up as false positives. a clever attacker could subtract
them out though.

------
RA_Fisher
I was skeptical at first, then I visited some of the sites it said I had not
visited. A second round caught them, eep! A little machine learning could
probably make this much more accurate, the PoC is clear.

------
whoopdedo
Are timing attacks over the internet affected by buffer bloat?

Not a single positive even though I have visited a number of the sites on the
list. There's even tabs open for Reddit right now.

------
drvc33
this worked on an older version of chrome for me, but not the recent ones --
the sites listed were incorrect.

additionally, some alternative browsers based on chromium also gave inaccurate
results when used on ipad and android.

this is strictly based on my exp w/ my own machines. im a security researcher
so maybe my machines exhibit more unconventional settings / environments that
are atypical of the avg user.

will try again later on a different machine. this is interesting stuff,good
work.

------
sengork
Security features (like any software features in general) are additional
vulnerability vectors prone to implementation flaws.

------
gbraad
Tried with Firefox for Android 41 and it is quite accurate.

Note: in China, so sometimes HTTPS actually fails to establish

------
BillinghamJ
Doesn't seem to be working in Safari on Mac. I'm getting over 650 CSP errors
in my console.

------
spacehome
I'm using HTTPS Everyhwere, and it couldn't get a single website correct.

~~~
kentonv
Yes, HTTPS Everywhere blocks this particular attack, hence why the top bar
says to disable it.

(Incidentally, the author of this attack is also one of the authors of HTTPS
Everywhere.)

------
loginusername
Does not seem to work without Javascript enabled.

------
hamhamed
A different version of this would of been to mess around with the :visited css
selector since it's assuming a list of domains that you probably visit

~~~
bretthopper
This has mostly been fixed.

See [http://dbaron.org/mozilla/visited-
privacy](http://dbaron.org/mozilla/visited-privacy) and
[https://blog.mozilla.org/security/2010/03/31/plugging-the-
cs...](https://blog.mozilla.org/security/2010/03/31/plugging-the-css-history-
leak/)

~~~
meowface
Yes. If you're using a browser version that's been updated past 2010-2011,
this will no longer work.

~~~
dlitz
Yes, and if you're running an older browser, then the webserver can provide
arbitrary code that just reads the history directly. :)

------
voltagex_
Wow. Our corporate proxy isn't going to like that many requests that quickly
from one box. I wonder if they can add a landing page.

~~~
27182818284
Yan has hit the HN homepage before, so hopefully it can weather this storm
too.

~~~
mangeletti
I believe voltagex_ meant outgoing requests from his/her location.

------
scosman
Sites you probably haven't visited: "myspace.com" < pffft. That's too easy.

------
grflynn
Luckily I have taken out entire classes of attacks against the browser (this
one included) using simple, baseline configs that harden the browser. I am
unsure how many people take these measures and I don't know the stats for how
many people are hardening their browser in some way, but I suspect large
swathes of web users are at risk here.

Since this is Hackernews, my efforts to educate the masses on weaponized
browser attacks like this would be futile, and I am sure many have configured
their browser in some rudimentary way to merry away the assholes.

There is a certain sigh of relief and 'ha catch me if you can' that coats me
when I see PoCs like this rendered obsolete and inert.

