5 ms·
Ssl.com: DCV bypass and issue fake certificates for any MX hostname
- cmeacham98 1y agoThis is a ... pretty serious oversight. But at least it initially appears SSL.com is taking it seriously, we'll have to see what the report says.
- CrimsonRain 1y agoI guess they can check logs and find how many times this has been abused already? Can we trust them to release full transparent report?
- thayne 1y agoAll such certs should be in transparancy logs, so I think it should be possible for a third party to verify.
- agwa 1y agoRandom third parties can't verify if domain validation was performed properly; only the domain owner knows. Which is why domain owners should monitor Certificate Transparency logs: https://certificate.transparency.dev/monitors/ https://certificate.transparency.dev/monitors/
- gruez 1y ago>We will provide a preliminary report on or before 2025-04-21.
- aaomidi 1y agoThey will need to most likely do a full mass revocation at this point.
- toast0 1y agoI would expect them to be able to report on certificates issued based on this validation method. That's a basic CA capability and other CA incidents often include these kinds of reports. Depending on what was logged during the validation, it might be tricky to determine if it was abuse or not. If the DNS content wasn't logged, they could pull a live record and report if the current record would support validation or not. My guess is that use of this method should be low... If you're updating DNS to add a TXT record, you might be more likely to add a direct verification value rather than an email. But that's speculative; I'm not a CA, I've just been a customer of several... IIRC, I've validated domain control by controlling postmaster@ (or the whois address when that was public) or adding direct TXT verification records or ACME http validations.
- agwa 1y agoThis method may be more popular than you'd think, since it only requires the TXT record to be published once, whereas using the DNS method requires periodically updating the DNS record. Yes, that can be automated or delegated, but for a legacy/manual/dysfunctional organization, email to TXT record contact is an easy alternative to the now-banned email to WHOIS contact method that they were likely using previously.
- thayne 1y agoYou could at least narrow it down to certs with multiple domains, since it sounds like the email domain was added as an additional domain.
- bawolff 1y ago> Can we trust them to release full transparent report? Generally browser vendors take a pretty dim view of CA's not being transparent when bad things happen. Given the seriousness of this issue,i suspect being aggressively transparent is their only hope of saving their business.
- thenickdude 1y agoThey've released their report now, 10 further certificates were mis-issued: https://bugzilla.mozilla.org/show_bug.cgi?id=1961406 https://bugzilla.mozilla.org/show_bug.cgi?id=1961406
- thayne 1y agoHave they started revoking invalid certs?
- voxic11 1y agoYou can see the cert was revoked here https://crt.sh/?id=17926238129 https://crt.sh/?id=17926238129
- progbits 1y agoUnclear who revoked that but I think it likely was the reporter who discovered the bug. They only needed it issued & logged as evidence, and would be good practice to revoke immediately.
- mcpherrinm 1y agoThe certificate remained unrevoked in OCSP until after SSL.com acknowledged the issue, so I don’t think the reporter was the one who had it revoked. It is also possible I was being served a stale/cached OCSP response.
- 0x0 1y agoSo I guess you couldn't get certificates for any random (MX) domain, only for those where you can obtain an inbox / user account. Still really bad, especially for things like gmail.com, but also larger enterprises. Intense.
- tptacek 1y agoIt is unlikely that SSL.com would issue a certificate for any major mail host; it would be malpractice for them not to have some kind of exclusion list. Issuing a Google certificate is a good way to get your whole CA killed.
- AdamJacobMuller 1y agoSure, gmail.com might be excluded, but its still a massive hole for a few reasons. This would affect ANY email provider who offers public email addresses. While I agree gmail.com is probably excluded (and maybe this doesn't bypass CAA -- maybe it does) there's a whole additional surface of anyone who has an email at any big enterprise getting a certificate for their domain. Even if I work at google.com, therefore have a google.com email, I should absolutely not be able to get a certificate for google.com just by getting an email at that company. I doubt it's even /that hard/ to buy an email account at a big company like that in the underground world, it seems like they are valuable generally and any company with 200k employees is going to have some leaks. This massively increases the attack surface of a simple leaked email account (which might otherwise have very little or no access). Crazy crazy oversight that has huge implications and is so easy to carry out that I would not be surprised if this was actually exploited by bad actors.
- londons_explore 1y agoplenty of companies have mailing lists which are listname@companydomain.com Getting on those lists is often easy. Same with support ticketing systems, etc.
- thayne 1y ago
- jenny91 1y agoWow... this is the most serious TLS issue I've seen since following these things.
- tptacek 1y agoIt's bad, but the WebPKI of the oughts featured CA certificates issued to random big enterprise IT teams that could simply issue arbitrary certificates. We've come a long ways.
- AdamJacobMuller 1y ago> We will provide a preliminary report on or before 2025-04-21. Bunch of engineers just got their easter weekend ruined. Sucks.
- sneak 1y ago[flagged]
- btown 1y agoPublic service announcement: CAA records exist and allow you to whitelist the CAs you trust to issue certificates for your domain. https://letsencrypt.org/docs/caa/ https://letsencrypt.org/docs/caa/ You can use https://www.entrust.com/resources/tools/caa-lookup https://www.entrust.com/resources/tools/caa-lookup (or e.g. `dig caa paypal.com`) to see if any domain is protected. https://isc.sans.edu/diary/26738 https://isc.sans.edu/diary/26738 is a cautionary study from 2020 indicating only 3% of the Alexa top 1M had CAA records. And just now, I've seen numerous news and government sites that do not have CAA enabled... making them vulnerable to issuance bugs like this on CAs they may never have heard of, and thus making their readership/constituencies vulnerable to misinformation and fraud, especially in the context of a potential multifaceted attack against router infrastructure to perform MITM attacks at scale. Of course, you'll want to make sure you don't accidentally disavow an important subdomain where an engineer used a different CA than your usual suspects. But looking at all historic issuers for your domain hierarchies on transparency logs using e.g. https://crt.sh/ https://crt.sh/ might be a good place to start. It's also good to monitor certificate transparency logs, but then the onus is on your security team to react if an incident occurs. Proactive controls are vital as well, and IMHO CAA avoids many of the downsides of pinning.
- agwa 1y agoDomain owners may find my CAA record generator <https://sslmate.com/caa/ https://sslmate.com/caa/> useful, as it can automatically generate a CAA policy that covers all the certificates found in CT logs for your domain. It's not always obvious how to translate from issuer name to CAA domain (due to white labeled intermediates); my tool consults CCADB data to determine the correct CAA domain.
- m_sahaf 1y agoI always wonder who/what checks if CAs respect CAA. I know some browsers now check the certificate transparency log, but are there any that check the CAA record against the issuer of the certificate?
- 9dev 1y agoWouldn’t that be an obvious quick win?
- 0xbadcafebee 1y agoAnd remember kids: there's hundreds of CAs, they all implement validation independently, and you just need one to do one of the three validation methods wrong to make any cert you want. And there's two dozen different attacks that work aside from bugs in validation. Cert validation is swiss cheese. But there's a fix: have the registrars confirm authority to issue certs using a public key uploaded by the domain owner. The CSR contains a request signed by the same domain owner key. The CA sends the CSR to the registrar, the registrar verifies it was signed by the same key they have, then they send back a newly signed object (that the eventual-https-end-user can later confirm was signed by the registrar, so everybody knows that every step of the way was confirmed cryptographically). This ensures a single secure authorization by the actual domain owner, verified by the registrar of the domain. All you have to change is how the CA validates, and the registrar needs to handle an extra step or two. Solves 95% of the vulnerabilities. ....but nobody's going to do that, because the fact that Web PKI is swiss cheese hasn't threatened a big enough business yet. Once money or politics is threatened, they'll fix it.
- cmeacham98 1y agoWith your solution, we end up with the same problem just one layer down. Browsers have to contain a list of 'trusted' registars, and an attacker only needs to find one buggy registrar that will incorrectly sign for a domain the attacker doesn't own.
- 0xbadcafebee 1y agoThat's a much simpler problem to solve than the current one. One attack vector to cover, one set of organizations, one trust list. It's definitely no worse than our current predicament. Basic math shows how much safer the new model would be: - Assume there are 350 CAs, 3 validation methods, and 12 kinds of exploit per validation method (there are more in some combinations but for simplicity I'll say 12). (350 x 3 x 12) leaves *12,600* possible attack vectors. - Now assume there's 2,650 domain registrars, 1 validation method, and 1 kind of exploit. (2650 * 1 * 1) leaves *2,650* possible attack vectors. So 4.75x fewer possible attack vectors. Add to this that with only 1 validation method and 1 feature to support, that's way less code, which means much fewer bugs. Add to that a cryptographic chain of proof that the key of the domain owner was used to sign the request all the way, which we don't have today.
- Galanwe 1y agoThe whole PKI concept is dead anyway. Users have been trained to bypass certificate warnings by CA store wars between browsers and OSes, MitM corporate SSL proxies a-la ZScaler / Intune, corporate self signing CAs for intranets and whatnot, blindfolded public CAs giving certs to whatever.
- peanut-walrus 1y agoWhat? When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)? What examples can you give for public CAs giving certs to "whatever"?
- Galanwe 1y ago> When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)? Essentially all the time for the last 10 years... Did you ever try to deploy a website with a certificate from a non public CA? Like, say, your company CA? If you want it to be valid for Java users, you will have to store your CA cert on the Java trust store. Want it available for users of Firefox ? Store it in the OS certificate store. Want it available for Chrome users? Store it in the Chrome certificate store. Want it available for Python users? Add it to certifi. And so on. No single piece of software validating certificates agree on a single CA certificate store. So, essentially, no company out there supports all these stores, and you just train users to bypass these warnings. > What examples can you give for public CAs giving certs to "whatever"? There have been dozens of CAs removed from widespread trust stores for failing to do proper diligence or reporting leaked keys. Not only that, but essentially I never myself to do any kind of diligence for whatever certificate I requested from public CAs beyond proving I had TXT records update powers at some point in time. I'm not even mentioning fortune 500 websites running with expired certs.
- LiamPowell 1y ago> So, essentially, no company out there supports all these stores, and you just train users to bypass these warnings. This just sounds like a problem with your company. The barrier for getting certs from a public CA is lower than ever now that Let's Encrypt and others exist. If you really must have a non-public CA then your company needs an IT team that can properly manage that. This isn't an issue for normal users.