4 ms·

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 al

by ejcx 11y ago

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.

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 ago
  Or, 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 ago
    Even without DNSsec, HSTS could pretty much work as advertised.
toomuchtodo 11y ago
Can anyone who runs a high trafficked site and isn't on the HSTS preload list explain why not? I am genuinely interested.
- ejcx 11y ago
  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.
yeukhon 11y ago
So what does it mean if now UA vendors have 1 million hosts added to HSTS pre-load list? Are they all created equal? Do they share the same preload list? Is there a single form to submit to all UA vendors? What if you have internal hosts that you still want the same mitigation in place? What is UA vendors' SLA on updating preload list? Preload suffers the same problem as pinning, correct me if I am wrong.
- ejcx 11y ago
  Preload does not suffer the same issue as pinning using a header. All sites on the list would just look like you probably visited them, which means ambiguity. Not all UAs share the same preload list, but they all borrow from the chrome preload list. Read here https://hstspreload.appspot.com/ https://hstspreload.appspot.com/. Its not a great ecosystem and I dont forsee it as one that is improving, with encryption being a big issue in some countries
meowface 11y ago
CSP, HSTS, and HPKP were all known to be exploitable for "supercookie" purposes, but not history sniffing like this. So it's fair to call this a novel attack.
- ejcx 11y ago
  No. Leaks were known far beyond the "supercookie", but attacks were not as high quality as these.
  - meowface 11y ago
    Could you link some older sources discussing some of these leaks? I'm having trouble finding any. Not doubting you, since you're probably right; would just be interested in reading them.
    - ejcx 11y ago
      AFAIK most of that info is in HN and twitter discussions between webappsec people. Here's a link[0] to a CSP leak that was briefly discussed on the webappsec mailing list. I also know Homakov wrote one[1]. That's one of the reasons I like this talk so much. It really cemented these type of issue with real attacks, instead of a loosely described bunch of PoC. I remember reading somewhere on an RFC (perhaps CSP) that reporting can cause unwanted information leakage, but I didn't find it in the security considerations with a quick control+f just now. [0] - https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0030.html https://lists.w3.org/Archives/Public/public-webappsec/2015Ju... [1] - http://homakov.blogspot.com/2014/01/using-content-security-policy-for-evil.html http://homakov.blogspot.com/2014/01/using-content-security-p...
      - meowface 11y ago
        Ah, I feel silly now. I remember reading Egor's blog post on that last year. Thanks.
      - bcrypt 11y ago
        In addition to Egor's stuff, I'd recommend just reading the "Privacy and Security Considerations" sections of various RFC's and W3C specs. Lots of theoretical attacks in there that people simply haven't built demos for! In case anyone's interested, slides are up at https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf and talk recording at https://www.youtube.com/watch?v=kk2GkZv6Wjs https://www.youtube.com/watch?v=kk2GkZv6Wjs

by ejcx 11y ago

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 ago
Or, 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 ago
  Even without DNSsec, HSTS could pretty much work as advertised.

toomuchtodo 11y ago

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

ejcx 11y ago
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.

yeukhon 11y ago

So what does it mean if now UA vendors have 1 million hosts added to HSTS pre-load list? Are they all created equal? Do they share the same preload list? Is there a single form to submit to all UA vendors? What if you have internal hosts that you still want the same mitigation in place? What is UA vendors' SLA on updating preload list? Preload suffers the same problem as pinning, correct me if I am wrong.

ejcx 11y ago
Preload does not suffer the same issue as pinning using a header. All sites on the list would just look like you probably visited them, which means ambiguity. Not all UAs share the same preload list, but they all borrow from the chrome preload list. Read here https://hstspreload.appspot.com/ https://hstspreload.appspot.com/. Its not a great ecosystem and I dont forsee it as one that is improving, with encryption being a big issue in some countries

meowface 11y ago

CSP, HSTS, and HPKP were all known to be exploitable for "supercookie" purposes, but not history sniffing like this. So it's fair to call this a novel attack.

ejcx 11y ago
No. Leaks were known far beyond the "supercookie", but attacks were not as high quality as these.
- meowface 11y ago
  Could you link some older sources discussing some of these leaks? I'm having trouble finding any. Not doubting you, since you're probably right; would just be interested in reading them.
  - ejcx 11y ago
    AFAIK most of that info is in HN and twitter discussions between webappsec people. Here's a link[0] to a CSP leak that was briefly discussed on the webappsec mailing list. I also know Homakov wrote one[1]. That's one of the reasons I like this talk so much. It really cemented these type of issue with real attacks, instead of a loosely described bunch of PoC. I remember reading somewhere on an RFC (perhaps CSP) that reporting can cause unwanted information leakage, but I didn't find it in the security considerations with a quick control+f just now. [0] - https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0030.html https://lists.w3.org/Archives/Public/public-webappsec/2015Ju... [1] - http://homakov.blogspot.com/2014/01/using-content-security-policy-for-evil.html http://homakov.blogspot.com/2014/01/using-content-security-p...
    - meowface 11y ago
      Ah, I feel silly now. I remember reading Egor's blog post on that last year. Thanks.
    - bcrypt 11y ago
      In addition to Egor's stuff, I'd recommend just reading the "Privacy and Security Considerations" sections of various RFC's and W3C specs. Lots of theoretical attacks in there that people simply haven't built demos for! In case anyone's interested, slides are up at https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf and talk recording at https://www.youtube.com/watch?v=kk2GkZv6Wjs https://www.youtube.com/watch?v=kk2GkZv6Wjs