Como suele ocurrir con Active Directory, algunas de las peores brechas de seguridad están causadas por configuraciones erróneas que dejan puertas abiertas a posibles ciberamenazas. Una configuración común que a los ciberdelincuentes les encanta explotar es la delegación sin restricciones.
¿Qué es la delegación ilimitada y por qué es un riesgo para la seguridad? La delegación es la acción de permitir que un ordenador guarde los tickets de autenticación Kerberos de un usuario, y luego usar esos tickets para hacerse pasar por el usuario y actuar en su nombre. La delegación ilimitada es un parámetro de configuración que muchas aplicaciones web multinivel necesitan para funcionar. Pero la configuración tiene implicaciones de seguridad, ya que un ordenador que almacena la información de los tickets Kerberos de un grupo de usuarios sería un objetivo obvio para los atacantes. Si los atacantes pueden hacerse con esos tickets, pueden actuar con la identidad y los privilegios de esos usuarios.
Si esta configuración es tan arriesgada, ¿por qué los administradores configuran los servidores con delegación no restringida en lugar de la tradicional delegación restringida? Probablemente porque en las primeras versiones del entorno de Active Directory, era la única forma de delegación admitida, y también es la más fácil de configurar, ya que sólo requiere una casilla de verificación. Y si la configuración de la delegación no restringida hace que la aplicación funcione, todo está bien, ¿verdad? Pero hay, de hecho, una excelente razón para revisar esta configuración. Eliminar la delegación ilimitada elimina un eslabón débil en una cadena de autenticación de confianza que podría causar daños significativos si se abusa de ella.
Lecturas relacionadas
Raíces de la delegación ilimitada
Las raíces de este riesgo potencial para la seguridad se remontan a hace 20 años. Microsoft introdujo la delegación no restringida de Kerberos en Windows Server 2000 para permitir a los servicios acceder a otros servicios en nombre de un usuario autenticado, de forma que no tuvieran que volver a autenticarse. Por ejemplo, si un usuario se ha autenticado en un servidor web, ese servidor web puede hacerse pasar por el usuario y acceder a bases de datos back-end sin que el usuario tenga que volver a introducir sus credenciales. Cuando se activa la delegación ilimitada en una cuenta, ésta puede suplantar al usuario en cualquier servicio del mismo dominio.
Aunque esta funcionalidad facilitaba la vida a los usuarios (y administradores), también presentaba un riesgo evidente. Si un servidor con la delegación no restringida activada estaba bajo el control de agentes de amenazas, podrían abusar de esta confianza para obtener acceso generalizado en todo el entorno. Microsoft intentó mitigar este riesgo introduciendo la delegación restringida en Windows Server 2003, que permitía a los administradores de dominio restringir a qué servicios podía acceder un servidor concreto.
Con el lanzamiento de Windows Server 2012, Microsoft otorgó a los administradores de servicios el poder de decidir si los servicios front-end podían acceder a los recursos back-end. Antes de este cambio, solo un administrador de dominio podía controlar los privilegios de delegación, lo que dejaba a los administradores de servicios sin una forma sencilla de saber qué servicios front-end podían acceder al recurso que poseían y, por tanto, qué posibles vías de ataque podrían estar abiertas. Conocido como delegación restringida basada en recursos (RBCD), este enfoque de la delegación de Active Directory es el más difícil de abusar.
En comparación, la delegación sin restricciones es la menos segura. Si los atacantes pueden aprovechar una delegación Kerberos insegura, pueden ocultar todo tipo de actividades maliciosas haciéndose pasar por un usuario legítimo. Un actor malicioso con acceso a un servidor web con esta configuración podría robar el «Ticket Granting Ticket» (TGT) del usuario, que se almacena en la memoria del servidor, y utilizarlo para suplantar a ese usuario y aprovechar sus privilegios de acceso o ampliar dicho acceso mediante la escalada de privilegios. Esta realidad convierte a la delegación sin restricciones en un mecanismo ideal para el movimiento lateral por todo el entorno. Un TGT perteneciente a un administrador de dominio, por ejemplo, podría dar al atacante acceso a cualquier servicio de su elección, o incluso permitirle acceder a una cuenta KRBTGT y lanzar un ataque de «Golden Ticket».
Un atacante puede utilizar el cmdlet Get-ADComputer del módulo de PowerShell de Active Directory para localizar los equipos en los que esta configuración está activada y, a continuación, ponerse manos a la obra. Puede utilizar Mimikatz, por ejemplo, para extraer todos los tickets de servicio de la memoria del sistema. Las consecuencias negativas de esto son evidentes.
Mejore la seguridad de AD desactivando la delegación ilimitada
La buena noticia es que puedes subsanar la brecha de seguridad que genera la delegación sin restricciones simplemente desactivando esta opción. Para que la delegación sin restricciones surta efecto, los administradores del dominio deben habilitarla para las cuentas marcando la casilla «Confiar en este equipo para la delegación a cualquier servicio (solo Kerberos)» en la pestaña «Delegación» de la consola de administración de ADUC.
Dado lo delicado que resulta habilitar esta configuración, las organizaciones pueden mejorar su nivel de seguridad identificando cualquier servidor que tenga habilitada la delegación sin restricciones, desactivando dicha configuración y sustituyéndola por la delegación restringida en los servidores que lo requieran. Las cuentas de administrador deben configurarse con la opción «La cuenta es sensible y no se puede delegar», y las cuentas con privilegios elevados deben incluirse en el grupo de seguridad «Usuarios protegidos». Los administradores pueden buscar bosques con relaciones de confianza entrantes que permitan la delegación de TGT y cualquier entidad de seguridad que permita la delegación sin restricciones mediante los scripts de PowerShell. También se puede detectar la delegación sin restricciones examinando los eventos de Windows. Cuando se emite un ticket de Kerberos, un controlador de dominio de Active Directory registra eventos de seguridad que contienen información sobre el dominio de destino. Se pueden examinar esos eventos para determinar si se está utilizando la delegación sin restricciones en las relaciones de confianza entrantes. O bien, puede descargar y ejecutar Purple Knight, una herramienta gratuita de evaluación de seguridad creada por los expertos en AD de Semperis que analiza su entorno de AD en busca de más de 80 indicadores de seguridad, incluida la delegación sin restricciones.
Deshabilitar la delegación no restringida puede causar problemas de compatibilidad para algunas aplicaciones que dependen de la función, lo que significa que tendrá que reconfigurar esas aplicaciones para utilizar la delegación restringida o RBCD. Como siempre, las organizaciones deben recordar que la seguridad de AD incluye algo más que parchear vulnerabilidades de código. Prevenir los ataques también significa tomar medidas para reducir la superficie de ataque y prevenir proactivamente los problemas antes de que surjan.
