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)  

Cómo explotar una vulnerabilidad de DLL Hijacking en Slack para Windows

Hasta aquí hemos hablado sobre qué es una DLL y en qué consisten las técnicas de DLL Injection, y también de cómo detectar oportunidades para el DLL Hijacking usando Process Explorer, en el caso de nuestro ejemplo en Slack para Windows. Ahora nos toca continuar el trabajo donde lo dejamos e intentar explotar esta oportunidad de DLL Injection. 

Figura 1: Cómo explotar una vulnerabilidad de DLL Hijacking en Slack para Windows

Como hasta este momento no hemos analizado el binario, no sabemos cómo reaccionará el programa frente al ataque, por lo que la única manera de saber si alguna de esas DLL hace al programa realmente vulnerable al hijacking es mediante ensayo y error. Por norma general, para demostrar un DLL Hijacking de forma práctica se suele recurrir a un programa que simplemente cargue una DLL en tiempo de ejecución mediante la función LoadLibrary(). El ejemplo típico es el siguiente:

Figura 2: Código prototipo en la demostración de un ataque de DLL Hijacking

Hacer un DLL hijacking a este programa es trivial ya que basta con crear una DLL que contenga en su entry-point un payload que nos ayude a identificar que esta DLL maliciosa se carga. En el caso de la siguiente figura el payload es una caja de texto con un mensaje.

Figura 3: DLL maliciosa cuyo payload lanza una ventana con un texto cuando se ejecuta

En este caso, al utilizar la función LoadLibrary() sin especificar la ruta absoluta de la DLL se buscará primero en el directorio de la aplicación (donde se ha depositado la DLL maliciosa previamente) y cuando se cargue la DLL maliciosa se ejecutará el lanzando el mensaje que habíamos escrito:

Figura 4: Resultado de la ejecución del payload

El problema surge cuando queremos ejecutar este mismo ataque con programas reales, entonces observamos que este ejemplo no es muy representativo en la práctica real. Cuando se trata de programas complejos la mayoría de las DLL que identificaremos como vulnerables al hijacking se cargarán mediante vinculación implícita (a través del linker) y, además, tendremos que asegurarnos de que la ejecución del programa no se rompa cuando se cargue la DLL maliciosa en vez de la DLL legítima. 

Figura 5: Libro de Hacking Windows en 0xWord
de Valentín Martín, Carlos García y Pablo González

Esto significa que nuestra DLL maliciosa debe contener, de alguna manera, las funciones que el programa importaría de la DLL legítima. Para lograr esto vamos a recurrir a una técnica conocida como DLL Proxying.

Efectuando un DLL Proxying

Como no sería práctico copiar o replicar en nuestra DLL cada una de las funciones que exporta la DLL legítima a la que intentamos suplantar, vamos a aprovechar la capacidad que nos ofrece el compilador de C/C++ de Visual Studio de Microsoft para exportar funciones a través de una directiva de preprocesador. 

Figura 6: Sintaxis de la directiva que actúa como forwarder

La idea es que cuando se cargue la DLL maliciosa, además de ejecutarse el payload, le “diga” al loader que las funciones deben importarse desde la DLL legítima, haciendo que nuestra DLL actúe como un proxy de funciones. Las directivas export que hacen esto posible se conocen como forwarders y tienen la sintaxis que puedes ver en la Figura 6. En resumen, para hacer un DLL Proxying vamos a introducir dos DLL en el directorio de la aplicación:

• La DLL maliciosa que actuará como proxy y que contiene el payload y los forwarders.

• La DLL legítima que contiene las funciones que necesitan ser exportadas para que el programa se ejecute correctamente.

El proceso para crear una DLL Proxy es un poco tedioso. Tras identificar la DLL que queremos suplantar, necesitamos conocer las funciones que esta DLL exporta. Para hacer esto vamos a utilizar el programa DLL Export Viewer (dllexp). El uso de dllexp es muy sencillo: abrimos el programa y seleccionamos la ruta de la DLL que queremos inspeccionar (generalmente en C:\Windows\System32\) y una vez generada la lista de funciones la exportamos como reporte en HTML:

Figura 7: Uso de DLL Export Viewer

Ahora que tenemos la lista de funciones exportadas hay que crear una directiva que sirva como forwarder para cada una de las funciones. Para hacer esto hay varios scripts que automatizan la tarea de convertir el reporte HTML a las directivas #pragma que necesitamos copiar en el código de nuestra DLL. Yo he usado el script de itm4n (Apartado 3, el script está incrustado como texto plano). Tras copiar las directivas en la DLL maliciosa tendrá este aspecto:

Figura 8: Ejemplo de DLL con directivas que actúan como forwarders

Con esto ya tenemos lista la DLL que actuará como proxy. También necesitamos copiar la DLL legítima que se encuentra en C:\Windows\System32\. Ahora solo tenemos que renombrar la DLL maliciosa con el nombre de la DLL legítima y la DLL legítima según el nombre que hayamos puesto en la directiva pragma. Si usas el script de itm4n el nombre por defecto es el mismo nombre de la DLL añadiendo el sufijo “_orig”. 

Figura 9: PoC de DLL Hijacking en Slack para Windows

Una vez hecho este trabajo, basta con introducir ambas DLL en el directorio de la aplicación y comprobar que al ejecutar Slack se ejecuta también nuestro payload tal y como se puede ver en el vídeo de la PoC anterior.

Saludos,  

Autor: Roberto Aranda (Conseguir 100 Tempos para MyPublicInbox gratis con ESET)

Contactar con Roberto Aranda

Metashield Bots: Análisis y limpieza de metadatos para todos desde Telegram, Skype o Slack

Hace no mucho, el laboratorio de ElevenPaths me sorprendió con un proyecto de los suyos que iba a llevar uno de mis productos favoritos, MetaShield, a todos los usuarios de Skype, Telegram o Slack. La idea es bastante sencilla, y a la vez bastante útil y cómoda. Se trata de integrar el motor de limpieza y análisis de metadatos que utiliza MetaShield como un bot de las plataformas Skype, Telegram o Slack.

Figura 1: Metashield Bots: Análisis y limpieza de metadatos para todos desde Telegram, Skype o Slack

El bot se puede invocar y hablar con él para extraer y analizar los metadatos de cualquier documento ofimático, y las únicas limitaciones que tiene son temporales. Es decir, el número de limpiezas que se puede hacer desde una determinada ubicación es de 2 por hora, aunque la integración que hemos hecho con la plataforma de bots permitiría hacer una limpieza de hasta 500 documentos a la hora, pero eso sería para implantaciones empresariales que lo requieran.

Figura 2: MetaShield Bot Skype

El funcionamiento es bastante sencillo, así que hemos grabado estos tres vídeos que explican el proceso de localización del bot en cada una de las plataformas - son bots públicos con los que cualquiera de vosotros puede interactuar -, como hacer el análisis de metadatos de un determinado documento y cómo limpiarlo.

Figura 3: MetaShield Bot Slack

Esto lo presentamos en el pasado Security Day de ElevenPaths, donde también hablamos de Dario - un proyecto que aparece en los vídeos de los bots de MetaShield - que sirve para analizar malware en macros de documentos ofimáticos, pero subiendo solo las partes del documento que son necesarias para ese análisis, lo que ayuda a dotar de más privacidad al documento. Pero eso es otra cosa que os contaremos más adelante.

Figura 4: MetaShield Bot Telegram

El el blog de ElevenPaths tenéis más información de estos tres bots de MetaShield en Skype, Telegram y Slack, y en la web de ElevenPaths tenéis información de todos los productos de la familia MetaShield Protector, incluida la versión de MetaShield Clean-up Online que permite analizar y limpiar metadatos en documentos con un sitio web.

Saludos Malignos!