Anthropic se reservó el lanzamiento de su modelo de detección de errores Mythos debido a la preocupación de que permitiera a los atacantes encontrar y explotar vulnerabilidades antes de que se pudiera generar una respuesta.
Sin embargo, el modelo Opus 4.6 de la compañía, ya reemplazado por el lanzamiento de Opus 4.7 el jueves, es capaz de desarrollar código de explotación (exploit) funcional.
En una publicación de blog del miércoles, Mohan Pedhapati (s1r1us), CTO de Hacktron, describió cómo utilizó Opus 4.6 para crear una cadena de explotación completa dirigida al motor JavaScript V8 en Chrome 138, que viene incluido en las versiones actuales de Discord.
“El error de V8 [out-of-bounds] que utilizamos provenía de Chrome 146, la misma versión que ejecuta Claude Desktop de Anthropic”, dijo. “Una semana de idas y venidas, 2,300 millones de tokens, $2,283 dólares en costos de API y unas 20 horas de mi parte resolviendo problemas. ¡Fue un éxito rotundo!”
El término “Popped calc” hace referencia a la apertura de la aplicación de calculadora, un evento comúnmente utilizado en código de pruebas de concepto (PoC) para indicar que un ataque comprometió el sistema objetivo.
Índice de temas
La realidad de crear exploits con Claude Opus: Costos y factibilidad
Pedhapati afirmó que, si bien $2,283 dólares es una suma considerable para un individuo, es muy poco si se tienen en cuenta las semanas que le tomaría a una persona desarrollar un exploit similar sin ayuda. Incluso si se añadieran varios miles de dólares por el tiempo que Pedhapati dedicó al modelo, seguiría siendo significativamente menor que la recompensa teórica (aproximadamente $15,000 dólares) que se podría obtener de los programas de bug bounty de Google y Discord. Y eso solo en el mercado legítimo; ¿quién sabe cuánto podrían pagar los delincuentes por una vulnerabilidad de día cero?
Según la hoja de especificaciones de Opus 4.7, “Opus 4.7 es bastante similar a Opus 4.6 en cuanto a capacidades cibernéticas”. Sin embargo, aparentemente es menos potente que Mythos Preview e incluye “medidas de seguridad que detectan y bloquean automáticamente las solicitudes que indican usos de ciberseguridad prohibidos o de alto riesgo”.
Para el CTO, el problema no radica en el modelo específico, sino en las constantes mejoras en la generación de código, que exigen un cambio en la estrategia y los procedimientos de IT.
“Da igual si Mythos está sobrevalorado o no”, afirmó Pedhapati. “La situación no mejora. Si no es Mythos, será la siguiente versión, o la siguiente. Con el tiempo, cualquier aficionado con suficiente paciencia y una clave API podrá acceder a software sin parchear. Es cuestión de cuándo, no de si sucederá”.
Para las aplicaciones basadas en el framework Electron de Chromium (por ejemplo, Slack, Discord, etc.), la pregunta es cuándo actualizarán su código a la última versión, que aún está por detrás de la versión estable de Google Chrome.
Electron 41.2.1, lanzado el 15 de abril, incluye Chrome 146.0.7680.188, solo una versión por detrás de la versión de escritorio de Google Chrome (147.0.7727.101/102) lanzada ese mismo día. Sin embargo, los desarrolladores de aplicaciones Electron no siempre actualizan sus dependencias ni publican nuevas versiones de inmediato. Y los usuarios no siempre reciben esas actualizaciones de forma automática.
Pedhapati explicó que eligió Discord como objetivo porque “utiliza Chrome 138, nueve versiones principales por detrás de la actual”.
Riesgos en la cadena de suministro: El motor V8 bajo la lupa de la GenAI
El experto argumenta que, a medida que los modelos de AI se vuelven más capaces de desarrollar exploits, el margen de tiempo para aplicar parches se reduce.
“Cada parche es básicamente una pista para un exploit“, afirma, y añade que esto será particularmente difícil para los proyectos de código abierto, ya que las correcciones a menudo se hacen visibles públicamente en el código antes de que se publique la versión revisada.
Su consejo para los desarrolladores es que se centren más en la seguridad antes de implementar el código y que presten mayor atención a las dependencias, para que los cambios se puedan realizar rápidamente. También argumenta que las actualizaciones de seguridad deberían realizarse automáticamente para evitar que los usuarios queden vulnerables por olvidarse de aceptarlas. Además, afirma que los proyectos de código abierto como V8 son más cautosos a la hora de publicar detalles sobre vulnerabilidades.
«Cada commit público es una oportunidad de oro para cualquiera que tenga una clave API y un equipo con experiencia capaz de explotar vulnerabilidades», declaró.
