(more) LDAP Injection tricks

Desde que en Septiembre de 2007 publicaramos el Reto Hacking IV sobre LDAP Injection & Blind LDAP Injection, hemos ido dando vueltas a la madeja de estas técnicas de ataque. Fueron bastantes los artículos que les dedique, pero, como en todo en la vida siempre hay cosas que se pueden mejorar, ampliar y, en el mundo del hacking, dar una vuelta más de tuerca. Es lo bueno de esto, siempre se puede avanzar un poquito.

Ayer sábado me pasaron el artículo de Ribadeo Hack Lab sobre LDAP Injection que recoge, en un artículo didactico, divulgativo y bien escrito algunas de las tecnicas que ya estaban por aquí: Login Bypass, AND LDAP Injection, OR LDAP Injection, Charset Reduction, Blind LDAP Injection, etc... muy bien organizadas.

A parte de eso, tiene algunos detalles dignos de comentar:

1) Componente y Servidor utilizado

En la parte de login bypass, el ataque se realiza con una inyección que genera dos filtros. Hay que recordar que estos ejemplos sólo son válidos en implementaciones tipo OpenLDAP en los que toma el segundo filtro como una lista de atributos y, aunque no sea correcta la lista, ejecuta la consulta. Tambien es funcional si está trabajando con implementaciones en las que se usan componentes como el IPWORKs que limpia todo lo que hay detrás del primer filtro correctamente construido [más sobre esto en: Jugando con LDAP]. Los ejemplos de login bypass en diferentes arquitecturas los tenéis en este artículo: Or 1=1 en LDAP.

2) Modificación Ldap

El artículo trae un parte en la que explica que se puede modificar los valores de los objetos si se detecta el uso de rutas ldap en parámetros de llamada a la función ldap_modify de PHP.

bool ldap_modify ( resource $li , string $dn , array $entry );

No suele ser fácil detectar esta llamada, pero es curioso el ejemplo que pone. Así mismo, se pueden hacer cosas similares si se detectan las funciones ldap_mod_replace(), ldap_mod_del() o ldap_delete().

3) Atacar LDAP desde el motor SQL Server

Este ejemplo de ataque si que me ha parecido chulo. La idea es utilizar un servidor SQL Server vulnerable a SQL Injection para enlazar a él el servidor LDAP Interno de la organización y, mediante el uso de OPENQUERY lanzar consultas al LDAP desde una aplicación web vulnerable. Muy chulo. El componente que usan es ADSDSOObject y lo hacen contra un Windows 2000 Server. Me gustaría comprobar en que motores de bases de datos viene cargado por defecto y si hay algo similar para Windows Server 2003 y 2008, pero la idea es chula de por sí.

Primero se crea el servidor enlazado en SQL Server:

EXEC sp_addlinkedserver 'ADSI', 'Active Directory Services 2.5', 'ADSDSOObject', 'adsdatasource'

Y luego se lanzan las consultas:

SELECT [Name], SN [Last Name], ST State FROM OPENQUERY( ADSI,'SELECT Name, SN, ST
FROM ''LDAP://ADserver/DC=ribadeohacklab,OU=Sales,DC=sales,
DC=ribadeohacklab,DC=com,DC=ar'' WHERE objectCategory = ''Person'' AND objectClass = ''contact''')

4) Connection String Attack en LDAP

El último elemento destacable es el ataque a la cadena de conexión a un árbol LDAP. Nosotros estuvimos mirando la posibilidad de realizar un CSPP a conexiones LDAP pero no llegamos a encontrar el componente con el comportamiento "polucionable" deseado. En este caso, con el componente citado anteriormente para AD, realizan una cosa curiosa. No es una polución como tal, sino un desplazamiento de parametros para sustituir un valor por su valor por defecto.

El ejemplo que ponen es, dada esta cadena de conexión construida dinámicamente:

objConn.ConnectionString = "Provider=ADsDSOObject;User Id=" + \
user +";Password="+ passwd + \
";Encrypt Password=True;ADSI Flag=" + \
str(ADS_SECURE_AUTHENTICATION + ADS_SERVER_BIND)

Introducir un contraseña del tipo: s3cr3t;x

Esto genereraía que el valor de Encrypt Password pase a ser x y, como no es un valor válido, sea sustituido por el valor por defecto, en este ejemplo false, desplazando el atributo completo de Encrypt Password a lss Extended Properties, es decir:

Provider=ADsDSOObject;User
ID=someUser;Password=s3cr3t;Encrypt
Password=False;Extended
Properties="xxx;Encrypt
Password=True";Mode=Read;Bind
Flags=0;ADSIFlag=513

Es un comportamiento peculiar el de este componente aunque no parece polucionable.

En definitiva, el artículo es una buena recopilación y algunas buenas ideas nuevas.

Saludos Malignos!