Or uno igual a uno ... en LDAP

Vamos a suponer que tenemos una aplicación Web que autentica contra un árbol LDAP. Para ello la aplicación realiza el proceso de BIND contra el servidor LDAP con un usuario y luego realiza búsquedas de objetos usuario que cuyo identificador y cuya contraseña correspondan con los introducidos en el formulario con una consulta mal construida y sin filtrar del tipo:

(&(uid=valor_usuario)(webpassword=valor_password))
¿Cómo conseguir acceso con un usuario sin saber la password?

Microsoft ADAM, OpenLDAP, SUN, etc...

En este servidor no se pueden generar dos filtros en la inyección así que, hay que conseguir que la inyección genere un único filtro. Para ello habría que introducir algo como:

Valor_usuario = admin)(!(&(|
Valor password = any))

El resultado tras esta inyección sería:

(&(uid= admin)(!(&(|)(webpassword= any))))
Este filtro es equivalente a recibir objetos con atributo uid=admin AND TRUE. Es decir, sólo se comprobará que el nombre del usuario sea Admin. Esta forma exige, como restricción, que los dos campos sean inyectables. Para entender bien lo que realiza esta inyección hay que tener en cuenta que en LDAP (|) es equivalente a Absolute FALSE y (&) es equivalente a Absolute TRUE según la RFC 4526

OpenLDAP y SUN

Este servidor, si recibe más de un filtro ejecuta sólo el primero, así que basta con construir con la inyección un filtro LDAP completo que se ejecute bien. Sin embargo, si existe comprobación sintáctica de filtros es recomendable que haya dos filtros correctamente construidos en lugar de uno “y algo”

Valor_usuario = admin))(|(|
Valor password = any

El resultado tras la inyección sería:

(&(uid= admin))(|(|)(webpassword= any))
Estos son dos filtros y OpenLDAP sólo ejecutará el primero. La ventaja es que basta con que el primer campo sea inyectable.

IPWorksASP.LDAP

Con este componente cliente, que se utiliza en las aplicacioens web, se desprecia todo carácter encontrado después del primer filtro LDAP bien construido, así que da igual si está o no bien cerrado el resto del LDAP Search filter.

Valor_usuario = admin)
Valor password = any

El resultado tras la inyección sería:

(&(uid= admin))(webpassword= any))
Sólo se ejecuta (&(uid=admin)), así que valdría esa inyección perfectamente.

Sin filtrar los asteriscos

Si diera la casualidad de que los * no estuvieran filtrados la cosa se simplifica mucho más, tanto como poner un * en la password o en el usuario, o en ambos para cambiar el acceso. Si se pudiera poner en la password, pues no es necesario inyectar, se pone el usuario y la password.

Si el asterísco se puede poner en el campo usuario pero no en el campo password sólo habría que sustituir "admin" en las inyecciones por "*".

Todo esto se basa en lo expuesto en el artículo Jugando con LDAP en el que se analizaba el comportamiendo de los servidores LDAP ante diferentes inyecciones. Y, si quieres practicar más puedes probar con el Reto Hacking IV.

Saludos Malignos!