9 ms·
Though HTTPS is better than nothing, and this attack relies on HTTP to inject the initial payload, state sponsored attackers in some countries can likely just s
by hedora 3y ago
Though HTTPS is better than nothing, and this attack relies on HTTP to inject the initial payload, state sponsored attackers in some countries can likely just subvert CA or CDN infrastructure instead.
- pipo234 3y agoOr get someone to click on a spoofed domain, certified by our beloved LetsEncrypt! Apparently al that is needed is an HTTP 302/307 redirect response (or html redirect payload, maybe even DNS?) pointing the client toward c.betly[.]me
- jefftk 3y ago> certified by our beloved LetsEncrypt Are you saying that CAs should be refusing to issue certs for potentially spoofed domains?
- pipo234 3y ago...or Digicert, Globalsign, the Hongkong post office, whichever CA is in your truststore. I just mentioned LetsEncrypt because it's free and exceptionally easy to use. I'm not implying in any way they aren't providing a great service, it's just that that service also gets misused because it's cheap and easy.
- insanitybit 3y agoHuge difference between being tricked into clicking a link vs just browsing the web and getting owned.
- aidos 3y agoIs there?
- insanitybit 3y agoYes. The move from 0 to 1 click exploits (thanks to putting Flash/Java behind a click) in the early 2000s marked a massive negative shift in attacker capabilities and ultimately destroyed multiple (black market) exploit dev businesses.
- fullspectrumdev 3y ago“Click to play” bypasses became incredibly valuable as an enabler for Flash/Java exploits, for a while. They were also few and far between, and if memory serves me, unreliable as fuck.
- pipo234 3y agoIt definitely matters. Just think about what sort of how much Dr. Evil would pay for an exploit that relies on user action versus one that doesn't. https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
- autoexec 3y agoI can probably avoid bring tricked into clicking a link, I've avoided many many attempts to trick me in the past. I probably can't avoid browsing the internet though.
- Macha 3y agoThe vector is an image file. Put your image in a display ad, now you don't need the user to click anything
- glaucon 3y agoI'm interested at your suggestion that Digicert et al are doing some sort of "keeping the streets safe" checking. I have zero experience of using them but I thought all they were doing was confirming the applicant represented some entity that matched the domain name. If I manage to get a company registered called G00gle, buy a corresponding domain and then send them my $500 are you suggesting they're going to refuse to issue a certificate? My impression was the CA's made the likes of Standard and Poor look rigorous, but I'm happy to learn more from actual experience of them rejecting such an application.
- vngzs 3y agoI don't see GP claiming CAs should be checking reputability for domain issuance certificates. But the thread originator mentioned subverting CAs! Something to remember about even the most advanced attackers is that they value the continued effectiveness of their tactics, tools and procedures. Even nation-states in possession of CA subversion abilities won't burn their malicious CA on someone if they can conduct the attack with a legitimately-issued certificate, and they won't bother with a legitimately-issued cert if they can conduct the attack without even involving a CA.
- glaucon 3y agoI was referring to this comment https://news.ycombinator.com/item?id=37615985 https://news.ycombinator.com/item?id=37615985
- deleted 3y ago[deleted]
- pipo234 3y agoYou are absolutely right, that (for plain, domain attestation) paid CAs are exactly as trustworthy as LetsEncrypt, and often much less (remember the Diginotar debacle, for example). "Keeping the streets safe" is not their responsibility, except in a very limited sense. The $500 extended validation was mostly paper work and snake oil. My point wasn't to discredit LetsEncrypt, but to point out that Google's claim to mitigate the MITM attack vector with https-first wasn't a very strong argument. I mean, yes, sure: if you can't intercept or downgrade to HTTP the MITM doesn't work. But all the HTTP seems to do was redirect to a malicious payload. But you can also do a redirect in HTTPS. So if you can spoof someone to go to https://g00gle.com/ https://g00gle.com/ it should be just as easy to launch the attack chain from there.
- malaya_zemlya 3y agoCoincidentally, the ACME DNS verification process that LetsEncrypt uses is vulnerable to the QUANTUM attack. If NSA injects a fake DNS response in the right spot, and have the their response arrive before the official response, they can get the domain verified. OTOH, Certificate Transparency Logs will give the game away, so there's that.
- jrockway 3y agoDoesn't Let's Encrypt check the DNS record from multiple widely-distributed endpoints to avoid this attack?
- astrange 3y agoYou probably can't forge a certificate like that without all the browsers noticing and dropping your CA; there's protections against it.
- kadoban 3y agoIf you're a nation you can just force the CAs that are in your jurisdiction to do whatever you want, or sneak in in various ways so they won't know. If you use the MITM judiciously, it's very likely that nobody will notice, or that those that notice can be compelled not to say anything.
- astrange 3y agoThe browser will notice that it's being given a cert that isn't in the CA transparency log + other hardcoded known certs for top sites and will phone home about it.
- kadoban 3y agoWhat browsers actually do that? And do all CAs support it? Besides, if you have enough access to the CA, you can just get whatever cert is in the transparency log, though that's almost certainly harder for most nations and CAs.
- trifurcate 3y ago> you can just get whatever cert is in the transparency log That would require compromising the certificate requester.
- notabee 3y agoA lot of certificate management services for enterprise customers "helpfully" store the private key files. How many cloud or SaaS vendors automatically handle the private keys as well instead of them being generated and staying securely only on the systems using them? So there are still points of centralization to attack, potentially.
- ComputerGuru 3y agoNote that it only took/takes one http visit (to any site) to compromise the device.