Ldap injection y Blind Ldap Injection

LDAP Injection y Blind LDAP Injection José María Alonso et al.

_____________________________________________________________________________________________

LDAP INJECTION y BLIND LDAP INJECTION
José María Alonso1, Rodolfo Bordón2, Marta Beltrán3 and Antonio Guzmán4
1
Informática64, S.L., chema@informatica64.com
2
Informática64, S.L., rodol@informatica64.com
3
Universidad Rey Juan Carlos, marta.beltran@urjc.es
4
Universidad Rey Juan Carlos, antonio.guzman@urjc.es

Abstract

It is common in web application interactions between end-users and databases. These applications may be
vulnerable to code injection attacks which take advance of weak validation in the parameters that the users use.
If one of these applications accept input from a client and execute it without first validating it, attackers have the
potential to execute their own queries and thereby extract sensitive information from the LDAP directory. In this
paper a deep analysis of the LDAP injection techniques is presented including Blind attacks. Attacker can inject
malicious code to change the behavior of the web application and gain access to confidential data.

Abstract
Es muy frecuente que las aplicaciones web permitan interacciones con los usuarios para realizar accesos a
bases de datos. Estas aplicaciones pueden ser vulnerables a ataques de inyección de código que aprovechen
una validación débil en los parámetros que usan los usuarios. Un atacante puede inyectar segmentos de
código malicioso a través de estos parámetros para obtener o modificar información confidencial de la base
datos. En este artículo se propone un análisis de las vulnerabilidades de los servicios del protocolo LDAP
frente a ataques blind sql injection. Además, se propone el análisis de un caso real para destacar los aspectos
más importantes a la hora de securizar aplicaciones frente a este tipo de ataques.

Key words: Seguridad en Bases de Datos, LDAP, SQL Injection y Blind SQL Injection.

____________________________________________________________________________________________
1
CollECTeR Iberoamérica 2008


_____________________________________________________________________________________________

1 Introducción

Desde 2002, el 50% de las vulnerabilidades explotadas en aplicaciones web han estado localizadas en una
deficiente validación de los parámetros de entrada ([1]). Una validación débil de estos parámetros supone facilitar la
implementación de ataques basados en la inyección de código. En ellos se aceptan datos desde un cliente y se
realizan consultas a la base de datos evitando tipo de validación previa ni del cliente ni de los datos.

Un atacante puede entonces ganar el acceso a la base de datos subyacente a la aplicación web, e incluso, penetrar
en el sistema operativo. Para implementar un ataque de estas características el atacante introduce un código que
genera una consulta errónea en la base de datos. Si el servidor contesta con un mensaje de error, esto implica que
la inyección de código ha tenido éxito, y por tanto es posible explotar una vulnerabilidad a inyecciones.

Muchas aplicaciones han sido fortificadas contra la inyección de código evitando que los servidores respondan con
mensajes de error. De esta forma se le impide al atacante implementar la inyección de código de la forma expuesta.
Desafortunadamente, este filtrado no protege de los denominados ataques ciegos, que se realizan implementando
una lógica binaria (Verdadero/Falso) a partir del comportamiento del servidor aunque no se produzcan mensajes de
error desde el servidor.

Las técnicas de ataque basadas en la inyección de código SQL son a las que tradicionalmente más esfuerzos se
han dedicado por la comunidad científica ([2], [3], [4], [5]), Sin embargo existen otras técnicas de inyección
asociadas a otros lenguajes o protocolos como XPath ([7], [8]) o LDAP([9], [10]) cuyo estudio tiene prácticamente la
misma importancia que la inyección de SQL. Los principios que hay detrás de la explotación de las vulnerabilidades
en estos lenguajes son las mismas que para el SQL, sin embargo los estudios realizados sobre estos casos son
muy escasos y existe muy poca literatura sobre ellos.

En este artículo se van a analizar las técnicas de inyección ciegas sobre LDAP. Se va a demostrar hasta qué punto
pueden ser vulnerables a un ataque de este tipo los árboles LDAP y, por tanto, las aplicaciones web basadas en su
uso. La estructura de este artículo que comienza con esta introducción continúa en la sección 2 con una
introducción al protocolo LDAP incluyendo los conceptos necesarios para entender el resto del artículo. La sección
3 analiza la técnica de ataque de inyección ciega de código LDAP (Blind LDAP Injection) y la sección 4 propone la
descripción de un ejemplo completo para ilustrar la criticidad de las vulnerabilidades en las aplicaciones web a este
tipo de ataques. Por último la sección presenta las conclusiones extraídas del análisis realizado.

2 LDAP (Lightweight Directory Access Protocol)
Los directorios son bases de datos jerárquicas diseñadas para almacenar y organizar información que comparten
una serie de características comunes: la forma en la que se estructura la información (árbol) y estar dotada de
eficaces capacidades de búsqueda y navegación por el árbol del directorio. Por lo tanto, un directorio es una base
de datos especializada en búsquedas y no en actualizaciones y en procesar consultas específicas y no en ofrecer
listados de resultados. Además, un directorio permite inconsistencias temporales entre sus repositorios.

El servicio de directorio es una aplicación software implementada para acceder a la información del directorio. LDAP
es un protocolo para realizar consultas y modificaciones eficaces y rápidas a los servicios de directorio que se
ejecutan sobre TCP/IP ([11], [6]). Existen múltiples implementaciones de este protocolo, siendo dos las más
extendidas: ADAM (Active Directory Application Mode, [14]) y OpenLDAP ([12]).

LDAP está orientado a objetos y cada entrada del
árbol LDAP es una instancia de un objeto y, por tanto, estará sujeto a las reglas fijadas por los atributos de dicho
objeto. LDAP está basado en el modelo cliente/servidor, por lo tanto, los cliente envían peticiones de operación al
servidor y el servidor responde con la información del directorio. La operación más frecuente es la búsqueda de
entradas del directorio. Para responder a estas búsquedas el servidor debe verificar si una entrada del árbol LDAP
presenta un atributo con un valor determinado. Esta comprobación se realiza mediante el uso de los filtros definidos
en la RFC 4515 [11].

La estructura de estos filtros pueden resumirse con:

____________________________________________________________________________________________
2


_____________________________________________________________________________________________
Filter = ( filtercomp )
Filtercomp = and / or / not / item
And = & filterlist
Or = | filterlist
Not = ! filter
Filterlist = 1*filter
Item = simple / present / substring
Simple = attr filtertype assertionvalue
Filtertype = “=” /” =”/”¿=” /”¡=”
Present = attr = *
Substring = attr “=” [initial]* [final]
Initial = assertionvalue
Final = assertionvalue

Se puede ver que todos los filtros deben estar entre paréntesis, y que sólo un conjunto de operadores lógicos (AND,
OR y NOT) y relacionales (≤, ≥, =, ≈) están disponibles para construirlos. Además, se introduce el asterisco como un
carácter especial que puede emplearse para reemplazar uno o más caracteres en la construcción de los filtros.

3 Blind LDAP Injection
Los ataques de inyección de código en servicios LDAP están basados en las mismas técnicas que los ataques de
inyección SQL. En ambos el concepto fundamental es aprovechar los datos que debe introducir un usuario para
generar una consulta determinada. Si la aplicación fuese segura debería realizarse un filtrado de estos datos antes
de construir la consulta y mandarla al servidor. Sin embargo, en un escenario vulnerable estos datos no se someten
a un proceso de filtrado y un atacante puede inyectar su código para cambiar los resultados que se obtendría con la
consulta sin inyectar.

Teniendo en cuenta la estructura de los filtros LDAP expuesta en la sección anterior y que las implementaciones
más extendidas son ADAM y OpenLDAP se puede concluir lo siguiente acerca de la inyección de código:

1. Sólo se podrán realizar ataques de inyección de código sobre aplicaciones web si los parámetros
introducidos por los usuarios no están filtrados y si las consultas normales empiezan por los operadores
lógicos | o &.
2. En estos casos, hay dos tipos de inyección que dependerán del tipo de escenario LDAP que se presente:
La inyección de código clásica o la inyección de código ciega.

Una solución extendida para evitar los ataques de inyección de código es evitar que el servidor muestre mensajes
de error cuando ejecuta consultas inválidas. Sin embargo, esta contramedida sólo protege al sistema de la inyección
clásica no de la inyección ciega. De hecho la única manera de blindar un sistema a cualquier técnica de ataque
basado en la inyección de código es el correcto filtrado en los datos introducidos por los usuarios.

Supongamos que se dispone un escenario en el que no se realiza un filtrado correcto de los parámetros de entrada
de una aplicación web pero si se ha evitado que el servidor genere mensaje de error. En este entorno de trabajo tan
frecuente hoy en día todavía es posible que el atacante sea capaz de inferir algún tipo de respuesta en el
comportamiento de la aplicación [13], aunque ello no suponga obtener una respuesta estándar de la misma. Este es
el caso de los ataques denominados de inyección ciega de código LDAP (Blind LDAP Injection). El objetivo del
atacante sería en este caso capaz de distinguir entre el comportamiento de la aplicación ante una inyección de
código que genera una respuesta válida y una inyección que provoca un error. Una vez que se ha identificado el
comportamiento correspondiente a una respuesta verdadera y el correspondiente a una respuesta falsa el atacante
podrá extraer información mediante cuestiones sucesivas de verdadero o falso. Aunque este tipo de inyección
plantea un proceso tedioso y muy costoso también facilita su automatización permitiendo extraer toda la información
de un sistema.

3.1 AND Blind LDAP Injection

Un escenario en el que a través de una consulta al árbol LDAP se liste las impresoras (p.e. Epson) disponibles en
un establecimiento, podría utilizar el siguiente filtro para extraer la información:

(&(objectClass = printer)(type=Epson*))

Al ejecutar esta consulta, si existe una impresora Epson, los datos de la impresora se le muestran al cliente; en caso
contrario, no se muestra ningún dato.

____________________________________________________________________________________________
3


_____________________________________________________________________________________________
En este entorno, si un atacante desea utilizar la técnica de ataque Blind LDAP Injection, puede inyectar código para
construir la siguiente consulta:

(&(objectClass=*)(ObjectClass=*))(&(objectClass=void)(type=Epson*))

El servicio LDAP procesará el primer filtro completo de la consulta y el resto será ignorado. De esta forma la
consulta que finalmente se ejecutará será la correspondiente a la inyección.

(&(objectClass=*)(ObjectClass=*))

Es decir, el resultado que se va a mostrar al cliente tendrá datos del sistema ya que el filtro objectClass = * siempre
devuelve un objeto (resultado verdadero para el ataque a ciegas).

A partir de este punto, se puede completar las técnicas de ataque Blind LDAP Injection obteniendo el
comportamiento del sistema ante una inyección que no ofrezca un resultado válido. Por ejemplo, se pueden
construir las siguientes inyecciones:

(&(objectClass=*)(objectClass=users))(&(objectClass=foo)(type=Epson*))
(&(objectClass=*)(objectClass=resources))(&(objectClass=foo)(type=Epson*))

Este conjunto de consultas permitirá a un atacante inferir los posibles valores del atributo objectClass. Cuando una
consulta devuelva datos de la impresora implicaría que el valor utilizado en la inyección existiría. Si los datos no se
muestran implicaría un resultado falso para el ataque a ciegas y que el valor inyectado no es un valor existente en el
árbol LDAP.

3.2 OR Blind LDAP Injection
En este caso, la lógica utilizada para extraer la información del escenario del apartado anterior es distinta y el filtro
sería el siguiente:

(| (objectClass=printer)(type=Epson*)

En este entorno basado en el uso del operador OR la inyección sería la siguiente:

(| (objectClass=void)(objectClass=void))(&(objectClass=void)(type=Epson*)

La ejecución de esta consulta provoca un resultado falso desde el servidor LDAP, y por lo tanto, los datos de la
impresora no se muestran al cliente. Cualquier resultado diferente a este será interpretado como un resultado
verdadero. De nuevo, a partir de este punto es posible extraer la información del sistema mediante la ejecución de
consultas consecutivas que implementen un análisis en el que las únicas respuestas desde el servidor serán
verdadero o falso. Algunas de las consultas que se pueden utilizar son las siguientes:

(|(objectClass=void)(objectClass=users))(&(ibjectClass=void)(type=Epson*))
(|(objectClass=void)(objectClass=resources))(&(objectClass=void)(type=Epson*))

4 Ejemplo de explotación
En esta sección, se analiza un entorno real de LDAP implementado para ejemplificar las técnicas descritas en las
secciones anteriores y para ilustrar la criticidad potencial del desarrollo de las mismas en la seguridad de cualquier
sistema.

Para mostrar la potencia de los ataques Blind LDAP Injection se ha creado, dentro de un árbol LDAP sobre ADAM
una estructura con objetos Printer. En la siguiente figura se pueden ver los atributos de un objeto de tipo Printer.

____________________________________________________________________________________________
4


_____________________________________________________________________________________________

Figura 1: Árbol LDAP sobre ADAM. Objeto tipo Printer

Sobre este árbol LDAP trabaja una aplicación web que se conecta, entre otros repositorios, a este árbol para
obtener información. En este caso tenemos una aplicación programada en php, llamada printerstatus.php que recibe
como parámetro el nombre de la impresora y construye una consulta LDAP de la siguiente forma:

(&(cn=HP Laserjet 2100)(objectclass=printer))

El resultado es una página web en la que se acceden a propiedades de la impresora en concreto.

Figura 2: Propiedades de la impresora HP LaserJet 2100

El parámetro idprinter se utiliza para construir la consulta LDAP y es vulnerable a LDAP Injection, sin embargo, no
se muestra ninguno de los datos de los objetos que se puedan seleccionar con cualquier consulta ejecutada, por lo
que únicamente se puede realizar una explotación a ciegas. Las siguientes fases muestran ejemplos de cómo
extraer información del árbol LDAP mediante Blind LDAP Injection.

4.1 Fase 1: Descubrimiento de atributos
El atancante inyecta atributos para descubrir si existen o no. Cuando el atributo no existe la consulta LDAP no
devuelve ningún objeto y la aplicación no muestra datos de ninguna impresora.

Hay que tener en cuenta que el comodín ( * )vale únicamente para los valores de tipo alfanuméricos, luego si el
atributo fuera de otro tipo no se podría descubrir así. Para los tipos numéricos y de tipo fecha se utilizan los
operadores >= , <= o = y para los booleanos las constantes True y False.

____________________________________________________________________________________________
5


_____________________________________________________________________________________________

Figura 3: Atributo IPaddress no existe o no tiene valor alfanumérico

En el siguiente ejemplo, el atributo distinguisedname existe y además es de tipo alfanumérico ya que funciona
perfectamente con el comodín ( * ). Esto se puede comprobar porque la página de resultados ha devuelto datos de
la impresora que se estaba utilizando.

Figura 4: Atributo distinguisedname existe y tiene valor alfanumérico

Como se puede ver en la figura 4, hay diferencias en las páginas que devuelven datos y las que no, con lo que se
puede automatizar la extracción de toda la información y el descubrimiento de los atributos simplemente
comparando los resultados HTML obtenidos.

En la figura 5, se obtiene de nuevo un resultado positivo que confirma la existencia de un atributo department.

Figura 5: Atributo Department existe y tiene valor Unicode extraíble

4.2 Fase 2: Reduciendo el alfabeto
Una de las opciones que se pueden sopesar es realizar una reducción del alfabeto posible de valores en un campo.
La idea consiste en saber si existe o no un determinado carácter en un atributo. Si el atributo tiene 15
caracteres de longitud y tenemos que probar, por ejemplo, 28 letras por 15 caracteres tendrían que
realizarse un total de 420 peticiones para extraer la información. Sin embargo, se puede realizar un
recorrido que nos diga si una letra pertenece o no al valor. De esa manera realizaríamos primero 28

____________________________________________________________________________________________
6


_____________________________________________________________________________________________
peticiones que nos dejarán, en el peor de los casos una letra distinta por cada posición, es decir, 15 letras.
Luego, en el peor de los casos tendríamos 15 letras x 15 posiciones + 28 peticiones de reducción del
alfabeto, es decir 253 peticiones. Además, se puede inferir, que si una letra ya ha sido utilizada puede que
no se vuelva a utilizar, con lo que tendríamos una reducción aun mayor si la letra se utiliza como última
opción, dejando la probabilidad en un sumatorio de 1 a15 + 28, es decir 148 peticiones.
Como conclusión se puede obtener que la reducción del alfabeto es un buena opción a la hora de extraer valores de
campos.

En los siguientes ejemplos (figuras 6 y 7) se muestra cómo averiguar si un carácter pertenece o no al valor del
campo.

Figura 6: La letra b no pertenece al valor del atributo department porque no se obtienen datos

Figura 7: La letra n si pertenece al valor del atributo department porque si se obtienen datos

Esta reducción dejaría un conjunto de valores válidos que pueden emplearse para extraer el valor del dato mediante
un proceso de despliegue.

4.3 Fase 3: El despliegue
En esta fase, una vez reducido el alfabeto, hay que ordenar las letras obtenidas, para ello comenzaremos un
proceso desde la primera posición (figura 8).

____________________________________________________________________________________________
7


_____________________________________________________________________________________________
Figura 8: El valor de department no comienza por la letra a porque no se obtienen datos

Se irán probando letras hasta que se obtenga un resultado positivo que confirme que con ese patrón se devuelven
datos.

Figura 9: El valor de department si comienza por la letra f porque si se obtienen datos

Una vez descubierta la primera letra (figura 9), esta se mantendrá fija y se procederá a buscar la segunda letra,
sustituyendo siempre los caracteres obtenidos en la fase de reducción del alfabeto.

Figura 10: El valor de department no comienza por las letras fa porque no se obtienen datos

Figura 11: El valor de department si comienza por las letras fi porque si se obtienen datos

Este proceso se repetiría con todos los atributos descubiertos y hasta que se hubieran descubierto todas las letras
permitiendo extraer información oculta de los objetos del árbol LDAP.

5 Conclusiones
LDAP es una tecnología en expansión cuya implantación en los sistemas de directorio y meta directorio la hacen
cada día más popular. Los entornos Intranet realizan uso intensivo de esta tecnología para ofrecer sistemas de
Single Sing-On e incluso es común encontrar entornos LDAP en los servicios de Internet.

____________________________________________________________________________________________
8


_____________________________________________________________________________________________
Esta popularidad hace que sea necesario incluir las pruebas anteriores dentro de los procesos de auditoría de
seguridad de las aplicaciones web. Las pruebas de inyecciones de auditoría que se estaban realizando hoy en día,
siguiendo la documentación existente, son de poca ayuda pues en los entornos más comunes como ADAM u
OpenLDAP no funcionan.

La solución para proteger las aplicaciones frente a inyecciones LDAP e inyecciones ciegas LDAP es, como en otros
entornos de explotación, filtrar los parámetros enviados desde el cliente. En este caso filtrar operadores, paréntesis
y comodines para que nunca un atacante sea capaz de inyectar lógica dentro de nuestra aplicación.

Este trabajo es único en la forma que se proporciona un análisis riguroso de las técnicas de Blind LDAP Injection y
la selección de ejemplos representativos sobre entornos reales. Se ha demostrado que es esencial filtrar los datos
de entrada de los usuarios antes de construir las consultas LDAP y enviarlas al servidor, y que las construcciones
basadas en los operadores AND y OR deben ser evitadas.

Referencias
PERIODICALS
[1] S. Barnum and G. Mc Graw. Knowledge for software security. IEEE Security and Privacy Magazine, 3(2):74-78,
2005

PAPERS PUBLISHED IN PROCEEDINGS

[2] E. Bertino, A. Kamra, and J.P.Early. Profiling database application to detect SQL injection attacks. In
Proceedings of the IEEE International Performance, Computing , and ommunications Conference, pages 449-
458, 2007.
[3] Xiang Fug, Xin Lu, Boris Peltsverger, Shijun Chen, Kai Qian, and Lixin Tao. A static analysis framework for
detecting SQL Injections vulnerabilities. In Proceedings of the 31st Annual International Computer Software and
Applications Conference, pages 87-96, 2007.
[4] E. Merlo, D. Letarte, and G. Antoniol. SQL-Injection Security evolution analysis in PHP. In Proceedings of the 9th
IEEE International Workshop on Web Site Evolution, pages 45-49, 2007.
[5] S.Thomas and L.Williams. Using automated fix generation to secure SQL statements. In Proceedings of the 3rd
International Workshop on Software Engineering for Secure Systems, pages 9-19,2007.
[6] V. Koutsonikova and A.Vakali. LDAP: framework, practices and trends. IEEE Internet Computing, 8(5):66-72,
2004

ONLINE SOURCES

[7] (1999) XPath 1.0 Specification. [Online]. Available: http://www.w3.org/TR/xpath.
[8] (2007) XPath 2.0 Specification. [Online]. Available: http://www.w3.org/TR/xpath20.
[9] (1995) RFC 1777: Lightweight Directory Access Protocol v2. [Online]. Available:
http://www.faqs.org/rfcs/rfc1777.html
[10] (1997). M.Wahl,T.Howes,and S.Kille. Lightweight Directory Access Protocol (v3). [Online]. Available:
http://www.ietf.org/rfc/rfc2251.
[11] (2006). M. Smith, Ed.. RFC 4515 - Lightweight Directory Access Protocol (LDAP): String Representation of
Search Filters. [Online]. Available: http://www.ietf.org/rfc/rfc4515.html .
[12] (2008) OpenLDAP main page. [Online]. Available: http://www.openldap.org.

THESIS or DISSERTATION

[13] J.M. Alonso, LDAP Injection y Blind LDAP Injection, M.S. thesis, Rey Juan Carlos University, Madrid, Spain,
2008.

REPORTS (technical reports, internal reports)

[14] Mark Russinovich and David Solomon. Microsoft Windows Internals. Microsoft Press, 2004.

____________________________________________________________________________________________
9

Ldap injection y Blind Ldap Injection

Más contenido relacionado

La actualidad más candente (20)

Similar a Ldap injection y Blind Ldap Injection (20)

Más de Chema Alonso (20)

Último (20)

Ldap injection y Blind Ldap Injection