Why Attackers Love Mismanaged PKIs

Sometimes, I feel like describing PKI as an aspect of “cybersecurity” is somewhat of a misnomer. A lack of visibility and centralization, the use of self-signed certificates, un-inventoried services and appliances, and other examples of bad PKI hygiene create complicated, brittle tech stacks and incur unnecessary costs (including lost revenue on downed services).

In this aspect, cyber stability or cyber resilience may be more accurate in describing the importance of a modern, well-functioning PKI.

However, a poorly managed PKI does lend itself to actual cyberattacks. Bad practices make it easier for malicious actors to seize the keys to systems and assets, while the blind spots these practices create give them room to move and dwell within organizational systems. 

Private keys are used to decrypt information, and every user and machine utilizes them. Public keys, in contrast, verify that the sender of an encrypted communication is who they say they are. If these keys are compromised, attackers can carry out man-in-the-middle attacks in which they intercept and decrypt communications during transport. Alternatively, depending on the certificate type, a bad actor may also sign malicious software or issue fraudulent certificates that enable other forms of attack. 

Once possessing the right keys, an attacker can open a myriad of doors. Attacks against PKI include social engineering, software vulnerabilities, supply chain attacks, and side channel attacks (among others).

To protect them, Private keys should be stored on hardware security modules (HSMs) and rotated regularly. Of course, they should be restricted only to those users and services that need access according to the principle of least privilege. Once these steps are taken, you can monitor and log access attempts to detect suspicious behavior while continuously monitoring and inventorying your PKI. Centralizing PKI and certificate management, enabling proactive discovery, and defining policies that prevent shadow PKI will enable organizations to better face the evolving attacks against PKI. 

Cryptographic algorithms, tools, best practices, and even vendors fall out of favor when they are no longer secure against new threats. After all, attackers are always upgrading their own capabilities and tools, just like we are. If a PKI utilizes weak keys or deprecated protocols, it becomes easier for attackers to exploit. 

A word on keys:

• Keys are like passwords, and we measure the length of a key in “bits.” More bits are more secure. Imagine a combination lock with only a 1 and a 0, but with 2,048 dials.
• Different types of keys have different recommended bit lengths for security. These are ever-changing.
• The downside to longer keys is that they require more computational power, which can impact the cost and speed of your PKI processes. 
• Newer algorithms aim to combine efficiency with size while considering post-quantum computing.

Attackers can brute force weak keys more easily, determine collisions for the key’s cryptographic hash, or reverse-engineer the original key. They can exploit known vulnerabilities in deprecated protocols and algorithms and do so at various levels and points of intrusion. 

Audit your PKI for outdated protocols and weak keys and update whatever’s needed. You should be using TLS 1.2 or newer, and you should not be using WEP, DES, RC4, or MD5. Then put controls in place to rotate keys frequently and limit the number of allowed attempts for incorrect key entries. 

Digital certificates are issued by trusted sources called Certificate Authorities (CAs). CAs exist in a hierarchy of trust. At the top sits the Root CA, also known as the trust anchor. Intermediate CAs comprise the next layer, and issuing CAs sit at the bottom. Organizations use a mix of public and private CAs. According to Keyfactor research, the average organization uses nine. 

Like digital certificates, CAs have their own private keys. Attackers can steal these private keys and use them to issue fraudulent certificates. This lets them carry out man-in-the-middle attacks. Alternatively, they may use malware or other infiltration techniques to get a fraudulent certificate signed by a CA without needing its private key. 

The Root CA must be protected at all costs. If someone manages to compromise it, the entire PKI must be rebuilt from scratch. The best way to protect it is by storing it offline in an HSM. 

Additionally, organizations would do well to build crypto-agility and enable processes for revoking compromised certificates, CAs, and keys in bulk.

Code signing keys and certificates validate that code and software have not been tampered with or corrupted. These keys and certificates are most often used by developers and DevOps teams. By stealing code-signing keys, attackers can sign malware and fake drivers that grant them access to sensitive assets.

In organizations with no standardized PKI processes or oversight, dev teams often procure their own PKI resources and sign their own certificates. This is a perfect example of how the tensions between security, policy ambiguity, and productivity create unnecessary risk for companies of all stripes. 

Not only are self-signed certificate practices less secure, but they are also often exacerbated by bad PKI hygiene, like lax key storage. As such, they become low-hanging fruit for attackers.

Recently, CABForum and Microsoft have been working to enhance code signing certificate baseline requirements to include requirements for organization vetting and HSM verification. We are excited to work with those groups to ensure that Keyfactor’s products will meet these evolving requirements and enable customers to grow, manage, and scale their PKI.

A Certificate Revocation List (CRL) is an inventory of withdrawn or invalidated certificates. Think of the CRL as a no-fly list for certificates; Certificates go on this list when they expire, are revoked, or are replaced due to compromise.

The CRL is maintained by the CA. Browsers and applications check the CRL to make sure the certificates they’re encountering have not been invalidated. Hackers can manipulate the CRL to camouflage a certificate’s revoked status.

To access the CRL, attackers may steal the CRL’s signing private key through phishing or exploiting software vulnerabilities. This allows the attack to create a fake, signed CRL re-enabling a potentially compromised certificate. Another method involves DNS spoofing to provide an outdated CRL.

Many organizations are moving toward the OSCP protocol, which checks the revocation status of each individual certificate rather than downloading the complete CRL. Making this switch might be a good move for your organization. 

In any case, you can protect the CRL by storing keys securely, maintaining strict access control privileges, and conducting regular security audits.  

PKI isn’t tough to defend against attackers. Huge gains in security will happen as a byproduct of modernizing your PKI to run more smoothly and efficiently. 

Take care of your keys. Store them on an HSM or software vault—or at least on a local filesystem that can both generate and store the private key without involving a server. Make your keys strong and rotate them regularly. Restrict access and regularly update access control lists.

Create PKI policies. When there are rules, an attacker’s aberrant behavior is easier to detect. Enable proactive discovery of all certificates and crypto-assets so you know what you need to protect. Consolidate them into a universal management platform. From that centralization, drive secure policies and procedures.

Conduct routine housekeeping. Checking for misconfigurations and vulnerabilities, updating access permissions, scanning for suspicious behavior, and mitigating PKI sprawl — this is how organizations truly build a PKI that is both secure and flexible. It’s a constant practice, not a big push once per year.

Security, infrastructure, and other teams that manage PKI have a lot on their plate. However, reacting to a PKI compromise is much more costly and intensive than preventing it in the first place.