Jugando con LDAP (III de III)

***************************************************************************************
- Jugando con LDAP (I de III)
- Jugando con LDAP (II de III)
- Jugando con LDAP (III de III)
***************************************************************************************

Los clientes

Cuando parecía que todo estaba visto sobre como procesan las implementaciones de ADAM y OpenLDAP los mensajes que llevan más de un filtro LDAP nos dimos cuenta de que algo no estaba funcionando como debía. Al realizar una aplicación web y lanzar dos filtros contra ADAM vimos que no estábamos recibiendo ningún error y que el primer filtro estaba siendo procesado. Vamos, como si fuera un OpenLDAP. No puede ser, alguien no está haciendo trampas. ¿Quién era el culpable?

En esta aplicación para probar consultas LDAP se puede ver el resultado de una consulta lanzada sobre el árbol LDAP del Retohacking IV, que funciona sobre ADAM, en color rojo. Como se puede ver son dos filtros pero sólo se está ejecutando el primero.

Aplicación Web enviando 2 filtros a ADAM
Pero esto no puede ser, hemos visto en la parte II, que cuando se lanza un mensaje con más de 1 filtro a un árbol ADAM nos devuelve un mensaje de desconexión. ¿Dónde está el misterio?

El componente web para clientes LDAP

Para reconstruir el entorno utilizamos el componente IPWorks de NSoftware y nuestro amigo, estaba tomando una tercera decisión de diseño. Así como OpenLdap ejecuta sólo el primer filtro correcto y ADAM termina la conexión, el componente IPWorks, elimina cualquier carácter por detrás del primer filtro correctamente construido. Es decir, si el programador carga dos filtros en el método de envío de la query LDAP, como se puede ver en la captura de abajo.

Visualización Valores en Visual Studio
El componente sólo lanza una consulta con el primero, como se puede ver en la captura realizada con Wireshark.

Captura envío con Wireshark
Este comportamiento es un tanto peculiar, ya que permite que un programador envíe datos erróneos, siempre y cuando haya un filtro correcto al principio.

La historia por debajo

Este comportamiento no dejaba de mantenerme un poco perplejo, ya que en OWASP se explica la inyección LDAP siguiendo los ejemplos de Sacha Faust, es decir, con dos filtros en un único mensaje y, en los ejemplos de Sacha se utiliza el componente IPWorks. ¿Sorprendido?

Ejemplo en documento de Sacha Faust
La idea parece ser, que, la gente de NSoftware, tras verse convertidos en ejemplo público de inyección LDAP con su componente IPWorks, optó por salirse de los ejemplos eliminando la posibilidad de inyectar código….con dos filtros. Sin embargo esta decisión de diseño favorece la inyección en consultas AND y OR pues hace que todos los parámetros a la derecha del parámetro inyectable puedan ser fácilmente excluidos de la consulta.

Preguntas Malignas

¿Es esta una buena decisión de diseño? ¿No hubiera sido mejor generar un error de aplicación? ¿Y dejarlo y enviar en bruto y que sea el error del servidor el que responda? Total, si la caga la aplicación es culpa del desarrollador, y si la caga el servidor es culpa del fabricante, ¿por qué tomar partido? ¿Es ahora algo más culpable? Yo creo que no, pero ….no me gusta esa decisión desde el punto de vista de seguridad. ¿Qué opináis vosotros?

Saludos Malignos!

***************************************************************************************
- Jugando con LDAP (I de III)
- Jugando con LDAP (II de III)
- Jugando con LDAP (III de III)
***************************************************************************************