Warum Angreifer mangelhaft verwaltete PKIs lieben

Manchmal habe ich das Gefühl, dass die Beschreibung von PKI als ein Aspekt der "Cybersicherheit" eine falsche Bezeichnung ist. Mangelnde Transparenz und Zentralisierung, die Verwendung von selbstsignierten Zertifikaten, nicht erfundene Dienste und Geräte und andere Beispiele für schlechte PKI-Hygiene führen zu komplizierten, brüchigen Tech-Stacks und verursachen unnötige Kosten (einschließlich entgangener Einnahmen durch ausgefallene Dienste).

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. 

Diebstahl privater Schlüssel

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. 

Sobald ein Angreifer im Besitz der richtigen Schlüssel ist, kann er eine Vielzahl von Türen öffnen. Zu den Angriffen auf die PKI gehören u. a. Social Engineering, software Schwachstellen, Angriffe über die Lieferkette und Seitenkanalangriffe.

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. 

Veraltete Protokolle und schwache Schlüssel

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. 

Ein Wort zu den Tasten:

• Schlüssel sind wie Passwörter, und wir messen die Länge eines Schlüssels in "Bits". Mehr Bits bedeuten mehr Sicherheit. Stellen Sie sich ein Zahlenschloss vor, das nur eine 1 und eine 0, aber 2.048 Ziffernblätter hat.
• Für verschiedene Schlüsseltypen gibt es unterschiedliche empfohlene Bitlängen für die Sicherheit. Diese ändern sich ständig.
• Der Nachteil von längeren Schlüsseln ist, dass sie mehr Rechenleistung erfordern, was sich auf die Kosten und die Geschwindigkeit Ihrer PKI-Prozesse auswirken kann. 
• Neuere Algorithmen zielen darauf ab, Effizienz und Größe unter Berücksichtigung des Post-Quantum-Computing zu kombinieren.

Angreifer können schwache Schlüssel leichter mit Brute-Force-Verfahren erzwingen, Kollisionen für den kryptografischen Hash des Schlüssels feststellen oder den ursprünglichen Schlüssel zurückentwickeln. Sie können bekannte Schwachstellen in veralteten Protokollen und Algorithmen ausnutzen und dies auf verschiedenen Ebenen und an verschiedenen Punkten des Eindringens tun. 

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. 

Kompromittierte Zertifizierungsstelle

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. 

Wie digitale Zertifikate haben auch CAs ihre eigenen privaten Schlüssel. Angreifer können diese privaten Schlüssel stehlen und sie verwenden, um gefälschte Zertifikate auszustellen. Auf diese Weise können sie Man-in-the-Middle-Angriffe durchführen. Alternativ können sie Malware oder andere Infiltrationstechniken verwenden, um ein gefälschtes Zertifikat von einer CA signieren zu lassen, ohne deren privaten Schlüssel zu benötigen. 

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. 

Darüber hinaus tun Unternehmen gut daran, Krypto-Agilität aufzubauen und Prozesse für den Widerruf kompromittierter Zertifikate, CAs und Schlüssel in großen Mengen zu aktivieren.

Gestohlene Code-Signatur-Schlüssel

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. 

Selbstsignierte Zertifikate sind nicht nur weniger sicher, sondern werden oft durch schlechte PKI-Hygiene, wie z. B. eine laxe Schlüsselspeicherung, noch verschlimmert. So werden sie für Angreifer zu einer leicht zugänglichen Beute.

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.

CRL-Manipulation

Eine Certificate Revocation List (CRL) ist ein Verzeichnis zurückgezogener oder ungültiger Zertifikate. Stellen Sie sich die CRL wie eine Flugverbotsliste für Zertifikate vor. Zertifikate werden in diese Liste aufgenommen, wenn sie ablaufen, widerrufen oder aufgrund einer Kompromittierung ersetzt werden.

Die CRL wird von der Zertifizierungsstelle verwaltet. Browser und Anwendungen überprüfen die CRL, um sicherzustellen, dass die Zertifikate, auf die sie stoßen, nicht ungültig gemacht wurden. Hacker können die CRL manipulieren, um den widerrufenen Status eines Zertifikats zu verschleiern.

Um auf die CRL zuzugreifen, können Angreifer den privaten Signierschlüssel der CRL durch Phishing oder Ausnutzung von software Schwachstellen stehlen. Auf diese Weise kann der Angreifer eine gefälschte, signierte CRL erstellen und ein potenziell gefährdetes Zertifikat wieder aktivieren. Eine andere Methode ist DNS Spoofing, um eine veraltete CRL bereitzustellen.

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 jedem Fall können Sie die CRL schützen, indem Sie die Schlüssel sicher aufbewahren, strenge Zugangskontrollen durchführen und regelmäßige Sicherheitsprüfungen vornehmen.  

Hygiene, PKI-Governance und Werkzeuge

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.

Sicherheits-, Infrastruktur- und andere Teams, die PKI verwalten, haben eine Menge zu tun. Die Reaktion auf eine PKI-Kompromittierung ist jedoch viel kostspieliger und intensiver, als sie von vornherein zu verhindern.