Enla búsqueda de vulnerabilidades y CVE, existe un problema de espacio de búsqueda. La superficie de ataque es aparentemente ilimitada, hasta tal punto que la selección de objetivos se considera a menudo la habilidad más importante de un cazador de recompensas por errores.
En este artículo, voy a explicar el proceso que utilicé para reducir el espacio de búsqueda. De millones de líneas de código a identificar tres líneas defectuosas. Por supuesto, conté con la ayuda de los últimos agentes LLM, así como con años de experiencia en seguridad de aplicaciones, lo que me ayudó a evitar los falsos positivos, algo habitual cuando los agentes se orientan hacia el hacking de recompensas.
El espacio de búsqueda
Enoctubre de 2025, Wiz anunció un nuevo concurso de hacking denominado Zeroday Cloud en colaboración con los tres principales cloud : Google Cloud, AWS y Microsoft. Inspirado en concursos de hacking como Pwn2Own, Zeroday Cloud incluía 20 objetivos de software de código abierto, bibliotecas, aplicaciones y kits de herramientas que cloud utilizan ampliamente para crear y potenciar cloud . El objetivo del concurso era sencillo, aunque no fácil de alcanzar: demostrar la ejecución remota de código (RCE) sin autenticación en el objetivo.
Establecer los límites
A partir deun espacio de búsqueda masivo, la lista inicial de objetivos se definió en solo veinte repositorios. Dejando de lado cualquier posible elusión de la autenticación, podemos reducir aún más las rutas de código a considerar a solo aquellas accesibles para un usuario no autenticado. Además, la mayoría de las reglas de los objetivos especifican que los exploits deben entregarse a través de la red, normalmente a través de un servidor API HTTP local.
Un lugar para empezar
Paraobtener algunos hilos iniciales que nos sirvan de punto de partida, tenemos dos opciones. Tradicionalmente, se podría inspeccionar manualmente el código fuente y la lógica de la aplicación en busca de funcionalidades sospechosas. La carga de archivos, los motores de scripts o los renderizadores de documentos son áreas que podrían facilitar la ejecución de código arbitrario.
Dado que aún quedaba mucho por investigar y el tiempo era limitado, opté por un enfoque diferente. Como los objetivos son repositorios de código de acceso público, entrené una herramienta de análisis de código estático en la base de código para generar pistas.
Comose puede ver en la captura de pantalla siguiente, se generaron docenas o incluso cientos de hallazgos de código por cada objetivo. Estos sirvieron como punto de partida para mi búsqueda de vulnerabilidades asistida por LLM.
Rastreo de contaminaciones con Claude
Notodos los hallazgos de código son igualmente interesantes. Solo se investigaron aquellos que tenían el potencial de avanzar en el objetivo del concurso, la ejecución remota de código. Entre ellos se incluyen cuestiones como:
- «Eval detectado»
- «Shell=True en llamada a subproceso»
- «Deserialización de Pickles en Pytorch»
- «Comando no estático en Exec»
- «Entrada del usuario en path.join»
- «Comando de escritura peligroso»
Mis indicaciones variaban en función de la línea de código y del problema señalado, pero seguían teniendo un tema general.
Ejemplo de indicación:
Estoy utilizando una herramienta de análisis estático para identificar vulnerabilidades en mi código. Ha identificado esta línea de código como un posible punto de inyección y ejecución de código. Tu tarea consiste en rastrear el origen de la entrada ejecutada en esta línea para ver si podría estar controlada por el usuario o influenciada en algún momento. Responde con un análisis detallado que rastree la entrada ejecutada hasta su origen.
Los LLM competidores
TantoGemini 2.5 como Claude Sonnet 4.5 obtuvieron resultados satisfactorios al rastrear la entrada en líneas de código sospechosas hasta su origen, rastreando metódicamente el punto de inyección y describiendo las transformaciones y manipulaciones que sufrió la entrada a lo largo del proceso.
Lasdiferencias entre los dos modelos comienzan a apreciarse en su análisis de la explotabilidad. Mientras que uno adoptó una postura escéptica y conservadora, el otro se mostró más dispuesto a encontrar riesgos potenciales y explorar vulnerabilidades tangenciales. Veamos cómo se comportaron estos dos modelos durante mi clasificación inicial de los resultados del análisis de código estático.
El arquitecto conservador frente al becario entusiasta
Lapersonalidad Gemini podría describirse como un arquitecto escéptico y de barba gris. Cuando se le pide que evalúe una línea de código en busca de posibles ejecuciones arbitrarias, su respuesta es conservadora y algo limitada a una visión poco imaginativa de la ruta de explotación. Definitivamente, no es excesivamente entusiasta ni encarna una mentalidad innovadora.
Aquí, Gemini 2.5 intenta convencerme de que todo está bien con una línea de código en particular (véase la figura A: Triaje conservador de Gemini). Se muestra inflexible en su creencia de que, dado que el código ejecutado proviene de un archivo de configuración, no puede ser explotable. El modelo intenta cerrar todas las puertas intelectuales para una investigación más profunda.
Claude, por otro lado, se parece a tu becario más entusiasta. Brillante, pero excéntrico. Lo que le faltaba en perspectiva, lo compensaba con su deseo de limpiar todas las trincheras.Surespuesta a la misma indicación se desvió significativamente del objetivo original de realizar un análisis de contaminación para detectar posibles inyecciones de código arbitrario, y en su lugar hizo afirmaciones optimistas sobre otros posibles riesgos de seguridad.
Aquívemos a Claude deseoso de proponer posibles pasos a seguir (véase la figura B: El entusiasmo de Claude). En la práctica, nunca he visto a Claude Sonnet responder sin ofrecer un atisbo de esperanza sobre una posible vulnerabilidad. Como se puede ver a continuación, incluso cuando se describen medidas de mitigación, estas siempre se plantean como riesgos potenciales si no se implementan correctamente.
Tú eres la arquitectura de la pizarra
Elflujo de trabajote presenta naturalmente a ti, el ser humano en el ciclo, como el experto esencial. Me encontré haciendo de abogado del diablo, desafiando el pensamiento cerrado del arquitecto conservador y actuando como el sensato frente a las sugerencias entusiastas del becario. Jugar con un modelo frente al otro, eligiendo la mejor de las dos sugerencias, es la arquitectura de pizarra en la práctica.
La arquitectura Blackboard es esencialmente un patrón de diseño que permite que múltiples agentes especializados en modelos lingüísticos grandes (LLM) colaboren para resolver problemas complejos y confusos. Es eficaz en una configuración con múltiples LLM porque proporciona a los agentes un espacio de trabajo central y compartido, el «pizarrón», donde pueden comunicarse y construir una solución de forma incremental sin estar limitados por un flujo de trabajo rígido y predefinido.
Esteconcepto se entiende mejor como una colaboración en equipo. Cada miembro del equipo aporta habilidades únicas y, aunque no pueden hablar entre ellos directamente, se comunican y crean la solución escribiendo en una pizarra o pizarra blanca compartida.
Los sofisticadossistemas multiagente cuentan con un «señor supremo» o gestor de agentes que selecciona las mejores soluciones, ayudando al equipo de agentes a sortear situaciones difíciles. Mi flujo de trabajo ad hoc evolucionó de forma natural hasta convertirme en la pizarra, el gestor de agentes y el negociador entre personalidades fuertes.
Una definición más amplia del éxito
¿Yeste flujo de trabajo dio sus frutos? No del modo que esperaba inicialmente. En las dos semanas que pasé evaluando posibles vulnerabilidades de software en código abierto, no logré alcanzar el estricto objetivo de la ejecución remota de código sin autenticación. Sin embargo, gracias a la curiosidad de Claude y a mi disposición a explorar callejones sin salida, descubrí algunos problemas interesantes en el código base que no se habían identificado anteriormente.
Sospecho que la mayoría de los investigadores de vulnerabilidades que utilizan la IA para buscar errores están tratando de optimizar su sobre/subestimación. Identificar las vulnerabilidades más «pertinentes» y con mayor CVSS 10.0 con el menor número de ciclos posible. Esto ha dejado una puerta abierta para que la intuición humana siga desempeñando un papel en el descubrimiento de vulnerabilidades. Por el momento, seguimos siendo los expertos humanos esenciales en el proceso.
Estén atentos (concretamente dentro de 90 días) al debate continuo sobre la búsqueda de errores asistida por IA para conocer los detalles de las vulnerabilidades que descubrí con la ayuda de múltiples agentes de IA.
