Pourquoi les attaquants adorent les ICP mal gérées

Parfois, j'ai l'impression que décrire PKI comme un aspect de la "cybersécurité" est quelque peu abusif. Un manque de visibilité et de centralisation, l'utilisation de certificats auto-signés, de services et d'appareils non inventoriés et d'autres exemples de mauvaise hygiène sur PKI créent des piles technologiques compliquées et fragiles et entraînent des coûts inutiles (y compris des pertes de revenus liées à des services interrompus).

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. 

Vol de clés privées

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. 

Une fois en possession des bonnes clés, un attaquant peut ouvrir une myriade de portes. Les attaques contre PKI comprennent l'ingénierie sociale, les vulnérabilités de software , les attaques de la chaîne d'approvisionnement et les attaques par canal latéral (entre autres).

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. 

Protocoles obsolètes et clés faibles

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. 

Un mot sur les clés :

• Les clés sont comme des mots de passe, et nous mesurons la longueur d'une clé en "bits". Plus il y a de bits, plus la sécurité est grande. Imaginez une serrure à combinaison avec seulement un 1 et un 0, mais avec 2 048 cadrans.
• Les longueurs de bits recommandées pour la sécurité varient selon les types de clés. Ces recommandations sont en constante évolution.
• L'inconvénient des clés plus longues est qu'elles nécessitent une plus grande puissance de calcul, ce qui peut avoir une incidence sur le coût et la rapidité de vos processus PKI . 
• Les nouveaux algorithmes visent à combiner l'efficacité et la taille tout en tenant compte de l'informatique post-quantique.

Les attaquants peuvent plus facilement forcer les clés faibles, déterminer les collisions pour le hachage cryptographique de la clé, ou faire de l'ingénierie inverse de la clé d'origine. Ils peuvent exploiter des vulnérabilités connues dans des protocoles et algorithmes obsolètes, et ce à différents niveaux et points d'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. 

Autorité de certification compromise

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. 

Comme les certificats numériques, les autorités de certification possèdent leurs propres clés privées. Les attaquants peuvent voler ces clés privées et les utiliser pour émettre des certificats frauduleux. Cela leur permet de mener des attaques de type "man-in-the-middle". Ils peuvent également utiliser des logiciels malveillants ou d'autres techniques d'infiltration pour faire signer un certificat frauduleux par une autorité de certification sans avoir besoin de sa clé privée. 

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. 

En outre, les organisations feraient bien de développer la crypto-agilité et de mettre en place des processus permettant de révoquer en bloc les certificats, les autorités de certification et les clés compromises.

Clés de signature de code volées

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. 

Non seulement les pratiques en matière de certificats auto-signés sont moins sûres, mais elles sont aussi souvent exacerbées par une mauvaise hygiène sur le site PKI , comme un stockage laxiste des clés. En tant que telles, elles deviennent des fruits faciles à attraper pour les attaquants.

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.

Manipulation des LCR

Une liste de révocation de certificats (LCR) est un inventaire des certificats retirés ou invalidés. Les certificats sont inscrits sur cette liste lorsqu'ils expirent, sont révoqués ou remplacés à la suite d'une compromission.

La CRL est tenue à jour par l'autorité de certification. Les navigateurs et les applications vérifient la LCR pour s'assurer que les certificats qu'ils rencontrent n'ont pas été invalidés. Les pirates peuvent manipuler la LCR pour camoufler l'état révoqué d'un certificat.

Pour accéder à la CRL, les attaquants peuvent voler la clé privée de signature de la CRL par hameçonnage ou en exploitant les vulnérabilités du site software . Cela permet à l'attaque de créer une fausse CRL signée qui réactive un certificat potentiellement compromis. Une autre méthode consiste à usurper DNS pour fournir une CRL périmée.

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. 

Dans tous les cas, vous pouvez protéger la LCR en stockant les clés en toute sécurité, en maintenant des privilèges de contrôle d'accès stricts et en effectuant des audits de sécurité réguliers.  

Hygiène, PKI gouvernance et outillage

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.

Les équipes chargées de la sécurité, de l'infrastructure et autres qui gèrent PKI ont beaucoup à faire. Cependant, réagir à une compromission sur PKI est beaucoup plus coûteux et intensif que de l'empêcher dès le départ.