(1 votes, average: 5.00 out of 5)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

September 18, 2018 Comments closed

What is a Rogue Certificate? How do you prevent them?

in Everything Encryption

A rogue certificate can wreak havoc on your company – here’s how to prevent that.

One of the most frequent questions we get asked is, “what is a rogue certificate?” And unfortunately, the answer isn’t quite as exciting as the name connotes. Still, rogue certificates represent a major threat to Enterprise businesses. Really, any business – it’s just that Enterprises have the most surface to cover, which means they’re easier to miss.

To answer the question “what is a rogue certificate?” we’re going to have to start with a little bit of background, discuss what it means when a Certificate Authority (CA) goes rogue and we’ll end our discussion with some tips on preventing rogue certificates from affecting your business.

So, what is a rogue a certificate? Let’s hash it out.

What your digital certificate is really authenticating

Let’s start by talking about the authentication aspect of Public Key Infrastructure – specifically in an SSL/TLS context. When a digital certificate is issued, you send the Certificate Authority your public key and a Certificate Signing Request, complete with all relevant information. The CA validates it and returns a signed digital certificate that contains the validated information.

Now, there are higher levels of validation, which authenticate businesses (Organization Validation and Extended Validation), we’re going to ignore those in this discussion and focus on the one authentication that all SSL/TLS certificates provide: server authentication.

When the CA performs domain validation it’s attempting to verify that the certificate request came from the domain’s legitimate owner.

There are a few ways to do this, the CA/Browser Forum (which determines the baseline requirements that government certificate issuance) actually just strengthened the checks that are made.

But the idea is always the same, the CA needs to verify that you are indeed the owner of the domain that is living on that server.

Once it’s done this, the CA issues the certificate. This is how it’s supposed to work.

So, what is a rogue certificate?

A rogue certificate is a legitimate, trusted certificate that has been issued by a trusted certificate authority but is either compromised or was issued to the wrong party. There are a few ways this can happen – we will get to those in a moment.

We’re not going to go in-depth in discussing the trust model (here’s a full description), but let’s at least cover the basic concepts. When a CA issues a certificate, it signs that certificate with one of its private keys. This private key was either signed by a trusted root, or was signed by an intermediate root that was signed by the trusted root. Either way, when a browser receives a trusted SSL certificate, it follows the digital signature back to the certificate it’s associated with until it eventually reaches one of the trusted roots in its trust store.

As long as the certificate’s signature can be chained back to a root the certificate is trusted. A rogue certificate is a trusted certificate that is associated with a site that the certificate’s owner doesn’t actually control.

Eric Vandenburg, the VP of TCDI (Technology Concepts & Design, Inc.) paints a pretty clear picture of why this is dangerous:

Rogue certificates allow attackers to create illegitimate sites that are indistinguishable from real sites like eBay, Google or PNC because their certificate hierarchy can be validated.  Users then will be redirected to such sites through phishing or ”man in the middle” attacks where a compromised host in-between the user and a legitimate site sends traffic to an illegitimate site instead.

We cover on a regular basis how convincing phishing websites are. How prevalent they are. How dangerous they are. And up until recently, Google’s HTTPS indicator – which placed a “Secure” badge beside the URL in the address bar – was only making things worse.

But even with all those factors tipping the scales in phishing’s favor, a discerning eye could still spot a fake.

Not with a rogue certificate. A rogue certificate will trick users’ web browsers into trusting the website despite it being a fake.

How can a rogue certificate trick a user’s browser?

Let’s talk about the way that certificate-based authentication actually works. This isn’t the validation that takes place during issuance, this is the check that a browser does when presented with a certificate upon arrival at a website.

The checks are:

1. Was the certificate signed by a trusted CA? Does the digital signature chain back to one of the roots in the trust store?
2. Is this certificate still valid? When was it issued? When does it expire? Are we still in that time frame?
3. Has the certificate been revoked? This requires an OCSP or CRL check.
4. Does the key pair match? Is the server in possession of the associated private key?

Step 4 is sometimes referred to as proof of possession. And I say steps, that’s just for reference – let’s not get too hung up on the terminology. The browser will encrypt some piece of throwaway data with the certificate’s public key. Now, the public key is actually derived from the private key, which is why only that private key can decrypt that public key. This is what prevents spoof websites from just copying a legitimate site’s SSL certificate and trying to present its public key as its own. That certificate’s public key wouldn’t work because the server presenting the certificate doesn’t have the private key.

Ok, so now let’s mix in a rogue certificate.

Remember, a rogue certificate is a valid certificate that has come into the possession of a third-party – typically a malicious one. That means that the attacker actually has the private key.

So when you arrive at a malicious website with a rogue certificate, your browser performs those four checks. It makes sure the certificate was signed by a trusted CA. It was. It makes sure the certificate is valid. It is. It checks if the certificate was revoked. It isn’t.

Now it’s going to check proof of possession.

It uses the public key associated with certificate to encrypt some data and the attacker, which has the associated private key, decrypts and returns it. As far as your computer system is concerned, this website is who it says it is.

A user’s computer never actually authenticates the server itself, it just authenticates the certificate. It’s kind of like when you present a police officer with your driver’s license. He’s going to make sure that the picture on the license matches, that the license is valid, that it hasn’t expired and he’s going to call into the DMV to make sure it hasn’t been revoked. If those all check out, he’s going to accept the license as legitimate. He’s not actually going to check your DNA and blood type to make sure it’s you on a biological level, he’s going off the documentation.

PKI works the same way. A rogue certificate isn’t all that different from a forged passport or a faked identity in a spy film. It allows an attacker to operate under a false identity.

How do rogue certificates get issued?

Here is the million dollar question, how do rogue certificates happen? Well, there are three primary sources of rogue certificates:

• Rogue Certificate Authorities
• Breached Certificate Authorities
• Beating a CA’s Domain Control check

Let’s start with certificate authorities going rogue and then we’ll talk about the various exploits that have been used to get legitimate CAs to mis-issue certificates.

When Certificate Authorities go Rogue

There are a number of reasons a Certificate Authority may go rogue. It could be as a result of root compromise, it could be the result of unscrupulous management decisions or it could be that the CA issued an intermediate root to an untrustworthy company.

That’s what ultimately led to the downfall of CNNIC, a Chinese company that had a trusted root that was revoked by Google (and other root stores) in 2015. CNNIC had issued an intermediate root to an Egyptian company, MCS Holdings, that misused the intermediate to sign malicious certificates for websites like Google and Microsoft, that were then installed on a MITM proxy server.

Remember, because the intermediate root was signed with the private key of a trusted root, any endpoint certificate signed by the intermediate is automatically trusted by browsers. That meant Google and Microsoft had to scramble to distrust CNNIC’s roots, invalidating thousands of legitimate certificates in the process.

A similar situation occurred in 2013 when ANSSI, which is the French National Cybersecurity Agency, issued an intermediate root to a sub-CA that then misused it to issue fraudulent certificates, also as part of a MITM proxy operation.

When Certificate Authorities are Breached

Breaching a CA is another method for getting rogue certificates issued. If attackers can break into the CA’s network and compromise the private key they can get certificates mis-issued. This happened twice in 2011, with the more notable case being that of DigiNotar, a Dutch CA that was breached that July.

In this case, Iranian hackers compromised the CA’s private key after gaining entry to the network via SQL injection. That was the beginning of the end for the Dutch CA. The Dutch government took over in September of 2011 and by the end of the month had declared DigiNotar bankrupt. The major root stores removed the DigiNotar roots, which in effect revoked all DigiNotar certificates the world over (they could no longer be chained back to a trusted root).

“To be able to use such a certificate, the hacker would need to intercept traffic and insert their own fake certificate in a Man-in-the-Middle (MitM) attack,” wrote Tech Republic’s Patrick Lambert. “In the case of DigiNotar, that’s exactly what happened. The Iranian government has proxy servers through which all of the country traffic transits. With such a certificate, it meant that they can suddenly access every single user’s Gmail account, bank account, or any encrypted connection they want in the country, since they had the private key of a trusted authority, and could then issue CSRs for any website they wanted.”

Beating a CA’s Domain Control Check

Finally, we have exploits that can trick a CA into issuing a rogue certificate without having to compromise the private key itself. Now, let me preface by saying that neither of these exploits would be easy to pull off – at least for the average internet user.

The first is now outmoded because the industry has mandated the use of SHA-2 as the hashing algorithm in X.509 certificates. So, unless you’ve got a working PKI that still uses MD5, this won’t work.

But the idea behind it is to create a collision using the MD5 algorithm. Hashing is the practice of mapping data of any length to a fixed length output.

Ideally, no two hash values should ever be the same. When they are, it’s called a collision.

Per the abstract on CAPEC-459:

An adversary exploits a weakness in the MD5 hash algorithm (weak collision resistance) to generate a certificate signing request (CSR) that contains collision blocks in the “to be signed” part. The adversary specially crafts two different, but valid X.509 certificates that when hashed with the MD5 algorithm would yield the same value. The adversary then sends the CSR for one of the certificates to the Certification Authority which uses the MD5 hashing algorithm. That request is completely valid and the Certificate Authority issues an X.509 certificate to the adversary which is signed with its private key. An adversary then takes that signed blob and inserts it into another X.509 certificate that the attacker generated. Due to the MD5 collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary’s second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

The second exploit (and no, this isn’t an exhaustive list) is a more recent one and involves DNS cache poisoning. We actually covered this earlier this month. Basically, the attack is initiated with a DNS request, the attacker needs to craft a correct DNS response before the real one from the nameserver arrives. When the CA performs the domain validation checks, it receives answers from the attacker’s DNS server.

In order for the attack to work the DNS response needs to be broken down into fragments, which are then injected to trick the CA into issuing the requested certificate. While the first fragments in the response actually contain the valid DNS challenge-response fields, the rest contains whatever information the attacker needs to get the certificate.

This attack hasn’t been seen in the wild yet, it was discovered by a group of German researchers that will present it at a security conference next month.

How can my company avoid rogue certificates?

There are a number of different steps you can take, as well as some exciting industry initiatives that should also help alleviate some of these concerns. Let’s start with the industry initiatives and then we’ll get into some certificate management advice.

Certificate Transparency

One of the initiatives Google has been most passionate about is Certificate Transparency. Earlier this year, CT logging became mandatory. In order for a certificate to be trusted, it must be properly logged. What that means is that every time a Certificate Authority issues an SSL/TLS certificate it is obligated to submit record of that issuance to a third party Certificate Transparency log. The rules for logging vary by company, but most browsers require that certificates be added to at least two CT logs.

By doing this, it gives companies greater oversight. Using tools like Facebook’s log viewer, it’s possible to see what certificates have been issued for what domains. And upon encountering any rogue certificates, request their revocation. Unfortunately, revocation is something that the whole SSL/TLS ecosystem needs to address, but CAs do have obligations to revoke certificates within a certain time-frame when it’s requested.

CAA Records

A CAA or Certificate Authority Authorization is a DNS record that serves as an internet security policy mechanism. Basically, a CAA dictates which Certificate Authorities are authorized to issue certificates for your organization. A CAA record can set policy for specific host names or an entire domain. CAA records are specified as RFC 6844.

By restricting issuance to just a handful of CAs, you can limit some of the risk posed by a rogue certificate. All CAs are required to make a DNS lookup for CAA before issuing. Failing to check it constitutes mis-issuance and most CAs are loath to mis-issue. Google has literally killed for less.

More tips for avoiding Rogue Certificates

We say it all the time, but the most important thing for Enterprises is visibility. You need a certificate management tool that allows you to inventory all of your digital certificates, track expiry and reissues, automate certain functions and just generally allow you to control your PKI through one interface.

RELATED: 11 critical mistakes to avoid when setting up your PKI

Beyond good certificate management habits, here are a few other pieces of actionable advice:

• Patch regularly, specifically browser and Operating System patches. This is good security hygiene in general, (just ask Equifax) but it’s especially important in this context because this is the way that updates to root stores are rolled out. When a Certificate Authority is compromised or mis-issues badly enough the most direct way to triage the problem is to remove the affected roots. This automatically distrusts all certificates that were signed by that root or one of its descendants. When this happens, your organization is vulnerable until it patches and updates its root stores.
• Limit asset exposure, meaning reduce attack surface by enacting strong CAA policies that restrict issuance to only a handful of CAs. It’s also important to create organizational policies for the issuance and cycling of digital certificates so that everyone has a clear idea of the stakeholders in the issuance process. Having too many employees involved – too many cooks in the proverbial kitchen – is only going to confuse things. So streamline by restricting what CAs can issue for what domains and which parties are authorized to request issuance in the first place.
• Perform regular scans. There are tons of tools that can help you scan CT logs, revocation lists, network notaries and locally stored databases. These scans will assist you in finding rogue certificates, from there you just need to contact the right CA and get the certificates revoked.

And here’s one last piece of advice on a personal level, make sure your browser is configured to check for revocations. Certificate Revocation Lists and Online Certificate Status Protocol (OCSP) logs are maintained by CAs and tell your browser when it shouldn’t trust a certificate. Make sure that if an OCSP call fails, that your browser treats the certificate as untrustworthy, too.

Well, there’s your rundown. The next time someone asks “What is a rogue certificate?” Point them in this direction.

And as always, feel free to leave any comments or questions below.

• #PKI
• #Rogue Certificates