The Abuse of Root Certificates, Certificate Mis-issuance and Certificate Transparency

In a recent study, academic researchers found a thriving marketplace for TLS certificates sold individually and packaged with a wide range of crimeware. These services deliver machine-identities-as-a-service to cybercriminals who wish to spoof websites, eavesdrop on encrypted traffic, perform man-in-the-middle attacks and steal sensitive data. In this post, I’m going to focus on a different element of certificate mis-use—the abuse of root certificates. I’ll also highlight some indicators for analyzing certificate misuse as well as explore the impact of Certificate Mis-issuance and Certificate Transparency.



 

First, a bit about root certificates. Root certificates are the linchpin of authentication and security. Indeed, they form the basis of an X.509-based public key infrastructure (PKI), determining the foundation of trust for an organization. In a certificate trust tree or certificate path, the root certificate is at the pinnacle and certificates signed by it inherit the trustworthiness. What does this mean? To use a real-world analogy, a signature from a root certificate is somewhat comparable to having your personal signature notarized by an authorized entity. 
 

Consequences of a root certificate being installed for malicious purpose

Because of the inherent trust that they engender, root certificates are incredibly valuable—not only to organizations, but also to the attackers that wish to compromise those organizations or impersonate an organization for financial or other gain.
 

Attackers have used the tactic of illicitly obtaining a root certificate in many incidents and campaigns—highlighted by MITRE’s ATT&CK framework—because it can allow them to:

• Avoid prompting users with security warnings when their compromised systems connect to malicious Command and Control servers as seen in case of Operation Emmental.
   
• Sign malicious code that may then bypass signature validation as demonstrated by security researcher Matt Graeber.
   
• Establish MITM capabilities for intercepting information as seen in the case of the Superfish incident. 
   

Indicators for certificate review and analysis

It’s important to continually monitor SSL/TLS certificates for any security risks or vulnerabilities. When analyzing TLS certificates either as part of a potential or actual incident investigation or as part of security audit or review, the following are some indicators or areas that one can look for:

• The root CA certificate is used for issuing certificates other than (or instead of) intermediate CA certificates. This is a critical finding because intermediate CA certificates are typically used to issue code signing and TLS certificates, which are high measures of trust.
   
• The certificate is of a type older than X.509 v3. The Baseline Requirements of the CA/Browser Forum—a body comprised of major Internet browser providers and leading issuers of SSL/TLS certificates—recommends that certificates MUST be of type X.509 v3 (version 3). Otherwise, they may be vulnerable to downgrade attacks.
   
• The certificate in question is missing fields, such as Organization (O), Organizational Unit (OU), or Country (C). Or the certificate issued is v3 but is missing common x.509 v3 extensions. Both of these shortcomings may indicate fraudulent intent or, at the very least, a validation oversight on the part of the issuing CA.
   
• It lacks reference to a certificate revocation mechanism, such as CRL or OCSP. Attackers are not concerned with providing tracking mechanisms for the validity of the certificates they are attempting to misuse.
   
• The validity period of an intermediate CA certificate is same as that of the Root CA certificate. Intermediate CA certificates are normally used to generate code signing and SSL certificates for an enterprise and have a typically shorter validity period.
   
• The algorithm being used is md5WithRSAEncryption. For maximum protection, certificates should be using stronger algorithms—at least SHA256 or better. To check if it’s an MD5 type certificate, you can run the following command using openssl:
  • openssl x509 -in certificate.crt -noout -text | grep "Signature Algorithm"
  • The following will be the output if the certificate is using MD5:
  • Signature Algorithm: md5WithRSAEncryption

CA certificate mis-issuance

The abuse of root certificates can occur when a particular CA issues a TLS certificate improperly. This could be due to any of the following:

• CA incorporates incorrect information in the issued certificate.
• CA issues a certificate to someone who does not represent the entity or the domain.
• CA is compromised.

When you discover that certificates are mis-issued, it is important that you remediate the situation immediately. The longer it takes you to invalidate the mis-issued certificates, the longer attackers have a window to abuse them.

Certificate Transparency (CT)

One of the ways to mitigate this concern of abuse associated with mis-issued certificates is to provide the user with the capability to audit / monitor certificate issuances of trusted CAs. Google’s Certificate Transparency (CT) effort, started in 2013 was created to address this to improve security by allowing analysis of suspicious certificates. The use of the word “Transparency” in the name comes from the framework’s public auditing and public monitoring features.
 

The setup of Certificate Transparency adds a public oversight framework for the current SSL/TLS ecosystem. In other words, it allows anyone to log, audit, and monitor SSL/TLS certificates that are newly issued via any of the CAs such as DigiCert, GlobalSign etc. It’s important to note that while Certificate Transparency helps in the detection of mis-issued certificates, it cannot prevent certificate mis-issuance.
 

CT logs utilize a crypto mechanism called Merkle Tree Hash that doesn’t allow modification or deletion of entries, so once posted they become visible to the public. Also, CT does introduce some privacy and security risks due to the ability for an attacker (with the help of CT logs) to conduct reconnaissance and extract info. in potentially mounting an attack. Because a discussion of such risks is outside the scope of this blog, I will discuss that issue in a separate post.
 

Here’s a typical CT scenario

1. A certificate from Certificate Authority (CA) is purchased by a server admin, who is validated by the CA.
    
2. A Precertificate is created by the CA. Precertificates and certificates both have the same serial number but precertificates contain a poison extension to make them invalid. 
    
3. Upon receipt of a valid precertificate, a signed certificate timestamp (SCT) is returned by a log server.
    
4. A certificate is issued by the CA.
    
5. The SCT accompanies the TLS certificate until revocation. It is a token of promise that the log server will add the TLS certificate to the log within a specific time.
    
6. During the TLS handshake, both the issued certificate as well as the SCT are validated by the browser.
    
7. This SCT is delivered to the clients when they make a TLS connection. It’s done in any of the 3 ways - via OCSP stapling, via a TLS extension or via x.509v3 Extension.
    
8. If in case any discrepancies are found by the TLS client, it leads to rejection of the certificate.
    
9. The browser then establishes a connection to the server.
    
10. A TLS-encrypted connection is established.

The implications of not having Certificate Transparency

Without Certificate Transparency, it would be difficult for a legitimate domain owner to detect whether an authorized but undocumented or otherwise unexpected certificate was issued for their domain. Also, Certificate Transparency enables a legitimate domain owner to determine in a timely manner if any unauthorized certificate(s) were ever issued as part of a security compromise or breach.
 

While Certificate Transparency is an important tool in detecting and preventing the abuse of root certificates, it is not the only tool. It is also critical that you manage and protect the entire certificate lifecycle for all machine identities used in your organizations. To learn more about how you can do that, click here.

Related posts

• Google Chrome Now Requires CT Logging for All TLS Certificates
• Facebook Unveils Four Updates to Its Certificate Transparency Tool
• The Astounding Persistence of Abusive Certificates in Malware 
• How Criminals Are Leveraging SSL and HTTPS