• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ldap injection y Blind Ldap Injection
 

Ldap injection y Blind Ldap Injection

on

  • 1,127 views

Artículo que repasa los ataques LDAP Injection y Blind LDAP Injection en aplicaciones web.

Artículo que repasa los ataques LDAP Injection y Blind LDAP Injection en aplicaciones web.

Statistics

Views

Total Views
1,127
Views on SlideShare
1,126
Embed Views
1

Actions

Likes
1
Downloads
34
Comments
0

1 Embed 1

http://translate.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Ldap injection y Blind Ldap Injection Ldap injection y Blind Ldap Injection Document Transcript

    • 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
    • LDAP Injection y Blind LDAP Injection José María Alonso et al._____________________________________________________________________________________________1 IntroducciónDesde 2002, el 50% de las vulnerabilidades explotadas en aplicaciones web han estado localizadas en unadeficiente validación de los parámetros de entrada ([1]). Una validación débil de estos parámetros supone facilitar laimplementación de ataques basados en la inyección de código. En ellos se aceptan datos desde un cliente y serealizan 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, penetraren el sistema operativo. Para implementar un ataque de estas características el atacante introduce un código quegenera una consulta errónea en la base de datos. Si el servidor contesta con un mensaje de error, esto implica quela 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 conmensajes 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 implementandouna lógica binaria (Verdadero/Falso) a partir del comportamiento del servidor aunque no se produzcan mensajes deerror 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 sehan dedicado por la comunidad científica ([2], [3], [4], [5]), Sin embargo existen otras técnicas de inyecciónasociadas a otros lenguajes o protocolos como XPath ([7], [8]) o LDAP([9], [10]) cuyo estudio tiene prácticamente lamisma importancia que la inyección de SQL. Los principios que hay detrás de la explotación de las vulnerabilidadesen estos lenguajes son las mismas que para el SQL, sin embargo los estudios realizados sobre estos casos sonmuy 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é puntopueden ser vulnerables a un ataque de este tipo los árboles LDAP y, por tanto, las aplicaciones web basadas en suuso. La estructura de este artículo que comienza con esta introducción continúa en la sección 2 con unaintroducción al protocolo LDAP incluyendo los conceptos necesarios para entender el resto del artículo. La sección3 analiza la técnica de ataque de inyección ciega de código LDAP (Blind LDAP Injection) y la sección 4 propone ladescripción de un ejemplo completo para ilustrar la criticidad de las vulnerabilidades en las aplicaciones web a estetipo 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 compartenuna serie de características comunes: la forma en la que se estructura la información (árbol) y estar dotada deeficaces capacidades de búsqueda y navegación por el árbol del directorio. Por lo tanto, un directorio es una basede datos especializada en búsquedas y no en actualizaciones y en procesar consultas específicas y no en ofrecerlistados 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. LDAPes un protocolo para realizar consultas y modificaciones eficaces y rápidas a los servicios de directorio que seejecutan sobre TCP/IP ([11], [6]). Existen múltiples implementaciones de este protocolo, siendo dos las másextendidas: 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 dichoobjeto. LDAP está basado en el modelo cliente/servidor, por lo tanto, los cliente envían peticiones de operación alservidor y el servidor responde con la información del directorio. La operación más frecuente es la búsqueda deentradas del directorio. Para responder a estas búsquedas el servidor debe verificar si una entrada del árbol LDAPpresenta un atributo con un valor determinado. Esta comprobación se realiza mediante el uso de los filtros definidosen la RFC 4515 [11].La estructura de estos filtros pueden resumirse con:____________________________________________________________________________________________ 2 CollECTeR Iberoamérica 2008
    • LDAP Injection y Blind LDAP Injection José María Alonso et al._____________________________________________________________________________________________ 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 = assertionvalueSe 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 uncarácter especial que puede emplearse para reemplazar uno o más caracteres en la construcción de los filtros.3 Blind LDAP InjectionLos ataques de inyección de código en servicios LDAP están basados en las mismas técnicas que los ataques deinyección SQL. En ambos el concepto fundamental es aprovechar los datos que debe introducir un usuario paragenerar una consulta determinada. Si la aplicación fuese segura debería realizarse un filtrado de estos datos antesde construir la consulta y mandarla al servidor. Sin embargo, en un escenario vulnerable estos datos no se sometena un proceso de filtrado y un atacante puede inyectar su código para cambiar los resultados que se obtendría con laconsulta sin inyectar.Teniendo en cuenta la estructura de los filtros LDAP expuesta en la sección anterior y que las implementacionesmá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 mensajesde error cuando ejecuta consultas inválidas. Sin embargo, esta contramedida sólo protege al sistema de la inyecciónclásica no de la inyección ciega. De hecho la única manera de blindar un sistema a cualquier técnica de ataquebasado 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 entradade una aplicación web pero si se ha evitado que el servidor genere mensaje de error. En este entorno de trabajo tanfrecuente hoy en día todavía es posible que el atacante sea capaz de inferir algún tipo de respuesta en elcomportamiento de la aplicación [13], aunque ello no suponga obtener una respuesta estándar de la misma. Este esel caso de los ataques denominados de inyección ciega de código LDAP (Blind LDAP Injection). El objetivo delatacante sería en este caso capaz de distinguir entre el comportamiento de la aplicación ante una inyección decódigo que genera una respuesta válida y una inyección que provoca un error. Una vez que se ha identificado elcomportamiento correspondiente a una respuesta verdadera y el correspondiente a una respuesta falsa el atacantepodrá extraer información mediante cuestiones sucesivas de verdadero o falso. Aunque este tipo de inyecciónplantea un proceso tedioso y muy costoso también facilita su automatización permitiendo extraer toda la informaciónde un sistema.3.1 AND Blind LDAP InjectionUn escenario en el que a través de una consulta al árbol LDAP se liste las impresoras (p.e. Epson) disponibles enun 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 casocontrario, no se muestra ningún dato.____________________________________________________________________________________________ 3 CollECTeR Iberoamérica 2008
    • LDAP Injection y Blind LDAP Injection José María Alonso et al._____________________________________________________________________________________________En este entorno, si un atacante desea utilizar la técnica de ataque Blind LDAP Injection, puede inyectar código paraconstruir 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 laconsulta 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 = * siempredevuelve 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 elcomportamiento del sistema ante una inyección que no ofrezca un resultado válido. Por ejemplo, se puedenconstruir 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 unaconsulta devuelva datos de la impresora implicaría que el valor utilizado en la inyección existiría. Si los datos no semuestran 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 InjectionEn este caso, la lógica utilizada para extraer la información del escenario del apartado anterior es distinta y el filtroserí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 laimpresora no se muestran al cliente. Cualquier resultado diferente a este será interpretado como un resultadoverdadero. De nuevo, a partir de este punto es posible extraer la información del sistema mediante la ejecución deconsultas consecutivas que implementen un análisis en el que las únicas respuestas desde el servidor seránverdadero 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ónEn esta sección, se analiza un entorno real de LDAP implementado para ejemplificar las técnicas descritas en lassecciones anteriores y para ilustrar la criticidad potencial del desarrollo de las mismas en la seguridad de cualquiersistema.Para mostrar la potencia de los ataques Blind LDAP Injection se ha creado, dentro de un árbol LDAP sobre ADAMuna estructura con objetos Printer. En la siguiente figura se pueden ver los atributos de un objeto de tipo Printer.____________________________________________________________________________________________ 4 CollECTeR Iberoamérica 2008
    • LDAP Injection y Blind LDAP Injection José María Alonso et al._____________________________________________________________________________________________ Figura 1: Árbol LDAP sobre ADAM. Objeto tipo PrinterSobre este árbol LDAP trabaja una aplicación web que se conecta, entre otros repositorios, a este árbol paraobtener información. En este caso tenemos una aplicación programada en php, llamada printerstatus.php que recibecomo 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 2100El parámetro idprinter se utiliza para construir la consulta LDAP y es vulnerable a LDAP Injection, sin embargo, nose muestra ninguno de los datos de los objetos que se puedan seleccionar con cualquier consulta ejecutada, por loque únicamente se puede realizar una explotación a ciegas. Las siguientes fases muestran ejemplos de cómoextraer información del árbol LDAP mediante Blind LDAP Injection.4.1 Fase 1: Descubrimiento de atributosEl atancante inyecta atributos para descubrir si existen o no. Cuando el atributo no existe la consulta LDAP nodevuelve 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 elatributo fuera de otro tipo no se podría descubrir así. Para los tipos numéricos y de tipo fecha se utilizan losoperadores >= , <= o = y para los booleanos las constantes True y False.____________________________________________________________________________________________ 5 CollECTeR Iberoamérica 2008
    • LDAP Injection y Blind LDAP Injection José María Alonso et al._____________________________________________________________________________________________ Figura 3: Atributo IPaddress no existe o no tiene valor alfanuméricoEn el siguiente ejemplo, el atributo distinguisedname existe y además es de tipo alfanumérico ya que funcionaperfectamente con el comodín ( * ). Esto se puede comprobar porque la página de resultados ha devuelto datos dela impresora que se estaba utilizando. Figura 4: Atributo distinguisedname existe y tiene valor alfanuméricoComo se puede ver en la figura 4, hay diferencias en las páginas que devuelven datos y las que no, con lo que sepuede automatizar la extracción de toda la información y el descubrimiento de los atributos simplementecomparando 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íble4.2 Fase 2: Reduciendo el alfabetoUna 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 CollECTeR Iberoamérica 2008
    • LDAP Injection y Blind LDAP Injection José María Alonso et al._____________________________________________________________________________________________ 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 decampos.En los siguientes ejemplos (figuras 6 y 7) se muestra cómo averiguar si un carácter pertenece o no al valor delcampo. 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 datosEsta reducción dejaría un conjunto de valores válidos que pueden emplearse para extraer el valor del dato medianteun proceso de despliegue.4.3 Fase 3: El despliegueEn esta fase, una vez reducido el alfabeto, hay que ordenar las letras obtenidas, para ello comenzaremos unproceso desde la primera posición (figura 8).____________________________________________________________________________________________ 7 CollECTeR Iberoamérica 2008
    • LDAP Injection y Blind LDAP Injection José María Alonso et al._____________________________________________________________________________________________ Figura 8: El valor de department no comienza por la letra a porque no se obtienen datosSe irán probando letras hasta que se obtenga un resultado positivo que confirme que con ese patrón se devuelvendatos. Figura 9: El valor de department si comienza por la letra f porque si se obtienen datosUna 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 datosEste proceso se repetiría con todos los atributos descubiertos y hasta que se hubieran descubierto todas las letraspermitiendo extraer información oculta de los objetos del árbol LDAP.5 ConclusionesLDAP es una tecnología en expansión cuya implantación en los sistemas de directorio y meta directorio la hacencada día más popular. Los entornos Intranet realizan uso intensivo de esta tecnología para ofrecer sistemas deSingle Sing-On e incluso es común encontrar entornos LDAP en los servicios de Internet.____________________________________________________________________________________________ 8 CollECTeR Iberoamérica 2008
    • LDAP Injection y Blind LDAP Injection José María Alonso et al._____________________________________________________________________________________________Esta popularidad hace que sea necesario incluir las pruebas anteriores dentro de los procesos de auditoría deseguridad 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 uOpenLDAP no funcionan.La solución para proteger las aplicaciones frente a inyecciones LDAP e inyecciones ciegas LDAP es, como en otrosentornos de explotación, filtrar los parámetros enviados desde el cliente. En este caso filtrar operadores, paréntesisy 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 yla selección de ejemplos representativos sobre entornos reales. Se ha demostrado que es esencial filtrar los datosde entrada de los usuarios antes de construir las consultas LDAP y enviarlas al servidor, y que las construccionesbasadas en los operadores AND y OR deben ser evitadas.ReferenciasPERIODICALS[1] S. Barnum and G. Mc Graw. Knowledge for software security. IEEE Security and Privacy Magazine, 3(2):74-78, 2005PAPERS 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, 2004ONLINE 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 CollECTeR Iberoamérica 2008