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 los ciberatacantes. 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 los tickets 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 servidores con delegación no restringida? Probablemente porque en las primeras versiones de AD, era la única forma de delegación soportada, y también es la más fácil de configurar, requiriendo sólo 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 los administradores de dominio podían controlar la 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 rutas de ataque podrían estar abiertas. Conocido como delegación restringida basada en recursos (RBCD), este enfoque de la delegación es el más difícil de abusar.
En comparación, la delegación sin restricciones es la menos segura. Si los atacantes pueden abusar de una delegación Kerberos insegura, pueden enmascarar todo tipo de actividades maliciosas haciéndose pasar por un usuario legítimo. Una amenaza 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 hacerse pasar por ese usuario y aprovechar sus privilegios de acceso. Esta realidad hace que la delegación sin restricciones sea un mecanismo ideal para moverse lateralmente 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 acceder potencialmente a una cuenta KRBTGT y lanzar un ataque Golden Ticket.
Un atacante puede utilizar el cmdlet Get-ADComputer del módulo PowerShell de Active Directory para encontrar equipos con esta configuración activada y ponerse manos a la obra. Pueden utilizar Mimikatz, por ejemplo, para extraer todos los tickets de la memoria del sistema. Las implicaciones negativas de esto son claras.
Mejore la seguridad de AD desactivando la delegación ilimitada
La buena noticia es que puede cerrar la brecha de seguridad creada por la delegación no restringida simplemente desactivando esta configuración. Para que la delegación no restringida surta efecto, los administradores de dominio deben habilitarla para las cuentas marcando "Confiar en este equipo para la delegación a cualquier servicio (sólo Kerberos)" en la pestaña Delegación de la consola de administración de ADUC.
Dados los altos riesgos de habilitar esta configuración, las organizaciones pueden mejorar su postura de seguridad identificando cualquier servidor con delegación no restringida habilitada, deshabilitando la configuración y reemplazándola con delegación restringida para los servidores que lo requieran. Las cuentas de administrador deben configurarse como "La cuenta es confidencial y no puede delegarse", y las cuentas con privilegios elevados deben colocarse en el grupo de seguridad de usuarios protegidos. Los administradores pueden buscar bosques con confianzas entrantes que permitan la delegación TGT y cualquier principal de seguridad que permita la delegación no restringida utilizando los scripts PowerShell. También puede detectar la delegación no restringida examinando los eventos de Windows. Cuando se emite un vale Kerberos, un controlador de dominio de Active Directory registra eventos de seguridad que contienen información sobre el dominio de destino. Puede examinar esos eventos para determinar si se está utilizando la delegación no restringida en las confianzas entrantes. O puede descargar y ejecutar Purple Knightuna herramienta de evaluación de seguridad gratuita creada por expertos en AD de Semperis que analiza su entorno AD en busca de más de 80 indicadores de seguridad, incluida la delegación no restringida.
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.
