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)  

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!

Examen del Máster de Seguridad de la UEM 2016

Como viene siendo tradición, un año más he vuelto a "torturar" a mis alumn@s con un examen al final del módulo dedicado a la seguridad de las aplicaciones. No me gusta ser excesivamente maligno, así que más o menos pongo siempre los mismos exámenes pero cambiando las preguntas porque, en este módulo de 16 horas, yo quiero que se lleven claros algunos conceptos básicos fundamentales. Estas son las preguntas que les tocó responder ayer a última hora. Anímate a responderlas.

Figura 1: Examen del módulo de Seguridad en las Aplicaciones del
Máster de Seguridad de la UEM. Curso 2015 -2016

A ver si saco algo de tiempo para responderlas yo - y las del último examen que también las dejé sin responder - para que tengáis la información completa. Al final os dejo la lista de exámenes de años anteriores.

1.- Tu organización dispone de una aplicación web de cara a internet consistente en ofertar productos y servicios con pasarela de pago propia desarrollada para una plataforma Java utilizando tecnologías Linux. Los datos de registro de los clientes, así como los pedidos solicitados se almacenan en una base de datos MySQL de la empresa, gestionando todo el proceso a través de la lógica de negocio. ¿Qué mecanismos de protección consideras que deberían implantarse en cuanto a la arquitectura de servidores y servicios se refiere? Cita reglas generales de fortificación y algunas medias concretas que creas convenientes para implantar.

2.- Una aplicación web de una empresa proporciona un proceso de autenticación que sospechamos un tanto curioso. Al analizar el código fuente de la página, vemos que la aplicación utiliza para el proceso de autenticación un Applet de Java con extensión JAR. Tras probar varios intentos de inicio de sesión, detectamos que no se produce Post-Back al servidor. ¿Qué fallo de seguridad podría tener esta aplicación y cómo debería investigarse?

3.- En qué consiste un ataque de tipo SQL Injection inband a una aplicación web. Pon algún ejemplo para sacar la lista de usuarios Tabla_USERS[Campo_Login, Campo_Password] de una web en un entorno vulnerable.

4.- Describe en qué consisten los ataques de Time-Based Blind SQL Injection y con qué tipo de funciones o métodos pueden realizarse en los motores de base de datos SQL Server, MySQL, Oracle y Access.

5.- Describe con tus palabras en qué consisten los ataques de LFI y cómo los podrías descubrir en una aplicación web durante un proceso de auditoría.

6.- Una aplicación web en PHP con MySQL es vulnerable a SQL Injection. Se quiere extraer la versión de Mysql realizando un ataque de Blind SQL injection. Describe el proceso que habría que realizar.

7.- En una aplicación web, la aplicación autentica a los usuarios con un árbol LDAP, para ello, cada usuario tiene un atributo uid y un atributo password. El programador ha filtrado el * y utiliza la función crypt antes de usar la contraseña en una consulta AND LDAP como ésta.

V_username: valor de usuario introducido en la página web por el cliente.
V_passwd: valor de contraseña introducido en la página web por el cliente.
C_passwd =crypt(v_passwd)
Consulta que da acceso o no a la aplicación:
(&(uid=+v_username+)(password=+c_passwd+))
¿Con qué inyección LDAP conseguirías entrar si la se está utilizando un árbol LDAP basado en OpenLDAP?

8.- Como administrador del sistema de tu organización, una mañana monitorizas que el antivirus corporativo reporta un malware en un directorio local del servidor donde tu empresa tiene alojado el sitio web. El archivo en cuarentena es un fichero denominado C99.php. ¿Qué tipo de ataque estás sufriendo y qué fallo o fallos de seguridad se ha/n podido aprovechar?

9.- Describe un posible método para robar una cookie marcada como HTTP-Only con un ataque de XSS y describe en qué entornos funcionaría.

10.- Describe como se puede hacer un proceso de hijacking de sesión a un usuario de una red social en la que las cookies no vayan por HTTP-s si en la web no se ha descubierto ninguna vulnerabilidad de código (ni SQLi, ni XSS).

Tiempo: 1 hora

Por si te animas a seguir, aquí tienes los exámenes de años anteriores, que también los he ido publicando en el blog.

- Examen Máster de Seguridad de la UEM 2009-2010
- Examen Máster de Seguridad de la UEM 2010-2011
- Examen Máster de Seguridad de la UEM 2011-2012
- Examen Máster de Seguridad de la UEM 2012-2013
- Examen Máster de Seguridad de la UEM 2013-2014
- Examen Máster de Seguridad de la UEM 2013-2014 (Herramientas auditoría)
- Examen Máster de Seguridad de la UEM 2014-2015

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!

Dorking & Pentesting con Tacyt: Inyección de comandos

En cualquier auditoría de una aplicación web es importante buscar los puntos en los que se introducen los comandos. Decía Michael Howard que "All input is EVIL until it proves otherwise" para referirse a la necesidad de controlar absolutamente todos los datos de entrada de un sistema sin importar de donde vengan. En el mundo del pentesting, localizar las entradas de parámetros pronto y testear las inyecciones de comandos de las distintas tecnologías es algo básico que se hace siempre.

Figura 1: Dorking & Pentesting con Tacyt. SQL Injection,
LDAP Injection y Command Injection

En el mundo del dorking masivo se ha utilizado mucho en el pasado a través de los buscadores. Hemos visto ataques SQL Injection realizados masivamente que se han llevado millones de aplicaciones web inseguras indexadas en Google, hemos visto campañas de explotación masiva que se han llevado a Apple.com por delante, y hemos visto como a través de buscadores como Shodan o los mismos buscadores de repositorio de código OpenSource se crean dorks para localizar sitios vulnerables. Esto también lo podemos hacer buscando en el código de las apps.

(Blind) SQL Injection

No voy a centrarme mucho en explicar los ataques de SQL Injection o Blind SQL Injection, ya que de ellos he escrito largo y tendido en el pasado e incluso tenéis un libro en 0xWord para profundizar más [Hacking Web: SQL Injection]. En esta parte, cuando comencé a mirar si con las apps se podría llegar fácilmente a localizar sitios de backend vulnerables a SQL Injection comencé por buscar enlaces con parámetros como SQLQuery o Query y luego nombres de aplicaciones en el backend que fueran como MySQL.php, SQL.php, QuerySQL.aspx, etcétera y salió de todo.

Figura 2: Un enlace en una app para conectarse a una base de datos

Como era de suponer, muchas de estas aplicaciones en backend no están indexadas en otros buscadores y por supuesto no están sometidas a los dorks de búsqueda masivos que hay ya creados para todos esos motores, así que aún no han sentido la importancia de revisar mucho el código de ejecución de una consulta SQL para detectar los ataques de SQL Injection.

Figura 3: Código decompilado de una app con ShowMyCode
para ver los parámetros de SQLQuery.php

Algunos de estas aplicaciones envían, como es normal, el envío de parámetros por POST usando un URLEncodedFormEntity, por lo que es cierto que cuando se descubre el enlace, en muchas ocasiones hay que decompilar el código (descomprimir el APK, decompilar el classes.dex, y con los ficheros en Bytecodes .class hacer un ShowMyCode para el ver el fichero Java y sacar los parámetros). El resto, inyectar con cualquier herramienta tipo Burp Proxy o similares.

Figura 4: En el parámetro Query basta con poner la consulta. FAIL!

Buscando por cosas como DBlink, QueryBBDD, BDD.php, SQLServer, etcétera, el resultado es que aparecen miles de resultados que llevan a backends con poca o ninguna protección contra ataques de inyección de comandos SQL.

Figura 5: Otro enlace en una app sin ningún tipo de protección en el parámetros query

(Blind) LDAP Injection

Desde hace años llevo yo jugando personalmente con las inyecciones de comando LDAP - tenéis el whitepaper que hicimos para BlackHat 2009 [(Blind) LDAP Injection] - y uno de los problemas ha sido siempre el encontrar entornos LDAP expuestos en Internet, ya que la mayoría de los árboles están siempre en la red interna. Por eso yo buscada en Shodan, con trucos en Robtex y hasta en las listas CRL de los certificados digitales para poder inspeccionar los árboles LDAP. 

Figura 6: Una app con un backend LDAP

Buscando por LdapSearch, también aparece alguna app que, lógicamente, lleva un enlace que permite inyectar parámetros en LDAP Search filters. Por supuesto, como es un enlace creado para una app, está fuera de los circuitos habituales para los dorks, así que tampoco está muy machacado.

Figura 7: Un LdapSearch en una app con escritura de LDAP Searh Filters

El número de apps utilizando LDAP es alto, así que los dorks para localizar estos entornos facilitan la misión. Teniendo en cuenta que las técnicas LDAP Injection no son "mainstream" y no todo el mundo está puesto con ellas, el resultado es que estas apps casi no tienen ninguna protección contra ellas.

Command Injection

Una vez metidos en harina, buscar cualquier tipo de aplicación web que pudiera tener un bug de estas características no es demasiado complicado. Basta con pensar qué no se debería hacer nunca para ver si a alguien le ha parecido una buena idea. Buscando por apps con Command Injection, busqué enlaces con el parámetro "command" o con la cadena Command.php, o Execute.cgi, o ... lo que se te ocurra.

Figura 8: Un enlace a un command.cgi en una app (con enlace local)

De hecho, después de eso comencé a buscar directamente comandos como mkdir en los enlaces y llegué a este mkdir que cuando se invocaba en el lado del servidor daba un error muy significativo.

Figura 9: Llamada aun programa para hacer directorios en el servidor.
Muchos lo han debido de usar ya.

Al final, la imaginación para hacer los dorks es tuya, y la gracia es que al tener en Tacyt un potente motor de filtros, cada vez que se descubre un nuevo app se le pasa por todos esos filtros. Si por cada dork que se te ocurra generas un filtro, por la mañana solo tienes que leer el feed RSS de tus dorks y ver qué ha caído nuevo.

Mañana la última parte

Si has seguido esta historia hasta aquí, supongo que ya te habrás hecho una idea de que en las apps que subas debes ser muy escrupuloso a la hora de dejar información, pues igual que dejar un leak en una aplicación web puede atraer a muchos atacantes que te localicen por medio de dorks, esto es exactamente los mismo con las apps móviles - peor aún, que también les dejas el código -. Por si queréis aprender más sobre esto, os dejo la referencia del libro "Desarrollo Android Seguro".

Saludos Malignos!

***********************************************************************************

- Dorking & Pentesting con Tacyt: Dominios, IPs y Puertos

- Dorking & Pentesting con Tacyt: Las P@ssw0rds

- Dorking & Pentesting con Tacyt: Las APIs de terceros
- Dorking & Pentesting con Tacyt: Inyección de comandos

- Dorking & Pentesting con Tacyt: Diapos de RootedCon Valencia 2015

***********************************************************************************

Examen Máster Seguridad UEM 2014 - 2015

Ayer sábado por la tarde fue el día del examen de mi módulo de Seguridad en Aplicaciones en el Máster de Seguridad Informática de la UEM, así que, como en años anteriores os dejo las 10 sencillas preguntas que les puse sobre conceptos base. Si ya te has hecho los de otros años te resultará muy familiar, pero aún así puedes probar a hacerlo.

Figura 1: Tarde de Sábado (ayer) para examinarese en la UEM

Examen Seguridad Aplicaciones Curso 2014-2015

1.- ¿Cuáles son las tres reglas principales para la fortificación de sistemas informáticos?

2.- Explica en que se diferencia una vulnerabilidad de RFI de una LFI

3.- Explica para que sirven los flags Secure y HTTP Only en una cookie

4.- ¿Qué son los headers HTTP de CSP?

5.- ¿Cómo extraerías el nombre de los usuarios de una base de datos a través de una vulnerabilidad SQL Injection Out-Band basada en errores ODBC?

6.- Explica cómo extraer de una aplicación web vulnerable a Time-Based Blind SQL Injection la versión de una base de datos si el motor es un MySQL v4.

7.- En un ataque LDAP Injection en el que la función de consulta es como la que sigue. ¿Cómo conseguirías acceso con algún usuario si el motor es un OpenLDAP?

Web:

User: v_userPass:v_pass

Consulta para acceso:

ldapfilter='(&(uid='+v_user+')(Pass='+crypt(v_pass)+'))';

8.- Explica en que consiste un ataque SQL Injection inband.

9.- ¿Cómo se podría realizar un ataque Time-Based Blind SQL Injection a una aplicación web que utilice un motor de base de datos Ms Access 2007?

10.- Explica algún método conocido para poder robar una cookie con el flag HTTP-Only.

Tiempo: 1 hora y 30 minutos.

Por la tarde pondré las respuestas para el que quiera saber cuál sería la respuesta adecuada a cada una de ellas. Además, os dejo los enlaces a exámenes de años anteriores, por si te quieres ver los de otros cursos, que ya son muchos años de vida de este Máster. 

-  Examen Máster de Seguridad de la UEM 2009-2010
-  Examen Máster de Seguridad de la UEM 2010-2011
-  Examen Máster de Seguridad de la UEM 2011-2012
-  Examen Máster de Seguridad de la UEM 2012-2013
-  Examen Máster de Seguridad de la UEM 2013-2014
-  Examen Máster de Seguridad de la UEM 2013-2014 (Herramientas auditoría)

Recuerda, lo más importante de esto siempre es aprender, no aprobar. Ya sabes que es mejor suspender que atenerse a las consecuencias.

Saludos Malignos!

Examen Máster de Seguridad de la UEM 2013-2014

Como todos los años anteriores hoy es el día en que toca hacer sudar un poquito a mis chicos del Máster de Seguridad de la UEM 2014. Este examen es una pequeña variación del que les toco hacer a los del Máster de de Seguridad de Mayo de 2013 - que no os publiqué por aquí -, a ver qué tal se les da. El examen se hace en papel, tienen 2 horas para hacerlo, y lo están haciendo ahora mismo, así que si te animas, puedes ponerte a hacerlo tú. Luego más tarde actualizaré el post con las respuestas para que sepan si les ha salido bien o no la prueba.

Además, tienes exámenes de años anteriores ya publicados por aquí, que espero que mis alumnos se hayan empapado en profundidad, ya que suelo hacer más o menos las mismas preguntas.... para ver si estudian o no. Por supuesto, en el examen siempre entra todo lo citado directa o indirectamente en las clases, las diapositivas y publicado en el blog.

Examen Máster de Seguridad de la UEM 2009-2010
Examen Máster de Seguridad de la UEM 2010-2011
Examen Máster de Seguridad de la UEM 2011-2012
Examen Máster de Seguridad de la UEM 2012-2013

Saludos Malignos!

Examen Máster de Seguridad 2014 de la Universidad Europea de Madrid

1.- Tu organización dispone de una aplicación web de cara a internet consistente en ofertar productos y servicios con pasarela de pago propia desarrollada para una plataforma .Net utilizando tecnologías Microsoft. Los datos de registro de los clientes, así como los pedidos solicitados se almacenan en una base de datos SQL Server de la empresa, gestionando todo el proceso a través de la lógica de negocio. ¿Qué mecanismos de protección consideras que deberían implantarse en cuanto a la arquitectura de servidores y servicios se refiere? Cita reglas generales y algunas medias concretas que creas convenientes para implantar.

- Respuesta: Reglas de fortificación 1) Mínimo Punto de Exposición 2) Mínimo Privilegio Posible y 3) Defensa en Profundidad. Design Guidelines for Secure Web Applications. Hacking Webs en .NET: Algunos trucos para auditoría.

2º.- Si tu organización dispone de un servidor de base de datos SQL Server 2008 pero el DBA es una persona con poca experiencia. ¿Qué mecanismos de seguridad pondrías en su conocimiento como disponibles en el entorno a la hora de cifrar la información que en él se aloja?

- Respuesta: Cifrado de almacenamiento de sistema, cifrado de base de datos, cifrado de datos, hashing seguro de passwords, cifrado de backups y cifrado de comunicaciones a nivel de cadena de conexión y aplicación web.

3.- Describe como se puede hacer un proceso de hijacking de sesión a un usuario de una red social en la que las cookies no vayan por HTTP-s si en la web no se ha descubierto ninguna vulnerabilidad de código (ni SQLi, ni XSS).

- Hijacking de session con cookies capturadas por la red.

4.- Describe un posible método para robar una cookie marcada como HTTP-Only con un ataque de XSS que se debería probar sabiendo que el servidor no tiene habilitado el método TRACE y que es un Apache 2.0.X.

- Robar cookies HTTP-Only con XSS y Error 400 en Apache. También se podría describir un método basado en un Applet Java.

5.- Una aplicación web de una empresa proporciona un proceso de autenticación que sospechamos un tanto curioso. Al analizar el código fuente de la página, vemos que la aplicación utiliza para el proceso de autenticación un Applet de Java con extensión JAR. Tras probar varios intentos de inicio de sesión, detectamos que no se produce Post-Back al servidor. ¿Qué fallo de seguridad podría tener esta aplicación y cómo debería investigarse?

- Autenticación local. Decompilación de Applets Java. Jugando con un Applet Java. Cómo localizar Applets Java con Shodan.

6.- Detectamos que una aplicación web realizada en ASP con acceso a SQL Server es vulnerable a SQL Injection. Describe porqué se producen este tipo de ataques y un método simple para solventarlos.

- Mi primera comilla.   

7.- En qué consiste un ataque de tipo Blind SQL Injection a una aplicación web. Explícalo con tus palabras por ejemplo para obtener la versión del motor de la base de datos que se está utilizando.

- Técnicas avanzadas en Blind SQL Injection

8.- La nueva tecnología adoptada por tu empresa para el sitio web interno corporativo te permite visualizar a través del navegador aquellas impresoras y recursos compartidos de red a los que sólo tienes acceso por pertenencia a un departamento en concreto. Analizando el código web, se ver que es un código muy parecido al que usan los administradores de sistemas Windows para gestionar los sistemas con CScript. Llegas a la conclusión de que puede tener algún tipo de inyección y estás en lo correcto ya que al introducir los caracteres de inyección adecuados, te permite visualizar más recursos corporativos de los que deberías ver en un principio ¿De qué tipo de vulnerabilidad estamos hablando y a qué tipo de base de datos estamos accediendo?

- (Blind) LDAP Injection in Web Applications

9.- Describe en qué consisten los ataques de Time-Based Blind SQL Injection y con qué tipo de funciones o métodos pueden realizarse en los motores de base de datos SQL Server, MySQL, Oracle y Access.

- Time- Based Blind SQL Injection using Heavy Queries

10.- Como administrador del sistema de tu organización, una mañana monitorizas que el antivirus corporativo reporta un malware en un directorio local del servidor donde tu empresa tiene alojado el sitio web. El archivo en cuarentena es un fichero denominado C99.php. ¿Qué tipo de ataque estás sufriendo y qué fallo o fallos de seguridad se ha/n podido aprovechar?

- Tienes una WebShell [Community Shells availables, Riesgos en el uso de WebShells en auditoría], Métodos HTTP Inseguros PUT, subida insegura de ficheros, Técnicas SQLi con acceso al File System de escritura, RFI si lo pilla en tmp o por red, Web compartida en hosting inseguro o hacking del servidor web por otro medio.

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!

ASP.Net autenticando con LDAP en Active Directory

El gran Andres Riancho, creador de w3af, ha escrito un post tocando uno de mis temas favoritos: LDAP Injection. Hace ya tiempo que dejé un poco de lado estos temas, ya que le dediqué el 2007 y 2008 al tema de las inyecciones LDAP, tiempo suficiente para que me apeteciera hacer otras cosas, pero como me han llegado varios mensajes pidiendo aclaración sobre si funciona el ejemplo o no en ASP.NET y AD que propone el ejemplo, voy a este tema por un post.

En el artículo publicado, creo que se cometen algunas imprecisiones que son dignas de resaltar, ya que el ejemplo que aparece no funciona tal y como está descrito, y puede llevar a error a muchos personas, así que vamos a hacer un resumen.

Resumen de las diferentes implementaciones LDAP

El primer paper que habla de LDAP Injection, el de Sacha Faust, hacía un ejemplo de inyección en el que a partir de un filtro LDAP simple, es decir, algo como (atributo=valor) inyectaba un filtro compuesto, haciendo algo como (atributo=injección), donde en injección ponía un nuevo filtro LDAP del tipo foo)(|(atributo2=valor).

Esa acción genera 2 filtos LDAP y no funciona ni en OpenLDAP ni en Microsoft ADAM [Active Directory Application Mode] o el nuevo MS LDS [Ldap Directory Services]. OpenLDAP porque solo ejecuta el primer filtro y desecha el segundo al no ser una lista de atributos válidos, Microsft LDS o ADAM porque no está correctamente formado (son 2 y no lo permite el estándar).

Esa inyección funciona en el ejemplo de Sacha Faust porque usa un servidor SUN que permite la ejecución de dos filtros LDAP en una única consulta -como si fuesen independientes-, pero no en OpenLDAP o MS AD, ADAM o LDS. Todo esto está explicado en el artículo titulado Jugando con LDAP.

Como curiosidad, el componente IPWorks*ASP LDAP que usa Sacha, y que usamos nosotros en nuestro Reto Hacking IV y en la escritura del paper, realiza un borrado de todo aquello que está fuera del primer filtro, lo que provoca situaciones muy curiosas, como que las inyecciones LDAP que generan 2 filtros se anulen, y solo quede el primer filtro.

Implementaciones Microsoft y filtros compuestos

Sin embargo, si el filtro es uno compueto, es decir, que tiene más de un condicionante, con un operando AND u OR, entonces sí que se pueden hacer inyecciones en árboles LDAP de Microsoft, siempre y cuando generen un único filtro LDAP en una consulta.

Así, el ejemplo que ponía Andres Riancho sobre saltarse la autenticación en un árbol LDAP de Microsoft, se podría hacer, tal y como expliqué en el artículo or 1=1 en LDAP. En un filtro escrito por el programador como el siguiente:

(&(uid=valor_usuario)(webpassword=valor_password))

¿Cómo conseguir acceso con un usuario sin saber la password? Pues como no se pueden generar dos filtros en la inyección, hay que conseguir que se genere un único filtro. Para ello habría que introducir algo como:

Valor_usuario = admin)(!(&(|
Valor password = any))

El resultado tras esta inyección sería:

(&(uid= admin)(!(&(|)(webpassword= any))))

Y no como se plantea en el post con una inyección que genere algo como (&(user=andres)(&))(password=notimportant)). Esto solo sería válido si se está utilizando un componente como IPWorks*ASP LDAP, con un comportamiento tan peculiar como el explicado de borrar el segundo filtro, o si se está utilizando un árbol OpenLDAP.

En cualquier caso, si se usa el componente por defecto de ASP.NET para conectarse a un árbol LDAP sea el que sea, ese componente es seguro y no permite inyección. Así que, para que el ejemplo publicado tenga sentido se deberían cumplir las siguientes condiciones:

1) No se usa el componente LDAP por defecto de ASP.NET
2) Se está usando un componente que jamás envía los dos filtros al árbol LDAP

Sin embargo, la parte de detección del ataque sería totalmente cierta.

Si te gusta el tema del LDAP Injecction tienes más información aquí:

- Ataques a LDAP
- LDAP Injection and Blind LDAP Injection
- Jugando con LDAP
- Or 1=1 en LDAP
- LDAP Injector
- El listín de teléfonos
- Whitepaper LDAP Injection & Blind LDAP Injection [Inglés]

Saludos Malignos!

Examínate este fin de semana

A mís pobres y sufridos alumnos del Master Universitario de Seguridad en Tecnologías de la Información y las Comunicaciones les he hecho sufrir un poco ayer con un "bonito exámen". Si te apetece probar, dale caña.

1.- Describe en que consiste un ataque XSS no-persistente, un entorno en el que se pueda encontrar esta vulnerabilidad y cómo puede ser utilizado para distribuir malware.

2.- Describe tres medidas que conozcas para evitar que los ataques de XSS no persistente tengan efecto.

3.- Describe en qué consiste un ataque de Cross-Site Request Forgery.

4.- Si una aplicación muestra un mensaje de Error ODBC de un servidor SQL Server, ¿qué sistema de ataque puede utilizarse para extraer información de la base de datos?

5.- Se ha encontrado una vulnerabilidad en una aplicación web de SQL Injection en la que si se pone una inyección SQL correcta sale la página de una noticia y, si se comete algún error sintáctico o semántico, el programador ha capturado la excepción y muestra una página genérica de error. Si se quiere realizar un ataque SQL Injection de tipo inboud, describe el proceso que habría que seguir para construir la inyección correcta.

6.- Dentro de los ataques inboud, explica en qué consisten los ataques de Serialized SQL Injection.

7.- Una aplicación web en PHP con MySQL es vulnerable a SQL injection pero no se pueden realizar ataques inbound y los errores de base de datos están capturados. Se quiere extraer la versión de mysql realizando un ataque de Blind SQL injection. Describe el proceso que habría que realizar.

8.- Describe en qué consisten los ataques de Time-Based Blind SQL Injection y cómo pueden realizarse.

9.- En una aplicación web, la aplicación autentica a los usuarios con un árbol LDAP, para ello, cada usuario tiene un atributo uid y un atributo password. El programador ha filtrado el * y utiliza la función crypt antes de usar la contraseña en una consulta AND LDAP como ésta.

V_username: valor de usuario introducido en la página web por el cliente.
V_passwd: valor de contraseña intoducido en la página web por el cliente.
C_passwd =crypt(v_passwd)

Consulta que da acceso o no a la aplicación:
(&(uid=+v_username+)(password=+c_passwd+))

¿Con qué inyección LDAP conseguirías entrar si la se está utilizando un árbol LDAP basado en OpenLDAP?

10.- En una aplicación web se sabe que el parámetro id se inyecta en una consulta AND LDAP. Se quiere extraer el valor del atributo objetclass de todos los objetos afectados por esta consulta. ¿Cómo realizarías el proceso con un ataque Blind LDAP Injection?

Si no eres capaz de hacerlo y te gustaría saber como van estas cosas, yo te enseño, como "amor y abrazos" en el próximo RootedLab que voy dar de Técnicas de Inyección en Aplicaciones Web. Y si se te ha quedado corto, puedes hacerte el exámen del año pasado.

Saludos Malignos!