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).

En este aspecto, la estabilidad o la resiliencia cibernética pueden ser términos más precisos para describir la importancia de una PKI moderna y con un buen funcionamiento.

Sin embargo, una PKI mal gestionada sí se presta a ciberataques reales. Las malas prácticas facilitan que los actores maliciosos se apoderen de las claves de sistemas y activos, mientras que los puntos ciegos que estas prácticas generan les dan espacio para moverse y permanecer dentro de los sistemas organizacionales.

Las claves privadas se utilizan para descifrar información, y cada usuario y máquina las utiliza. Las claves públicas, en contraste, verifican que el remitente de una comunicación cifrada es quien dice ser. Si estas claves se ven comprometidas, los atacantes pueden llevar a cabo ataques de intermediario (man-in-the-middle) en los que interceptan y descifran las comunicaciones durante el transporte. Alternativamente, dependiendo del tipo de certificado, un actor malicioso también puede firmar Software malicioso o emitir certificados fraudulentos que permitan otras formas de ataque.

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).

Para protegerlas, las claves privadas deben almacenarse en módulos de seguridad de Hardware (HSM) y rotarse regularmente. Por supuesto, deben restringirse solo a aquellos usuarios y servicios que necesiten acceso según el principio de mínimo privilegio. Una vez que se toman estas medidas, puede monitorear y registrar los intentos de acceso para detectar comportamientos sospechosos, mientras supervisa e inventaría continuamente su PKI. Centralizar la gestión de PKI y certificados, habilitar el descubrimiento proactivo y definir políticas que prevengan la PKI en la sombra permitirá a las organizaciones enfrentar mejor los ataques en evolución contra la PKI.

Los algoritmos criptográficos, las herramientas, las mejores prácticas e incluso los proveedores pierden vigencia cuando ya no son seguros frente a nuevas amenazas. Después de todo, los atacantes siempre están mejorando sus propias capacidades y herramientas, al igual que nosotros. Si una PKI utiliza claves débiles o protocolos obsoletos, resulta más fácil para los atacantes explotarla. 

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. 

Audite su PKI en busca de protocolos obsoletos y claves débiles y actualice lo que sea necesario. Debe utilizar TLS 1.2 o superior, y no debe utilizar WEP, DES, RC4 o MD5. Luego, establezca controles para rotar las claves con frecuencia y limitar el número de intentos permitidos para entradas de clave incorrectas. 

Los certificados digitales son emitidos por fuentes de confianza denominadas Autoridades de Certificación (CA). Las CA existen en una jerarquía de confianza. En la cima se encuentra la CA raíz (Root CA), también conocida como ancla de confianza. Las CA intermedias (Intermediate CAs) constituyen la siguiente capa, y las CA emisoras (Issuing CAs) se encuentran en la parte inferior. Las organizaciones utilizan una combinación de CA públicas y privadas. Según la investigación de Keyfactor, la organización promedio utiliza nueve. 

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. 

La CA raíz debe protegerse a toda costa. Si alguien logra comprometerla, toda la PKI debe reconstruirse desde cero. La mejor manera de protegerla es almacenándola offline en un HSM. 

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

Las claves y certificados de firma de código validan que el código y el Software no han sido manipulados ni corrompidos. Estas claves y certificados son utilizados con mayor frecuencia por desarrolladores y equipos de DevOps. Al robar claves de firma de código, los atacantes pueden firmar malware y controladores falsos que les otorgan acceso a activos sensibles.

En organizaciones sin procesos de PKI estandarizados ni supervisión, los equipos de desarrollo a menudo adquieren sus propios recursos de PKI y firman sus propios certificados. Este es un ejemplo perfecto de cómo las tensiones entre seguridad, ambigüedad de políticas y productividad crean riesgos innecesarios para empresas de todo tipo. 

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.

Recientemente, CABForum y Microsoft han estado trabajando para mejorar los requisitos básicos de los certificados de firma de código, incluyendo requisitos para la verificación de la organización y la verificación de HSM. Nos entusiasma colaborar con esos grupos para asegurar que los productos de Keyfactor cumplan con estos requisitos en evolución y permitan a los clientes crecer, gestionar y escalar su PKI.

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.

Muchas organizaciones están adoptando el protocolo OSCP, que verifica el estado de revocación de cada certificado individual en lugar de descargar la CRL completa. Realizar este cambio podría ser una buena decisión para su organización. 

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.  

Defender la PKI de los atacantes no es difícil. Se lograrán grandes avances en seguridad como resultado de modernizar su PKI para que funcione de manera más fluida y eficiente. 

Proteja sus claves. Almacénelas en un HSM o en una bóveda de software, o al menos en un sistema de archivos local que pueda generar y almacenar la clave privada sin necesidad de un servidor. Cree claves robustas y rótelas periódicamente. Restrinja el acceso y actualice regularmente las listas de control de acceso.

Cree políticas de PKI. Cuando existen reglas, el comportamiento anómalo de un atacante es más fácil de detectar. Habilite el descubrimiento proactivo de todos los certificados y criptoactivos para saber qué necesita proteger. Consolídelos en una plataforma de gestión universal. A partir de esa centralización, impulse políticas y procedimientos seguros.

Realice un mantenimiento rutinario. La verificación de configuraciones erróneas y vulnerabilidades, la actualización de permisos de acceso, el escaneo de comportamientos sospechosos y la mitigación de la proliferación de PKI: así es como las organizaciones construyen realmente una PKI segura y flexible. Es una práctica constante, no un esfuerzo puntual una vez al año.

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.