Cuando una empresa tiene una red con Active Directory es necesario preocuparse por la seguridad de éste, ya que afecta a la seguridad de toda la organización. Dentro de las medidas de seguridad que se pueden poner se encuentran las que entran dentro de la fase de fortificación de la plataforma, más las que añaden los equipos de seguridad con el objetivo de proteger los activos, detectar los ataques y mitigar su impacto.
Fortificar un servidor Windows Server con Active Directory consiste en seleccionar cuáles deben ser los roles y características que debe tener un servidor y aplicar todas las medidas que cumplan los principios de Mínimo Punto de Exposición (MPE), Mínimo Privilegio Posible (MPP) y Defensa en Profundidad (DeP). Es decir, una vez definido qué y cómo debe trabajar Active Directory, se pone en producción fortificado.
No obstante, no siempre la fortificación del sistema cierra todos los posibles ataques, ya sea por necesidades de la empresa o por limitaciones de la tecnología. En ese punto hay que pensar qué medidas de terceros se pueden poner para añadir una capa extra de fortificación al sistema y qué mecanismos de monitorización se deben implementar para detectar cualquier posible ataque a esas debilidades y poder mitigar el impacto de un ataque.
Un ejemplo con la gestión de credenciales
Para atacar el problema del robo de contraseñas de los usuarios se puede implementar un sistema de contraseñas complejas, de login basado en SmartCards o directamente deshabilitar las cuentas que tengan mala actividad dentro de la organización, pero ni aún así esto puede ser la solución definitiva en muchos casos, como vamos a ver. Por supuesto, nuestra propuesta para fortificar y dificultar el robo de credenciales es configurar Latch para Windows en Active Directory como una de esas medidas que permite fortificar el sistema de autorización del uso de identidades y así evitar que las contraseñas puedan ser robadas y utilizadas por un atacante.
No obstante, a pesar de que se puedan poner muchas medidas de fortificación, aún existen multitud de ataques que pueden hacerse sin conocerse la contraseña de un usuario del sistema. Estos ataques pueden ser utilizados por un pentester contratado o por un atacante que esté en medio de un ataque dirigido contra la empresa. Estas técnicas de explotación de sistemas pueden realizarse como forma de pivotar de una máquina a otra cuando se ha conseguido comprometer previamente una máquina de la organización y pueden terminar convirtiéndose en un robo de la identidad para acceder a un montón de recursos dentro de la organización.
Ataques Pass-the-Hash
Si se tiene una máquina comprometida y se consigue utilizar una técnica similar a Mimikatz se podrían llegar a conseguir las contraseñas almacenadas localmente dentro del sistema operativo Windows controlado desde la organización, pero si no, con atacar a la base de datos de credenciales locales, con una herramienta como WCE (Windows Credentials Editor) sería posible acceder a los hashes NTLM de los usuarios almacenados localmente dentro de la máquina y utilizar una técnica como Pass-the-Hash para conseguir la autenticación en un recurso de la red directamente inyectando el hash NTLM extraído localmente del equipo en el proceso de autenticación LSASS, sin necesidad de utilizar la contraseña.
A partir de ese momento, en todo punto de control en el que se pueda o haya que realizar una autenticación NTLM a través del servicio de Network Logon, se realizará todo el proceso de cifrado del desafío de 16 bytes que provee el servidor de autenticación con el hash NTLM, sin importar para nada cuál fuera la contraseña. Es decir, no servirá para los procesos de inicio de sesión interactivos, pero sí para los inicios de sesión en red.
Desde el punto de vista del atacante, conseguir un hash para circular por la red será casi como conseguir la password, ya que el hash será válido mientras el usuario no cambie la contraseña. Es por eso que las buenas prácticas de fortificación de sistemas Microsoft Windows hablan siempre de forzar al usuario a cambiarla periódicamente, limitando temporalmente el impacto que pueda haber tenido el robo de una contraseña o el robo de un hash NTLM.
Fortificar un servidor Windows Server con Active Directory consiste en seleccionar cuáles deben ser los roles y características que debe tener un servidor y aplicar todas las medidas que cumplan los principios de Mínimo Punto de Exposición (MPE), Mínimo Privilegio Posible (MPP) y Defensa en Profundidad (DeP). Es decir, una vez definido qué y cómo debe trabajar Active Directory, se pone en producción fortificado.
No obstante, no siempre la fortificación del sistema cierra todos los posibles ataques, ya sea por necesidades de la empresa o por limitaciones de la tecnología. En ese punto hay que pensar qué medidas de terceros se pueden poner para añadir una capa extra de fortificación al sistema y qué mecanismos de monitorización se deben implementar para detectar cualquier posible ataque a esas debilidades y poder mitigar el impacto de un ataque.
Un ejemplo con la gestión de credenciales
Para atacar el problema del robo de contraseñas de los usuarios se puede implementar un sistema de contraseñas complejas, de login basado en SmartCards o directamente deshabilitar las cuentas que tengan mala actividad dentro de la organización, pero ni aún así esto puede ser la solución definitiva en muchos casos, como vamos a ver. Por supuesto, nuestra propuesta para fortificar y dificultar el robo de credenciales es configurar Latch para Windows en Active Directory como una de esas medidas que permite fortificar el sistema de autorización del uso de identidades y así evitar que las contraseñas puedan ser robadas y utilizadas por un atacante.
 |
| Figura 1: Plugins de Latch para Windows Personal y Enterprise Edition |
No obstante, a pesar de que se puedan poner muchas medidas de fortificación, aún existen multitud de ataques que pueden hacerse sin conocerse la contraseña de un usuario del sistema. Estos ataques pueden ser utilizados por un pentester contratado o por un atacante que esté en medio de un ataque dirigido contra la empresa. Estas técnicas de explotación de sistemas pueden realizarse como forma de pivotar de una máquina a otra cuando se ha conseguido comprometer previamente una máquina de la organización y pueden terminar convirtiéndose en un robo de la identidad para acceder a un montón de recursos dentro de la organización.
Ataques Pass-the-Hash
Si se tiene una máquina comprometida y se consigue utilizar una técnica similar a Mimikatz se podrían llegar a conseguir las contraseñas almacenadas localmente dentro del sistema operativo Windows controlado desde la organización, pero si no, con atacar a la base de datos de credenciales locales, con una herramienta como WCE (Windows Credentials Editor) sería posible acceder a los hashes NTLM de los usuarios almacenados localmente dentro de la máquina y utilizar una técnica como Pass-the-Hash para conseguir la autenticación en un recurso de la red directamente inyectando el hash NTLM extraído localmente del equipo en el proceso de autenticación LSASS, sin necesidad de utilizar la contraseña.
A partir de ese momento, en todo punto de control en el que se pueda o haya que realizar una autenticación NTLM a través del servicio de Network Logon, se realizará todo el proceso de cifrado del desafío de 16 bytes que provee el servidor de autenticación con el hash NTLM, sin importar para nada cuál fuera la contraseña. Es decir, no servirá para los procesos de inicio de sesión interactivos, pero sí para los inicios de sesión en red.
Desde el punto de vista del atacante, conseguir un hash para circular por la red será casi como conseguir la password, ya que el hash será válido mientras el usuario no cambie la contraseña. Es por eso que las buenas prácticas de fortificación de sistemas Microsoft Windows hablan siempre de forzar al usuario a cambiarla periódicamente, limitando temporalmente el impacto que pueda haber tenido el robo de una contraseña o el robo de un hash NTLM.
Esto, en las SmartCards o en los sistemas biométricos, por desgracia, no es así. Por un lado, cuando se decide utilizar un sistema de SmartCards o un sistema basado en biometría, hemos conseguido reducir la posibilidad de que alguien copie la contraseña al sustituirla por algo que debe poseerse, ya sea un patrón biométrico o una SmartCard. Sin embargo, se ha inyectado un problema grave en el uso de las técnicas de Pass-the-Hash, ya que al final se usará un hash NTLM por debajo para el proceso de autenticación que nunca va a cambiar, al ser generado en el momento de enrollment en la cuenta de usuario de la SmartCard o la biometría. Es decir, si un usuario consigue robar el hash NTLM de una SmartCard, por ejemplo, podrá estar usándolo para autenticarse por NTLM siempre, ya que el hash no cambia nunca.
En Windows 8.1, estas técnicas han cobrado un poco más de importancia con la aparición del Restricted Admin Mode en las conexiones RDP (Remote Desktop Protocol). Hasta el momento, la autenticación en un servidor para conseguir el inicio de sesión interactivo se hacía pasando un proceso que exigía poner la contraseña, o usar el inicio de sesión basado en credenciales cifradas RDP del que hemos hablado en los ataques Citrix/RDP, pero ahora en Windows 8.1 se puede usar el Restricted Admin Mode y pedir que la autenticación se haga vía Network Logon, lo que abre un nuevo servicio al ataque Pass-the-Hash.
 |
| Figura 3: PoC de Ataque Pass-the-Hash en una conexión RDP |
Como os podéis imaginar, esta es una técnica muy utilizada dentro de la explotación de redes Microsoft, y por supuesto está documentada dentro del libro de Ethical Hacking o en cualquier otro manual de realización de pentesting que se centre en el ataque a redes Microsoft Windows desde que hace años, en concreto en 2008, el investigador argentino Hernán Ochoa (@hernano) la documentara en detalle. En su presentación de RootedCON 2011, podéis ver los detalles del trabajo que hizo.
Ataques Pass-the-Ticket
Por supuesto, en un entorno con Active Directory, la autenticación NTLM no se usa en el acceso a la mayoría de los recursos de red de la organización, ya que el protocolo por defecto de Microsoft para realizar su autenticación bajo una arquitectura SSO(Single Sign-On) es Kerberos. El esquema es sencillo, tras realizar un proceso de desafío contra el servicio de autenticación Authentication Service dentro del KDC(Key Distribution Center) de la organización Kerberos, el usuario recibe un token que le permitirá solicitar autenticación en cada uno de los servicios que quiera acceder. Es el TGT (Ticket Granting Ticket) o "el ticket que concede tickets de acceso" y viene a ser un token que se utilizará como hash para firmar los futuros desafíos desde el servidor, al igual que el token NTLM se utiliza para confirmar que se tiene la password de la cuenta.
Al final, el token TGT viene a ser como un hash NTLM pero que solo tiene validez durante un periodo de tiempo de sesión así que si es robado sólo se puede usar durante ese espacio temporal. A partir de ese momento, cuando un usuario quiere acceder a cualquier recurso, con su TGT pasa un proceso de validación en el KDC solicitando el acceso a ese recurso, y si la cuenta representada por ese TGT está permitida, entonces se le entrega un TGS (Ticket Granting Service) o "el ticket que concede el servicio" y que se entregará al acceso del recurso.
 |
| Figura 4: Extracción de tickets kerberos TGT y TGS |
Por supuesto, las técnicas de Pass-the-Ticket funcionan de igual manera que las técnicas de Pass-the-Hash, pero utilizando el TGT en lugar del hash NTLM. Estos TGT están limitados temporalmente, pero el tiempo puede ser razonablemente largo, ya que su renovación por defecto es cada 10 horas y alguien podría incluso extenderla hasta 7 días de vida, por lo que el atacante tendría la posibilidad de emitirse muchos TGS. Conseguir los TGT se pueden sacar igualmente del Windows Credential Store localmente, por lo que no se diferencia demasiado el proceso.
Una curiosidad que tienen los TGT es que pueden utilizarse incluso después de que la cuenta haya sido borrada, deshabilitada o bloqueada, ya que la comprobación de salud de la cuenta se realiza dentro del dominio cada 20 minutos, pero si es una cuenta de usuario que viene con un TGT que no ha expirado desde un dominio remoto con el que se ha establecido una relación de confianza, entonces no se comprueba el estado de salud - es decir, que no esté bloqueada, borrada o deshabilitada - lo que le permitiría a un atacante seguir campando con un TGT de una cuenta zombie.
¿Cómo detectar y mitigar estos ataques?
En este artículo he hablado de Pass-the-Hash y Pass-the-Ticket por poner dos ejemplos de ataques que se producen en redes Microsoft Windows. Pass-the-Hash en entornos en los que no hay validación Kerberos (que pueden ser muchos, incluidas redes con Active Directory en puntos y situaciones concretas) y Pass-the-Tickets en entornos Kerberos como Active Directory. Pero el objetivo principal era haceros pensar en la respuesta a la pregunta que os hecho en esta sección.
Lo cierto es que en un entorno Active Directory se pueden hacer muchos más abusos del sistema, como conectarse con cuentas de máquina usando una elevación de privilegios a System para enumerar los objetos del AD o hacer ataques de User-Guessing contra Kerberos. Además, podríamos tener el robo de un cuenta por parte de un usuario que estuviera siendo usada de forma anómala dentro de la red para acceder a documentos o información que va a ser robada de la empresa.
Descubrir que en tiempo real se está produciendo alguno de estos ataques dentro de la red no es fácil. Si tenemos un IDS o un IPS dentro de la organización, habría que ser capaz de hacer Deep Packet Inspection de los protocolos de red utilizados por las redes Microsoft para localizar qué información se está utilizando. Habría que analizar Kerberos, LLMR, CIFS, etcétera y generar reglas de inteligencia sobre la información que de ellos se pueda extraer, algo que por desgracia no es fácil de hacer hoy en día.
Microsoft tiene una guía de fortificación para reducir el impacto de los ataques Pass-the-Hash y a mí personalmente me gusta la herramienta DAF de Aorato. Lo que ellos hacen es justamente eso, hacer DPI para detectar todos los ataques que se estén produciendo de Pass-the-Hash, Pass-the-Ticket, abuso del Active Directory, o simplemente comportamientos anómalos de las cuentas de usuario o de máquina dentro de la red.
 |
| Figura 5: Alertas de ataques Active Directory con Aorato DAF |
Para ello, configuran un puerto mirror en el switch que lleva el tráfico al Active Directory al que conectan una sonda que captura y analiza el tráfico. Este se envía a un repositorio central donde se realiza el cruzado de datos y el análisis inteligente de la información, y se le envía al equipo de seguridad el listado de alertas que están siendo descubiertas por la red. Es decir, una herramienta de análisis de seguridad del tráfico de Active Directory y de equipos Windows para detectar cuándo un ataque se está produciendo en la red que solo podrías detectar si haces DPI a los protocolos Microsoft.
¿Se puede hacer sólo con el IDS? Seguro que sí. Al final analizar los protocolos de Microsoft no es del todo imposible. Muchos de ellos están bien documentados. Poner la lógica por encima de ellos para detectar un ataque de Pass-the-Hash o de Pass-the-Ticket es posible también, pero no en muchas organizaciones he visto una protección que detecte los ataques Pass-the-Hash o Pass-the-Ticket.
Saludos Malignos!
No hay comentarios:
Publicar un comentario