Microsoft declara oficialmente obsoleto el protocolo de autenticación NTLM en Windows

Hace unos días, Microsoft anunció que finalmente optará por “deprecar” NTLM. Aunque esto pueda parecer un cambio drástico en la postura de Windows y su conocida retro-compatibilidad, lo cierto es que se trataba de “una muerte anunciada”. Este cambio era previsible, y tanto Microsoft como sus empleados lo han estado manifestando desde octubre de 2023 a través de diferentes medios. 

Figura 1: Microsoft declara oficialmente obsoleto el protocolo

de autenticación NTLM en Windows

Podemos verlo en esta charla de Steve Syfuhs, Principal Engineer en Microsoft, y también en este post del blog de Microsoft escrito por Matthew Palko, donde ambos hablan de la evolución de la autenticación en Windows y cómo NTLM está quedando relegado por Kerberos. NTLM siempre ha sido uno de los grandes problemas de seguridad que obliga a tomar medidas de fortificación en Windows para evitar riesgos.

Figura 2: "Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición"

de Sergio de los Santos en 0xWord.

Sin embargo, no ha sido hasta ahora, el 11 junio de 2024, que Microsoft, en su lista de funcionalidades “deprecated” para Windows ha anunciado oficialmente la desaparición y “deprecación” del mítico protocolo de autenticación NTLM, que será oficialmente reemplazado por Kerberos siempre que sea posible. Esto significa, que Microsoft dejará de mantener de forma activa este protocolo y priorizará el soporte de otros como Kerberos.

Figura 3: Anuncio de que NTLM está en la lista de

funciones deprecadas en Windows

Si bien en el anuncio se comenta que seguirá funcionando en la próxima versión de Windows Server y en la próxima versión anual de Windows, es cierto que todas las llamadas a NTLM deberían intentar autenticarse haciendo uso de Kerberos, de esta forma solo se recurriría a NTLM en los casos que sea estrictamente necesario.

Funcionamiento y Riesgos de NTLM

Ya sabéis que NTLM, tuvo un predecesor (y también unos cuantos sucesores o alternativas), todos conoceréis LM o LAN Manager. Este protocolo que nació en 1987 cuando Microsoft, junto con IBM, desarrollaban un sistema operativo de redes, el denominado OS/2. No tardaron en mostrarse al mundo las vulnerabilidades inherentes del algoritmo de hash LM. 

Para crear estos hashes, comenzamos con la primera de las restricciones, contraseñas de un máximo de 14 caracteres. Luego, a pesar de permitir introducir mayúsculas y minúsculas, todas las letras se convertían a mayúsculas, por lo que el conjunto de caracteres se reducía a la mitad, y contraseñas como “HaCkEr” o “hacker” generaban el mismo hash. 

Por último, y para más “inri”, se generaban dos hashes concatenados al segmentar la contraseña de 14 caracteres en dos de 7 caracteres cada una. El resultado, cómo podéis imaginar, todo un protocolo digno de aplicar un ataque de fuerza bruta. En la siguiente imagen os dejo una explicación básica de este algoritmo:

Figura 4: Funcionamiento del Hash LM

Microsoft tenía que hacer algo, y nació NTLM (New Technology LAN Manager), el protocolo de autenticación sucesor de LAN Manager. Este protocolo, que apareció por primera vez en 1993 junto a Windows NT 3.1, utiliza un mecanismo de desafío-respuesta para autenticar a un cliente en un servidor mediante una contraseña. El flujo de funcionamiento de NTLM es el siguiente:

1) El cliente comienza una negociación con un servidor y envía un NEGOTIATE_MESSAGE anunciando sus capacidades y características de seguridad soportadas. 

 

2) Una vez negociados los detalles de la comunicación (por ejemplo, la versión de LDAP a utilizar), el servidor responde con un CHALLENGE_MESSAGE, que incluye un nonce (un número aleatorio) que el cliente tendrá que cifrar con el hash de su contraseña (que debe ser igual al hash NTLM guardado en la SAM). Este nonce es de 8 bytes en NTLMv1 y de 16 bytes en NTLMv2. 

 

3) Tras esto, el cliente responde con un AUTHENTICATE_MESSAGE, que contiene el nonce cifrado con el hash NT de la contraseña del usuario, junto con otros datos de autenticación.

• En el caso de un entorno de Active Directory, el servidor envía el desafío y la respuesta enviada por el cliente al controlador de dominio para que este verifique su validez.
• El controlador de dominio verifica la respuesta y envía la confirmación de autenticación al servidor.

4) Finalmente, si la verificación enviada por el controlador de dominio es correcta, el servidor validará correctamente al usuario o, por el contrario, devolverá un error.

Figura 5: Flujo de autenticación NTLM

Como se puede comprobar, en este proceso de autenticación NTLM no se ha utilizado en ningún momento la contraseña del usuario de manera directa, sino que se emplea para crear su hash NTLM, hash que está almacenado en la SAM (Security Account Manager) del equipo. Debido a la ausencia de “salting” y que el hash NTLM y la contraseña son equivalentes a nivel de secreto en el protocolo NTLM, el conocido ataque PassTheHash tiene sentido. En este tipo de ataque, un atacante que ha obtenido el hash NTLM de un usuario puede autenticarse como ese usuario sin necesidad de conocer su contraseña en texto plano.

Figura 6: Hacking Windows: Ataques a sistemas y redes Microsoft 2ª Edición

escrito por Carlos García, Valentín Martín y Pablo González en 0xWord.

Por último, comentar acerca del sucesor definitivo de NTLM, Kerberos, un protocolo de autenticación creado por el MIT en 1989, de código abierto y mantenido por una gran comunidad, entre la cual se encuentra Microsoft que desarrolla su propia versión (compatible en gran medida con la “oficial”).

Kerberos, deja atrás el método de desafío-respuesta propio del protocolo de autenticación NTLM y pasa a utilizar un sistema de tickets para autenticar a los usuarios. En Kerberos encontramos componentes claves como el centro de distribución de claves (KDC), el servidor de autenticación (AS), el servidor de concesión de tickets (TGS), … Todo esto, da para verlo con más detalle en otro post.

Figura 7: Misión de Kerberos.org

La misión de Kerberos es establecerse como la plataforma universal de autenticación en todas las redes del mundo, así lo comentan kerberos.org. Actualmente, Kerberos es el protocolo de autenticación principal por defecto, mientras que NTLM interviene en circunstancias específicas. Por ejemplo, se utiliza NTLM cuando se autentica a través de sistemas configurados en un grupo de trabajo en lugar de un dominio, en la autenticación local en controladores que no forman parte de un dominio o en aplicaciones que no soportan otros tipos de protocolos.

Tú mismo puedes hacer uso de un Fiddler (un proxy que registra todo el tráfico HTTP/HTTPS entre el equipo e Internet) para recopilar todas las peticiones realizadas, y mediante la observación de las cabeceras, detectar en qué casos se está usando Kerberos o NTLM. En una cabecera de autorización, si el token comienza por “YII” estaremos ante un caso donde se está utilizando Kerberos. Si, por el contrario, comienza por “TlR” estaremos ante un protocolo de autenticación distinto a Kerberos (normalmente NTLM). Por ejemplo:

• Cabecera de autenticación de Kerberos:
• Authorization: Negotiate YIIVDAYGKwYBE...

• Cabecera de autenticación no perteneciente a Kerberos:
• Authorization: Negotiate TlRMTVNTUA...

Volviendo a la noticia, con este anuncio, Microsoft se ha comprometido a trabajar para eliminar y mitigar todos estos escenarios que hacen uso de NTLM en componentes de Windows, y en el momento que lo vean oportuno lo deshabilitaran por completo. Este movimiento ha provocado toda una ola de reacciones entre los usuarios. Algunos elogian este cambio, otros se preguntan por qué ahora y no hace 20 años, y otros defienden el uso de NTLM, criticando la falta de retro-compatibilidad que esta modificación implicará para los equipos más antiguos.

Figura 8: Libro de Ethical Hacking 2ª Edición  de 0xWord
escrito por Pablo González Pérez

Ahora toca esperar y ver cómo Microsoft sigue moviendo ficha hasta que veamos por completo la eliminación de NTLM. No obstante, es un cambio positivo ya que pasamos de utilizar un protocolo de autenticación donde el conocimiento del hash del usuario rompe por completo la seguridad; a utilizar por defecto un protocolo más seguro como es Kerberos. Y para los Ethical Hacking, pues a ponerse las pilas con Pass-the-ticket.

Saludos,

Autor: Javier Álvarez Páramo (Investigador en el IdeasLocas)

Contactar con Javier Álvarez Páramo

Unos consejos para fortificar MongoDB en el mundo NoSQL

Conocí el mundo de los NoSQL allá por el año 2013 cuando comenzamos con ElevenPaths a construir nuevas tecnologías. Teníamos muchos retos tecnológicos por completar ante nosotros. Fue una etapa en la que aprendimos mucho ante todos los cambios y avances en tecnología que aparecían ante nosotros. Hay algo que nos enseñaban cuando estudiábamos en la carrera y es que un Ingeniero debe buscar soluciones, es decir, analizar el problema, analizar una posible solución, diseñar, implementar, etcétera.

Figura 1: Unos consejos para fortificar MongoDB en el mundo NoSQL

A uno de esos problemas de aquella época le dimos solución basándonos en un tipo de bases de datos no relacionales llamas "Not Only SQL"  o NoSQL. Hoy me quiero centrar en una de esas NoSQL, en MongoDB. Es, por mérito propio uno de los motores de base de datos no relacional más utilizados hoy en día. En su día sacamos alguna noticia sobre MongoDB dónde su seguridad no quedaba bien parada, pero quizá no sea la seguridad que MongoDB puede aportar, si no la configuración que le apliquemos. Es decir, no es problema del producto y sí de la configuración que el administrador ejecute, con el caso de estos artículos del blog:

• Big Data Security Tales: MongoDB & Cassandra Level 101
• Vigila que tu MongoDB no le de los datos a cualquiera

El caso de MacKeeper fue recordado por los 13 millones de usuarios filtrados y los 21 GB de información sensible. Algunos echaron la culpa al producto, pero realmente y clarísimamente, fue una mala configuración. No es el único caso en el que este tipo de soluciones se han visto involucradas, por ejemplo, y más recientemente, tenemos el caso de las miles de apps de iOS que filtraron datos en Firebase, pero no solo en Firebase, en el listado aparece MongoDB también.

Figura 2: El caso de MacKeeper y los datos filtrados

En el artículo de hoy vamos a hablar de cómo fortificar MongoDB. La gente de MongoDB pone a disposición de sus usuarios / administradores una serie de “tips”. En muchos casos, hay cosas “obvias”, por ejemplo, que la conexión vaya cifrada entre la aplicación y la base de datos. De esto ya hemos hablado en el pasado con los ataques Network Packet Manipulation.

Figura 3: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

Sea como sea, siempre viene bien tener un listado de “tips” o una “checklist” dónde verificar algunas de las cosas que debemos configurar sí o sí en una base de datos, en este caso, no relacional como puede ser MongoDB.

Habilitar el control de acceso y configurar RBAC

Para que no ocurra como en los ejemplos anteriores de filtrado de información, es muy importante habilitar el control de acceso. Como hemos visto, si tu MongoDB da soporte a una aplicación web o un servicio expuesto en la red, es una de las primeras cosas que van a buscarse en un Hacking de Web Technologies. Los motores NoSQL con acceso anónimo son objetivo de pentesters y atacantes peor intencionados. Para ello, se puede utilizar un mecanismo de autenticación SCAM o x509 que trae el propio MongoDB. Además, se puede integrar con Kerberos o LDAP. 

Otra recomendación sería crear primero un administrador de usuarios y luego ir creando los usuarios necesarios. Es importante, crear un usuario por cada aplicación o persona que requiere acceder al sistema. Como define una de las mínimas de la seguridad informática, debemos seguir el principio del menor privilegio. Es decir, vamos a crear roles que definan derechos de acceso para un conjunto de usuarios.  

Figura 4: Hacking Web Technologies 2ª Edición

De esta forma, podemos crear usuarios y asignarlos solo a los grupos/roles que ellos necesiten para poder ejecutar sus tareas u operaciones. Cuando hablamos de usuarios, hay que tener en cuenta que muchas veces son las propias aplicaciones que requieren conectarse contra la base de datos.

Ya hemos comentado sobre RBAC de forma implícita, pero por si acaso, decir que RBAC es un control de acceso basado en roles (Role Based Access Control). Es decir, consiste en asignar derechos de acceso, como comenté antes, a los usuarios en función de los roles y las operaciones o tareas que tienen que realizar.  Para habilitar la autenticación, simplemente debemos cambiar la directiva “auth” o habilitar a true en el fichero de configuración /etc/mongodb.conf.

Figura 5: Configurando /etc/mongodb.conf

El resultado es que cuando queremos conectarnos con MongoDB a la base de datos que hayamos creado pues nos solicitarán credenciales. Puedes ver más sobre la creación de usuarios en la documentación oficial de MongoDB.

Figura 6: Conectándonos con nuestro usuario a MongoDB

Esto es algo muy básico, pero que como hemos visto pues no es algo que siempre se configure. Importante, antes de habilitar la autenticación hay que tener en cuenta el crear usuarios. Eso se hace con la función db.createUser y un documento JSON con el siguiente formato:

{

user: “pablo”,

pwd: “xxx”,

roles: [“dbOwner”] #si queremos que sea el propietario

}

MongoDB tiene lo que se llama “Collection-level access control” y permite hacer un permiso muy específico sobre las colecciones de datos. Es decir, puedes indicar qué tipo de acción puede hacer un rol sobre una colección de datos. Hay que recordar que una colección de datos está dentro de una base de datos. Sería como las tablas en el mundo SQL.

Cifrar comunicaciones con TLS/SSL y cifrar y proteger datos almacenados

El cifrado es clave tanto en lo que a la comunicación entre el cliente y el servidor como en el almacenamiento de los datos. Ya hemos comentado lo que son los ataques de Network Packet Manipulation. Además, Wireshark da soporte para mostrar los paquetes de MongoDB y diseccionarlo de forma sencilla. En otras palabras, si alguien se pone en medio de la comunicación entre la aplicación y el servidor de MongoDB toda la información que viaje entre ambos nodos quedará expuesta.

Figura 7: Paquetes MongoDB en WireShark

Explicar el proceso para proteger la comunicación entre cliente y servidor daría para uno o dos posts, por lo que os dejo el enlace a dicha información y se puede configurar de manera sencilla. Hay que tener en cuenta que habrá que configurar tanto servidor como cliente. 

Encypted at Rest: Almacenamiento seguro de la información  

Ahora, hablemos de la protección de la información en el interior de la base de datos. Cuando se crea un usuario, se nos indica en la documentación que la contraseña no se almacena en texto plano, como era de esperar. MongoDB dispone de una “feature” importante que es el motor de almacenamiento cifrado o “Encrypted Storage Engine”. Esta “feature” solo está disponible en MongoDB 3.2 en adelante y en la versión Enterprise. 

Figura 8: Encryption at Rest y MongoDB

Si el cifrado está activo, MongoDB Enterprise utiliza AES256-CBC a través del uso de OpenSSL. Se utiliza la misma clave para cifrar que para descifrar. MongoDB también soporta un cifrado en modo FIPS y AES con el modo Galois/Counter Mode.  Cuando se habilita este cifrado, el proceso incluye las siguientes acciones:

• Generación de una clave maestra y la generación de claves para cada base de datos. Es decir, que cada base de datos estará cifrada con una clave diferente. Esto es algo lógico.

• Cifrar los datos de cada base de datos con las claves generadas previamente para cada base de datos. También se cifrarán las claves de la base de datos con la clave maestra.

• El cifrado es llevado a cabo de forma transparente. Este cifrado se lleva a cabo en todo el almacenamiento, es decir, los archivos que contienen los datos están completamente cifrados. Lo interesante es que los datos descifrados solo existirán en la memoria y nunca en el disco, donde siempre estarán cifrados.

Nota: Ya hemos hablado en este blog sobre ataques a procesos en memoria con el objetivo de sacar información.

Registros y auditoría de las acciones

La trazabilidad es una de las subdimensiones de la seguridad. Es algo importante y el tener un registro de actividad también lo es. Habilitar la auditoría en un MongoDB es algo vital y que permite conocer que está ocurriendo en tu base de datos. Cuando se habilita la auditoría se escriben eventos en la consola del propio MongoDB, en el Syslog o en archivos.

Figura 9: Configuración de Filtros de Auditoría en MongoDB

Se registran operaciones de autenticación, de acceso, de autorización, etcétera. Se puede configurar filtros para restringir eventos capturados. Esto se puede hacer a través de la configuración de los filtros de auditoría. En la auditoría se registran:

• Autenticación y cómo se dijo anteriormente, también la autorización.

• Operaciones del cluster de MongoDB.

• Operaciones de lectura y escritura.

• Operaciones con el esquema o DDL.

• Mensajes personalizados de aplicaciones.

Asegurar el entorno de MongoDB

Este paso es muy importante. De nada valdrá tener las mejores recomendaciones y consejos en el ámbito del hardening a MongoDB, si luego tenemos las capas inferiores desprotegidas. Imagínate que permitimos que cualquier usuario pueda acceder a este equipo físicamente y no ponemos barreras, ¿Serviría tener cifrado los datos en disco? Si no tiene un login de usuario, si no tiene un firewall que rebaje la exposición, si no hay unas barreras físicas que evitan que cualquiera pueda acceder a ese equipo físicamente, etcétera.

Figura 10: Auditando MongoDB con Tenable Nessus

En este caso las recomendaciones van por la parte del firewall, pero no hay que quedarse solo con eso. Si vemos el modelo defensa en profundidad, la seguridad va en armonía con todas las capas. No vale fortificar mucho una capa, si luego por debajo, la base, no se sostiene.  Hay un artículo interesante de la gente de Tenable en la que hablan sobre la auditoría a MongoDB con Nessus.

Ejecuta MongoDB con opciones de seguridad habilitadas

Este apartado habla sobre la necesidad de ejecutar MongoDB con un usuario dedicado en el sistema. De forma que si es comprometida, no haya mucho que se pueda hacer hasta que haya una escalada de privilegio en el sistema. Además, hay una serie de opciones de seguridad que se pueden trabajar desde el principio y que ayudan a tener un entorno más seguro dentro de MongoDB. Seguramente, a estos consejos o recomendaciones se pueden añadir más y entrarían en opciones de seguridad habilitadas desde el principio.

• Deshabilitar la escritura side-server: MongoDB soporta la ejecución de código Javascript. Para llevar a cabo la mitigación de una posible vulnerabilidad a nivel de aplicación, es recomendable deshabilitar el código del lado del servidor. Esto se puede deshabilitar en el archivo de configuración con la directiva noscripting = false.

• Deshabilitar la interfaz de estado: ¿Qué es la interfaz de estado? Esto es un servidor HTTP que expone un sitio web el cual contiene estadísticas e información que pueden ser de interés para un administrador del sistema, pero también para un atacante. En el archivo de configuración se puede deshabilitar esta opción con la directiva nohttpinterface = true.

• Desactivar la interfaz REST: Es una interfaz administrativa que es interactiva, la cual se encuentra desactivada por defecto. Esta interfaz no tiene soporte para autenticación y se debe restringir el acceso a dicha interfaz, por ejemplo, por dirección IP o mediante interfaz de loopback. Para deshabilitar esta interfaz en el fichero de configuración debemos verificar rest = false.

• Limitar la exposición en la red: Limitar la exposición de direcciones IP de un servidor o de interfaces de red es importante. La opción bind_ip indica la interfaz de red por la que se escucharán peticiones en la base de datos. Esto ya depende de cada uno y sus necesidades. Se puede utilizar la directiva bind_ip para limitar la accesibilidad a la red de un programa MongoDB. También se puede jugar con un firewall y dejar pasar el tráfico que provenga de la dirección IP dónde se encuentra la aplicación. En el fichero de configuración se configura esta opción con la directiva bind_ip = [dirección IP de la interfaz que queremos].

Estos son algunos tips para mejorar la seguridad de una basa de datos MongoDB. Por supuesto, hay más cosas que se pueden hacer, pero con estas estamos mejorando bastante la seguridad de MongoDB. Es importante alinear los esfuerzos con el resto de capas, tal y como se indica en el modelo defensa en profundidad.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 11: Contactar con Pablo González

Nuevo libro de "Hacking Windows: Ataques a Sitemas y Redes Microsoft " en @0xWord

Hoy viernes toca hablar de una novedad en nuestra pequeña editorial 0xWord, donde hemos trabajado para tener el nuevo título disponible para la vuelta al cole. El objetivo era llegar a tiempo para la Navaja Negra, y ahora ya está también disponible a la venta en la tienda de 0xWord.

Figura 1: Nuevo libro de "Hacking Windows: Ataques a Sitemas y Redes Microsoft " en @0xWord

Es un libro completamente nuevo y se ha llamado "Hacking Windows: Ataques a sistemas y redes Microsoft". En éste título, escrito por Valentín Martín, Carlos García García y Pablo González, se recogen algunos de los ataques más comunes a estos sistemas que van desde Pass-the-Hash o Pass-the-ticket, a los ataques a las credenciales, los clásicos Man in the Middle o los bypass de UAC para conseguir elevación de privilegios. 

Figura 2: Hacking Windows: "Ataques a sistemas y redes Microsoft"

Este libro es un complemento ideal si ya te has leído Máxima Seguridad en Windows, Pentesting con PowerShell y Metasploit para pentesters porque te ayudará a sacar el máximo partido de todas las técnicas que conocías con un objetivo claro: Hacking Windows. Para que tengáis más detalles del contenido del libro os he dejado aquí el índice completo, para que veáis qué temas se cubren en él a lo largo de los distintos capítulos que conforman este texto.

Figura 3: Índice libro "Hacking Windows: Ataques a redes y sistemas Microsoft"

EL ejemplar ya está disponible a la venta, está en la Navaja Negra, y estará en los próximos eventos en los que participará 0xWord, y de los que os iremos avisando por la cuenta de Twitter (@0xWord). Ah, por supuesto, la portada es otra obra de arte de coleccionista hecha por Rodol. 

Saludos Malignos!

Los registros de servicios

Como en los últimos años me toca "torturar" a mis alumnos de los masters con algún trabajo que los vuelva locos. En este caso tengo a un grupo de tres sufriendo para generar una base de datos de registros en servidores DNS predecibles que permitan estrujar un servidor en un proceso de auditoría para pintar el mapa de red. La idea es poder incorporar toda esa base de datos a la FOCA, para poder reconocer nuevos servidores y nuevos roles.

A los registros well-known que actualmente busca FOCA, es decir, NS, SOA (para sacar el primary.master), MX, SPF, version.bind y registros PTR, se pueden añadir, en primer lugar los registros de servicio que utilizan los dominios de Microsoft, luego esos que han utilizado en Microsoft para cosas particulares, como WINS o WPAD, y luego los que se han estandarizado para publicar los servicios proporcionados por organización y que permitan ser encontrados por protcolos de autodescubrimiento, tales como los servicios de VOIP, presencia o comunicaciones varias. Cuando esté el proyecto terminado y presentado, os pondré la lista final de todos los registros analizados.

Al final, si tienes catalogados qué aplicaciones o protocolos usan qué registros de servicios, basta con hacer consultas de tipo SRV y descubrir más información de la organización, algunos ejemplos:


Figura 1: Registros SIP en Adobe


Figura 2: Registros Kerberos en Debian


Figura 3: Registro Ldap en la Universidad de Michigan


Figura 4: Registros jabber en Google


Figura 5: Resgistros XMPP Server en Google


Figura 6: Registros SIP en Oracle


Figura 7: Registros SIP en CISCO
Interpretar los regisros SRV no es demasiado complicado, son unos puertos, prioridades y servidorers que ofrecen esos servicios. Datos jugosos, sin duda, para un pentesting.

Saludos Malignos!

Pass the Ticket: Kerberos authentication bypass POC

Las técnicas Man-In-The-Middle se están convirtiendo en las estrellas de este mundo hiper-mega-conectado. En este caso, la técnica Mitm se utiliza para realizar ataques a Kerberos en entornos de dominio Windows.

Kerberos es el mecanismo de autenticación y autorización utilizado en los dominios Micrososft Windows y se acaba de publicar un paper, con una prueba de concepto funcional, que demuestra como es posible realizar ataques MitM para acceder a recursos por parte de usuarios no autenticados.

En el 2008 Emmanuel Bouillón había alertado de la posibilidad de enlazar ataques de spoofing al KDC (Key Distribution Center), unidos a un ataque de Replay en un entorno de Man In The Middle para hacer esto.

La conferencia, bajo el título de "Gaining access through Kerberos" se presentó en la PacSec 2008. En BlackHat Europe de 2009 amplió el trabajo y presentó un paper en el que especificaba más todas las fases necesarias para implementar dicho ataque: "Taming the beast : Assess Kerberos-protected networks"

Ahora, desde Venezia, Italia, Tommaso Malgherini, como trabajo de su Thesis Doctoral "Pass The Ticket", ha realizado una implementación completa del ataque y ha sacado unas herramientas que permiten realizar un bypass de la autenticación en una red con Kerberos en cualquiera de sus versiones. En sus pruebas, se ha puesto en contacto con Microsoft que ha confirmado que solucionará este problema en el próximo service pack de los productos.

Las herramientas pueden ser descargadas desde la página del proyecto en http://secgroup.ext.dsi.unive.it/kerberos/. Estas herramientas y este ataque ha demostrado funcionar en entornos de Kerberos sobre Windows y no sobre Linux.

¿Y cómo arreglas esto si tienes un dominio Windows?

Este no es el primer ataque al protocolo kerberos que sufren las plataformas Microsoft Windows. De hecho, la popular herramienta Cain lleva un módulo para hacer romper las claves de los usuarios cuando se autentican por Kerberos en un entorno de Man In The Middle.

La solución que propone Microsoft, desde hace años, es utilizar IPSec en las máquinas del dominio. Si tienes instalado un Dominio Microsoft puedes utilizar IPSec en varias formas.

La más sencilla es utilizar IPSec sólo para cifrar y autenticar el tráfico Kerberos. De esta forma todo el tráfico que implique autorización y/o autenticación kerberos ira protegido contra ataques Man In The Middle.

Si quieres evitar cualquier tipo de ataque Man In The Middle en tu red, puedes utilizar IPsec para todos los protocolos. Aquí tienes un webcasts para usar IPSec para autenticar Kerberos en Windows Server 2003. Aquí tienes una guía sobre como aislar los dominios Windows 2008 escrito por nuestro compañero "Silverhack" y coomo evitar ataques MitM con IPSec y en Windows Técnico tienes como implantar IPSec punto a punto a través del Firewall avanzado.

Saludos Malignos!