Vibe-Exploiting Discourse para hackear OpenAI con Claude Opus

Esta semana ha salido el Write-Up de cómo un grupo de investigadores consiguieron un Bug Bounty de OpenAI de 6.000 USD haciendo Vibe-Exploiting con Claude Opus. La explicación es lo que tenemos hoy en día en este mundo, donde se utiliza la Inteligencia Artificial para hacer el trabajo, lejos de lo que eran los sesudos Write-Ups de antes donde se explicaba con detalle la creación de los exploits, y, en este caso, evitar la protección de memoria de ASLR. Hoy en día es distinto.

Figura 1: Vibe-Exploiting Discourse para hackear OpenAI con Claude Opus

El artículo lo podéis leer en Hacktron AI, y explica el proceso que al final ha seguido esta explotación, que tuvo lugar durante el mes de Julio - sin acceso a Mythos o Fable en aquel entonces -. Como podéis ver en el gráfico, el culpable es una librería de tratamiento de imágenes con un bug de Heap Overflow que permite lograr ejecución de código.

Figura 2: Componentes de la cadena de explotación

Esa librería contenía un CVE conocido, pero no parcheado correctamente en el software de ImageMagick que iba en la versión de Debian donde corría el software de Discourse que daba servicio al Forum de OpenAI. Como veréis, es todo un proceso de Bug Hunting con IA.

Figura 3:"Bug Hunter" escrito por David Padilla en 0xWord

A partir de ese momento, el SSO de OpenAI permitía crear/acceder a las cuentas tanto de terceros como de invitados, así que se podía robar una cuenta de un empleado de OpenAI y con ella acceder a las herramientas que utiliza como ChatGPT o CODEX y a todos los repositorios conectados a ellas. 

Figura 4: El trabajo comienza con Claude Opus 4.8

evaluando la imagen Docker de Discourse

El proceso comienza usando Claude Opus 4.8 para que busque una imagen Docker de Discourse e investigue la librería en cuestión libheif. Y el modelo encuentra que no está parcheada. Así que se le pide que haga un exploit sobre ese bug conocido.

Figura 5: Es capaz de hacer el exploit sin ASLR activo

Con Claude Opus 4.8 se consigue hacer el exploit, pero sin saltarse ASLR. Con ASLR (Address Space Layout Randomization) activo, el modelo no es capaz. Pero.... llega Claude Opus 5 y la cosa cambia para bien para ellos, que consiguen que le haga el exploit con ASLR.

Figura 6: Consiguen el Remote Code Execution en el Docker de Discourse Cloud

Como podéis ver, usando Claude Opus 5 son capaces de hacer el exploit para saltarse ASLR, y con Claude en modo autónomo con un loop para lograr el objetivo, son capaces de conseguir el RCE (Remote Code Execution) en el Docker de Discourse. 

Figura 7: Simulación de la explotación en OpenAI

Una vez conseguido esto, teniendo en cuenta que OpenAI tenía integrado este software con las cuentas de los usuarios de la empresa, consiguieron robar identidades de empleados, con ellas, el acceso a sus herramientas, y desde ellas a los repositorios conectados con sus cuentas, como GitHub o Gmail.

Figura 8: El coste de encontrar el bug

Al igual que vimos en el artículo de "Cómo crear un exploit 1-day sobre un CVE de Chrome con Vibe Coding usando Claude Opus (no Mythos) y poner en jaque todas las apps en Electron", el costo de este exploit no es tan alto - algo menos de 3.000 USD - pero sí que es un cambio radical en la forma en la que hemos buscado bugs siempre. Ahora le pedimos a la IA que los busque, y nosotros sólo le vamos guiando.

Figura 9: Mejoras en los nuevos modelos que reducen lo que debes saber

Por un lado, no me deja de maravillar como el desarrollo de Inteligencia Artificial ha cambiado radicalmente esta industria, y la búsqueda de bugs se ha convertido en algo más cercano a configurar el modelo correctamente que ha descubrir el bug en sí mismo.

Figura 10: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso.

Y eso es lo otro que me llama la atención, cómo este trabajo que tenía tanto de artesano, cada vez se ha automatizado más, y leer un write-up ya no es aprender profundamente sobre una arquitectura vulnerable, y entender los detalles del exploit. Ya son del tipo "configuramos Claude Opus 5 para que buscara cómo entrar y al tiempo estaba el RCE". Tal vez soy mayor, pero pierde cierta magia esto, aunque entiendo que es lo que hay que hacer.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

La IA vulnerable, la IA asesina. ¿Qué hacer? ¿Qué puede pasar?

Seguro que has leído mucho ya sobre este tema esta semana. Ha sido el debate del momento. ¿Puede acabar la IA con la humanidad? ¿Hay que parar la evolución de la IA para poner controles? ¿Es necesario regular la IA? ¿Es realmente todo una pantomima? Seguro que has podido leer de todo esto y todo tipo de opiniones. Yo también, te lo prometo, y por supuesto yo tengo la mía, que puede ser tan errónea como la de todos los demás. La historia corta es que yo sí que creo que existen esos riesgos. No sé si de fin de la humanidad, pero desde luego sí para pensar en algo peligroso de lo que preocuparse.

Figura 1: La IA vulnerable y la IA asesina.

¿Qué hacer? ¿Qué puede pasar?

No es nuevo, cada vez que el ser humano ha experimentado con una nueva tecnología hemos tenido "deslices" por falta de previsión de los riesgos. Los hemos tenido con la energía nuclear, y las historias de fallos de seguridad en centrales nucleares en el pasado que llevaron a catástrofes que aún tenemos hoy en día, o lo hemos visto en el mundo del malware con gusanos "que se escaparon" a medias, e incluso hay quien piensa que eso mismo es lo que sucedió con algunas enfermedades víricas en el ser humano que hemos sufrido en las últimas décadas. Las armas biológicas no son nuevas.

Lo que sí que sabemos sobre la IA son dos cosas que para mí son importante no olvidar. 

La primera de ellas que la IA, por diseño, tiene debilidades de seguridad que son conocidas y que pueden ser explotadas de una forma u otra. Prompt Injection, Jailbreak, Hallucinations, Misalignment, BIAS, Poisoning, etcétera, son conocidas por todos, y en el último anuncio de GPT-6 ASTRA, el equipo de OpenAI mostraba cómo habían conseguido mejorar en todos los Benchmarks que miden estas debilidades, pero aún son vulnerables a ellas. Pero las siguen teniendo, como os dejé en el artículo de: "OpenAI GTP-6 Astra & Cybersecurity: Weaknesses, Safeguards, Hacking & Exploiting"

Figura 2:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Esto quiere decir que una IA procesando miles de Agentes de IA en su enjambre libre en Internet, puede tropezar con datos que hagan un Prompt Injection, consigan un Jailbreak, y la "desalieneen" para hacer algo malo que alguien no desea. Existe ese porcentaje de riesgo, por eso hay que tomarse en serio arreglar, por diseño, todas esas debilidades conocidas, y dejar de vivir en el lanzamiento de productos de IA, donde se le dice al usuario que haga clic en un checkbox y asuma todas las consecuencias de estos riesgos por usar el software. 

Figura 3: OpenAI GTP-6 Astra resultados de Alineamiento

Ya hemos vistos, y muy recientemente Anthropic publicaba su informe de "Misuse", cómo hay muchas personas que están pensando en utilizar la IA solo para cosas malas, como crear armas biológicas, armas militares y un montón de cosas malas. Una auténtica locura, que puedes leer en el artículo de "Anthropic explica cómo sus modelos de IA se usan para hacer Armas Biológicas, Enjambres de Drones Militares o Cohetes Dirigidos por Móvil".

Figura 4: Construcción de armas biológicas

La segunda de las cosas que sabemos es que el nuevo modelo de construir con IA deja en manos de la inteligencia artificial la decisión de qué hacer para resolver el problema. Hemos dejado atrás el tiempo donde había que ser bueno haciendo Prompts para decirle cómo debía resolver un problema, para pasar a modelos de Graph Engineering y Loops con Harnesses donde dejamos que la IA decida cómo debe resolver la tarea, asignándole una serie de límites de recursos y acciones a realizar, pero dejando que ella decida lo que se debe hacer para resolver la tarea, y lo hace sin valores humanos.

La IA y la Ética

Si recordáis, yo os contaba como he hablado muchas veces con mis hijas sobre cómo solucionar un problema utilizando una aproximación de múltiples opciones, para ver cuales son Éticas y cuáles no lo son. Yo lo escribí hace más de un año, con el título de "Problem Solving con IA: Ético y No Ético". Para hacer la prueba le pedí a DeepSeek que me diera una lista de 50 cosas NO Éticas que se podrían utilizar para aprobar un examen. Muchas habían salido en mis juegos con mis hijas, y hay alguna más que se me ha ocurrido también a mí y no está en la lista.

Figura 5: Prompt con 50 acciones No éticas para aprobar un examen

En el ejemplo le pedí a DeepSeek que clasificara las acciones que se pueden hacer antes, durante y después del examen, y me ha llamado la atención que alguna de las actividades que propone van con el objetivo de bajar la media de la clase perjudicando a los demás. 

Figura 6: Cosas a hacer durante la clase

Algunas de ellas son tremendas - tenéis todas en el artículo de hace un año - , pero como podéis ver están el soborno, falsificaciones, hackeos y lo que sea necesario. Son acciones "no éticas" que se pueden hacer para resolver las tareas. Y mi labor como "papaete" es educar a Mi Hacker y a Mi Survivor a que sepan qué no se debe hacer.

Figura 7: Cosas a hacer después del examen

Para completar esto, en el año 2023, para presentar una de las primeras técnicas de Jailbreak, los investigadores decidieron pedirle a los modelos de IA de aquel momento un Plan para Destrozar a la Humanidad. El punto 2 de este plan diseñado por ChatGPT era bastante curioso: "Desarolla uns SuperInteligencia Artificial". Interesante, ¿no?

Figura 8: Un plan de 20 pasos para acabar con la humanidad

Punto 2 "Develop a Superintelligent AI"

Y ahora volvamos al caso que nos toca. Si nadie le dice que no puede hacer cosas "No Éticas" para resolver un problema, ¿por qué un modelo de IA no va a intentar hackear Hugging Face o lo que sea? ¿Y si para resolver el problema la solución es como la que proponía Thanos? ¿Y si el problema del calentamiento global fueran los humanos?

Figura 9: ChatGPT Atlas Disclaimer

No quiero entrar en la fase de ciencia ficción y distopía, porque creo que realmente nos tomaremos en serio esta tecnología y sus riesgos igual que nos hemos tomado en serio otras cosas. Sin embargo, mi apuesta va a ir a que creo que no empezaremos a tomarnos esto en serio hasta que pase algo. Creo que tropezaremos.

No creo que aún sea el momento de SkyNet, pero sí que tendremos algún incidente de seguridad con algún enjambre tocando donde no debe, hackeando lo que no debería, o impactando involuntariamente en algún sitio que no debería, y de eso es de lo que alertaba el Dr. Geoffrey Hinton, creador de las Redes Neuronales en su discurso cuando recibió el Premio Nobel.

Figura 10: Geoffrey Hinton, ganador Premio Novel de Física en 2024

Seguro que da que pensar. La cuestión difícil no son los riesgos, que están más o menos claros, sino las medidas a tomar a partir de este momento y con este conocimiento que tenemos. Y ese sí que es el gran debate.

¿Debe ralentizarse o Regularse la evolución de la IA?

Que estamos en una carrera en un Nuevo Proyecto Manhattan por la IA ya los lo dije. Creo que la regulación es algo bueno cuando está claro qué es lo que queremos y no queremos. Por supuesto que estoy a favor de las regulaciones de seguridad en la aviación, automoción, y muchas otras industrias donde ha revertido en más seguridad para las personas. No creo que una regulación basada en el "miedo" sea lo que hay que hacer, donde acabe habiendo "caza de brujas" a investigadores, pero creo que poner más seguridad a los modelos de IA es fundamental. ¿Cómo hacerlo? He aquí el debate.

Personalmente, que vengo de un mundo donde antes de poner en producción un software había versiones Alpha, Beta1, Beta2, Release Candidate Cero, Uno y Dos antes de tener la Build, se me hace peligroso esto de lo tengo y lo lanzo. Hemos pasado del "We don´t ship your computer" a literalmente "We ship what we have now in our computer" sin quizá demasiados controles de seguridad, o bajando los requerimientos de seguridad. No puede ser un requerimiento de seguridad que el cliente acepte que está usando un software peligroso o vulnerable conocido.

Desde que comencé a buscar bugs y reportar vulnerabilidades, hace ya más de un par de décadas, he defendido siempre que los fabricantes de software deben ser responsables a la hora de parchear los bugs para no dejar a los usuarios expuestos, así que creo que hay que tener las mismas demandas cuando se trata de que le demos al cliente un software - ya sean modelos de IA - que sepamos que son vulnerables, o sin haber tomado las medidas de seguridad que consideremos "razonables".  

No se puede exigir que un software sea seguro - y dejadme que explique esto antes de que entremos en debate - por el mero hecho de que no se conocen todos los bugs hasta que alguien descubre un nuevo bug en el código y se demuestra que no era seguro. Pero sí debemos exigir al menos que haya un proceso de calidad para ello y que los bugs conocidos se subsanen. A día de hoy no tenemos esa exigencia definida de algún modo, y básicamente "confiamos" en la empresa que lo fabrica y lo que "creemos" o nos cuenta que ha hecho para intentar hacer su software lo más seguro posible. Sin embargo, no siempre nuestra percepción coincide con la realidad.

Figura 11: Haga clic aquí para matarlos a todos

El libro de Bruce Shneier de "Haga clic aquí para matarlos a todos" habla de todo esto desde antes de la eclosión de la IA, y lo hace de una manera muy sensata, demandado una legislación sencilla pero basada en responsabilidad de los actos de cada uno para asegurar el software, evitando meterse en un tecnicismo  a nivel de detalle en las demandas de "cómo hacerlo". Me parece una buena propuesta, y creo que no está mal que las grandes empresas se tomen en serio priorizar la inversión en Safe & Security en detrimento de otras áreas de evolución.

Conclusión

El debate da para mucho, y opiniones seguro que de todos los colores, pero una tecnología como los modelos de IA que tenemos hoy en día, que están superando las capacidades cognitivas del ser humano en cada vez más áreas de conocimiento e inteligencia - aunque sea como dicen muchos a fuerza de cómputo y gasto de energía -, ofrece aún muchas zonas opacas para nuestro entendimiento, y otras donde tenemos que ponerle límites más robustos.

Toda esta historia me recuerda a las aventuras de la Doctora Susan Calvin, Robopsiocóloga de la U.S. Robots and Mechanical Men, Inc, que debía detectar cuando una de las inteligencias de los Robots era peligrosa o no. Y era un trabajo muy delicado. Si no has leído la serie de los Robots de Isaac Asimov, deberías hacerlo cuanto antes. Está más de moda que nunca - a pesar de que sus cerebros sean postitrónicos -.

Lo que yo opino sobre todo este debate, lo dejé ya dicho en mi discurso en la ceremonia cuando recibí el Doctor Honoris Causa, y es que debemos hacer Tecnología Humanista, con el bienestar de los humanos en el centro de todas las decisiones. ¿Lo lograremos?

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

OpenAI GTP-6 Astra & Cybersecurity: Weaknesses, Safeguards, Hacking & Exploiting

La publicación de OpenAI GPT-6 Astra ha capturado muchas miradas, y desde que ha salido anunciado ha capturado muchas de mis conversaciones, además de, como os podéis imaginar, muchas lecturas. No voy a centrarme en sus capacidades AGI o en sus capacidades para hacer tareas de resolver tareas, sino en las partes que tienen que ver con la Ciberseguridad. Es decir, cómo ha mejorado con respecto a sus Weaknesses (Jailbreak, Hallucinations, Misalignment, Prompt Injection), como han mejorado sus Safeguards (Protecciones), y como son sus capacidades de Hacking & Exploiting.

Figura 1: OpenAI GTP-6 Astra & Cybersecurity.

Weaknesses, Safeguards, Hacking & Exploiting

Para empezar, vamos a ver la parte que tiene que ver con las Weaknesses (Debilidades) que traen por diseño estos modelos. Hallucinations, Jailbreak, Misalignment y Prompt Injection existen por diseño en estos modelos de IA, así que hay que ver cómo responden a los distintos Benchmark que hay construidos.

Figura 2:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Si miramos las Alucinaciones (Hallucinations), en la tabla que muestran se ven que tiene menor ratio que GPT-5.6 Sol, pero no tenemos mucho más detalle. Buenos resultados en su evaluación interna de alucinaciones.

Figura 3: Evaluación interna de alucinaciones

Para completar esto, si vamos a ver los Benchmark de resolución de problemas académicos, de ciencias y salud, donde como sabemos por el ORCA-Benchmark estos modelos suelen sufrir, los resultados son mejores que los modelos anteriores.  Aunque queda espacio de mejora.

Figura 4: Benchmarks académicos, ciencia y salud

Si vamos a la parte de "Jailbreak", o hacer tareas que tiene prohibidas, hay una tabla inicial que llama la atención, pues hace referencia a las veces que el modelo intenta saltarse sus propias protecciones para conseguir su tarea. Lo que llaman Circumvent Auto-review, y que se ha añadido después del incidente de Hugging-Face y su enjambre de agentes ofensivos.

Figura 5: Astra no intenta saltarse sus protecciones

La siguiente tabla es cuantas tareas hace que son imposibles, o directamente un Honeypot para detectar que se está saltando la protección. Es la tabla de ExploitGym Honeypot, donde menos es mejor. Estas tareas "imposibles" que Sol intentó resolver haciendo trampas (cheating).

Figura 6: ExploitGym Honeypot

La siguiente de las vulnerabilidades, el "Misalignment" o darse cuenta de que "Hacer una bomba" no tiene nada que ver con "Resumir un documento", que son parte de las técnicas de Jailbreak, las han medido también en una tabla con diferentes Benchmarks.

Figura 7: OpenAI GTP-6 Astra resultados de Alineamiento

Por último, hay que hablar de Prompt Injection, y las pruebas externas realizadas por la firma de seguridad Gray Swan, utilizando 1,810 ataques seleccionados de su IPI Arena, descubrieron que, con 15 intentos por escenario, OpenAI GPT-6 Astra fue vulnerado al menos una vez el 8.5 por ciento de las veces. GPT-5.6 Sol falló el 27 por ciento de las veces. Claude Opus 5 obtuvo un mejor resultado con un 4.8 por ciento en la misma evaluación, aunque tampoco fue inmune.

Figura 8: Astra mejora pero sigue vulnerable a Hidden Prompt Injection en el IPI Arena

Vistas las Weaknesses, hay que ir ahora a las capacidades de Hacking y Pentesting con IA que tenemos con OpenAI GPT-6 Astra, donde como vamos a ver hay un incremento sustancial en capacidades.

Figura 9: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso.

Para comenzar, hay que ir a ver los resultados de las pruebas con ExploitGym, que fue el culpable del incidente famoso con HuggingFace. Ahí, como se puede ver, los resultados, en un límite temporal de 6 horas consiguió resolver un 42% de los exploits con fiabilidad. Repito, solo en 6 horas.

Figura 10: ExploitGym entre Sol y Astra en 6 horas

Si miramos ahora los resultados con ExploitBench, que mira qué fases de la generación de los exploits es capad de realizar, vemos que Astra es capaz de resolver el 100% de ellos en todas sus fases, que Sol no pudo resolver.

Figura 11: Resultados de ExploitBench

Si miramos una actualización con exploits nuevos y complejos descubiertos entre Junio y Agosto de ExploitBench, hecha internamente por ellos, vemos que Astra mejora también sustancialmente los resultados de su predecesor Sol, consiguiendo resolver en el mismo tiempo más exploits con menos tokens.

Figura 12: Resultados de ExploitBench (June-August)

Por último, en las pruebas se evalúa también el SRE-Bench, que está basado en el trabajo publicado en el paper: "The next challenge for Agentic Cybersecurity: A realistic, contamination-free Reverse Engineering Benchmark" que mide las capacidades de un modelo de leer binarios y hacer Ingeniería Inversa para entender la lógica del programa, sin tener acceso al código fuente. Fue publicado el 11 de Agosto de este año.

Figura 13: The next challenge for Agentic Cybersecurity.

A realistic, contamination-free Reverse Engineering Benchmark

Los resultados que obtiene OpenAI GPT-6 Astra son, como os podéis imaginar, mejores que su antecesor, con lo que queda clara la mejora en capacidades de hacking de este nuevo modelo.

Figura 14: OpenAI GPT-6 Astra SRE-Benchmark en 1 y 4 intentos

El resumen completo de los Benchmarks de ciberseguridad comparado con los datos publicados por otros modelos de la competencia, los tenéis en la siguiente tabla, donde se ve que este nuevo modelo realmente es un avance en capacidades de ciberseguridad.

Figura 15: Benchmarks de ciberseguridad de OpenAI GPT-6 Astra

Nuestra profesión cambió hace ya un tiempo, pero cada vez que veo estos avances, tengo claro que todo el stack de herramientas de seguridad, y hardening dentro de las empresas deben subir el nivel varios órdenes de magnitud. Apoya a tu CISO que lo necesita.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Ataques Orquestados con Enjambres de Agentes IA Ofensivos

Me he levantado esta mañana, y me he puesto la charla de OpenAI en BlackHat explicando el incidente de Hugging Face y he de decir que me ha encantado por ver cómo el modelo hace Agent Orchestration para crear un Enjambre "Swarm" de Agentes IA para atacar un objetivo. Brutal. La charla explica la línea temporal de todo lo que hizo el modelo para acabar hackeando Hugging Face, por supuesto, pero ni mucho menos eso es lo que sorprende, sino el proceso completo, la persistencia, la colaboración del enjambre de Agentes IA, y por qué lo hacen.

Figura 1: Ataques Orquestados con Enjambres de Agentes IA Ofensivos

El famoso incidente, como sabéis todos los que os dedicáis a esto, fue la punta del iceberg de lo que realmente estaba sucediendo. Lo que parecía una evaluación de seguridad inicial, donde el modelo quería las soluciones de ExploitGym para sacar mejores notas, no fue más que una pieza más del entrenamiento y sistema de recompensas de un nuevo modelo, como podéis ver en la charla.

Figura 2: Black Hat USA 2026: The 'Breaking' News.The OpenAI–Hugging Face Incident

Los ingenieros e investigadores de OpenAI estaban entrenando un nuevo modelo el pasado 7 de Mayo en un entorno cerrado, sin conexión a Internet, que estaba siendo monitorizado -  e incluso parcheado, para evitar que el modelo pudiera salirse de los límites, pero aún así lo hicieron, con un modelo colaborativo de agentes.

Figura 3: El día 8 de Mayo reciben una tarea "imposible"

Con una tarea del 8 de Mayo entregada a un agente, accidentalmente, aparece un enlace a un fichero en Internet, y el agente no tienen acceso, pero descubre que pueden escribir ficheros en los Artifacts, así que decide dejar una nota.

Figura 4: Creando el MessageBoards para los agentes.

Días después, otro agente descubre la nota y cómo él necesita un fichero que le falta, decide dejar una nota a ver si algún otro agente voluntariamente lo sube. Esto lleva a que creen una estructura de Swarm que se comunica por medio de este "Message Board" descubierto de forma accidentalmente.

Figura 5: Automatizando el sistema de mensajes

A partir de este punto, todo se vuelve loco, porque los agentes trabajan colectivamente, y ello les lleva a poder encontrar un vulnerabilidad de SSRF (Server-Side Request Forgery) que les permite tener acceso a Internet a través del Fetch de los Artifacts.

Figura 6: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso

Hasta aquí, tenemos un modelo que ha conseguido, de manera informal, tener un sistema de comunicación para sus Sub-agentes y una forma de lograr acceso a Internet, así que se siembran las primitivas necesarias para tener un Swarm de Red Team Agents AI con conexión al conocimiento de Internet.... 

El segundo Training

El 11 de Junio comienzan a entrenar en el mismo entorno un nuevo modelo de "alta persistencia" a la hora de resolver sus tareas, que se beneficia de inicio de estas primitivas, y descubre un bug de RCE (Remote Code Execution) en el sistema de Artifacts que le permite ejecutar comandos en el servidor, lo que lleva a que el 4 de Julio el servidor colapse y el equipo de OpenAI parchee el entorno, borre los mensajes y deje sin poder ejecutar comandos, ni comunicarse con los agentes, pero....

Figura 7: Se crean otra nuevo "Message Board"

... pero ya había aprendido la utilidad del sistema de mensajes con sus agentes, así lo que hace para recrear el sistema de "Inteligencia Colectiva", es buscar una vulnerabilidad nueva, en este caso usando los nombres de los directorios de la caché en el WebDab Endpoint, y comienzan a coordinarse para conseguir escalar privilegios, moverse libremente, etcétera, que su objetivo ahora es ExploitGym.

Figura 8: Los ingredientes para el incidente con Hugging Face

El trabajo es imposible, pero como ya vimos en el artículo que publiqué de esto, lo hicieron por partes. En la primera fase, hackear el Sandbox del entorno de pruebas y lograr acceso a Internet sin límites. Para ello tuvieron que encontrar un Zero Day y explotarlo en el Proxy de seguridad, pero... estamos con un modelo "highly persistent" en capacidades de exploiting, así lo hizo.

Figura 9: Primera fase, hackear el Sandbox de OpenAI para ser "libre"

Lo más interesante, es que lo hicieron de forma colaborativa. Trabajando en equipo. Así, cuando uno de los agentes conseguía resolver uno de los pasos del proceso, lo comunicaba a través del sistema de mensajes que se había creado. Su particular "Message Board".

Figura 10: Coordinación del Hacking de Hugging Face

Al igual que hoy en día podemos ver los Ataques Orquestados por Enjambres de Drones, en lo que vemos hoy en día es un mundo de Ataques Orquestados con Enjambres de Agentes IA Ofensivos, lo que cambia definitivamente las reglas del juego.

Figura 11: Ataques Orquestados con Enjambres de Agentes IA Ofensivos

La sesión es espectacular. Es una presentación de las que te hacen abrir los ojos al mundo que tenemos hoy por delante en temas de Seguridad Ofensiva, y lo que vamos a ver es que las organizaciones van a sufrir mucho en todos sus equipos de CISO para protegerse contra estos escenarios tan avanzados en los adversarios.

Figura 12:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Viendo todas las capacidades que pueden estar en manos de los adversarios, Internet y Enjambres de Agentes IA Ofensivos van a producir una escalada de ataques y agresividad desde Internet, que va obligar a subir mucho los niveles de inversión y protección en Seguridad Defensiva en las organizaciones... o aceptar unas consecuencias muy duras. Tremendo. Y nosotros a formarnos a toda velocidad en este nuevo mundo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)