La infraestructura de clave pública (PKI) es una tecnología fundamental para la mayoría de las empresas cuando se trata de mantener la seguridad. Pero también es una tecnología que se implanta con demasiada facilidad y se ejecuta en segundo plano sin prestar demasiada atención a las actualizaciones o mejoras continuas.
¿Cómo asegurarse de que la PKI sigue cumpliendo las nuevas normas? ¿Y qué puede ir mal si no este enfoque proactivo?
Esa fue la premisa de nuestra conversación con Chris Hickman, Director de Seguridad de Keyfactor, y Will Schroeder y Lee Christensen, arquitectos técnicos de SpecterOps, un proveedor de ciberseguridad centrado en el adversario que ayuda a a defenderse de ataques avanzados.
Recientemente, Will y Lee sacaron a la luz esta preocupación cuando publicaron un nuevo whitepaper basado en la investigación que hicieron sobre Microsoft Active Directoryque incluye una amplia gama de errores de configuración comunes en la implementación de PKI de Microsoft que pueden ser explotados. Estos son algunos de los puntos más destacados de nuestra conversación.
¿Cuáles son algunas de las principales conclusiones del informe?
Lee: Algo que realmente nos llamó la atención con Active Directory Certificate Services es que es muy omnipresente en las redes empresariales. Pero también es antiguo y no se conoce muy bien. En general, no hay muchas consideraciones de seguridad al respecto, a pesar de que se utiliza en todas partes y es clave para la autenticación y el funcionamiento de la red. Por eso es un blanco fácil para los atacantes.
Will: Lo interesante de esta investigación es que, dado que Active Directory Certificate Services es tan amplio y está tan integrado en Active Directory, no se trataba de un único fallo o una única forma de escalar. Lo dividimos en una variedad de formas en las que la gente podría robar certificados o inscribir certificados de forma maliciosa con el fin de robar credenciales y persistir en la máquina. Terminamos codificando todo en robo de credenciales, escalada de dominio y persistencia de dominio, que son muy amplios e interesantes por derecho propio.
Lee: La cuestión de la escalada de dominios también ha cobrado actualidad recientemente. A finales de julio, hubo un montón de noticias sobre un nuevo tipo de ataque de retransmisión NTLM llamado PetiPotam. La vulnerabilidad principal de ese ataque son los servicios de certificación de Active Directory, que permiten a un usuario sin privilegios escalar a derechos de administrador de dominio a través de la red de Windows.
Otra cosa importante es ver cómo un atacante puede obtener o persistir en una red utilizando los servicios de certificados de Active Directory. Un buen ejemplo de esto es cuando inicias sesión en una red Windows con tu nombre de usuario y contraseña. Cuando tienes Servicios de Certificación de Directorio Activo, puedes iniciar sesión utilizando un certificado que está completamente separado de tu contraseña. Pero muchos defensores de la red no saben esto. En ese caso, aunque borren la máquina o restablezcan la contraseña de un usuario comprometido, si el atacante tiene el certificado de ese usuario o de ese ordenador, puede seguir iniciando sesión como ese usuario o accediendo a ese ordenador. Este es un importante punto ciego en la detección y la respuesta a incidentes del que los defensores deben ser conscientes.
¿Cómo afecta a estas vulnerabilidades el hecho de que muchas organizaciones no se den cuenta necesariamente de que están utilizando certificados en tantos lugares diferentes?
Will: Los certificados están en todas partes, y si la gente no entiende y comprende las implicaciones de seguridad, es extremadamente fácil que un bit cambiado en una plantilla de certificado comprometa toda la red. Lo que hemos visto es una falta general de familiaridad con los servicios de certificación de Active Directory.
Lee: La otra cosa a tener en cuenta es que los Servicios de Certificación de Active Directory aparecieron en 2001, y han ido avanzando a lo largo de los años. Dado que lleva tanto tiempo en las organizaciones, es fácil que se produzca un error de configuración o que se activen cosas que puedan causar una configuración insegura. Es importante que los equipos le hagan mantenimiento y vean cómo están las cosas.
¿Qué riesgos conlleva esa falta de familiaridad con el programa?
Chris: Lo que hemos visto es que la gente hace cambios de configuración por necesidad. Encuentran un artículo sobre cómo hacerlo, y funciona; pero no entienden del todo las implicaciones posteriores, y estos cambios aparentemente menores afectan a la confianza que depositas en esa infraestructura a lo largo del tiempo. Se abre una caja de Pandora de vulnerabilidades.
Will: Nos gusta el término deuda de desconfiguración. Esos pequeños cambios realizados por alguien que sólo intenta hacer su trabajo se acumulan con el tiempo. Sentimos mucha empatía por los administradores de sistemas, porque es muy fácil desconfigurar accidentalmente estos sistemas de forma profunda.
Chris: Desde mi experiencia, tenemos que poner las cosas en contexto. Active Directory Certificate Services es una CA. Una PKI es toda una infraestructura que incluye una CA y muchas otras cosas. Es como tener un motor, un volante y cuatro neumáticos: eso no lo convierte necesariamente en un coche. Es la forma en que todos esos sistemas funcionan juntos lo que le da la confianza para conducir a toda velocidad.
Mucha gente mira a Certificate Services y dice que es una PKI tan buena como cualquier otra, cuando, de hecho, la infraestructura completa no está ahí para convertirlo en el sistema adecuado para una organización. No tiene todas las características de seguridad y controles compensatorios que se necesitan para reconocer la deuda técnica que se está creando y, lo que es más importante, la deuda de riesgo que hay detrás.
¿Existe alguna tendencia que usted observe que conduzca a estas situaciones en las que los Servicios de certificación de Active Directory se pasan por alto o están mal configurados?
Will: A menudo nos encontramos con que no hay suficiente polinización cruzada entre los equipos de seguridad y los otros equipos que gestionan Active Directory, lo que hace que sea fácil pasar por alto estos problemas. O si las organizaciones nunca han llevado a cabo una evaluación de PKI, puede que no sepan cuáles son los problemas.
Lee: Sorprendentemente mucha documentación de los vendedores ha llevado a estas vulnerabilidades. Varios productos han sugerido habilitar configuraciones de nombres alternativos de sujeto (SAN) que pueden llevar a un estado muy inseguro de PKI. Es complejo, e incluso los vendedores no saben exactamente lo que tienen que hacer.
También es muy difícil en los entornos de Active Directory, y en las grandes redes en general, comprender las implicaciones de los cambios. ¿Qué ocurre si modifico esta configuración o añado un usuario a este grupo? ¿Permitirá esto que alguien aumente sus privilegios? Nuestro objetivo es aumentar esa visibilidad.
Chris: Estoy de acuerdo en que la visibilidad es una parte importante. Esa es una de las razones por las que la plataforma Keyfactor Command proporciona visibilidad sobre qué certificados se despliegan y por qué se despliegan, para que puedas encontrar esas anomalías y aplicar políticas de forma coherente en todos los certificados emitidos. De este modo se pueden detectar vulnerabilidades o errores de configuración antes de que se conviertan en un problema.
El otro punto que añadiré es que cuando estás implantando algo gratis, es difícil explicar a los dirigentes que hay un coste asociado a la gestión de su complejidad a largo plazo. La mayoría de las organizaciones no están preparadas para ocuparse de en qué se convierte PKI al final del día.
Si nos fijamos en lo que puede fallar en una ICP, ¿hay algo con lo que se encuentre a menudo?
Chris: Los mayores errores son a veces los más fáciles de cometer. En este caso, es algo así como accionar un interruptor que permite poner nombres alternativos arbitrariamente en los certificados. En general, la investigación pone de relieve algunos de los peligros basados en el hecho de que Active Directory Certificate Services se configuró hace 20 años y no ha avanzado necesariamente a la misma velocidad o con la misma celeridad de seguridad que otros productos.
Will: Hubo un error de configuración en particular que cubrimos en el informe que llamamos escalada ocho. Los siete primeros son problemas en los que la gente tuvo que desconfigurar cosas después de la instalación. La escalada ocho es algo que deseamos que Microsoft solucione.
Lee: En ese caso, hay un rol de servidor adicional que suele habilitarse con Active Directory Certificate Services que permite solicitar un certificado mediante HTTP.
Si esta opción está activada, como vemos a menudo, cualquiera puede solicitar un certificado utilizando el protocolo HTTP. El problema aquí es que utiliza NTLM para la autenticación por defecto. Hay un ataque llamado NTLM relay que permite a los atacantes hacerse pasar por un usuario. Si Will intenta conectarse a mi máquina, puedo hacerme pasar por Will, y luego conectarme a los Servicios de Certificación de Active Directory y solicitar un certificado como él. O hay algunas herramientas como PetitPotam o SpoolSample que me permiten coaccionar a un ordenador arbitrario de la red para que se conecte conmigo. Entonces puedo hacerme pasar por ese controlador de dominio utilizando la retransmisión NTLM y solicitar un certificado a los Servicios de Certificación de Active Directory desde ese punto de entrada HTTP. Puedo obtener ese certificado y luego conectarme como un controlador de dominio, dándome acceso a las contraseñas de los usuarios y sus hashes.
Esto puede usarse para comprometer una red, yendo desde un privilegio bajo hasta el administrador del bosque. Es una vulnerabilidad que vemos en entornos todo el tiempo.
No es sólo teórico. ¿Ha podido llegar a un acuerdo utilizando esta metodología?
Will: Así es. Los proveedores y las organizaciones a veces dudan en esforzarse por solucionar problemas que se consideran teóricos. Esto entra en el terreno de la publicación de pruebas de concepto o herramientas ofensivas, algo que intentamos hacer desde el punto de vista ético, pero hemos descubierto que el cambio no se produce realmente a menos que la gente pueda ver que los ataques son reales.
Lee: Hemos utilizado todos los escenarios de escalada que identificamos, e incluso todos los oficios que identificamos. Son cosas reales que los delincuentes pueden hacer en tu red. En respuesta, hemos sacado un conjunto de herramientas defensivas para que la gente pueda empezar a vigilar estas cosas. Una de esas herramientas es PSPKIAuditque puede identificar estos problemas con los servicios de certificación de Active Directory.
También tenemos un producto llamado Bloodhound que tiene una versión para open-source y otra para empresas. Estamos trabajando activamente para incorporar las detecciones de estas vulnerabilidades para que la gente pueda verlas y corregirlas en sus entornos.
¿Cuáles son sus recomendaciones para que los arquitectos de PKI hagan frente a estas vulnerabilidades?
Voluntad: Herramientas como PSPKIAudit enumerarán las configuraciones erróneas que conocemos y luego le permitirán intentar arreglarlas, pero tenga en cuenta que no hay sólo "arreglar esta cosa". Tiene que entender qué configuraciones están ahí y por qué se están utilizando para no romper la funcionalidad existente.
Además de eso, es importante pensar en los servicios de certificación desde el punto de vista de la seguridad de respuesta instantánea, es decir, si alguien pone en peligro una cuenta o un sistema, ¿tiene forma de identificar qué certificados emitió ese usuario? Se trata de un problema muy difícil de resolver para muchas organizaciones, ya que la implementación de los servicios de certificados de Active Directory no cuenta con funciones de gestión realmente buenas.
Chris: La otra cosa a tener en cuenta es que es muy difícil en PKI volver atrás una vez que se establece la confianza. Si tienes certificados con SAN arbitrarios y no hay forma de encontrarlos y revocarlos, puedes cambiar la configuración, pero eso no soluciona necesariamente los problemas. Es difícil volver a poner los caballos en el proverbial establo.
¿Le interesa obtener más información sobre las vulnerabilidades de los servicios de certificación de Active Directory y lo que su organización puede hacer al respecto? Haga clic aquí para ver el debate completo con Chris, Will y Lee.
