TLS/SSL certificates have proven to be valuable commodities to organizations that use these machine identities to establish trust for connections and communications with customers, partners and employees. Unfortunately, this same trust is extremely valuable to cyber criminals for much the same reasons. When they fall into the wrong hands, TLS/SSL certificates can bring hidden risks to organizations, as we often see them being exploited in vulnerabilities and sophisticated attack campaigns.
PKI is based on a trust model, called chain of trust. A chain of trust is a list of certificates, usually starting with an end-entity certificate, followed by one or more intermediate certificates, with the last certificate in the list, called root certificate. The root certificate serves as a trust anchor, a certificate you trust because it was delivered to you by some trustworthy procedure. The root certificate, also called a trusted root, is at the center of the trust model that secures PKI.
Root certificates are being issued by Certification Authorities (CA), which are companies or government agencies that have been authorized to issue TLS and code signing certificates. In order to enforce the trustworthiness of CAs and their root certificates, these organizations undergo annual audits by third parties so as to insure they are in compliance with the CA/Browser Forum (CA/B Forum for short) Baseline Requirements.
The CA/B Forum was established to standardize the requirements for issuing publicly-trusted certificates. Members include browser vendors and public CAs. “Publicly-trusted” means that certificates issued by a CA are trusted by browsers and other systems that use certificates. The Baseline Requirements were designed to strengthen the security around authentication processes and SSL issuance operations. The requirements include identity vetting, certificate content and profiles, CA security, certificate revocation mechanisms, use of algorithms and key sizes, audit requirements, liability, privacy and confidentiality, and delegation of authority.
When CAs and Certificates Misbehave
Despite all the compliance and auditing mechanisms put in place by the CA/B Forum, there are cases when things go wrong. Current cryptographic mechanisms cannot detect malicious websites if they’re provisioned with mistakenly issued certificates or certificates that have been issued by a CA which has been compromised. In these cases, browsers see nothing wrong with the certificates because the CA appears to be in good position, giving users the impression that the website they are visiting is authentic and their connection is secure.
Although CAs are designated as trusted third-parties, security researchers argue that they are “corruptible central points of failure,” capable of compromising the integrity and security of the entire internet. The security of online communications can be undermined because of the complexity of managing keys and certificates, which is further complicated by the risk of coercion or compromise of a CA. Because of these dangers, users cannot be certain that their communications are not being compromised by a fraudulent certificate allowing a man-in-the-middle (MiTM) attack.
“Certificate Authorities are the basis of HTTPS, but they are also its greatest weakness,” says Cooper Quintin of the EFF. “Any of the dozens of certificate authorities trusted by your browser could secretly issue a fraudulent certificate for any website. A certificate authority (or other organization, such as a government spy agency) could then use the fraudulent certificate to spy on your communications with that site, even if it is encrypted with HTTPS. Certificate Transparency can mitigate some of the risk by requiring public logging of all issued certificates but is not a panacea.”
Fraudulent certificates is not the only threat. As noted by Malwarebytes, an attacker who steals the private key that belongs to a root certificate can generate certificates for his own malevolent purposes. If this root certificate already resides within a trust store, these bad actors can then issue their own certificates, sign them with the private key and thereby stage MiTM attacks or install malware onto web browser users’ machines. To make things worse, security researchers at the University of Maryland found that simply copying an authenticode signature from a legitimate file to a known malware sample can cause antivirus products to stop detecting it, even though it results in an invalid signature.
CA errors or compromise can result in forged or fraudulent certificates that allow attackers to perform MiTM traffic attacks to impersonate legitimate properties. It could also result in mis-issued intermediate certificates that allow attackers to act as their own certification authority and issue fraudulent certificates for virtually any site. In many cases, mistakenly issued certificates have been used by hackers for malicious attacks that have dire consequences, but the fallout after mitigation can be far ranging and harmful. The use of distrusted certificates and their revocation may cause a ripple effect as people will be denied access to government and private sites that were provisioned with the distrusted certificates.
Case studies: Lack of compliance with baseline requirements
The case of mistaken certificate issuance procedures went “viral” with the Symantec certificate authority. Back in 2015 Google found that Symantec was issuing unauthorized certificates for domains owned by Google, Opera and three other organizations. The scandal caused Symantec to fire a number of employees and Google required Symantec to begin adding all the certificates it issued to Certificate Transparency logs. At that point in time only EV certificates were required to be logged.
A year later, Symantec got in trouble for mis-issuing a new batch of test certificates. While Symantec claimed it was just 33 certificates, Google estimated it was close to 30,000. The subsequent Google investigation uncovered lax oversight over validation in some regions. From the browsers’ perspective (not just Google, but Mozilla, Apple and Microsoft, too) these mistakes undermined faith in Symantec’s entire PKI. How could any Symantec SSL certificate be trusted knowing that there was such lax oversight over the validation required for issuance? Symantec had to be distrusted and removed from the browsers’ trust stores.
Less known is the case with the Venezuelan CA PROCERT, when “PROCERT have not been, and continue not to be, adequately aware of the requirements placed upon them by various RFCs, the CA/Browser Forum’s Baseline Requirements, and Mozilla Root Store Policy. They have not demonstrated sufficient control of their issuance pipeline or sufficient checking of the results to avoid regularly creating certificates which violate the requirements of one or more of those documents,” reads Mozilla’s decision to distrust this CA.
Finally, in 2019, following a discovery of pre-certificates that were issued for unregistered domains by the French CA Certinomis, Mozilla launched an investigation which proved that Certinomis was facing serious configuration problems with certificate issuance that they were unable to solve in short time. As a result, Mozilla decided to distrust Certinomis due to repeated violations of certificate validation rules and to “remove the ‘Certinomis - Root CA’ from the Mozilla root store”.
What is the worst that could happen?
A Venafi sponsored academic study of the availability of SSL/TLS certificates on the dark web, and their role in the cybercrime economy, uncovered thriving marketplaces for TLS certificates sold both individually and packaged with a wide range of crimeware. Together these services deliver “machine-identities-as-a-service” to cyber criminals who wish to spoof websites, eavesdrop on encrypted traffic, perform man-in-the-middle attacks and steal sensitive data “in order to give attackers immediate access to high levels of online credibility and trust.”
More specifically, fraudulent certificates could be sold in the online underground market on the dark web to malicious parties if a trusted certificate authority is breached and private keys are stolen from it. In turn, these malicious actors could use them to move silently between trusted machines, “listen” to encrypted traffic, and escalate privileges to access sensitive data. Moreover, if the verification processes used by trusted certificate authorities to verify the identity of the requesting party can be circumvented or spoofed, malicious actors can be issued a TLS certificate that delivers the highest levels of trust, such as an EV certificate. This allows attackers to create “trustworthy” spoofed or malicious websites and encrypt the traffic between malicious servers to targeted users, making it more difficult to identify problematic behavior. It is a systemic failure of the trust model of authentication.
Internet users should not trust a site only because the TLS certificate is valid. These sites can also be spoofed. It is our shared responsibility to mitigate this attack vector, even if it proves difficult. There are ways for organizations to safeguard their legitimate certificates and the best one is to ensure successful management of certificates and keys. Organizations must have visibility into each of their TLS key and certificates, and they should recourse to automation for effective management of digital certificates.