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

Utilizar la Inteligencia Artificial para buscar vulnerabilidades es algo de lo que os he hablado en más de alguna ocasión. En el artículo de "Usar Deep Reasoning en GitHub para buscar ( y parchear ) Bugs en proyectos Open Source" os hablaba hace ya un años de que me extrañaba mucho que esto no fuera un parte fundamental de los repositorios de código. Y sobre explotar CVEs publicados sólo con la información pública, ya tuvimos en el año 2024 el paper de "LLM Agents can Autonomously Exploit One-day Vulnerabilities".

Figura 1: 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

Esto, lógicamente, lleva a que la profesión de dedicarse al Bug Bounty haya cambiado, y empiece a ser imprescindible trabajar con los LLM tanto para la búsqueda como para la explotación, que es de lo que habla David Padilla  en su libro de "Bug Hunter".

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

Esto mismo es lo que ha hecho el investigador s1r1us con Google Chrome, para demostrar el riesgo que además esto tiene en las aplicaciones hechas con Electron, y que ha publicado en un artículo que debes leer "I Let Claude Opus Write a Chrome Exploit: The Next Model (Mythos?) Won't Need My Help?". El gran problema es que las aplicaciones hechas con Electron llevan embebidas versiones de Chrome completas, pero hay un gap entre la actualización y parcheo de vulnerabilidades de Google Chrome y las versiones que llevan aplicaciones súper populares hechas con Electron.

Figura 3: Versiones de Google Chrome en aplicaciones Electron

A día de hoy, estamos, tras la última actualización del 7 de Abril en Google Chrome 147, así que todos los bugs parcheados en esta última versión, aún están presentes en Cursor, Claude Desktop, Discord, Slack, etcétera. Así que... ¿por qué no, a partir de la publicación de los CVEs parcheados en Google Chrome usar Claude Opus (No Mythos) para intentar hacer el exploit de estas vulnerabilidades conocidas?

Figura 4: Lista de CVEs de criticidad alta parcheados en Google Chrome 147

Para ello, s1r1us estuvo enfocando a Claude Opus sobre distintos CVEs de los que no había exploit público, gastando tokens y dinero en ellos, hasta que encontró uno que el modelo descubrió cómo explotarlo, y con la ayuda del investigador - sólo con prompting - fue trabajando hasta que consiguió un código funcional que permitía ejecutar las primitivas de escritura y lectura dentro de la Sandbox de Google Chrome.

Figura 5: CVE explotado en el estudio

Por supuesto no es un 0-day, sino un 1-day o n-day, como quieras llamarlo, pero del que no existe un exploit público, por lo que sigue teniendo mucho valor en el mercado del bug bounty legítimo, pero como os podéis imaginar, también en el mercado negro. 

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.

El siguiente fase hay que conseguir evadir la sandbox, y de esto no hay un CVE claro, pero el investigador hace una cosa maravillosa, que es irse a Chromium Tracker y buscar un reporte de existencia de este problema, y encontró el fallo descrito como: "V8 Sandbox Bypass: WasmCPT handle UAF by import dispatch table growth", un fallo conocido en la V8 Sandbox de Chromium.

Figura 7:"V8 Sandbox Bypass: WasmCPT handle UAF by import dispatch table growth"

Así que apuntó a Claude Opus hacia él, y juntando las dos piezas fue capaz de conseguir construir un exploit totalmente funcional para un CVE público del que no había exploit conocido, y que tiene un valor espectacular para el equipo de seguridad de Google, para las empresas de seguridad ofensiva y, por supuesto para el black market.

Figura 8: Explotando el Sandbox

Por supuesto, los datos son los más interesantes, porque dejan ver el mundo hacia donde vamos, y que como podéis ver permite que con unas 20 horas de trabajo de "babysitter", y unos 2.000 USD en tokens se posible explotar un CVE conocido que está sin parchear en tooooooodas las aplicaciones Electron tan populares que tenemos hoy en día, con millones de instalaciones en todas las empresas y organizaciones que te puedas imaginar.

Figura 9: Coste en Tokens para hacer el exploit funcional

Estos exploits, se pagan en los Bug Bounties por unos 10.000 USD, así que sigue saliendo positivo en términos económicos el experimento, pero sobre todo pensando en la evolución de estos modelos. ¿Cómo será este mundo cuando se liberen modelos como Mythos? ¿Podremos permitirnos publicaciones de CVEs con tanta información pública? 

Figura 10: Explotación del CVE-2026-5873 con Claude Code. Horas, tokes y coste

¿Serán sostenibles estos gaps entre los componentes y las aplicaciones que usan esos componentes? En la gráfica anterior tenéis un resumen de los días, las horas, los tokens y los costes invertidos en conseguir hacer este exploit. En el mundo de los exploits, estos costes son ridículos, y tener exploiters experimentados capaces de hacer estas cosas suele costar mucho más dinero. Mundo curioso al que vamos.

Figura 11:"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 te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que se han  escrito, citado o publicado en este blog 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)  

Google Chrome: Al final era "Security & Privacy Bug" y no una "Feature" o un "Issue"

El próximo 25 de Mayo hará 6 años que, desde el equipo de Informática 64 reportamos al equipo de seguridad de Chromium que en Google Chrome 4 había un comportamiento anómalo de seguridad por como gestionaba las opciones de protección contra la carga del contenido que se hace en una página web. Básicamente, existía un caso en el que aún habiendo sido bloqueada la carga de contenido JavaScript desde un determinado dominio, si este se metía en un iframe se saltaba esta protección.

Figura 1: Google Chrome: Al final era "Security & Privacy Bug" y no una "Feature" o un "Issue"

Para estudiar aquel caso se abrió un ID en el sistema de reporte de bugs con el número 44985 donde dejamos toda la información. Al principio, algunos de los ingenieros defendieron ese comportamiento y lo llegaron a calificar como un problema en la explicación de la "Feature", por lo que en la clasificación le asignaron un "WordFix" y lo dieron por cerrado en una primera catalogación.

Figura 2: Primera catalogación como Feature y se cierra como un "WordFix"

Por supuesto, al poco, comenzó el debate cuando algunos ingenieros no tenían tan claro que ese debiera ser el comportamiento de Google Chrome ante el contenido cargado desde un iframe si el usuario había expresado claramente que no quería cargar ningún JavaScript desde un determinado dominio - viniera o no ese contenido en un iframe -, por lo que se volvió a abrir y se convirtió en una "Issue" en una segunda catalogación.

Tercera catalogación

Con el paso del tiempo, este "Issue" se unió con otras conversaciones que fueron apareciendo posteriormente durante el año 2014 y se le asignó el ID 444744 para que lo estudiaran. En ese momento, la catalogación de este Issue pasó a ser de Privacy & Security-UX Feature con prioridad 3 para ser arreglada.

Figura 3: Tercera catalogación como Privacy & Security-UX Feature

Con este tratamiento, ya se puso en la cola de tareas a corregir, pero aún no se pusieron manos a la obra a corregirla. Tendríamos que esperar aún un par de años para que esto se tomara de otra forma.

Cuarta catalogación

Como yo abrí el caso, cada vez que hay un cambio en el estado de este "Issue" recibo una alerta, y la última me ha traído como sorpresa que ha sido recatalogado esta vez como Security & Privacy Bug con prioridad 2. 

Figura 4: Cuarta catalogación como Security & Privacy Bug

Es decir, la Feature mal explicada que se catalogó inicialmente como un WordFix, que luego se catalogó como Issue, que luego se puso como Privay & Security-UX Feature, ha terminado como Security & Privacy Bug al cabo de 6 años. Hemos pasado de la versión 4 a la versión 49 de Google Chrome, pero nunca es tarde si al final lo acaban corrigiendo.

Saludos Malignos!

El "issue" de Google Chrome 4 sigue activo en la versión 36

Fue en el año 2010 cuando, desde Informática 64, reportamos a Google que la función de bloqueo de contenido JavasScript en Google Chrome 4 no funcionaba demasiado bien, pero por decisión suya, a día de hoy sigue funcionando tal y como funcionaba en aquel entonces. Con la notificación se abrió un expediente de seguimiento en Chromium, en concreto con el ID 44985.

Esta semana, ha habido un cambio de categoría del mismo y me ha llegado una notificación por correo electrónico. En el expediente se puede ver que el "issue" se considera una característica que afecta a la Privacidad, la Seguridad y la Experiencia de Usuario en Seguridad, tal y como puedes ver aquí.

Figura 1: Expediente del "issue" 4495 en el proyecto Chromium

Por supuesto, después de este mensaje he decidido que había que comprobar que seguía activo, y sí. Sigue estando de la misma forma en la que se dejó en el año 2010, allá por la versión de Google Chrome 4, pero en la versión Google Chrome 36. Si tienes otra versión, puedes probar también.

Figura 2: Versión de Google Chrome probada

Para los que no estén al día, el "fallo en la experiencia de usuario de seguridad" que catalogaron como "issue" se produce con el bloqueo de contenido JavaScript. Supongamos que alguien quiere bloquear el contenido JavaScript de un dominio. Para ello se va a las opciones de configuración, y en la parte de contenido deja JavaScript habilitado para todas las páginas, excepto para la del dominio concreto que quiere bloquear. En mi caso he elegido un web con un emulador JavaScript de NES.

Figura 3: Se permite JavaScript para todos los dominios excepto para jsmess.textfiles.com

Una vez que se ha hecho esto, si alguien accede a cualquier página de ese dominio, lo que se obtiene es que el contenido JavaScript no se ejecuta, por lo que no se puede cargar el emulador, tal y como puedes ver en la imagen siguiente.

Figura 4: Si se accede a la URL ahora está bloqueado JavaScript

Pero basta con invocar el contenido de la URL con un iframe src que cargue el contenido, y listo. Así que cierra el navegador, abre una nueva pestaña con el archivo que carga en el iframe el emulador JavaScript y podrás verlo funcionando. Es decir, la opción de bloquear el contenido JavaScript solo afecta si la web se carga en la barra de direcciones, pero nada más.

Figura 5: Contenido JavaScript ejecutado en el iframe, pese a estar bloqueado el dominio

Al final, el problema es que si alguien piensa que esta opción le puede servir para protegerse, por ejemplo, de sitios que hagan tracking de hábitos - por ejemplo empresas de publicidad agresiva - bloqueando los dominios desde donde las webs afiliadas cargan los ficheros JavaScript, se estará equivocando. Esto solo funciona si la web se carga en el dominio principal, pero nada más.

Figura 6: La respuesta -> "Es un issue"

Aún sigue abierto el "issue", así que tal vez en un futuro, cercano o no, acabarán cambiándolo para que esto tenga realmente una utilidad, o al menos informando de cómo funciona realmente esa característica, que parece que sirve para bloquear el JavaScript de un dominio, ¿verdad?.

Saludos Malignos!