CodeMender: Un Agente IA para buscar bugs y parchear código fuente

Hace unos meses os dejé el artículo titulado: "Usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source" donde hablaba de algo que parecía bastante evidente, que es utilizar, los modelos de Deep Reasoning para lo que dice el título, buscar las vulnerabilidades, avisar de ellas en los proyectos Open Source, para que quién se vaya a descargar el software sepa qué bugs tiene, que el mantenedor del código lo pueda parchear, o que directamente haya una propuesta de parche hecha directamente por un modelo de GenAI.

Figura 1: CodeMender - Un Agente IA para buscar

bugs y parchear código fuente

Es decir, que cuando se visita un proyecto OpenSource en GitHub u otra plataforma similiar, 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. 

Figura 2: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Y finalmente que haga con GenAI propuestas de código de parchear el proyecto automáticamente, como hace la plataforma Plexicus, que está empujando José Palanco, y que es una de las primeras soluciones profesionales que hace esto.

Figura 3: Plexicus parchea con GenAI los bugs

Ahora Google ha presentado CodeMender, que utilizando esta misma idea lo ha estado usando para analizar y parchear código de proyectos OpenSorce con un Agente AI. Y si veis el proceso en el vídeo siguiente, el modelo es muy, muy, muy similar a lo que tenéis en el vídeo anterior.

Figura 4: Esquema de funcionamiento de CodeMender

Para que veáis cómo funciona CodeMender, en la web se presentan un par de ejemplos. Este primero escanea el código razonando en busca de vulnerabilidades, de igual forma que yo os contaba en el artículo donde usaba DeepSeek. En este caso, lógicamente, utilizando Gemini.

Figura 5: CodeMender AI evalúa el código y busca bugs

En este caso, se pregunta qué sucede si no se sacan los elementos de la pila, lo que podría generar un error, como razona CodeMender en la siguiente fase.

Figura 6: Los elementos puede que no se vacíen de la pila

A partir de este momento hace un análisis detallado de cómo se gestiona la pila en este código, y comprueba que se puede producir una situación donde los elementos no salen de ella, tal y como se ve en la imagen siguiente.

Figura 7: CodeMender hace el seguimiento del error

Una vez que ha descubierto que ya hay una situación errónea no controlada en el código, comienza la fase de encontrar un parche correcto y proponerlo al código.

Figura 8: CodeMender hace un parche directamente

En este caso, el proceso de DeepReasoning de Google Gemini ha estado permitiendo que CodeMender funcione en modo Agentic AI evaluando todo el código para ver si descubre algún bug, pero también puede funcionar directamente para parchear un código que se sabe ya que tiene el fallo, como se ve en este vídeo.

Figura 9: Haciendo un parche concreto para un código con bug

Según el blog, durante los últimos 6 meses durante la construcción de CodeMender, han estado analizando proyectos OpenSource y el agente ha hecho 72 Security Fixes para proyectos populares, algunos de hasta 4.5 Millones de líneas de código.

Figura 10: Libro de Bug Bounty: De profesión "Cazarrecompensas"

en 0xWord, escrito por Pablo García

Por supuesto, como decía yo en el artículo, esta es una herramienta perfecta también para los que tienen el mundo del Bug Bounty: De Profesión "Cazarecompensas", que pueden encontrarse con premios descubiertos por estos modelos que te hagan la vida más sencilla.

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: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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 dé 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!

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!

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

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