4 ms·

another this time showing SSL https://twitter.com/saleemrash1d/status/1217495681230954506 https://twitter.com/saleemrash1d/status/1217495681230954506 edit: in

• tialaramex 7y ago
  The result with Chrome makes sense and I hadn't thought of that outcome. Let's walk through it for anybody else as slow as I am. You forge a certificate to attack a Windows victim.. - Chrome uses Windows' broken cert validation when run on Windows. So that passes. - But then it also checks SCTs. An SCT is a signature from a public Certificate Transparency log saying they've logged this exact certificate and it's available to the public. You get to pick in your bogus cert from two options A: Just use SCTs from some other certificate which was logged. Chrome (not Windows) checks the signatures and they don't match so your certificate is rejected. B: Try to log your bogus certificate to obtain an SCT. But the log checks certificate signatures and isn't running Windows, so it rejects the attempt. The SCTs needn't be baked into a certificate (if you're a random server operator yours probably are, but for some applications the extra work to do it another way was worth it) but that doesn't help an attacker because they can't get a valid SCT for their bogus certificate. Updated with: Things that might work Google only made logging mandatory for new certificates from April 2018. A February 2018 certificate could have the old maximum lifetime (39 months) and be exempt from the SCT requirement. So I think a forged cert which claims notBefore 2018-02-27 and notAfter 2021-04-01 or whatever would work with no SCTs inside it, against unpatched Windows systems. Certificates which aren't from the Web PKI skip the SCT check. So if you have a company CA which does ECC then a certificate could be forged from that CA and used to attack you in Chrome because the SCT checks don't fire.
• CiPHPerCoder 7y ago
  Bypassing CT on Chrome in this context should be trivial: https://cs.chromium.org/chromium/src/components/certificate_transparency/chrome_require_ct_delegate.cc?rcl=ae2f49f1fce4cacac5232782d9133239ff60821a&l=182 https://cs.chromium.org/chromium/src/components/certificate_... Set your notBefore to a date earlier than 2018-05-01 and you're golden.
  • tialaramex 7y ago
    Probably not too much earlier https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.cc https://cs.chromium.org/chromium/src/net/cert/cert_verify_pr... Method HasTooLongValidity splits certs into four categories First, really old certs with notBefore prior to 2012-07-01. This is before the Baseline Requirements, and so Chrome gives them the benefit of the doubt and presumes they might honestly have been issued with up to 10 years to expire BUT fortunately this grandfathering of old garbage was designed to end in July 2019 so all these certs are now distrusted. Any real ones were probably long gone by then anyway. Second, those from 2012-07-01 but before 2015-04-01 get up to 60 months = 5 years. So a cert issued 2015-03-31 must expire within about ten weeks from now, a workable demo but not a long-lived attack tool. Third, from 2015-04-01 but before 2018-03-01 it was 39 months. So any cert from 2015-04-01 is long expired, but one claiming it was issued 2018-02-28 expires in May 2021, that's a nice long time to exploit this bug. Finally from 2018-03-01 it was shortened to 825 days. A cert from 2018-04-30 would thus expire in August 2020. So the sweet spot is claiming issuance in February 2018. Edited: I can't count to four apparently.