7 ms·
Timing attack against HSTS to sniff browser history in Chrome and Firefox
- hobs 11y agoProbably 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.
- bcrypt 11y agocreator here. sorry, i did not expected to be hn'ed. not running js is usually a good idea though!
- kentonv 11y agoThe results never leave your browser, though, so there's not much to worry about.
- desdiv 11y agoThe 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 11y agoActually 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 11y agoUnless, 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.
- robzyb 11y ago> The JS code sent to kentonv's browser might be safe, but you can't really meaningfully comment on hobs' situation [...] But if that's the case then you shouldn't click on anything on HN. I would argue that it is A-OK to post this link directly on hackernews. It just says "look at what your browser can do! imagine if blackhats took advantage of this."
- bcrypt 11y agoIn any case, I didn't minify or remove comments, so you can just view-source:http://zyan.scripts.mit.edu/sniffly/index.js http://zyan.scripts.mit.edu/sniffly/index.js
- vonklaus 11y agoThat is what I thought about my browser history.
- heretek 11y agoWhile I probably would have linked HN to the slides instead of the site, I do think calling it an attack site is paranoid and disingenuous.
- hobs 11y agoDoes the term "example attack site" not mollify that a bit? I tried to be clear that its not a real attack site (or my comment we be much more alarming) but something that executed malicious behavior, even if it wasnt from a malicious actor. Wasnt looking to castigate the author, just looking for a title with a warning.
- kzhahou 11y agoHonest question: what is your concern? Any link you click could possibly contain a hidden attack, perhaps a malicious one. If this link had been labeled differently, would you not have clicked?
- deleted 11y ago[deleted]
- hoverbear 11y agoOne nice thing is that it is quite inaccurate, I've visited a large number of the sites it tells me I haven't.
- chrismarlow9 11y agoIt'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
- michaelmior 11y agoI saw several sites pop up on the list of sites I visited that I'm quite sure I've never explicitly been to. It's possible these were all loaded via ads or some such thing, but it seems unlikely.
- lysium 11y agoI've just checked my history and the sites I thought I have not visited do not show (2/14). Maybe 85%?
- bcrypt 11y agoYeah, 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
- bcrypt 11y agowhat browser and extensions? feel free to file a bug at github.com/diracdeltas/sniffly
- voltagex_ 11y agoWow. 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 11y agoYan has hit the HN homepage before, so hopefully it can weather this storm too.
- mangeletti 11y agoI believe voltagex_ meant outgoing requests from his/her location.
- detaro 11y agoAny picture/script heavy main page (news etc) probably produces the same number of requests
- markbnj 11y agoI 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.
- deleted 11y ago[deleted]
- bcrypt 11y agointeresting, are you using any browser addons? please file a bug at https://github.com/diracdeltas/sniffly https://github.com/diracdeltas/sniffly, thanks
- PepeGomez 11y agoSame here. Most sites are those that I visited shortly a long time ago.
- cm2187 11y agoSame here. The only addon I use is uBlock origin. I also had to activate javascript on the page which I normally don't.
- markbnj 11y agoIn Chrome I am running ABP, which can't be very uncommon, Evernote web clipper, rest console, xpath helper, and a bunch of Google's own shims. I will file a bug later today if I can repro the results.
- scrollaway 11y agoSame on Firefox 41.0.2. It got 1 or 2 correct hits; a lot of correct ones in "sites you probably haven't visited" but then again that's not the hard part?
- rplnt 11y ago> you could probably say that about 2/3 of the population Hardly.
- Tinyyy 11y agoHow much of this is accurate, and how much of this is simply the top XXX sites that people visit?
- deleted 11y ago[deleted]
- bcrypt 11y agoI 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 11y agoAt 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 11y agoYeah, 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.
- lifthrasiir 11y agoA 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
- whoopdedo 11y agoAre 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.
- SanPilot 11y agoThis 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?
- mccr8 11y agoYou used to be able to do that, but it was fixed in 2010: https://blog.mozilla.org/security/2010/03/31/plugging-the-css-history-leak/ https://blog.mozilla.org/security/2010/03/31/plugging-the-cs...
- seanwilson 11y agoYes, this attack was demoed to work several years ago but has been patched as far as I know: https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_%3Avisited_selector https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and... "The first change is that Gecko will lie to web applications under certain circumstances. In particular, getComputedStyle() and similar functions such as element.querySelector() always return values indicating that a user has never visited any of the links on a page."
- bzbarsky 11y agoThis 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.
- ejcx 11y agoMitigation, 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.
- e12e 11y ago> Mitigation, get your site added to the HSTS Preload list. If that could scale, we wouldn't need DNS? Come to think of it, as ip addresses aren't distributed, why not have HSTS be a flag in DNS, rather than a header? (Yeah, I know, because DNS isn't secure - but that's the real problem, right there...).
- AndyMcConachie 11y agoOr, if the site you're visiting is DNSSEC enabled, you could just look for a TLSA record. If the TLSA record is present, don't allow unencrypted connectivity. That's probably how you could replace HSTS with DNS.
- cbsmith 11y agoEven without DNSsec, HSTS could pretty much work as advertised.
- toomuchtodo 11y agoCan anyone who runs a high trafficked site and isn't on the HSTS preload list explain why not? I am genuinely interested.
- ejcx 11y agoThere'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.
- hamhamed 11y agoA 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 11y agoThis 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-css-history-leak/ https://blog.mozilla.org/security/2010/03/31/plugging-the-cs...
- gergles 11y agoThankfully, 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 11y agoadblocked 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 11y agoI 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.
- scosman 11y agoSites you probably haven't visited: "myspace.com" < pffft. That's too easy.
- spacehome 11y agoI'm using HTTPS Everyhwere, and it couldn't get a single website correct.
- kentonv 11y agoYes, 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.)
- peteretep 11y agoHaving 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 11y agosort 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.
- michaelmior 11y agoThis was wildly inaccurate for me. I think it was wrong far more than it was right.
- gbraad 11y agoTried with Firefox for Android 41 and it is quite accurate. Note: in China, so sometimes HTTPS actually fails to establish
- zmanian 11y agoThe 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 11y agoTor 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
- EngineerBetter 11y agoCompletely inaccurate for me.
- BillinghamJ 11y agoDoesn't seem to be working in Safari on Mac. I'm getting over 650 CSP errors in my console.
- devit 11y agoThe 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 11y agoYou 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 11y agoIndeed, 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.
- jpdus 11y agoStrange. 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?
- dgoldstein0 11y agoHm, 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.
- dgoldstein0 11y agoHm, 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 11y agoI'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
- bobedybobbob 11y agoThe 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
- woogley 11y agoI 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/net/http/transport_security_state_static.json https://code.google.com/p/chromium/codesearch#chromium/src/n...
- runesoerensen 11y agoPreloaded HSTS entries are filtered out https://github.com/diracdeltas/sniffly/blob/c645af76cb53a21a8eba449d766d25da18d3db54/util/process.py#L65 https://github.com/diracdeltas/sniffly/blob/c645af76cb53a21a...
- grflynn 11y agoLuckily 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.
- sengork 11y agoSecurity features (like any software features in general) are additional vulnerability vectors prone to implementation flaws.
- loginusername 11y agoDoes not seem to work without Javascript enabled.
- drvc33 11y agothis 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.