PKI Bootcamp: How an Attacker Gets a Rogue Certificate
PKI Bootcamp: How an Attacker Gets a Rogue Certificate
The basic role of a certificate is to bind a name (e.g., www.venafi.com) to a public key. There are a lot of other pieces of information in a certificate but the Subject and Public Key fields are its raison d’être—what a recipient of the certificate (machine or person) cares about.
When a machine or person receives a certificate, they’ll want to ensure it is valid by checking that the issuer (certificate authority or CA) is an entity they trust, the signature is valid, the certificate is not expired or revoked, etc. But at the end of the day, they care most about whether the name in the Subject matches the person or system they’re interacting with and they want to use the public key for that interaction.
If an attacker wants to impersonate another system or person (e.g., www.venafi.com in the certificate above), they need to get a certificate with the targeted name and their (the attacker’s) public key from a CA that the recipient trusts. Since certificates are trusted credentials for authentication, CAs are attractive targets for attackers. If they can trick the CA into thinking they’re someone else, or actually compromise the CA to get it to issue a rogue certificate, they’ve got the equivalent of a key that unlocks somebody else’s doors.
Certificate authorities (CAs) issue certificates. It is their responsibility to verify the identity of entities to which they issue certificates. In a PKI, the role of the person or process that verifies identities prior to issuance by a CA is called a registration authority (RA). The RA can be within the same company as the CA or in a separate company. If the certificate is being issued to a person, the RA must ensure that the person has the name/identity being placed in the certificate (e.g., Bob Simms at Venafi or CN=Bob.Simms; O=Venafi). If the certificate is being issued to a system or application, the name is typically a unique address, such as a DNS address (e.g., www.venafi.com). In this case, the RA has to ensure that person is authorized to request a certificate for that address—for example, making sure the organization they work for owns/controls that domain and that the organization has authorized the requester to request certificates for that domain.
There are a number of different ways an attacker can attempt to get a rogue certificate from a CA, including:
- Impersonation: The attacker convinces the RA (the person responsible for verifying that they’re authorized to request a certificate) that they’re someone else. For example, in 2001, someone successfully convinced Verisign that they were a Microsoft employee (they were not) in order to get a code-signing certificate for Microsoft issued to them. Fortunately, Verisign and Microsoft detected the error before the certificate could be misused and revoked it. There have been many other instances of attackers successfully tricking RAs and CAs to issue rogue certificates.
- Compromise the RA: The attacker compromises the RA systems, or an employee of the RA, and authorizes the CA to issue several rogue certificates. In 2011, ComodoHacker (the name the attacker gave himself) was able compromise one of Comodo’s RA partners. They authorized the issuance of nine certificates for sites owned by Google, Yahoo, and others. Comodo discovered the mis-issued certificates within a short period of time and was able to revoke them and contact browser developers so they could block the certificates explicitly.
- Compromise the CA: The attacker is able to compromise the systems on which the CA operates and issue one or more rogue certificates. This is much more serious than an RA compromise because the attackers can potentially cover their tracks by doctoring logs, so you don’t actually know which rogue certificates were issued. In 2011, a Dutch CA, DigiNotar’s CA infrastructure was compromised by ComodoHacker. They were able to issue 531 rogue certificates for sites owned by Google, Yahoo, Microsoft, etc. In this case, software manufacturers (browsers, operating systems, etc.) had to explicitly pull the DigiNotar root certificate from their trust stores. It is important to note that this attack could also occur if a publicly trusted CA goes rogue, such as one operated or controlled by a nation state. For example, China Internet Network Information Center (CNNIC) issued a questionable CA certificate in 2015 that was then used to issue rogue certificates for several Google-owned domains.
- CA Private Key Theft: The attacker is able to get a copy of the CA’s signing key and issue one or more rogue certificates. In this case, the attacker can patiently pick the time when they’ll issue and use the rogue certificates. I’m not aware of a publicly announced instance of this sort of attack.
- Forge a Certificate: The attacker is able to exploit weaknesses in signing algorithms to forge one or more rogue certificates. In 2012, it was discovered that the developers of the Flame malware exploited MD5 to successfully forge CA certificates that were trusted by the Windows Update system (so that the malware could be quickly propagated through fake but trusted updates). Recently, successful collisions with SHA-1 have been demonstrated, opening the possibility of more forged certificates, since there are many SHA-1 certificates still in use today.
There are two types of fallout from these attacks. First, if the rogue certificate in question has the name of one of your domains or employees in it, the attacker can act like they are part of your organization and do various sorts of harm to your organization or your customers/partners. Second, if the compromised CA is one you use for the issuance of your certificates, you may have to rapidly replace all of your certificates. The Dutch government, for example, had to scramble to replace all of their certificates when DigiNotar was compromised because they were a big DigiNotar customer. This caused significant fallout to the operations and reputation of the Dutch government.
The moral of the story is you don’t have to be the target of a rogue certificate attack to be significantly impacted by it. For this and other reasons, you must always have the capability and be prepared to rapidly and non-disruptively replace all of your certificates.
See Popular Tags
- {[{item.name}]} {[{item.uuid}]} tags
About the author
Paul Turner
Paul Turner writes for Venafi's blog and is an expert in machine identity protection.
Read Posts by Author
Sign up for Venafi Cloud
Sign Up For Our Newsletter
Get monthly updates on relevant topics that impact encryption, cryptographic keys and digital certificates
Thank you for signing up for our newsletter!
Please whitelist Venafi.com so that you can be sure to receive our emails.
In the meantime, please explore more of our solutions