¿Problemas de seguridad LDAP?

3

He instalado muchas redes basadas en Active Directory (AD) y he aplicado varias plantillas de seguridad estándar basadas en las mejores prácticas, sin embargo, nunca he visto LDAP a un nivel más profundo y después de leer recientemente sobre los problemas de LDAP OSX Lion (< a href="http://www.theregister.co.uk/2011/08/08/26/mac_osx_lion_security_hole/"> The Register y Slashdot ), estoy bastante preocupado y bastante preocupado.

He pasado un tiempo leyendo esto, pero sigo viendo informes conflictivos. ¿Hay alguna información sólida sobre con qué problema está realmente?

Además, siempre tuve la impresión de que con seguridad, tratas todo como el peor de los casos / infectado / lo que sea ... ¡culpable hasta que se demuestre lo contrario! Si esto es posible, seguramente es el servidor LDAP el responsable en lugar de solo el cliente.

    
pregunta wilhil 30.08.2011 - 20:22
fuente

2 respuestas

8

Habiendo cometido el mismo error hace un par de años:

La mayoría de los protocolos / software devolverán un código de error si intenta iniciar sesión con un nombre de usuario válido (que no sea "anónimo") y una contraseña vacía. Esto es cierto incluso para la mayoría de los sistemas que permiten algún tipo de uso anónimo sin iniciar sesión en absoluto.

Para LDAP, sin embargo, el caso común es que el servidor permite inicios de sesión con cualquier nombre de usuario y una contraseña vacía . El usuario terminará siendo anónimo. Pero el inicio de sesión devuelve un código de estado que indica el éxito.

RFC2829 dice:

  

Un cliente LDAP también PUEDE elegir enlazar explícitamente de forma anónima. Un cliente que desee hacerlo DEBE elegir la opción de autenticación simple en la solicitud de enlace (consulte la sección 4.1) y configurar la contraseña para que sea de longitud cero. (Esto lo hacen a menudo los clientes LDAPv2). Por lo general, el nombre también es de longitud cero.

Entonces, ahora imagine que el usuario no realiza el inicio de sesión directamente. Pero el usuario inicia sesión en otro software, y este software toma el nombre de usuario y la contraseña y realiza un inicio de sesión LDAP entre bastidores.

Si este software confía ciegamente en el resultado "exitoso" del servidor LDAP sin tener un manejo especial de casos para contraseñas vacías, boom .

Ese software podría incluso intentar leer cierta información sobre el usuario actual, como la dirección de correo electrónico. Pero si LDAP se utiliza como un directorio de personas, esta información puede ser accesible para usuarios anónimos. Los servidores LDAP a menudo solo son accesibles desde la red de la empresa y no desde Internet.

Dije al principio, que yo mismo cometí este error. Nuestro software es compatible con muchos tipos diferentes de frente de autenticación y backends. LDAP fue el único sistema afectado de todos los que admitimos.

Para garantizar que esto no vuelva a suceder, ahora rechazamos globalmente las contraseñas vacías para todos los sistemas de autenticación , a menos que el sistema no tenga contraseña, como los servicios de inicio de sesión único y las tarjetas inteligentes. Y agregamos un caso de prueba adicional a nuestra documentación (buen caso de prueba, prueba de contraseña incorrecta, contraseña de prueba vacía).

    
respondido por el Hendrik Brummermann 30.08.2011 - 20:53
fuente
0

La solicitud simple BIND toma una de cuatro formas dependiendo de los datos transmitidos con la solicitud:

  • nombre nulo, contraseña nula: anonymous , este es también el estado de autorización de todas las sesiones LDAP iniciales, es decir, donde el cliente LDAP aún tiene que emitir una solicitud BIND o una solicitud BIND ha fallado o ha sido rechazada. Los administradores del servidor deben considerar la configuración para rechazar los intentos de autenticación anónimos y establecer el código de resultado de la respuesta BIND en unwilling to perform , ya que no se ha realizado la autenticación.
  • nombre no nulo, contraseña nula: unauthenticated . Los administradores del servidor deben considerar la configuración para rechazar los intentos de autenticación anónimos y establecer el código de resultado de la respuesta BIND en unwilling to perform , ya que no se ha realizado ninguna autenticación
  • nombre no nulo, contraseña no nula: authenticated . Los administradores del servidor deben considerar la configuración del servidor para rechazar estas solicitudes si dichas solicitudes se transmiten a través de una conexión no segura, es decir, una conexión sin confidencialidad.
  • nombre nulo, contraseña no nula: undefined . El comportamiento del servidor no está definido por los estándares LDAP en este caso, por lo tanto, los administradores del servidor deben considerar la configuración para rechazar los intentos de autenticación anónimos y establecer el código de resultado de la respuesta BIND en unwilling to perform , ya que no se ha producido autenticación.

ver también

LDAP: Métodos de autenticación y mecanismos de seguridad

    
respondido por el Terry Gardner 09.07.2012 - 12:50
fuente

Lea otras preguntas en las etiquetas