PKI Under Attack
Total Page:16
File Type:pdf, Size:1020Kb
DEVELOPING AND CONNECTING ISSA CYBERSECURITY LEADERS GLOBALLY PKI Under Attack By Jeff Stapleton – ISSA member, Fort Worth, USA Chapter In the September 2012 ISSA Journal, the author looked at a concise history of public key infrastructure and mentioned several Certificate Authority compromise incidents from 2011. This trend seems to be continuing as PKI continues to be under attack. This article explores various PKI vulnerabilities. PKI and SSL framework n the September 2012 ISSA Journal, we looked at a con- cise history of public key in- Ifrastructure (PKI) and mentioned several Certificate Authority (CA) compromise incidents from 2011. This trend seems to be continuing as PKI continues to be under attack. To explore this further, let’s first establish a typical PKI framework, shown in figure 1, to discuss the various vulnerability points and attack vectors. For Figure 1 – PKI and SSL framework this discussion we will focus on a secure socket layer (SSL) [1] scenario which includes a CA consisting of a root certificate of the Red subordinate CA. The Blue root CA typi- (Blue) and two subordinates (Red and Green), a server (S), cally operates in an offline manual mode, and does not issue and the relying parties consisting of the browser manufactur- any other certificates, except possibly to other Red peer-level er (M) and the browser (B). The most common PKI and SSL subordinate CAs not shown. Note that most root CAs have option is using the RSA algorithm for server-side certificates. numerous sub-CAs dedicated to various PKI techniques and As a quick refresher, the browser recognizes the SSL certifi- usage (e.g., RSA keys, other asymmetric algorithms, SSL, cate sent to it by the server. Essentially the browser gener- code signing, email, disk encryption), but for this discussion ates a random symmetric key and encrypts it using the server we will only look at SSL sub-CA. The Red subordinate CA RSA public key for subsequent session encryption which es- signs the certificate of the Green subordinate CA; it might sentially is the SSL tunnel. Actually the browser encrypts a operate in an offline manual or online automatic or manual master secret with the public key which is used by both par- mode, and it does not issue any other certificates, except pos- ties to derive a symmetric encryption key; however, for this sibly to other Green peer-level subordinate CAs not shown. discussion it is easier to just envision the public key encrypt- The Green subordinate CA operates in an online automatic ing the symmetric key. SSL and Transport Layer Security mode, and signs the certificate of the server (S) and many (TLS) [2, 3, 4, and 5] also support a keyed hash as a message other servers not show. During the SSL handshake, the server authentication code (HMAC) [7] for data integrity. From a has provided the certificate chain to the browser, consisting cryptography viewpoint, for the browser to trust the server of the server certificate, the Green sub-CA certificate, and the public key, the server SSL certificate must be validated. For Red sub-CA certificate, but not the Blue root CA certificate. this to occur, the browser needs the root CA public key of the Thus, for the browser to validate the certificate chain, it fol- certificate chain. Let’s look at the certificate in more detail. lows the issuance links from the server certificate to the Blue For this scenario, the Blue root CA is the highest authority root CA certificate. The Blue root CA certificate is a trust- an in this PKI structure, and signs its own certificate, and the chor in the browser (B), as provided by the browser manufac- March 2013 | ISSA Journal – 33 ©2013 ISSA • www.issa.org • [email protected] • All rights reserved. PKI Under Attack | Jeff Stapleton turer (M). The Blue root CA public key is then used to vali- is compromised, then an adversary can “peek” inside the tun- date the Red subordinate CA certificate by verifying the Blue nel by decrypting the session key and then decrypting the data signature. The Red subordinate CA public key is then used packets sniffed on the connection. An adversary, having both to validate the Green subordinate CA certificate by verifying the private key and public key certificate, could masquerade the Red signature. The Green subordinate CA public key is as the server; however the domain name matching makes this then used to validate the server SSL certificate by verifying problematic. More significantly, if the Green subordinate CA the Green signature. The server public key is then used by the private key is compromised, then an adversary can issue any browser to encrypt the random symmetric key. server certificate in any name for any key pair whose certifi- In addition to following the issuance links and verifying the cate chain still validates to the Blue root CA trust anchor. As certificate signatures, the browser is expected to validate that another example, if any CA private key is compromised, then the domain name in the certificate matches the server uni- an adversary can issue any certificate, including the creation form resource locator (URL), and that all of the certificate of a whole fraudulent PKI. validity dates are legitimate. Further, if any of the certificates However, as it turns out, the ability to issue a fraudulent cer- provide a link to a certificate revocation list (CRL) or an on- tificate does not necessarily require compromising the CA line certificate status protocol (OCSP) responder, the browser private key. Asymmetric private keys are usually protected is also expected to check the status of the certificates to en- using cryptographic hardware modules so the ability to “see” sure none have been revoked prior to expiration dates. or copy the private key unencrypted is infeasible [6]. But, as it However, the PKI trust model has come under attack from turns out, gaining access to the issuance application that uses counterfeit SSL certificates issued by adversaries external to the CA private key is much easier, since systems and individ- the CA. uals are vulnerable to password cracking, phishing, malware, and social engineering. The frontend of any CA is a registra- Counterfeit certificates tion authority (RA) to process certificate signing requests Interestingly, most PKI risks were focused on the vulnerabil- (CSR). The RA might be a functional component of the CA; ity of the private key, and what might occur if the private key it might be a standalone system; or it might be an authorized of any of the participants is compromised. Certificates are re- affiliation to CA. The following CA compromises are based voked for a variety of operational reasons including known or on publicly available information. suspected compromise, but if the compromise is undetected At the USENIX Security 2011 Symposium, Jesse Burns and and the certificates are not revoked, then an adversary can Peter Eckersley reported that their study of the Certificate Re- mount various attacks. For example, if the server private key vocation Lists (CRLs) published by CAs seen by the SSL Ob- DEVELOPING AND CONNECTING CYBERSECURITY LEADERS GLOBALLY Click here for On-Demand Conferences Cyber Attacks: Past, Present and Future Asset Management in a Consumerized World Recorded Live: February 19, 2013 Recorded Live: August 28, 2012 Security Reflections of 2012 and Predictions for 2013 Social Media Gone Wild Recorded Live: January 22, 2013 Recorded Live: June 26, 2012 Data Loss Prevention: Gone in Under 60 Milliseconds You’ve Got Humans on Your Network: Securing the End User Recorded Live: November 20, 2012 Recorded Live: May 22, 2012 GRC: Is There Such a Thing as TMI? Breach Report: Lessons Learned Recorded Live: October 30, 2012 Recorded Live: April 24, 2012 Application Security: Is That Malware in Your Package? Security and Legislation Recorded Live: September 25, 2012 Recorded Live: March 27, 2012 A Wealth of Resources for the Information Security Professional – www.ISSA.org 34 – ISSA Journal | March 2013 ©2013 ISSA • www.issa.org • [email protected] • All rights reserved. PKI Under Attack | Jeff Stapleton servatory revealed that 14 CAs had been compromised. The An attacker obtained the username and password of a Como- names of the alleged compromised CA were not published as do Trusted Partner in Southern Europe. We are not yet clear the research was still ongoing; however, there are several pub- about the nature or the details of the breach suffered by that licly available articles on DigiNotar, Comodo, GlobalSign, partner other than knowing that other online accounts (not StartSSL, and TurkTrust certification authorities. with Comodo) held by that partner were also compromised at about the same time. The attacker used the username and DigiNotar password to login to the particular Comodo RA account and DigiNotar was a Dutch certificate authority owned by VAS- effect the fraudulent issue of the certificates. The attacker was CO Data Security International. The CA issued two types of still using the account when the breach was identified and the certificates: certificates under their own name (where the root account suspended. The attacker may have intended to target CA was “DigiNotar Root CA”) and certificates for the Dutch additional domains had he had the opportunity. government’s PKIoverheid (“PKIgovernment”) program [9]. Remediation efforts began immediately once the breach was On July 10, 2011, a wildcard certificate, which could be used discovered. The certificates have all been revoked and no web with multiple subdomains of a domain, was issued by Digi- browser should now accept the fraudulently issued certificates Notar’s systems for Google by an attacker with access to their if revocation checking is enabled. Additional audits and con- systems. This certificate was subsequently used by unknown trols have been deployed as described in the detailed incident persons in Iran to conduct a man-in-the-middle attack report.