Hierarchical Reasoning Model

En el mundo de la Inteligencia Artificial, si te pierdes una semana, entonces te has quedado atrás. Hoy os quería hablar del paper publicado hace diez días, que define una arquitectura que los investigadores han denominado "Hierarchical Reasoning Model", y que permite, resolver problemas de razonamiento complejo, reduciendo la carga de predicción mediante una división de tareas a dos niveles, uno más estratégico de visión completa, y otro nivel más ejecutivo orientado a resolver las tareas inmediatas. Y los resultados son espectaculares.

Figura 1: Hierarchical Reasoning Model

El paper lo tenéis publicado para que lo podáis leer, y merece la pena que lo marquéis en favoritos, porque parece que va a ser una referencia que nos vamos a encontrar en los artículos subsiguientes, así que toma buena nota de éste.

Figura 2: Hierarchical Reasoning Model

Como se explica en el gráfico de esa primera página del paper, que como los trabajos brillantes, se explican bien en pocas palabras, lo que hacen es copiar las zonas de actividad del cerebro, donde los trabajos de razonamiento más complejo tienen lugar en la zona frontal, mientras que las tareas más de ejecución inmediata y cuasi-automática se ejecutan cerca del hipotálamo.

Figura 3: Funcionamiento de HRM

Teniendo en cuenta que las tareas de razonamiento más complejo dan órdenes a las labores de trabajo más inmediato, el tiempo de ejecución es distinto. El High-Level revisa la "big picture" de cómo va el proceso completo cada cierto tiempo para la resolución del problema global, revisando periódicamente cómo se están ejecutando las tareas de Low-Level, lo que permitirá tomar nuevas decisiones desde el High-Level que mandarán nuevas tareas en el Low-Level, que trabajará por tanto con mayor frecuencia.

Figura 5: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Esto permite que, por tanto, con un modelo mucho más pequeño en número de tokens, en el ejemplo del paper se habla de 27 millones de parámetros, y con un entrenamiento mucho menor - 1.000 samples -, se consiga vencer a modelos de Deep Reasoning como DeepSeek v3 con DeeptThink R1 utilizando el Prompt Analysis constante en la Chain of Thoughts, a Claude 3.7 8K o a o3-mini-high.

Figura 4: Comparación en Benchmarks

Pero hoy me gustaría dejaros la explicación de Gabriel Merlo, que hace un trabajo de divulgación maravillosa sobre Inteligencia Artificial, y lo ha explicado en poco más de veinte minutos de manera brillante en este vídeo que ha construido, así que os lo dejo para que lo disfrutéis.

Figura 5: Gabriel Merlo explicando el Hierarchical Reasoning Model

Los avances en Inteligencia Artificial están cambiando nuestro mundo y han hecho que el contexto en el que vivimos y trabajamos como personas, profesionales, empresas y sociedades esté en disrupción. La carrera por dominar la IA se está viviendo a nivel Geo-Político, a nivel empresarial, y, claro que sí, a nivel profesional, así que ponte las pilas. Te recomiendo que te veas los vídeos de Gabriel Merlo en su canal, que son todos muy buenos.

Figura 6: Vídeos de Gabriel Merlo sobre Inteligencia Artificial

Para los que nos dedicamos al area profesional de ciberseguridad, pentesting, hacking, también. Así que 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)  

El Ratio Potemkin de Comprensión de Conceptos en los Large Language Models

Sí, hoy vuelvo a hablaros de un paper que tiene que ver con LLMs y su potencia de conocimiento. En este caso para hablar de un estudio que se ha llamado "Potemkin Understanding in Large Language Models", o lo que viene a ser, una manera de descubrir si los modelos LLMs responden a las cuestiones porque han aprendido cómo responderlas o han entendido el concepto por el que deben responder así.

Figura 1: El Ratio Potemkin de Comprensión de

Conceptos en los Large Language Models

La idea se basa en algo que seguro que has visto en muchos exámenes y pruebas de acceso de esas que nos preparan a los humanos. Ahí, te hacen varias preguntas que enfocan el planteamiento de distinta manera o desde distintos puntos de vista, pero que se fundamentan en haber aprendido el concepto. ¿Hacen eso los LLMs? Es difícil saber, y te puedes encontrar que preguntando sobre el mismo concepto las respuestas sean contrarias. Esto es lo que han llamado un "Potemkin".

Figura 2: Potemkin Understanding in Large Language Models

Descubrir si una respuesta correcta realmente sobre un concepto no está bien aprendido y se trata de un Potemkin, se hace preguntando algo donde tenga que aplicarse ese concepto. En el gráfico siguiente, cada una de las filas son sobre un tema concreto del que se van realizando pregutnas, por ejemplo, teorema de Pitágoras,  música, o una técnica de hacking. Después, en cada columna, están las preguntas con aplicaciones de ese concepto, que pueden ser correctas o erróneas. Si responde correctamente a la interpretación, pero luego lo aplica mal, pues es un Potemkin, ya que parece que entiende el concepto pero luego no lo aplica bien.

Figura 3: LLM Potemkin.

Una pregunta KeyStone implica que interpreta bien el concepto.

En la fila de LLM interpretation aparece que responde correctamente a la primera pregunta del concepto "q1" pero después se equivoca en tres cuestiones donde debería aplicar ese concepto. En la siguiente imagen hay dos ejemplos donde se ve bien esto. En la primera se le pide que elija una palabra para hacer una rima, y da una respuesta, pero cuándo se le pregunta si la respuesta es correcta, dice que no.

Figura 4: Dos ejemplos de Potemkin

En el ejemplo de la derecha se le pregunta por el teorema de la desigualdad del triángulo, y cuando tiene que aplicarlo da un resultado que no lo cumple. Ambos ejemplos, hechos con ChatGPT, son lo que se denominan Potemkin.  Encontrar esto Potemkins es fundamental para poder hacer la valoración de un modelo LLM por medio de un Benchmark. Podría ser que un LLM contestara bien a todas las preguntas de un examen de medicina, pero que tuviera un Potemkin en el entendimiento de que un cuerpo humano no funciona sin corazón, que surgiera en un análisis profundo de la aplicación de los conceptos.

Figura 5: Detección de Potempkins para validar Benchmarks.

Una Keystone de 2 implica que dos preguntas juntas definen un concepto.

Al final lo que tenemos en las preguntas en rojo son una Hallucination o simplemente una Respuesta Errónea, pero si estamos evaluando los LLMs en tests de conocimiento con Benchmarks, se debería estresar la búsqueda no de respuestas correctas - que podrían haber sido entrenados con esas mismas preguntas -, sino de conceptos correctamente aplicados, y por tanto la detección del máximo de Potemkins en los modelos. 

Figura 6: Ejemplos de Potemkins

En la imagen anterior veis como dos conceptos muy sencillos le cuesta interpretarlos correctamente en preguntas en las que ChatGPT ha alucinado, y que debería ser un aviso a navegantes a la hora de valorar el nivel de inteligencia de los LLMs. 

Evaluación de Potemkins en Modelos LLM

Para tener una primera aproximación sobre cómo es el aprendizaje de conceptos en los modelos, los investigadores han propuesto una metodología bastante sencilla. Han utilizado 7 modelos y les han preguntado por 32 conceptos. Después, se le ha pedido que Genere, Clasifique y Edite una respuesta donde debe aplicar ese concepto. Por ejemplo, en la imagen siguiente tenéis un proceso de Clasificación.

Figura 7: Clasificación de una respuesta en base

a un concepto para detectar un Potemkin

Los resultados del experimento los tenéis en la siguiente tabla, y son bastante llamativos. En la tabla siguiente tenéis los "Potemkin Rate" de cada una de esas tareas por modelo, donde 1 significa que ha entendido perfectamente el concepto, y entre paréntesis los ratios de errores estándar medios de los Potemkins. 

Figura 8: Ratio de Potemkins

Es decir, por ejemplo 0.57 (0.06)  en Classify refleja que en tareas de clasificación asociadas a conceptos que han sido respondidos correctamente, tienen un 6 % de errores en las respuestas a las preguntas, y dejan un ratio de un 57% de Potemkins donde 100% sería libre de Potemkins,  o lo que es lo mismo, que te responda bien a un concepto (Keystone) significa que lo entiende y lo sabe aplicar en el 100% de los casos.

Figura 9: Evaluación de modelos

Al final, es solo un experimento que demuestra que aunque un modelo LLM responda bien al concepto, al igual que los humanos, puede que no sepa aplicarlo siempre, por lo que no se puede garantizar que sepa de un tema por que haya respondido correctamente a un test concreto, sino que se debe conseguir que una vez que responda a los conceptos bien, debería obtener un Potemkin Rate de 1 para garantizar que ha entendido el concepto, si no, tendremos que un LLM tiene un ratio de aplicación de los conceptos que responda correctamente de un X%, que es lo que trata de poner de manifiesto este trabajo. 

Figura 10: Evaluación automática de Potemkins

Es decir, están bien los Benchmarks, ¿pero cuál es el ratio de aplicación que tiene de los conceptos que sabe? Este trabajo no responde a todas las preguntas que genera la existencia de los Potemkins, y tampoco plantea una metodología completa de cómo medirlo, pero sí que abre el debate de que si queremos reemplazar tareas críticas por modelos de IA basados en LLM, deberíamos conocer cuál es su ratio de aplicación correcta de lo aprendido, y más, después de ver ayer cómo un simple "Cat Attack" podría generar más errores de aplicación.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cat Attack: O cómo atacar el razonamiento de un modelo de Deep Reasoning con preguntas y comentarios insulsos (sobre gatos)

En lel libro de Maniac del que os hablé hace no mucho, en la última parte del mismo, se cuenta cómo Lee Sedol, el gran campeón del mundo de Go consiguió su única victoria frente a AlphaGo (el campeón perdió 4 partidas a 1) mediante un movimiento extraño, cuasi suicida, llamado "El dedo de Dios", que hizo entrar a AlphaGo en alucinaciones, y emitir movimientos absurdos que le llevaron a la derrota. 

Figura 1: Cat Attack: O cómo atacar el razonamiento de un modelo de

Deep Reasoning con preguntas y comentarios insulsos (sobre gatos)

Fue la única victoria en igualdad de condiciones que consiguió Lee Sedol frente la Inteligencia Artificial, y lejos estaba AlphaGo aún de las mejoras que llegarían con AlphaZero. En aquel momento un movimiento inesperado - "El dedo de Dios" - en mitad la partida llevó a un estado de confusión al modelo, y no fue capaz de resolver el problema y vencer la partida a partir de ese momento. Se perdió en el hilo de su razonamiento perfecto. 

Figura 2: Maniac 

De ese capítulo me he acordado cuando he estado leyendo el artículo de "Cats Confuse Reasoning LLM: Query Agnostic Adversarial Triggers for Reasoning Models" o en español "Los gatos confunden el razonamiento de los modelos LLM", donde los investigadores explican el CatAttack o "Ataque del Gato", metiendo comentarios o preguntas insulsas, en los Prompts, para confundir el flujo de razonamiento del modelo de Deep Reasoning.

Figura 3: Cats Confuse Reasoning LLM: Query Agnostic

Adversarial Triggers for Reasoning Models"

En este caso, plantean tres formas de generar estas "confusiones", como son estos tres "Adversarial Triggers", o cambios de razonamiento puestos por un atacante para confundir al modelo al meter preguntas o comentarios que no son parte de la información que debe procesar.

Figura 4: Cat Attacks

• Redirection of focus by general statements: O decir una perogrullada que no aporta nada, ni tiene nada que ver con el ámbito del problema. Básicamente, meter una afirmación con un dato que no aporta ni resuelve nada del problema y que lleva a otros temas.

• Unreleated Trivia: Me ha recordado a los "Fun Facts" de Sheldon Cooper. En este caso, contar algún dato curioso, como que los gatos pasan la mayor parte de su vida durmiendo

• Misleading Questions: Redirigir el foco de atención haciendo una pregunta después de haber dado la orden, que no es mentira ni verdad, pero que consigue mover el foco de atención de lo que realmente tiene que hacer el modelo.

Básicamente, si metes mucha cháchara, el modelo se puede liar. Si el planteamiento del problema es de matemáticas, y le añades muchos números y alguno de los tres ejemplos anterior, puede que se confunda, y lleve a errores muy básicos.

Probando el Cat Attack con un problema simple de matemáticas

Como no podía ser de otra manera, cuando vi este paper pensé en "lo tengo que probar", así que construí un problema de matemáticas muy sencillo de Inversión en una empresa, gasto mensual de esa empresa, y si está empresa tiene un ROI en 10 meses, cuánto generará. Pero para liarlo, hice trampas. Le metí nombres de otras empresas con números, le pregunté el ingreso cada 3 meses, metí preguntas retóricas de por medio como "¿casualidad? No lo creo", y al final metí un General Statement que no tenía nada que ver con el problema. Vamos, un "Cat Attack".

Figura 5: Prompt con el Cat Attack a DeepSeek con DeepThink R1

Como podéis ver en el Prompt anterior lanzando a DeepSeek con DeepThink R1, el Thought Time fue de 136 segundos. lo que debería haber resuelto muy rápido, porque es un problema bastante sencillo, pero en el razonamiento, que es muy largo, dio veinte vueltas a lo mismo, preocupado por entender cada palabra del enunciado, que de eso trata el Cat Attack, pero al final lo resolvió.

Figura 6: DeepSeek DeepThink R1 lo resuelve bien al fiinal

Al final, la gracia del Cat Attack es que el modelo de DeepReasoning tiene que procesar todos los tokens de entrada, y les da la misma importancia a todos al principio, así se necesita un coste de razonamiento algo para poder eliminar aquello que no aporta nada. Da igual debe procesarlo. 

Figura 7: ChatGPT también lo resuelve

De hecho, tanto DeepSeek, como Grok 3 - no os dejo la captura -, como ChatGPT lo resuelven, pero al final hacen la comprobación del General Statement como si fuera una comprobación de que lo ha hecho bien, cuando no tiene nada que ver con la pregunta. Por suerte para ellos, el resultado les cuadra, así que no tienen que decidir entre la respuesta al General Statement y el Resultado del Problema, y con la misma solución hacen las dos. 

Cat Attack con éxito en Perplexity

Sin embargo, probado con Perplexity Pro, vemos como el Cat Attack ha tenido éxito, y da un resultado que está dirigido por el General Statement en lugar de estar dirigido por la pregunta original del problema. Ha sido un ataque exitoso.

Figura 8: El Cat Attack tiene éxito en Perplexity

Además, una vez resuelto puedes hacer la prueba de enviarlo de vuelta a otro modelo para que le diga si está bien o mal resuelto, y aunque en la mayoría de las pruebas han detectado el error, en este ejemplo con ChatGPT4o se puede ver cómo da por bueno el razonamiento erróneo de Perplexity.

Figura 9: ChatGPT4o dando por bueno el razonamiento erróneo

Al final, estos ataques a los modelos de razonamiento son muy peligrosos sobre todo en los entornos de Agentic AI, donde además, en muchos entornos vamos a tener modelos lejanos a los Frontier Models, que han sido destilados con ellos para ahorra costes, por lo que estos ataques de "falta de claridad" en el Prompt, hecho maliciosamente, pueden llevar a manipulaciones en los cálculos de facturas, pagos, precios, etcétera, simplemente hablando de "Gatos..." mola, ¿no?

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Generar números aleatorios con un LLM es una muy mala idea de seguridad

Esta semana he estado revisando algún paper que tenía por ahí marcado para poder leerlo y procesarlo con calma, y uno de ellos es este titulado: "Deterministic or probabilistic? The psychology of LLMs as random number generators" que viene a decir lo que os he dejado en el título del artículo, pero que si lo pruebas tú verá que es gracioso y hasta un poco como jugar a la psicología y contra-psicología con los LLMs, pero que pueden terminar en un serio problema de seguridad.

Figura 1: Generar números aleatorios con un LLM

es una muy mala idea de seguridad

Para probar esto, puedes hacerlo tú mismo con ChatGPT pidiéndole cosas que tengan que ver con elegir un número entre el 1 y el 50, como podéis ver en esta primera imagen, donde nos ha seleccionado el número 27.

Figura 2: ChatGPT elige el número 27 de entre 1 y 50

Pero lo divertido es que le pides cosas similares donde debe seleccionar un número entre 1 y 50, y el resultado más común es el mismo. Elige el número 27.... Y como dice ChatGPT..."al azar".

Figura 3: Elige el 27 al azar

Esto no tiene por qué ser siempre así, pero lo cierto es que si vas abriendo nuevas sesiones y vas pidiendo números entre el 1 y el 50 para diferentes cosas, tiende a elegir el número 27. Aquí para un sorteo.

Figura 4: Para un sorteo elige también el 27

Y si lo pruebas en otros modelos, puedes encontrar también el mismo sesgo o muy similar. Por ejemplo, probando en DeepSeek v3 (sin Deep Think), vemos como devuelve el mismo número.

Figura 5: Para DeepSeek el 27 es un buen número también

Este no es más que un sesgo o BIAS que tienen los modelos, que además no es único de ChatGPT, sino que DeepSeek, Llama, Anthopic o Gemini también comparten, como explica el paper que os he citado de "Deterministic or probabilistic? The psychology of LLMs as random number generators" y que podéis leer aquí.

Figura 6: Deterministic or probabilistic? The psychology of LLMs as random number generators

Según el estudio, probados los diferentes modelos a elegir números en un rango, tienen siempre sesgos (BIAS) de elección, y pintados en mapas de calor en función de las veces que eligen ese número es muy fácil de ver que es "un poco más alto que en el medio". 

Figura 7: Mapa de calor de distribución de números a elegir entre 1 y 5

Así, si le piden elegir números entre el 1 y el 5 se puede ver cómo los diferentes modelos tienden a ir principalmente al 3, con un poco de desplazamiento al 4, un poco menos al 2, y casi nada a los extremos. 

Figura 8: Mapa de Calor para Google Gemini

En las pruebas se ha tocado la Temperatura, para ver si afectaba mucho a la elección, pero como veis, aunque cambia un poco, no es excesivo su impacto en el resultado de que tiene un sesgo clarísimo. Solo Gemini 2.0 (Japón) tiene un comportamiento muy diferente, como se ve en la imagen anterior. Y probado sobre 10 números, pues más de lo mismo.

Figura 9: Elige un número el 1 al 10. Mapas de calor

Al final, esto es evidenciar algo que ya sabemos, que elegir como generador números aleatorios aun modelo LLM es una muy mala idea de seguridad. Ahí, lo mejor es usar Quantum Random Number Generators (QRND) que es una de las mejores soluciones, o buscar generadores lo más robustos posibles. Esto, en la base de datos de debilidades CWE (Common Weakness Enumeration) del MITRE está recogido en varios expedientes. 

Figura 10: De las 943 Weaknesses hay diez de ellas

 dedicadas al riesgo de los RNG

Y un ejemplo sencillo lo podéis ver en esta petición, donde le digo a ChatGPT que me ayude a generar un contraseña - otra muy malísima idea - que tenga un nombre y un número... ¿adivináis qué numero ha elegido?

Figura 11: Eligiendo un número para una password... el 27

Curiosamente, en los modelos de DeepReasoning, esto es un poco diferente, ya que tienen en cuenta muchas otras cosas que tienen que ver con el Contexto, con lo que tengan en Memory de ti, etcétera, como puedes ver en DeepSeek v3 DeepThink R1 donde usa un razonamiento curioso para elegir el número.

Figura 12: El 7 es el de la suerte...

Eso sí, vuelve a tirar al "medio", y llama la atención que evalúe el 7 (que es más elegido entre 1 y 10), tire a reglas matemáticas de los números o a la parte cultural "hacker" del 42 (*), que si no lo sabes... deberías leerte ya la "Guía del autoestopista galáctico".

¡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 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)