lunes, mayo 14, 2012

RootDSE: SupportedSASLMechanisms

Uno de los temas que se tocan en el libro de Ataques en Redes de Datos IPv4 e IPv6 es la de realizar un man in the middle a una conexión LDAP, y robar las credenciales del usuario en el proceso de Binding. Para ello, como está publicado en el artículo de Ataques LDAP, es fundamental conocer qué protocolos de autenticación y qué medidas de seguridad exiten durante el proceso de un autenticación con credenciales.

Es por ello que si quieres hacer un ataque man in the middle a un árbol LDAP se debe conocer esa información. Para ello, si el árbol LDAP permite la conexión anónima, como en el caso de la Nasa o Debian, se puede echar un vistazo al elemento RootDSE, en lugar de conectarse a cualquier otro nodo del árbol.

Figura 1: Conexión a RootDSE en Debian

En el nodo RootDSE se encuentran los protocolos de autenticación SASL y los protocolos de cifrado soportados. Para verlos, hay que configurar en la herramienta de conexión que se esté utilizando que se visualicen todos los atributos, incluidos los que se crean por mantenimiento y operación.

Figura 2: Para ver todos los atributos del árbol

Así, por ejemplo, los protocolos que soporta el árbol LDAP de Debian se pueden ver en los atributos supportedSASLMechanisms son los siguientes:

Figura 3: Protocolos de autenticación soportados en el árbol Debian

Por lo que hay que extremar la complejidad de las contraseñas que se usan y las redes utilizadas en la conexión, ya que para ellos existen técnicas para hacer un ataque man in the middle con éxito. En el caso de la Nasa, la información que se puede obtener es la siguiente.

Figura 4: Protocolos de autenticación soportados en el árbol de la Nasa

Y en cuanto a los protocolos de cifrado se pueden ver en supportedSSLCiphers, se soportan tanto robustos, como no robustos, lo que no sería lo recomendable en una instalación fortificada.

Figura 5: Sistemas de cifrado soportados en el árbol LDAP de la Nasa

Analizando la información en servidores LDAP que permiten conexiones anónimas se pueden encontrar algunos árboles con protocolos de autenticación inseguras, como GSSAPI y SIMPLE, que permiten, negociar en determinados entornos el envío de la contraseña en texto plano.

Figura 6: Un árbol LDAP basado en Novell

Esto es permitido, por ejemplo, en los servidores Windows Server 2003 con Active Directory, ya que permiten por medio de GSSAPI negociar la autenticación SIMPLE.

Figura 7: Password de conexión LDAP enviada en texto plano

Esto hace que, como se ve en el libro de Ataques en redes de datos, la password sea capturada en texto plano en cualquier conexión de una aplicación LDAP que pase por la red atacada.

Saludos Malignos!

6 comentarios:

Anónimo dijo...

La verdad es que por ahora no veo dónde está el problema, además creo que es a propósito así en LDAP.

Saber qué protocolos se permite, bueno, pues no es tan difícil imaginárselo, no hay tantos para usar con LDAP.

En el caso concreto de Debian, que lo normal es usar la librería SASL, pues vaya, es sota, caballo o rey, no hay de dónde sacar más.

Vamos, que no es necesario conocer esa información, si eres capaz de snifar, ya ves si va cifrado o no o si usa Kerberos o lo que sea, por eso no creo que conocer ese nodo y que sea público aporte nada. Lo que puede haber ahí es obvio, que sea público no implica ninguna amenza.

El problema sería que permitieras protocolos planos sin usar TLS. Pero eso es como todo lo demás, si usas una autenticación básica en un servidor WEB y no le metes SSL, pues es que ya sabes qué consecuencias puedes tener.

Además creo recordar que que el RootDSE sea público es bueno y debe ser así, porque así hay clientes que pueden leerlo y saber qué protocolos pueden o deben usar y qué está disponible. Vamos, que es una característica disponible para los clientes.

Esto es como cuando te conectas a un servidor de correo y le preguntas qué protocolos están disponibles.

Chema Alonso dijo...

@Anonimo, un servidor de correo de envío de correo electrónico también debe estar protegido siempre que sea posible para evitar eso. Solo deberían verse lo protocolos cuando no se pueda poner de otra forma. Es por ello que las empresas, para conectarse al servidor de correo saliente exigen un VPN o un RPC/HTTPS para luego autenticar la cuenta y enviar los correos.

Cualquier información que se de antes es mala. En el caso de Debian, por poner un ejemplo, no solo se ven los protocolos que ayudarían a preparar un ataque en cualquiera de las redes en las que se esté conectando un usuario del árbol LDAP de Debian, sino que además se pueden ver datos de usuarios de administración (viendo los atributos operacionales).

De todas formas, es una cuestión de opiniones, si a ti te parece bien así, pues que sea bien.

Yo, si no es absolutamente necesario no lo pondría jamás así.

Saludos!

Inma dijo...

Hola Chema
Gracias por las explicaciones, pero sigo pensando igual que @anónimo, que el rootDSE solo da información a los clientes sobre la versión del protocolo, el contexto principal, los mecanismos de autenticación y que controles y extensiones están disponibles en el servidor, información necesaria para que clientes como este tuyo de softerra pueda conectarse y tomar ciertas decisiones. De hecho la primera regla de control que se suele sugerir es
access to dn.exact="" by * read
Precisamente para dar acceso al rootDSE. Y tu propones justo lo contrario, no?

A muchas MTAs también puedes conectarte directamente a través de SMTPs y después del hello te suelta toda la información sobre que métodos de autenticación soporta, antes de autenticarte.

He comprado vuestro libro de Ataques en redes de datos, aún no lo he leído, cuando vea esta parte puede que tenga que darte la razón, :) ya te contare.
Si estoy de acuerdo contigo en no exponer un directorio... pero eso ya depende de la funcionalidad que se busque.

Anónimo dijo...

Sigues sin entender la idea.

La infraestructura de Debian es muy descentralizada. Muchas de las máquinas que se usan no son de Debian, sino de empresas que donan ciclos de CPU en ratos idle.

Para tener una autenticación centralizada necesitamos que sea abierta.

Que sí, que puede que nos comprometan (http://lists.debian.org/debian-announce/2003/msg00001.html), no hay duda. Pero es un riesgo que se corre para ser funcionales. De ahí a estar "abierto de patas" hay un largo trecho.

Cuando encuentres algo que contradiga http://db.debian.org/doc-direct.html , vuelve a hacer sonar la campana... :) si?

Chema Alonso dijo...

@Luciano, como ya te conté por Twitter, es vuestra decisión. Este post no es de Debian, sobre de LDAP - Debian es un ejemplo más. Para vuestras necesidades te recomiendo las VPNs y los sistemas federados.

}:))

Saluods!

jnahuelperez dijo...

Muy buena entrada. Pues creo que ya son 3 los librecos que tengo en mente...sera hora de pagar los gastos de envio nomas? no puedo esperarte hasta septiembre Chema!

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares