Por qué a los atacantes les encantan las PKI mal gestionadas

A veces, siento que describir la PKI como un aspecto de la "ciberseguridad" es un tanto inapropiado. La falta de visibilidad y centralización, el uso de certificados autofirmados, servicios y appliances no inventariados, y otros ejemplos de mala higiene de PKI, crean pilas tecnológicas complicadas y frágiles, e incurren en costos innecesarios (incluida la pérdida de ingresos por servicios caídos).

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. 

Robo de claves privadas

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. 

Una vez que posee las claves correctas, un atacante puede abrir una miríada de puertas. Los ataques contra la PKI incluyen ingeniería social, vulnerabilidades de Software, ataques a la cadena de suministro y ataques de canal lateral (entre otros).

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. 

Protocolos obsoletos y claves débiles

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. 

Una nota sobre las claves:

• Las claves son como las contraseñas, y medimos su longitud en «bits». Más bits significan mayor seguridad. Imagine una cerradura de combinación con solo un 1 y un 0, pero con 2048 diales.
• Los diferentes tipos de claves tienen distintas longitudes de bits recomendadas para la seguridad. Estas están en constante evolución.
• La desventaja de las claves más largas es que requieren mayor potencia computacional, lo que puede afectar el costo y la velocidad de sus procesos de PKI. 
• Los algoritmos más recientes buscan combinar eficiencia con tamaño, considerando la computación postcuántica.

Los atacantes pueden forzar claves débiles con mayor facilidad, determinar colisiones para el hash criptográfico de la clave o aplicar ingeniería inversa a la clave original. Pueden explotar vulnerabilidades conocidas en protocolos y algoritmos obsoletos, y lo hacen en varios niveles y puntos de intrusión. 

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. 

Autoridad de certificación comprometida

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. 

Al igual que los certificados digitales, las CA tienen sus propias claves privadas. Los atacantes pueden robar estas claves privadas y utilizarlas para emitir certificados fraudulentos. Esto les permite llevar a cabo ataques de intermediario (man-in-the-middle). Alternativamente, pueden utilizar malware u otras técnicas de infiltración para conseguir que una CA firme un certificado fraudulento sin necesidad de su clave privada. 

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. 

Además, las organizaciones harían bien en desarrollar criptoagilidad y habilitar procesos para revocar certificados, CA y claves comprometidos de forma masiva.

Claves de firma de código robadas

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. 

Las prácticas de certificados autofirmados no solo son menos seguras, sino que a menudo se ven agravadas por una mala higiene de PKI, como un almacenamiento de claves deficiente. Como tales, se convierten en un objetivo fácil para los atacantes.

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.

Manipulación de CRL

Una Lista de Revocación de Certificados (CRL) es un inventario de certificados retirados o invalidados. Piense en la CRL como una lista de exclusión aérea para certificados; los certificados entran en esta lista cuando caducan, son revocados o son reemplazados debido a un compromiso.

La CRL es mantenida por la CA. Los navegadores y las aplicaciones verifican la CRL para asegurarse de que los certificados que encuentran no han sido invalidados. Los hackers pueden manipular la CRL para camuflar el estado de revocación de un certificado.

Para acceder a la CRL, los atacantes pueden robar la clave privada de firma de la CRL mediante phishing o explotando vulnerabilidades de Software. Esto permite al atacante crear una CRL falsa y firmada, reactivando un certificado potencialmente comprometido. Otro método implica la suplantación de DNS para proporcionar una CRL desactualizada.

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. 

En cualquier caso, puede proteger la CRL almacenando las claves de forma segura, manteniendo estrictos privilegios de control de acceso y realizando auditorías de seguridad periódicas.  

Higiene, gobernanza de PKI y herramientas

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.

Los equipos de seguridad, infraestructura y otros que administran la PKI tienen una carga de trabajo considerable. Sin embargo, reaccionar ante un compromiso de PKI es mucho más costoso e intensivo que prevenirlo desde el principio.