¿Qué diablos está pasando realmente en estos informes de vulnerabilidad LDAP de Lion?

Simplemente lea un hilo de Slashdot sobre la rotura de LDAP en OSX. ¿Alguien puede explicar exactamente qué es lo que está garantizando OpenLDAP y por qué cualquier otra cosa que no sean los datos almacenados en una máquina Lion podría estar en riesgo?

Una cita del artículo:

"Como probadores de pen, una de las primeras cosas que hacemos es atacar el servidor LDAP", dijo Rob Graham, CEO de la firma de auditoría Errata Security. “Una vez que poseemos un servidor LDAP, somos dueños de todo. Puedo acercarme a cualquier computadora portátil (en una organización) e iniciar sesión en ella ”.

¿Cómo se pasa de hackear un servidor LDAP mac aleatorio a ser dueño de toda la empresa?

security mac-osx ldap

— jldugger
fuente

Slashdot, The Register y MacRumors están llenos de información errónea y exageración. Tome sus declaraciones con un grano de sal hasta que lo lea en una fuente confiable. Esos artículos son muy ligeros en cuanto a los detalles, y existe una gran confusión sobre si esto afecta algo más allá de las cuentas en la máquina local . Circulan rumores de que este problema es una "pesadilla de seguridad empresarial" o podría permitir a los usuarios tener el servidor LDAP, pero parece poco probable. Los clientes LDAP rotos y personalizados no son nada nuevo.

— Stefan Lasiewski

Esta es una buena pregunta. Casi todos los artículos que he leído carecen de detalles.

— Zoredache

Respuestas:

No te alarmes. Esta no es una gran amenaza para las redes empresariales que sugiere este artículo en The Register .

Apple Lion es nuevo y, por lo tanto, este error está recibiendo una cantidad desproporcionada de atención en comparación con fallas similares en otros sistemas operativos. Aquí hay algunas descripciones más tranquilas de este mismo problema:

" Mac OS X Lion no puede verificar las contraseñas cuando se autentica a través de LDAP ".
Paul Ducklin de nakedsecurity.sophos.com escribió un artículo más razonado sobre este problema y la exageración detrás de él.

Este es un exploit local en un sistema Apple Lion que afecta solo a ese sistema. Apple aún no ha proporcionado ningún detalle. Así es como entiendo el problema: si alguien inicia sesión en un sistema Apple Lion una vez con éxito, entonces cualquier otra persona puede iniciar sesión en el mismo sistema con cualquier contraseña. Este es un problema grave para ese sistema, pero el daño se limita principalmente a ese sistema en particular. Desafortunadamente, ese sistema ahora es menos confiable y puede estar en su red.

Este problema NO permite que un hacker sea dueño de sus servidores AD / LDAP, por sí mismo. Sus servidores AD / LDAP seguirán rechazando cualquier solicitud de autorización LDAP incorrecta de cualquier cliente LDAP. Para evitar esto, se requeriría una falla importante en el servidor LDAP o el protocolo LDAP o un servidor mal configurado, que es un problema completamente diferente al problema descrito anteriormente.

Tenga en cuenta que este problema solo afecta a los sistemas Apple Lion que usan LDAP para la autenticación. En la mayoría de las organizaciones, este será un número muy pequeño de clientes. Un servidor Apple Lion podría ser más vulnerable, pero Apple necesita dar más detalles sobre el problema y aún no han sido muy comunicativos sobre este tema. ¿Te imaginas a RedHat reteniendo información sobre una vulnerabilidad públicamente conocida durante tanto tiempo?

— Stefan Lasiewski
fuente

El problema con la vulnerabilidad está bastante bien explicado en el artículo vinculado por slashdot.

El verdadero problema es que una vez que alguien ingresa a cualquier máquina Lion en la red que está utilizando LDAP como método de autorización, puede leer el contenido del directorio LDAP. Lo que le daría acceso a todas las cuentas en la red que usan autenticación central. Además, le da acceso a cualquier cosa asegurada por el sistema de autorización LDAP. Básicamente, ahora posee todo en esa red.

Como nota al margen, tengo curiosidad por saber si se trata de un error en la autorización LDAP o en el sistema de autenticación subyacente (probablemente kerboros).

Además, si no está utilizando LDAP como fuente de autorización (OpenLDAP, Active Directory, NDS, etc.), esto no le afecta.

Para responder a su pregunta específica:

¿Alguien puede explicar exactamente qué está garantizando OpenLDAP?

La respuesta es "Depende ..." de lo que su infraestructura de TI haya configurado para usar LDAP para la autorización.

— Zypher
fuente

Además, le da acceso a cualquier cosa asegurada por el sistema de autorización LDAP. - ¿Cómo es posible tomar un cliente LDAP roto (o un cliente LDAP personalizado con fines maliciosos) y usarlo para obtener acceso a los recursos que están protegidos por LDAP? ¿No requeriría esto una falla en el protocolo LDAP o en el servidor LDAP?

— Stefan Lasiewski

Para que quede claro, mis preguntas se refieren a otros recursos en la red ("Básicamente, ahora posee todo en esa red").

— Stefan Lasiewski

¿Está seguro de que realmente puede leer / volcar el contenido del directorio? ¿Cómo se lograría esto? Kerberos no es necesario en una configuración OSX. Un cliente que acepta un usuario no válido como auténtico no significa que el servidor lo acepte como autenticado. Si el servidor LDAP no permite lecturas anónimas y el usuario no ha proporcionado una contraseña válida, ¿cómo podrían leer algo?

— Zoredache

Es un directorio Por supuesto, los usuarios pueden leer cosas en directorios. ¿Puede leer el atributo userPassword sin vinculación?

— jldugger

@jldugger, en mi directorio (no OD), ni siquiera puede obtener una lista de usuarios sin un enlace exitoso. Sin embargo, no conozco OSX realmente bien, ¿construye un conjunto de credenciales por máquina (como AD), no pensé que lo hiciera, pero podría estar equivocado. Si no hay credenciales para la máquina, y Apple no está haciendo algo estúpido como almacenar una copia reversible de la contraseña, entonces no sé cómo un error de almacenamiento en caché del cliente significa que tiene acceso libre al directorio.

— Zoredache