Mesa redonda: Comprendiendo las implicaciones de los servicios de certificados de Active Directory en la PKI

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.

So how do you make sure PKI continues to perform up to evolving standards? And what can go wrong if you don’t take this proactive approach?

That was the premise behind our conversation with Chris Hickman, Keyfactor’s Chief Security Officer, and Will Schroeder and Lee Christensen, technical architects at SpecterOps, an adversary-focused cybersecurity provider that helps defend against advanced attacks.

Most recently, Will and Lee brought light to this concern when they published a new whitepaper based on research they did about Microsoft Active Directory, including a wide gamut of common misconfigurations in Microsoft’s PKI implementation that can be exploited. Here are some of the highlights from our discussion.

¿Cuáles son algunas de las principales conclusiones del informe?

Lee: Something that really stuck out to us with Active Directory Certificate Services is that it’s very ubiquitous in enterprise networks. But it’s also old and not very well understood. Overall, there’s not a lot of security considerations around it even though it’s used everywhere and is key to authentication and how the network is run. That makes it a ripe target for attackers.

Will: What’s interesting with this research is that, because Active Directory Certificate Services is so expansive and so integrated in Active Directory, it wasn’t just one flaw or one way to escalate. We broke it into a variety of ways that people could steal certificates or maliciously enroll certificates for the purposes of credential theft and machine persistence. We ended up codifying everything into credential theft, domain escalation and domain persistence, which are all very expansive and interesting all in their own right.

Lee: The domain escalation issue has also become very timely recently. At the end of July, there was a lot of news about a new type of NTLM relay attack called PetiPotam. The root vulnerability in that attack is Active Directory’s Certificate Services allowing an unprivileged user to escalate to domain admin rights over the Windows network.

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: Certificates are everywhere, and if people don’t understand and grasp the security implications, it’s extremely easy to have one bit flipped in one certificate template that compromises the entire network. What we’ve seen is an overall lack of familiarity with Active Directory Certificate Services.

Lee: The other thing to note is that Active Directory Certificate Services came out in 2001, and it’s been chugging along over the years. Since it’s been in organizations for so long, it’s easy for a misconfiguration to happen or for things to be enabled that may cause an insecure configuration. It’s important for teams to do maintenance on it and see how things are looking.

¿Qué riesgos conlleva esa falta de familiaridad con el programa?

Chris: What we’ve seen is that people make configuration changes out of necessity. They find a knowledge article about how to do it, and it works; but they don’t fully understand the downstream implications, and these seemingly minor changes impact the trust you put in that infrastructure over time. It opens up a Pandora’s box of vulnerabilities.

Will: We like the term misconfiguration debt. Those small changes made by someone who’s just trying to do their job build up over time. We have a lot of empathy for system administrators, because it’s very easy to accidentally misconfigure these systems in a profound way.

Chris: From my experience, we have to put things in context. Active Directory Certificate Services is a CA. A PKI is an entire infrastructure that involves a CA and many different other things. It’s like having an engine, a steering wheel and four tires — that doesn’t necessarily make it a car. It’s how all those systems work together that give you the confidence to drive at speed.

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: We often find there’s not enough cross-pollination between security teams and the other teams that manage Active Directory, which makes it easy to overlook these issues. Or if organizations have never led a PKI assessment, they might not know what the issues are. 

Lee: Surprisingly lots of vendor documentation has led to these vulnerabilities. Several products have suggested enabling subject alternative name (SAN) settings that can lead to a very insecure state of PKI. It’s complex, and even vendors don’t realize exactly what they need to do. 

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: I agree visibility is a huge part of it. That’s one of the reasons why Keyfactor’s Command platform provides visibility into what certificates are deployed and why they’re deployed, so you can find those anomalies and apply policy consistently across every certificate that’s issued. That way you can catch vulnerabilities or misconfigurations before they become an issue. 

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: The biggest mistakes are sometimes the easiest to make. In this case, that’s something like flipping a switch that allows you to put alternate names arbitrarily into certificates. Overall, the research really highlights some of the dangers based on the fact that Active Directory Certificate Services was configured 20 years ago and has not necessarily moved at the same speed or with the same security alacrity as some other products have.

Will: There was one particular misconfiguration that we cover in the report that we called escalation eight. The first seven are issues where people had to misconfigure things post-install. Escalation eight is something that’s stock that we wish Microsoft would fix.

Lee: In that case, there’s an additional server role that is often enabled with Active Directory Certificate Services that allows you to request a certificate using 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: That’s right. Vendors and organizations are sometimes hesitant to go through the efforts to fix issues that are regarded as theoretical. This gets into the realm of releasing proof of concepts or offensive tooling, which we try to do ethically, but we found that change doesn’t really come about unless people can see that the attacks are real.

Lee: We’ve used all of the escalation scenarios we identified, and even all of the trade craft that we identified. This is actual stuff that bad guys can do in your network. In response, we came out with a defensive tool set so people can start getting their eyes on this stuff. One of those tools is PSPKIAudit, which can identify these issues with Active Directory Certificate Services. 

We also have a product called Bloodhound that has an open-source version and an enterprise version. We’re actively working to incorporate the detections of these vulnerabilities into that as well so people can get their eyes on it and can fix it in their environments.

¿Cuáles son sus recomendaciones para que los arquitectos de PKI hagan frente a estas vulnerabilidades?

Will: Tools like PSPKIAudit will enumerate the misconfigurations we know about and then allow you to try to fix them, but keep in mind there’s no just “fix this one thing.” You have to understand what settings are there and why they’re being used so you don’t break existing functionality. 

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: The other thing to note is that it’s really hard in PKI to go back once you establish trust. If you have certificates out there with arbitrary SANs and no way to find and revoke them, you could turn the configuration setting around, but that doesn’t necessarily remediate the issues. It’s difficult to put the horses back in the proverbial barn.

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