Usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source

Fue allá por el año 2007 comencé a trabajar en las técnicas de LDAP Injection & Blind LDAP Injection que a la postre sería mi primera charla internacional en BlackHat Europe 2008, donde presenté el paper de "LDAP Injection & Blind LDAP Injection in Web Applications" que puedes ver online. En aquel entonces, busqué aplicaciones vulnerables que pudiera usar de ejemplo, y para ello tire de proyectos Open Source, haciendo dorkings y mucho Hacking con Buscadores para encontrar las víctimas propicias.

Figura 1: Usar Deep Reasoning en GitHub para buscar

( y parchear ) Bugs en proyectos Open Source

Una de ellas fue LABE (LDAP Address Book Editor) un aplicación web para tener una libreta de direcciones basada en un árbol LDAP. Por supuesto, vulnerable a las técnicas de LDAP Injection & Blind LDAP Injection.

Figura 2: El bug de LDAP Injection en el código fuente de LABE

Ayer, después de estar revisando un nuevo paper de cómo utilizar LLMs para hacer ataques de red - del que os hablaré muy prontito - me vino el pensamiento de sería mucho más fácil y más seguro si los repositorios de código fuente tuvieran ya metadatos de seguridad y bugs para todos los proyectos que hospedan analizados con modelos de Deep Reasoning.

Figura 3: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Repositorios que te alertan de los bugs

Es decir, tú vas a un proyecto OpenSource en GitHub u otros, y el repositorio ha revisado ya todo el código y muestra a los usuarios que se los van a descargar si tiene vulnerabilidades conocidas o no, para que no te lo descargues o para que le llegue un aviso al mantenedor de que ese código debe ser actualizado o se marcará como inseguro. Y que le de con GenAI opciones de parchear el código automáticamente, como hace la plataforma Plexicus, que está empujando José Palanco.

Figura 4: Plexicus parchea con GenAI los bugs

Ahora mismo, los repositorios tienen secciones de "issues" donde se pueden reportar bugs, fallos, warnings, etcétera, pero todos hechos por "humanos" por ahora, y tal vez deberían estar ya aprovechando el mundo de los LLMs para mejorar la seguridad de los proyectos OpenSource de "long-tail" de manera masiva. Yo he ido a probar con el repositorio de LABE y le he pasado el código a Perplexity Pro con Deep Research, y le he pedido que busque bugs en uno de los ficheros del proyecto, y me diga cómo parchearlos.

Figura 5: Bug de LDAP Injection alertada en LABE

El primero de todos los bugs que reporta es el que ya conocía yo de LDAP Injection, pero el proyecto sigue están disponible para que más usuarios se lo descarguen sin ningún warning, y la lista de bugs es más larga.

Figura 6: LABE tiene bug de XSS persistente

Como podéis ver  en la imagen anterior, tiene un XSS persistente, pero a día de hoy cuenta también con funciones obsoletas, y acceso inseguro a variables globales como $_GET que además está obsoleta. Normal, este código tiene muchos años.

Figura 7: Más debilidades en el código de LABE

No se trata de "demonizar" LABE, sino de ver lo bien que lo hacen los modelos de Deep Reasoning para buscar debilidades y fortificaciones a un código Open Source en un repositorio, y que si lo hace el propio repositorio una vez, nos ahorramos hacerlo todos una y otra vez para ver qué nos estamos instalando.

Figura 8: CSRF y fallos de inicialización

No le he pasado todo el proyecto, sólo un fichero que ya tenía controlado con un LDAP Injection, pero como podéis ver en las imágenes ha salido también XSS, CSRF que son Client-Side Attacks, errores no controlados, variables sin inicializar, uso de funciones deprecadas, etcétera, lo que sería información muy valiosa que podría venir en los repositorios de código como GitHub y los gestores de paquetes.

Figura 9: Bug CVE-2024-35226

También nos aparece un bug en la "cadena de suministro", ya que en el año 2024 se reportó un bug con severidad 7.3 en el framework de smarty que permite inyección de código, lo que demuestra que hay que tener un control constante de tus librerías para evitar estos peligros.

Análisis con DeepSeek Deep Think R1 

He querido probar con un repo de GitHub que también hace uso de búsquedas en árboles LDAP y que en este caso está escrito en C++, para ver cómo hace el análisis, y si GitHub podría hacer este análisis con su GitHub Copilot y dejar la info en forma de Warnings a los que se descargan el código.

Figura 10: QLDAP Editor en GitHub

Entiendo que poner issues de seguridad en los repos puede ayudar a los atacantes, pero es que los atacantes pueden hacer este trabajo, tener un 0day de un repo de long-tail y tener a GitHub entregando descargas a nuevas víctimas durante años.

Figura 11: Thinking de Deep Seek

Os ahorro las capturas del Prompt donde le paso el código del fichero que ves en la Figura 9 y le pido que busque bugs y me diga cómo corregirlos. Pero en la Figura 10 tenéis el Thinking que sí es interesante, pues en 19 segundos analiza el código y saca los resultados.

Figura 12: DeepSeek reporta un LDAP Injection

Como se puede ver, lo que reporta es  un LDAP Injection en primer lugar, ya que construye los filtros LDAP de las consultas sin ninguna sanitización, y eso se puede ver en el código como os dejo a continuación.

Figura 13: Construcción de filtros LDAP inseguros

Pero es que el análisis completo es bastante bueno, ya que sigue analizando el código y todas las implicaciones y las explica muy bien. Por ejemplo, cómo acceder con la inyección a atributos sensibles como passwords que pudieran existir en el árbol LDAP.

Figura 14: Explotación de LDAP Injection con manipulación de parámetros

En la siguiente imagen vemos cómo reporta también un problema de flujo de la lógica al no escapar los caracteres de control de LDAP que podrían cmabiar el comportamiento.

Figura 15: Escapado de caracteres de control

Y si seguimos viendo el informe, podemos ver cómo el tratamiento de errores no es seguro, permitiendo problemas en el funcionamiento del programa pero también Data Leaks de la estructura de la red al no haber controlado los errores de conexión al árbol LDAP.

Figura 16: Errores no controlados.

Para terminar aún nos da unas recomendaciones más que sensatas de seguridad añadidas que deberían ser tenidas en cuenta, como son estas dos, que yo las tendría en cuenta. Este código no lo conocía de antes, ni sabía si era vulnerable a LDAP Injection o no, y ni mucho menos del resto, pero si miráis en los issues, no hay nada de esto. 

Figura 17: Recomendaciones finales

Al final, desde hace años ya conocemos las capacidades de los LLMs para buscar bugs, esto es de lo primero que probamos, por supuesto. Así que si las usamos para fomentar que los proyectos OpenSource alerten a los usuarios que se los descargan, para que los repositorios de código incentiven a los mantenedores a parchearlos, o que lo hagan de forma automática ayudaría a reducir los bugs que acaban en los servidores de las víctimas.

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Ataques DDoS con amplificación vía CLDAP (Connection-less LDAP) en la botnet Mirai

Como supongo que la mayoría de vosotros sabéis, el ataque de DDOS de la semana pasada fue realizado con la botnet Miari. Multitud de dispositivos controlados remotamente para atacar un único objetivo y hacer que la potencia sea tal que no pueda dar servicio. Pero para generar tal cantidad de tráfico - se habla de picos de 1.2 TBps - no basta con controlar muchos dispositivos, sino de amplificar todo lo que se pueda la generación de tráfico.

Figura 1: Ataques DDoS con amplificación vía CLDAP (Connection-less LDAP) en la botnet Mirai

Supongamos un equipo conectado en una casa particular con una línea de comunicaciones de 1MB que forma parte de la botnet. A priori, parece lógico pensar que este equipo puede aportar hasta un máximo de 1MB en el ataque total de la red, pero los atacantes, desde hace tiempo, utilizan técnicas de amplificación para conseguir que este dispositivo infectado genere mucho más tráfico que ese MB. Y aquí es donde la empresa Corero Network Security dice que Mirari utilizó un nuevo 0day en el protocolo CLDAP para conseguir este efecto.

Ataques de amplificación

Los ataques de amplificación no son nuevos, y podemos irnos muchos años atrás para ver cómo funcionaba el Ataque del Pitufo (Smurf Attack) y entender el proceso. Básicamente, todos los ataques de amplificación se basan en buscar una conexión de Internet de gran potencia (mucho más de 1MB) que ante una petición de tamaño X genere una respuesta de tamaño Y, donde el tamaño de Y es mayor que el de X. Se dice que la respuesta entonces está amplificada en un factor K > 1 tal que Y= K* X.

Figura 2: El ataque Smurft hacía amplificación con paquetes ICMP enviados a direcciones broadcast

Cuanto mayor sea el factor K, mayor tráfico se conseguirá con un bot en una conexión de 1MB. Supongamos que ante una petición DNS un atacante, con enviar una petición de 20 bytes consigue una respuesta de 80 bytes. En ese caso estaríamos hablando de una petición que consigue un factor de amplificación 4, con lo que un equipo controlado detrás de una conexión de 1MB sería capaz de conseguir un total de 4MB de tráfico de respuesta.

Figura 3: Ejemplo de un ataque simple de DNS amplification

El objetivo de los ataques de amplificación es conseguir que ese tráfico generado desde el servidor no sea enviado al equipo que originó la petición - en este caso el bot detrás de la conexión de 1 MB - sino que acabe en el servidor que se quiere atacar. Para eso, hay que conseguir hacer un ataque de spoofing - o suplantación de dirección IP - y para ello lo más sencillo es que se haga con servicios que funcionen sobre el protocolo UDP.

Por supuesto, en el pasado hemos visto ataques de spoofing sobre protocolo TCP, pero estos deben realizar la negociación de la conexión a ciegas, y la existencia de algoritmos robustos de generación de los números de secuencia TCP dificultan estos ataques - amen de protección en dispositivos de red que tienen sistemas de alerta contra este tipo de ataques -.

Un 0day de CLDAP (Connection-Less LDAP)

A lo largo de la historia hemos visto muchos tipos de ataques de amplificación. Ataques de DNS amplification como se utilizaron en el ataque de Spamhaus o de NTP amplification - además del ataque del pitufo citado anteriormente -. Ahora, según parece, hay un 0day que podría afectar al protocolo CLDAP.

Figura 4: Servidores usados en ataque DDoS de 400 GBps con NTP amplication en 2014

Según la empresa Corero Network Security, entre el tráfico detectado en el ataque de Mirai a Dyn se detectó mucho tráfico de respuestas CLDAP, lo que apunta a que se ha descubierto un 0day que permite hacer una amplificación con estas peticiones suplantando la dirección de origen de la petición CLDAP. Esto es así porque el protocolo CLDAP permite realizar conexiones UDP a los árboles LDAP, lo que facilita el proceso de suplantación.

El protocolo CLDAP puede estar habilitado en tus árboles LDAP e incluso Active Directory de Microsoft soporta este tipo de conexiones para acelerar los procesos de consulta a los objetos del árbol LDAP que da soporte a AD.

Figura 5: MS-CLDAP en Active Directory

En el libro de Hacking Web Technologies, yo le dediqué todo un extenso capítulo a los ataques a servidores LDAP y cómo protegerse de ellos, pero no hacía por supuesto ninguna referencia a este posible 0day. Ahora que es público, lógicamente, si tienes servicios LDAP abiertos a Internet, debes mirar si tu servidor soporta conexiones vía UDP de tipo CLDAP, porque entonces puedes ser parte de los ataques como elemento amplificación.

Saludos Malignos!

Nuestro nuevo libro de "Hacking Web Technologies" @0xWord #pentesting #hacking

Hoy estoy contento, pues después de varios meses de trabajo ya esta disponible desde hoy un nuevo libro de 0xWord en el que he podido trabajar con grandes amigos. Haciendo equipo con Enrique Rando, Pablo González, Ricardo Martín y Amador Aparicio hemos escrito un libro orientado al pentesting y hacking de tecnologías web, y desde hoy lo puedes comprar: Hacking Web Technologies

Figura 1: Nuestro nuevo libro de "Hacking Web Technologies" @0xWord

El libro está centrado en explotar diferentes vulnerabilidades de los sistemas basados en tecnologías web, sin tocar para nada las técnicas de SQL Injection, de las que ya sabéis que escribimos otro libro Enrique Rando y yo. En éste libro nos centramos en otros tipos de ataques como son, por ejemplo, los ataques a las tecnologías LDAP, ataques a Connection String, los ataques de Info Leaks, las técnicas de Local File Inclusion o XPath Injection. 

Figura 2: Libro de Hacking Web Technologies

Además, en el libro se tocan temas como el uso de herramientas de auditoría web como ZAP Proxy de manera profesional, las técnicas de ataque de PHP Object Injection o la explotación de ataques de MongoDB Injection. El índice del libro lo he subido a SlideShare para que lo podáis ver en detalle.

Figura 3: Índice del libro "Hacking Web Technologies"

Este es el libro número 40 de la colección de libros de 0xWord, y por ahora está dentro ya del pack de Colección Completa, aunque probablemente lo incluyamos pronto en algún pack. Puedes comprarlo online y solicitarlo a nuestros distribuidores en latinoamérica para que te llegue lo antes posible.

Saludos Malignos!

Tres info leaks que puedes aprovechar en phpLDAPadmin

Hace mucho tiempo ya que le dediqué una entrada a este cliente de administración web para árboles LDAP escrito en PHP. En aquel entonces le dediqué el post a phpLDAPadmin porque en el interfaz es posible acceder de forma anónima a muchos árboles LDAP como si los directorios estuvieran publicados en Internet. Una forma sencilla de acceder a información de una organización.

Figura 1: 3 Info Leaks en phpLDAPadmin

Durante este tiempo atrás he vuelto a revisar este software debido a un par de motivos. El primero de ellos es porque en el nuevo libro de 0xWord que vamos a publicar en breve yo he tenido que hacer un par de capítulos, y uno de ellos se lo he dedicado a las tecnologías LDAP. El segundo, debido a un estudio que espero tengamos publicado en breve sobre unas técnicas de hacking que tienen que ver con estos paneles de administración.

Es por culpa de este último, que vine a comprobar si este panel de administración cumplía las características necesarias para estar incluido, y aunque no fue así, disfrute volviendo a jugar un poco con este software para descubrir tres fugas de información fáciles de extraer en el caso de que topes con él en una auditoría de seguridad.

1.- Lista de servidores LDAP y usuarios cacheados

La primera de las fugas de información es tan sencilla como que el panel de administración muestra el nombre de los servidores LDAP incluso para los usuarios desconectados. Esto es así debido a que para poder administrar uno de estos servidores LDAP con la herramienta phpLDAPadmin primero hay que dar de alta los servidores. Así, con solo ver el panel puedes saber el nombre que le han dado al servidor.

Figura 2: árbol LDAP listado y objeto usuario cacheado

Puede no ser muy significativo, o puede que sí que lo sea, pero lo cierto es que el nombre debe estar configurado antes de que te puedas conectar y sale en el árbol de la izquierda. A veces, incluso te puedes encontrar cacheado el objeto de algún usuario por defecto con el que se realiza el proceso de Binding por defecto, tal y como se ve en este ejemplo.

2.- El modo Debug por defecto

El punto 1 que os he puesto no está puesto por casualidad. A pesar de ser una fuga de información bastante sencilla, resulta que es la causante de otra que he encontrado activada en todos paneles de administración que he visitado. Cada servidor que se da de alta en la lista de servidores a administrar recibe un server_id. Este server_id va por parámetro GET y cuando un usuario quiere hacer login uno de los servidores LDAP de la lista de árboles disponibles, debe indicarse mediante un valor numérico. El primer servidor tiene server_id=1, el segundo server_id=2, etcétera.

Figura 3: Server_id=4 para iniciar sesión en el servidor LDAP número 4

El problema es que cuando se pide un server_id que no existe, por ejemplo, un server_id=99, la aplicación da un error que si tienes el modo DEBUG activado, muestra por pantalla la ruta de instalación del software. 

Figura 4: Error en modo DEBUG en phpLDAPadmin en el sitio oficial de demo

El modo DEBUG viene por defecto configurado y en todas las instalaciones, incluso en la que tienen de demo en el sitio web del proyecto (que no parece que esté muy vivo pues la última versión es de 2013), se puede comprobar este comportamiento.

Figura 5: Config.php define el modo de DEBUG de phpLDAPadmin

Si tienes este software y quieres evitar este leak de información debes cambiar el modo DEBUG para que no se muestre por pantalla toda la ruta a los ficheros del servidor.

3.- El comando Server_Info

El último de los leaks de información tiene que ver con la forma en la que se invocan los comandos. Si descargamos el código fuente de la aplicación - ya que es OpenSource - veremos que los comandos en realidad son ficheros PHP dentro del directorio que se invocan con el programa cmd.php?cmd=Nombre_fichero.

Figura 6: Archivos de phpLDAPadmin en una instalación en el servidor web

Así, en la figura superior se puede ver que para hacer login la URL de llamada es cmd.php?=login_form&server_id=x porque el fichero PHP que hay que invocar es login_form.php. Invocando todos, uno a uno, es posible ver que server_info es posible llamarlo para obtener la información del objeto RootDSE, donde ya se puede obtener mucha información del servidor sin ni siquiera haber hecho login.

Figura 7: Acceso a la información de RootDSE sin haber hecho login. Es un OpenLDAP

En primer lugar se puede acceder al domain_name del servidor, expresado en formato de objeto LDAP. En segundo lugar se puede sacar información importante, como la versión del software del árbol LDAP (en este caso un OpenLDAP) y los protocolos de autenticación soportados.

Figura 8: Protocolos de autenticación soportados por el servidor LDAP

Como se puede ver, en este ejemplo estamos ante un servidor LDAP que permite autenticación sistemas de autenticación inseguros, pero en este otro se permite GSSAPI, un sistema que deja negociar autenticación SIMPLE, lo que tal y como se explica en el libro de Ataques en redes de datos IPv4&IPv6 permite ataques de man in the middle a las conexiones LDAP con downgrade de protocolo de autenticación.

Figura 9: Árbol LDAP con autenticación GSSAPI

Al final, si tienes estos paneles de administración de servidores - ya sean de motores SGBDR, árboles LDAP, estadísticas, monitorización de servicios, etcétera, lo mejor es que no estén publicados a Internet. Si los tienes en la intranet, revisa su seguridad constantemente, ya que puede que estos proyectos se queden sin soporte o que aparezcan nuevas técnicas de explotar nuevas vulnerabilidades, así que no te relajes ni un ápice. Además de todo esto, phpLDAPadmin no tiene Segundo Factor de Autenticación, así que además de arreglar estas tres cosas, si alguien quiere un proyecto de desarrollo para hacer, integrarle Latch sería sencillo para dejarlo aún más seguro.

Saludos Malignos!

Cómo NO debes publicar y retirar una app de Google Play

Con tanto ajetreo de viajes casi no he tenido tiempo de sentarme un rato a disfrutar del placer de la tecnología durante las últimas dos semanas. Cada momento lo he llevado cronometrado, tanto que he tenido que quitarle tiempo a las horas de sueño y descanso. Una vez acabado mi periplo por latinoamérica, me queda aún conseguir adaptar mi cuerpo a los horarios de sueño de la franja horaria de España por lo que hoy he estado en pie desde las 5 de la mañana y me he puesto a leer un rato los RSS, contestar algunos de los cientos de correos electrónicos que tengo sin procesar y, cuando me he aburrido, he ido a probar alguna cosa que tenía en mente con los servidores LDAP y las apps de Android.

Figura 1: Cómo NO debes publicar y retirar una app de Google Play

Como sabéis, desde hace años me gusta jugar con las técnicas de LDAP Injection y quería buscar algún ejemplo con un tipo concreto de servidor LDAP para probar unas cosas. Para ello, haciendo uso de Dorking & Pentesting con Tacyt, me busqué algún backend que pudiera estar construido en LDAP y que tuviera alguna aplicación para consultarlo.

Figura 2: Buscando apps en Android con links a LDAP

Como se ve aparecen 14 apps, pero una de ellas me llamó especialmente la atención. Se trata de una app que tenía el backend de acceso a los servidores LDAP construido con WebServices, tal y como ya publicamos en un artículo anterior. 

Figura 3: Enlaces a un backend LDAP accedido vía WebServices

Por desgracia, la app parecía que había sido retirada de Google Play hacía algún tiempo, así que lo más probable es que no estuviera ya disponible el backend. Es lo que se debe hacer cuando se retira una app del mercado.

Figura 4: La app estaba retirada de Google Play

Sin embargo, al probar se puede alcanzar la información de los WebServices aún activados, así que si tenía un poco de suerte tal vez toda la infraestructura detrás de la app también estaría funcionando.

Figura 5: El backend aún activo

Al mirar WebsService concreto para obtener información de los usuarios se puede comprobar que necesitamos unas credenciales de acceso. Por supuesto se puede intentar hacer un ataque de LDAP Injection en el acceso, pero en esta ocasión lo que hace la aplicación es utilizar el usuario y contraseña para hacer un Bind contra el árbol LDAP y luego genera el LDAP Search Filter con el resto de los parámetros XML, con lo que se necesita un usuario y password sí o sí para poder hacer la consulta al árbol.

Figura 6: Petición SOAP al WebService para hacer un LDAP Search Filter al árbol LDAP

Por supuesto, aunque la app está retirada, nosotros tenemos copia en Tacyt, así que me la descargué, la descomprimí, la decompilé y llegué al fichero donde la app - ya retirada del market - tenía configurado el usuario y contraseña para hacer Binding en el árbol LDAP. No deberías poner tus passwords en tus apps.

Figura 7: Código de construcción de llamada al WebService en la app con datos de árbol LDAP

El resto es sencillo. La petición SOAP va por POST, así que basta con abrir una herramienta como Burp y usando el Repeater hacer la petición al WebService para consultar al árbol LDAP.

Figura 8: Construcción de petición SOAP en Repeater de Burp

Figura 9: Respuesta del WebService con la salida del LDAP Search Fileter

El resto ya es probar los LDAP Search Filters y comprobar si la aplicación web es o no vulnerable a LDAP Injection, que tal y como se puede ver es así ya que podemos incluir parámetros en la consulta para hacer las pruebas que quería hacer.

Figura 10: Respuesta de error forzada con filtro LDAP inyectado

Recapitulando, en un solo ejemplo nos hemos topado con una app publicada en el market que tiene los siguientes errores de publicación y retiro de la app:

1) Tiene los WebServices del Backend expuestos a Internet.
2) Son vulnerables a LDAP Injection por medio de la llamada SOAP.
3) Publicó la app con las credenciales hardcodeadas.
4) Retiró la app y no retiró el servicio de backend.
4) Retiró la app y no cambió las credenciales.

Nunca se debe hardcodear una credencial, pero especialmente si retiras la app deberías retirar todo y cambiar las contraseñas que utilizaste.

Saludos Malignos!

Una tarde de e-mulero: Parte 1

Este domingo por la tarde tenía algo de tiempo que perder mientras intentaba no morirme en los calores de este año, así que decidí darle un repaso a la red P2P con el e-mule, que me dejó bastante tocado la historia del robo de identidad por culpa de un DNI publicado en la red. Documentación sigue habiendo en la red a patadas, no solo DNIs o Pasaportes o tarjetas de crédito, sino que puedes encontrar hasta nóminas de trabajadores.

Figura 1: Ficheros con nóminas personales en la red P2P

Con ese punto de partida, me puse a ver hasta que niveles de falta de conciencia se podría llegar con el uso del e-mule, así que me puse a buscar cosas que pudieran estar compartidas en la red al alcance de cualquiera... y salió de todo. Empecé con cosas básicas, como facturas, recibos y resguardos de transferencias bancarias. Y de todo ahí y en buenas cantidades. La privacidad de los datos parece importar poco.

Figura 2: Datos de una transferencia hecha en Junio de 2013

Después busqué cosas más curiosas, como las tarjetas de embarque de las compañías de vuelo o nombres de fotografías generados automáticamente por cámaras de fotos digitales y terminales móviles, ya sabéis, los típicos DSC_XXX, para ver sus metadatos y la información que se podría sacar. Y te puedes cansar.

Figura 3: Metadatos de fotos volcadas y boarding pass con número de viajero frecuente

Pasé a ver los certificados digitales, con sus claves privadas, a ver si había ficheros PFX con las claves privadas exportadas desde Internet Explorer o P12 exportadas desde Firefox, a ver qué salía.

Figura 4: Claves privadas de certificados digitales

Lógicamente, si habían salido los certificados digitales, encontrar copias de seguridad de bases LDAP exportadas en formato LDIF iba a ser bastante más sencillo de encontrar dentro de la red.

Figura 5: Exportaciones de datos LDAP en formato LDIF

Ya que había de todo, pensé en los ficheros de configuración de los accesos a servidores remoto vía RDP de Terminal Services o vía ICA de Citrix, a ver si alguien estaba compartiendo sus conexiones, y por supuesto también estaban por allí.

Figura 6: Conexiones a RDP y Citrix

Visto que solo había que desear algo para que apareciera, decidí rizar el rizo con alguna cosa aún más extraña todavía... pero os lo cuento mañana mejor, que en verano las lecturas largas cansan más.

Saludos Malignos!

**************************************************************************************
- Una tarde de e-mulero: Parte 1
- Una tarde de e-mulero: Parte 2 {Mis amig@s de Apple}
**************************************************************************************

6.317 bugs de LDAP Injection (y alguno más)

Ayer, en el Curso Online de Auditoría y Seguridad Web, me tocó impartir la sesión destinada a (Blind) LDAP Injection y (Blind) XPath injection. En esa sesión utilicé las mismas diapositivas que tanto me costó cerrar para mi primera charla de Black Hat en la que hablamos de eso mismo (Blind) LDAP Injection Attacks in Web Applications.

LDAP Injection & Blind LDAP Injection de Chema Alonso

En una de las últimas diapositivas [en la número 48 exactamente] aparece la referencia a una sección de código de un proyecto que, en los tiempos en los que estuve preparando todo el trabajo sobre los ataques LDAP Injection, usé como ejemplo en muchas charlas, pero que nunca publiqué en ningún sitio.

El fallo es un bug de LDAP Injection en LABE (LDAP Address Book Editor), un proyecto que añade una libreta de direcciones web a tu árbol LDAP, es decir, te permite tener contactos en tu Active Directory como si fuera una web con un listín de teléfonos y basta con echar un vistazo al código para ver que en las consultas de búsqueda no se está filtrando ninguno de los valores que vienen por POST para realizar consultas.

Figura 1: LABE (Ldap Address Book Editor)

En su momento descargamos este software, lo instalamos e hicimos pruebas de LDAP Injection sobre Active Directory, pero es que se puede ver a la legua que es inyectable, sin necesidad de dejarse los ojos analizando.

Figura 2: El bug de LDAP Injection en el código fuente

Hoy he ido a revisar si habían solucionado el bug y he visto que no, así que, cuando me he fijado en  que ya había más de 6.000 descargas he pensado que ya era hora de avisarles para que lo arreglaran y les he puesto un mensaje de aviso para que lo solucionen.

Figura 3: Descargas de LABE a lo largo del tiempo

Lo curioso es que desde que se publicó el paper de LDAP Injection y Blind LDAP Injection he dicho en todas las charlas que basta con ir a los repositorios de código y buscar filtros LDAP - casi como si fueras un analizador de código estático usando Google que a mi me encanta el hacking con buscadores - y darse cuenta para ver que hay una gran cantidad de proyectos con bugs LDAP Injection activos.

Figura 4: Proyectos en Google Code con ldap_filters

Mientras que escribo este post, y aprovechando un poco de desvelo nocturno, he buscado algunos bugs más de LDAP Injection y hay aún para dar y tomar. Ya os publicaré más adelante alguno más, explicado en detalle. Pero si te aburres puedes ponerte a ello ya mismo.

Saludos Malignos!