Nota: Este artículo se publicó por primera vez en el número de julio de 2021 del boletín mensual Network Security, y aparece aquí con el permiso del editor.aquí con el permiso del editor.
Retroceder el reloj 21 años hasta el cambio de milenio sería una experiencia
extraña, dado el mundo en que vivimos hoy. Incluso dejando a un lado la pandemia de Covid-19
y sus repercusiones, aún sin determinar, la vida ha cambiado muchísimo
en las dos últimas décadas.
En el año 2000, Spotify, Facebook, Instagram y Uber no existían, mientras que Netflix (¿recuerdas el alquiler de DVD y CD por suscripción?) y Amazon eran totalmente nuevos. Internet era todavía algo novedoso y el iPhone no aparecería hasta dentro de siete años. La lista podría continuar, pero la cuestión es que el desarrollo tecnológico en el mundo de las TI se ha acelerado exponencialmente en los últimos 20 años aproximadamente.
A pesar de esta evolución, una innovación fundamental ha prevalecido, prácticamente sin cambios, durante todo este periodo.
Lecturas relacionadas
Punto de dolor
En los años 90, los directorios eran uno de los principales problemas administrativos de las empresas. El mundo laboral se sustentaba en una serie de pequeños directorios que hacían que compartir datos y archivos clave fuera una tarea complicada y laboriosa. Para acceder a los archivos compartidos, los usuarios tenían que iniciar sesión en cada sistema de archivos individual, para lo que necesitaban diversas credenciales, software y aplicaciones.
Con la introducción de Windows NT a mediados de los noventa, Microsoft ya ayudó a muchas empresas a adoptar el concepto de "dominio", que permitía unir varios sistemas en un círculo de confianza, reduciendo eficazmente la segmentación de las identidades de usuario en directorios separados. Pero aunque Windows NT permitió a Microsoft introducirse con éxito en los centros de datos corporativos, las limitaciones de escalabilidad inherentes a los dominios de Windows NT obligaban a crear y gestionar múltiples directorios de dominio en distintas geografías, con fideicomisos entre ellos para compartir el acceso de los distintos usuarios de una empresa. Esto se convirtió en un reto cada vez mayor a medida que no sólo las empresas sino también sus sistemas informáticos se subían al carro de la globalización.
Aparece Microsoft Active Directory (AD), que en su momento fue una tecnología revolucionaria, lanzada originalmente con el sistema operativo de servidor Windows 2000 y que sigue soportando gran parte del mundo laboral hiperconectado que habitamos en la era moderna.
En muchos sentidos, fue innovador. Las empresas internacionales podían ampliar sus directorios sin tener que depender de muchos dominios pequeños y difíciles de gestionar. De hecho, había otros directorios que luchaban por ofrecer las mismas ventajas a las empresas. Novell eDirectory, por ejemplo, era muy utilizado. Sin embargo, Microsoft AD prevaleció sobre todos los demás por una razón fundamental: era abierto.
¿Abierto o seguro?
"Abierto", en el caso de los servicios de directorio, significa "legible por cualquiera", que sigue siendo el valor predeterminado en cualquier configuración AD actual, al menos para el usuario autenticado, es decir, cualquier usuario que haya iniciado sesión en un ordenador con su cuenta AD. Novell optó por la vía más segura con eDirectory, exigiendo a los administradores que concedieran específicamente permisos de lectura a cada sección necesaria para usuarios y aplicaciones, lo que añade un obstáculo operativo a la hora de incorporar e integrar nuevas aplicaciones.
Esta apertura, que hace 21 años era el mayor punto fuerte de Microsoft Active Directory, se ha convertido desde entonces en su debilidad más preocupante.
En el momento de su lanzamiento fue muy aclamado por su capacidad para integrarse fácilmente con las aplicaciones y ofrecer un inicio de sesión único en todo el entorno empresarial, reduciendo así las molestias de la gestión de contraseñas y directorios con una autenticación de amplio alcance. Gracias a esta apertura y facilidad de integración, AD sigue siendo una pieza fundamental de la infraestructura del 90% de las empresas. De hecho, se utiliza a una escala tan amplia que la mayoría de las aplicaciones empresariales actuales ni siquiera tienen su propio directorio, sino que confían en que el usuario se autentique en Windows.
Sin embargo, esta apertura también ha creado vulnerabilidades.
Delegación ilimitada
Tomemos como ejemplo las funciones específicas de Kerberos. Kerberos es un protocolo de autenticación de redes informáticas que funciona sobre una estructura de tickets para permitir que los nodos que se comunican a través de redes corporativas se proporcionen mutuamente su identidad de forma segura. Era un protocolo muy seguro para su época, lo que subrayaba el significado de su nombre: En la mitología griega, Kerberos es un perro de tres cabezas que vigila las puertas del Inframundo para impedir la salida de los muertos.
Una capacidad especial que ofrecía Kerberos era la de delegación, que funcionaba para garantizar que un usuario que accedía a una aplicación en un sistema sólo pudiera acceder a información específicamente compartida (a menudo un archivo o datos específicos en una base de datos) con esa aplicación en otro sistema, impidiendo el acceso a otros datos. Desde un punto de vista técnico, esto se conseguía suplantando al usuario por la aplicación mientras ésta accedía al otro servicio en nombre del usuario. Se "delegaba" a la aplicación -o más bien al servidor que alojaba la aplicación- el uso de la autenticación Kerberos de otra persona, es decir, se le concedía el derecho a reenviar el vale Kerberos del usuario a otro sistema como si el usuario estuviera accediendo directamente a ese otro sistema. Con la introducción de AD en 2000, sólo era posible configurar la delegación Kerberos de forma "ilimitada", lo que significaba que la aplicación podía transmitir el vale Kerberos del usuario a cualquier otro sistema.
Hoy en día, esto ha quedado obsoleto por formas mucho más seguras y fluidas de compartir datos. Pero la configuración de delegación no restringida sigue prevaleciendo en un número significativo de sistemas, a menudo porque el impacto potencial no es comprendido por los operadores de AD o los propietarios del objeto de servidor específico elegido para ser configurado de esta manera. Los hackers de hoy en día pueden utilizar esto para hacerse pasar por cualquier usuario de AD en cualquier otra máquina. Combine esto con el conocimiento de que un hacker puede usar cualquier cuenta AD sin privilegios para leer casi todos los atributos y objetos en AD, incluyendo sus permisos, permitiéndole encontrar cuentas de equipo en cualquier dominio de un bosque AD que estén configuradas con delegación sin restricciones, y tendrá una idea de por qué la apertura por defecto de AD se ha convertido en una vulnerabilidad.
En el peor de los casos, el intruso podría acceder a dicho sistema y, además, descubrir que sus controladores de dominio aún tienen el servicio de impresora (spooler) en ejecución. El servicio de impresora está siempre activado por defecto en cualquier servidor Windows;los administradores de TI deberían desactivarlo en cualquier servidor que no lo necesite, pero muchos no lo hacen. En nuestro escenario, un hacker puede entonces invocar un controlador de dominio para autenticarse en el ordenador con la delegación no restringida y utilizar el llamado bug de la impresora para invocar una petición de autenticación desde el controlador de dominio al ordenador capturado. Aunque no hay nada que imprimir, a través de este proceso un actor de amenaza puede asegurar el ticket Kerberos de un controlador de dominio y así habrá comprometido su dominio y bosque AD.
La delegación restringida es un poco más segura, pero sigue siendo atacable.
Oportunidad para los actores de amenazas
Hay más ejemplos de cómo el perro de tres cabezas ha perdido parte de su fuerza protectora con el paso del tiempo. Cada vez se han encontrado y documentado públicamente más vectores de ataque contra él, lo que ha permitido a los ciberdelincuentes utilizarlos durante su ruta de ataque contra AD.
Otro buen ejemplo proviene de los nombres principales de servicio (SPN), que es la forma en que un cliente Kerberos identifica de forma única una instancia de un servicio para un equipo de destino Kerberos determinado (por ejemplo, una base de datos SQL) y también ayuda a localizar la cuenta de servicio relacionada (por ejemplo, la cuenta de servicio SQL), que es utilizada por el propio servicio para autenticarse en AD.
Este mecanismo permite a los usuarios aprovechar Kerberos para la autenticación en una base de datos SQL en lugar de autenticarse con el protocolo NTLM, menos seguro, y se ha convertido en el estándar para integrar la autenticación AD en implementaciones SQL en la mayoría de las empresas. El inconveniente es que los investigadores de seguridad han descubierto que los propios SPN son fácilmente atacables a través de la información que transmiten durante la autenticación Kerberos al servicio -en concreto, el hash de la contraseña de la propia cuenta de servicio-, incluso si el solicitante no procede a autenticarse en el servicio.
Ese hash está ahora sujeto a intentos de descifrado fuera de línea, en los que una variedad de herramientas disponibles públicamente, como John the Ripper, están encantadas de ayudar.
Debido a la apertura de AD, un intruso es fácilmente capaz de encontrar SPNs privilegiados en el entorno (piense en un SPN unido a una cuenta de administrador de dominio), creando otro vector de ataque fácil capaz de ser manipulado para proporcionar altos privilegios y visibilidad completa. Esta combinación de control y visibilidad puede ser increíblemente peligrosa. Cuando tienes los permisos más altos, tienes el control total y puedes derribar una empresa y pedir un rescate.
Pero también puedes usarlo para reconocimiento previo a esto. "¿Cuáles son las cuentas privilegiadas? ¿Cuáles son las vulnerabilidades que puedo atacar?". Para los actores de amenazas, Active Directory actúa como un mapa, destacando los puntos débiles del entorno. Una vez en su red, un hacker utilizará AD para buscar y atacar sus datos importantes, extraerlos, cifrarlos y pedirle un rescate. Y muchas empresas simplemente no están preparadas para tal eventualidad. Esto crea un conflicto. ¿Dispone de copias de seguridad adecuadas para recuperar toda su empresa -incluido su Directorio Activo- rápidamente sin tener que pagar un rescate?
Para muchos, la respuesta es no: se ven obligados a pagar el rescate y los piratas informáticos pasan a otro objetivo igualmente desprevenido, creando un círculo vicioso.
El ejemplo de SolarWinds
Entonces, ¿con qué frecuencia se aprovecha AD de esta forma por parte de los actores de amenazas? La brecha de SolarWinds, también conocida como Solorigate, es uno de los ejemplos recientes más tristemente célebres, en el que AD desempeñó un papel decisivo en un ataque a gran escala a la cadena de suministro que afectó a decenas de miles de organizaciones de alto nivel, incluidos organismos gubernamentales estadounidenses. La propia SolarWinds es uno de los principales proveedores mundiales de soluciones informáticas, y su herramienta de gestión de redes Orion es uno de los principales programas informáticos que estas organizaciones utilizaban para asegurar, mantener y proteger sus propias redes. En el ataque a SolarWinds, los piratas informáticos consiguieron inyectar un troyano en el software Orion, que se propagó a través de un mecanismo de descarga periódica instalado por los clientes de la empresa. Iniciado en marzo de 2020, este ataque patrocinado por el Estado y su troyano no se descubrieron hasta diciembre de ese año.
Fue un ataque altamente malicioso que afectó a innumerables empresas de la lista Fortune 500 y a organismos gubernamentales de vital importancia en Estados Unidos. Pero, ¿cómo se permitió un ataque tan potente a la cadena de suministro? Aquí es donde entran en juego las filtraciones AD y on-premise.
SolarWinds había configurado un servicio de federación entre sus propios servicios de directorio locales y la nube, donde gestionaba su código de software Orion. En una configuración de este tipo, la nube confía plenamente en el servicio de federación para probar correctamente la identidad de un usuario, lo que le permite iniciar sesión con su identidad local, a menudo junto con una solución de autenticación multifactor (MFA) de terceros.
Al iniciar sesión de esta forma y recibir un token de federación debidamente firmado, su proveedor de la nube confía en usted para la autenticación y, a continuación, autorizará a los usuarios autenticados proporcionándoles acceso a los recursos de la nube solicitados.
En el caso del ataque a SolarWinds, los intrusos pudieron utilizar esta federación en su beneficio para acceder sigilosamente al código fuente de Orion alojado en la nube mediante el robo del certificado de firma de tokens. Fue el primer ataque de este tipo del que se tiene constancia que utilizó un lenguaje de marcado de acceso seguro dorado (SAML). La federación se produce a través de protocolos como SAML, utilizado para pasar un token de seguridad a la parte que confía. Pero, ¿cómo consiguió el intruso este certificado de firma de token?
Volvemos al punto en el que se produjo la brecha: el certificado de firma del token estaba protegido por la cuenta de servicio para los servicios de federación de AD, que está alojada como cualquier otra cuenta en el AD local. Una vez que los actores de la amenaza obtuvieron acceso al AD local y a la cuenta de servicio ADFS, pudieron leer el certificado y utilizarlo para crear su propio token SAML y obtener acceso a los recursos en la nube de SolarWinds. Como resultado, la cadena de acontecimientos muestra que la seguridad de Active Directory fue uno de los puntos débiles clave en la ruta de ataque de esta importante brecha.
De hecho, es un ejemplo paradigmático de una empresa que creyó que sus sistemas en la nube eran seguros cuando no lo eran, debido a AD y a su confianza en las instalaciones. Aunque la nube estaba separada, la confianza entre los vulnerables sistemas locales y la nube proporcionaba acceso a la red, creando un puente que los actores de la amenaza podían utilizar para inmiscuirse en los recursos en la nube de la empresa.
Afrontar los retos
Desde el punto de vista de la seguridad, AD es la fuente de muchos quebraderos de cabeza. Microsoft no ha invertido en una actualización relacionada con la seguridad para AD desde 2016, a pesar de que este sistema de identidad principal sigue siendo utilizado por el 90% de las empresas en la actualidad.
La solución más fácil sería erradicar AD, pero eso no va a ocurrir. Es una solución heredada, pero no va a desaparecer a corto plazo con tantas empresas y cientos de miles de aplicaciones de línea de negocio que todavía dependen de la tecnología. Dicho esto, no es una causa perdida y las empresas pueden tomar medidas para protegerse.
De hecho, se trata de un proceso: la aplicación de protocolos de protección adecuados, empezando por el reconocimiento y la comprensión de las vulnerabilidades potenciales. Lleva a cabo una lluvia de ideas y pregúntate: "¿Qué pasaría si los sistemas críticos se cayeran?".
Las empresas pueden hacer frente a las interrupciones funcionando con centros de datos duales, o con una solución híbrida de centro de datos y nube, pero deben ir más allá y considerar lo que podría ocurrir si un sistema crítico como la gestión de identidades se viera comprometido. Tómese el tiempo necesario para comprender las dependencias de todas sus aplicaciones empresariales. Y explore las dependencias entre su proceso de autenticación y la nube. Con un sistema de autenticación basado en la federación, podría acabar en problemas muy rápidamente.
Una vez que haya comprendido estas dependencias, podrá empezar a identificar, comprender y priorizar qué vulnerabilidades debe abordar. Debe ser un proceso holístico que no deje piedra sin remover en el camino para lograr una preparación completa. Si un barco tiene fugas y no se dispone del equipo necesario para repararlas, el barco se hundirá. Del mismo modo, si sólo se detecta uno de los múltiples agujeros que tienen fugas, el barco se hundirá igualmente.
Es vital que una empresa comprenda exhaustivamente todas las vulnerabilidades potenciales para abordarlas y prepararse según sea necesario. Por lo menos, el ataque de SolarWinds sirve como una importante curva de aprendizaje, demostrando los efectos catastróficos que podrían ocurrir cuando se produce un ataque basado en AD. Dado el creciente y cada vez más complejo entorno de amenazas, nunca ha sido tan importante como ahora abordar las vulnerabilidades basadas en AD.
