Anonymous ID: e7eabe June 4, 2021, 3:15 a.m. No.13827221   🗄️.is 🔗kun   >>7233

Certificate Authority

 

Timeline of Certificate Authority Failures

Certificate authorities have a long history of security failures. Would you blindly trust them with your security?

 

2001 - VeriSign

An attacker posing as a Microsoft employee convinces VeriSign to issue two unauthorized code signing certificates for Microsoft.

 

Root cause: Insufficient validation of the request by VeriSign.

 

VeriSign is later acquired by Symantec, which is eventually distrusted by all major platforms due to additional malfeasance.

 

2008 - Thawte

Mike Zusman registers the email address sslcertificates@live.com and uses it to obtain a rogue SSL certificate from Thawte for Microsoft's live.com.

 

Root cause: Thawte allowed domain validation emails to be sent to an email address (sslcertificates@live.com) that wasn't commonly reserved as an administrative address.

 

Thawte is later acquired by Symantec, which is eventually distrusted by all major platforms due to additional malfeasance.

 

2008 - StartCom

Mike Zusman exploits a flaw in StartCom's web interface to obtain certificates for domains without proper authorization.

 

Root cause: The StartCom web interface was blindly trusting user input, allowing domain validation emails to be sent to arbitrary email addresses at unrelated domains.

 

Eight years later, StartCom is distrusted by all major platforms due to additional malfeasance.

 

2008 - Comodo

Eddy Nigg discovers that Certstar, a Comodo reseller, was not performing domain control validation of any kind and exploits this to obtain a rogue certificate for www.mozilla.com.

 

Root cause: Comodo was trusting resellers to perform domain control validation, which is a critical certificate authority function, instead of doing it themselves.

 

https://sslmate.com/certspotter/failures

Anonymous ID: e7eabe June 4, 2021, 3:21 a.m. No.13827233   🗄️.is 🔗kun   >>7239

>>13827221

 

2009 - Null prefix attack

Moxie Marlinspike gets a certificate from ipsCA for a DNS name containing a null character. Although ipsCA correctly validates the DNS name as belonging to Moxie's domain, the null character tricks some clients into thinking the certificate belongs to www.paypal.com, enabling impersonation of PayPal.

 

Root cause: TLS clients were only comparing DNS names up to the first null character instead of in their entirety. ipsCA was allowing null characters in DNS names despite this being a violation of X.509 standards.

 

Cert Spotter detects null prefix attacks and alerts the owner of the domain being targeted.

 

2011 - Comodo

An attacker by the alias "Comodohacker" compromises several Comodo resellers and obtains rogue certificates for www.google.com, mail.google.com, addons.mozilla.org, login.live.com, login.yahoo.com, and login.skype.com.

 

Root cause: Comodo was trusting resellers to perform domain control validation, which is a critical certificate authority function, instead of doing it themselves.

 

2011 - DigiNotar

An unknown attacker completely compromises DigiNotar and after obtaining full administrative access to all critical CA systems, issues rogue certificates for numerous domains. Over 500 fake certificates are detected, but the full extent of the breach remains unknown. A rogue wildcard certificate for google.com is used for mass interception of traffic from Iranian citizens.

 

Root cause: Insufficient network segmentation and generally poor security practices allowed the attacker to completely compromise DigiNotar after exploiting a vulnerability in a publicly-facing web server running out-of-date software.

 

DigiNotar is quickly distrusted by all major platforms.

 

2011 - TurkTrust

TurkTrust accidentally issues two intermediate CA certificates to subscribers. These intermediate certificates can be used to forge certificates for any domain on the Internet. Sixteen months later, one of them is used to forge a certificate for google.com.

 

Root cause: TurkTrust mistakenly applied a security policy from their test environment to their production environment, causing unconstrained intermediate CA certificates to be issued instead of regular end-entity certificates.

 

2014 - NICCA

The National Informatics Centre (NIC) of India, a subordinate CA of the Indian Controller of Certifying Authorities (India CCA), issues rogue certificates for Google and Yahoo domains. NIC claims that their issuance process was compromised and that only four certificates were misissued. However, Google is aware of misissued certificates not reported by NIC, so it can only be assumed that the scope of the breach is unknown.

 

Root cause: Compromise of certificate authority, with unknown scope.

 

2015 - CNNIC

CNNIC, in violation of their certificate practice statement, willfully issues an unconstrained intermediate CA certificate to MCS Holdings, an organization with no certificate practice statement or technical infrastructure whatsoever to operate a certificate authority. MCS Holdings uses the intermediate CA to forge certificates for Google and likely other domains.

 

Root cause: CNNIC violated their certificate practice statement and failed to properly oversee the practices of their subordinate certificate authorities.

 

CNNIC is distrusted by browsers.

 

2015 - WoSign

A researcher discovers that WoSign will perform domain control validation via unprivileged TCP ports and uses this to obtain an unauthorized certificate for a university. Despite being informed of the misissuance, WoSign fails to notify web browsers and the incident is not noted in WoSign's annual audit. It will not be publicly disclosed until a year later.

 

Root cause: WoSign was allowing unprivileged TCP ports (1024 and above) to be used for domain control validation. Since non-administrative users are typically allowed to accept connections on unprivileged TCP ports, this allowed users to obtain certificates for domains they did not administer.

 

Initially, WoSign announces that all certificates they issue will be logged to Certificate Transparency logs, but they are ultimately distrusted by all major platforms due to their malfeasance.

 

https://sslmate.com/certspotter/failures

Anonymous ID: e7eabe June 4, 2021, 3:23 a.m. No.13827239   🗄️.is 🔗kun   >>7247

>>13827233 CAs CONT'D

 

2015 - Let's Encrypt

 

SSLMate founder Andrew Ayer discovers that ACME, the automated issuance protocol used by Let's Encrypt, suffers from a cryptographic flaw that would allow attackers to fraudulently obtain certificates for domains they don't control. The flaw had gone undetected during a formal security audit. Fortunately, the flaw is discovered and fixed before Let's Encrypt goes live.

 

Root cause: ACME was misusing digital signatures by assuming a nonexistent security property.

 

2015 - Symantec

Over a period of several years, Symantec willfully issues over 100 test certificates for 76 different domains without the authorization of the domain owners. This is discovered when Google's Certificate Transparency log monitor detects an unauthorized certificate for google.com in Certificate Transparency logs.

 

Root cause: Symantec was willfully disregarding industry regulations by issuing trusted certificates without proper authorization.

 

Initially, Google requires that all certificates issued by Symantec be logged to Certificate Transparency logs, but Symantec is ultimately distrusted by all major platforms due to further malfeasance.

 

2015 - Symantec

Andrew Ayer discovers that Symantec is not properly extracting administrative email addresses from whois records, allowing attackers to fraudulently obtain certificates from Symantec for domains whose whois emails contain special characters such as plus. Symantec fixes the vulnerability and it is not believed to have been exploited.

 

Root cause: Symantec was unrobustly parsing domain whois records and failing to consider special characters such as + as valid characters for an email address.

 

Symantec is later distrusted by all major platforms due to additional malfeasance.

 

2016 - StartCom

Thijs Alkemade discovers that StartCom's brand new automated issuance API suffers from numerous flaws, including flaws that had previously been discovered and fixed by other CAs, that would allow attackers to obtain certificates for domains they don't control.

 

Root cause: StartCom ignored developments in the standards community and instead chose to design their own, insecure automated issuance API.

 

During the ensuing investigation, it is revealed that StartCom had concealed their purchase by WoSign, another incompetent certificate authority.

 

Initially, StartCom announces that all certificates they issue will be logged to Certificate Transparency logs, but they are ultimately distrusted by all major platforms due to their malfeasance.

 

2016 - Comodo

Matthew Bryant discovers that Comodo's domain validation emails are susceptible to dangling markup injection, allowing attackers to obtain unauthorized certificates if the domain administrator opens the validation email in an email client that supports HTML. Comodo fixes the vulnerability and it is not believed to have been exploited.

 

Root cause: Comodo was not properly sanitizing attacker-controlled input when emailing out domain control validation emails.

 

2016 - Comodo

Florian Heinz and Martin Kluge discover that Comodo is using unreliable optical character recognition to extract authorized administrative addresses from whois records. They are able to obtain an unauthorized certificate for a domain whose administrative address was misinterpreted by the optical character recognition. In response, Comodo ceases the use of optical character recognition.

Anonymous ID: e7eabe June 4, 2021, 3:25 a.m. No.13827247   🗄️.is 🔗kun   >>7251 >>7318

>>13827239

 

2017 - Symantec

 

Andrew Ayer discovers (using the API example on Cert Spotter's home page) that Symantec had issued over 100 certificates without proper validation, including certificates for example.com that were not authorized by example.com's owner. The ensuing investigation uncovers further malfeasance by Symantec, leading to the distrust of Symantec by all major platforms.

 

2018 - GoDaddy

During a proactive self-audit, GoDaddy discovers that the secret code that they email to an official domain contact to validate the certificate can be disclosed to unauthorized parties, allowing the issuance of unauthorized certificates. GoDaddy fixes the vulnerability.

 

2018 - Certinomis

Andrew Ayer discovers (via a Cert Spotter notification) that Certinomis has issued an unauthorized certificate for test.com. A further investigation using Certificate Transparency reveals additional misissuances, including an unauthorized certificate for pourtest.com, leading to the distrust of Certinomis by Mozilla.