Why Attackers Love Mismanaged PKIs

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

En este aspecto, la ciber estabilidad o ciber resiliencia pueden ser más precisas para describir la importancia de una PKI moderna y que funcione correctamente.

Sin embargo, una PKI mal gestionada se presta a ciberataques reales. Las malas prácticas facilitan a los actores maliciosos apoderarse de las claves de sistemas y activos, mientras que los puntos ciegos que estas prácticas crean les dan espacio para moverse y habitar dentro de los sistemas organizativos.

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

Una vez en posesión de las claves adecuadas, un atacante puede abrir un sinfín de puertas. Los ataques contra la PKI incluyen la ingeniería social, las vulnerabilidades de software , los ataques a la cadena de suministro y los ataques de canal lateral (entre otros).

Para protegerlas, las claves privadas deben almacenarse en módulos de seguridad hardware (HSM) y rotarse regularmente. Por supuesto, deben restringirse únicamente a aquellos usuarios y servicios que necesiten acceder a ellas de acuerdo con el principio del menor privilegio. Una vez tomadas estas medidas, puede supervisar y registrar los intentos de acceso para detectar comportamientos sospechosos al tiempo que supervisa e inventaría continuamente su PKI. Centralizar la PKI y la gestión de certificados, permitir la detección proactiva y definir políticas que impidan la PKI en la sombra permitirá a las organizaciones afrontar mejor los ataques en evolución contra la PKI.

Algoritmos criptográficos, herramientas, mejores prácticas, e incluso proveedores caen en desuso cuando dejan de ser seguros frente a las nuevas amenazas. Después de todo, los atacantes siempre están actualizando 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 aprovecharse de ella.

Unas palabras sobre las llaves:

• Las claves son como las contraseñas, y medimos la longitud de una clave en "bits". Más bits son más seguros. Imagina una cerradura de combinación con sólo un 1 y un 0, pero con 2.048 diales.
• Los distintos tipos de claves tienen diferentes longitudes de bits recomendadas para la seguridad. Éstas cambian constantemente.
• El inconveniente de las claves más largas es que requieren más potencia de cálculo, lo que puede repercutir en el coste y la velocidad de sus procesos de PKI. 
• Los algoritmos más recientes tratan de combinar eficiencia y tamaño teniendo en cuenta la computación poscuántica.

Los atacantes pueden aplicar la fuerza bruta a 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 hacerlo en varios niveles y puntos de intrusión. 

Audite su PKI en busca de protocolos obsoletos y claves débiles y actualiza lo que sea necesario. Debería utilizar TLS 1.2 o una versión más reciente, y no debería utilizar WEP, DES, RC4 o MD5. A continuación, establezca controles para rotar las claves con frecuencia y limitar el número de intentos permitidos para las entradas de claves 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 parte superior se encuentra la CA raíz, también conocida como ancla de confianza. Las CA intermedias constituyen la siguiente capa, y las CA emisoras se sitúan en la parte inferior. Las organizaciones utilizan una combinación de CA públicas y privadas. Según un estudio de Keyfactor la organización media 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 man-in-the-middle. Alternativamente, pueden utilizar malware u otras técnicas de infiltración para obtener un certificado fraudulento firmado por una CA sin necesidad de su clave privada. 

La CA raíz debe protegerse a toda costa. Si alguien consigue comprometerlatoda la PKI debe ser reconstruida desde cero. La mejor forma de protegerla es almacenarla sin conexión en un HSM.

Además, las organizaciones harían bien en crear cripto-agilidad y habilitar procesos para revocar certificados, CAs y claves comprometidas en masa.

Las claves y certificados de firma de código validan que el código y software no han sido manipulados ni corrompidos. Estas claves y certificados son los más utilizados por los desarrolladores y los equipos de DevOps. Mediante el robo de claves de firma de código, los atacantes pueden firmar malware y controladores falsos que les concedan acceso a activos sensibles.

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

Las prácticas de certificados autofirmados no sólo son menos seguras, sino que a menudo se ven agravadas por una mala higiene de la PKI, como un almacenamiento de claves poco riguroso. Como tales, se convierten en fruta 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 con el fin de incluir requisitos para la verificación de organizaciones y la verificación de HSM. Nos complace colaborar con estos grupos para garantizar que los productos de Keyfactorcumplan estos requisitos en constante evolución y permitan a los clientes ampliar, 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, se revocan o se sustituyen debido a un compromiso.

La CRL es mantenida por la CA. Los navegadores y las aplicaciones comprueban 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 que el ataque cree una CRL firmada falsa que vuelva a habilitar un certificado potencialmente comprometido. Otro método implica la suplantación de DNS para proporcionar una CRL obsoleta.

Muchas organizaciones están adoptando el protocolo OSCPque comprueba el estado de revocación de cada certificado individual en lugar de descargar la CRL completa. Hacer este cambio puede 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.  

PKI no es difícil de defender contra los atacantes. La modernización de la PKI subproducto de la modernización de su PKI para que funcione de forma más fluida y eficiente.

Cuide sus llaves. Almacénalas en un HSM o en una cámara acorazada software o, al menos, en un sistema de archivos local que pueda generar y almacenar la clave privada sin necesidad de un servidor. Haz que tus claves sean seguras y rótalas con regularidad. Restrinja el acceso y actualice periódicamente las listas de control de acceso.

Cree políticas PKI. Cuando hay reglas, el comportamiento aberrante de un atacante es más fácil de detectar. Permita la detección proactiva 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 tareas rutinarias de mantenimiento. Comprobación de errores de configuración y vulnerabilidades, actualización de permisos de acceso, búsqueda de comportamientos sospechosos y mitigación de la proliferación de la PKI: así es como las organizaciones construyen realmente una PKI segura y flexible. Es una práctica constante, no un gran empujón una vez al año.

Los equipos de seguridad, infraestructura y otros que gestionan la PKI tienen mucho trabajo por delante. Sin embargo, reaccionar ante un problema de PKI es mucho más costoso e intensivo que prevenirlo desde el principio.