Smart Things trabajando más allá de su "End of Life": Parchea los electrodomésticos de tu casa.

La noticia de los frigoríficos hakeados ha dado la vuelta al mundo, y a la gente le llama la atención que algo así haya sucedido. La explicación es tan sencilla como sabemos desde hace muchos años. Un producto End of Life, es decir, fuera de soporte y mantenimiento, no tiene parches de seguridad, lo que hace que a partir del día que entra en EoL es un peligro que hay que mitigar.

Figura 1: Smart Things trabajando más allá de su "End of Life".

 Parchea los electrodomésticos de tu casa.

Si a esto le sumas la llegada de la Inteligencia Artificial para Offensive Security, permitiendo que haga un descubrimiento de los elementos, que ayude a construir software de explotación para cualquier protocolo de un dispositivo, por muy raro que parezca, pues tenemos el ecosistema perfecto.

Figura 2: Hacking Home Devices I: PoCs & Hack Just for Fun!

El nuevo libro de 0xWord para aprender a buscar bugs en casa.

Escrito por Gerard Fuguet.

Esto lo lleva advirtiendo Gerard Fuguet muchos años, en sus libros de Hacking Home Devices I y Hacking Home Devices II, donde hace exactamente este tipo de pruebas con todos los Smart Devices que tengas en casa, pero sobre todo explica a cómo realizar estos ataques. 

Figura 3: Un frigorifico no actualizado

Para que entendáis el riesgo fácilmente, yo he querido hacer una pequeña consulta a la Gemini para que me ayude con un escenario que puede ser ficticio, o real, donde un Smart Fridge de Samsung Family Hub no ha sido actualizado desde el día uno. ¿Cuál será su riesgo si lo tengo en casa?

Figura 4: Lista de vulnerabilidades conocidas

Como podéis ver en estas dos imágenes, la lista de vulnerabilidades conocidas es grande y bien documentada. Al final todos se basan en piezas y componentes comunes que son estudiados, de los que se descubren bugs, y que hay que gestionar. Y si no se hace, pues tienes un dispositivo lleno de vulnerabilidades al alcance de cualquier Botnet.

Figura 5: Más vulnerabilidades de mi Smart Fridge ficticio

El resultado es que estando ahí, solo hay que esperar a que un escaneo de un malware de la red, o si tu dispositivo se conecta a Internet y acaba explotado, haga el resto. Lo normal es que se le meta una herramienta de administración remota, y se convierta en un Proxy para los malos, en un bot de scrapping, en un bot para DDoS o infinidad de otras cosas.

Figura 6: Hacking Home Devices II: PoCs & Hack Just for Fun!

Escrito por Gerard Fuguet.

Los riesgos son claros y bien conocidos, y cuando le he preguntado a Gemini, las conclusiones son exactamente las mismas que os acabo de describir, así que no hay mucha más magia y ciencia que la que sabemos: Un Smart-Whatever trabajando en EoL es un riesgo alto de seguridad.

Figura 7: Es un riesgo alto de que acabes en una botnet

La manera de gestionarlo es, parchea todo lo que puedas, y si se te quedan cosas sin parchear, probablemente la recomendación más sensata es que lo desconectes de la red inmediatamente. Es lo que hay.

Figura 8: Pull the plug!!

El problema es que mucha gente ha llenado su casa de televisiones que siguen funcionando, de electrodomésticos que aún se usan, de paneles energéticos, o sistemas de calefacción conectados, que están en EoL y que, porque no tengan parches deban desconectarlo, no es algo que muchos quieran/queramos hacer. Pero es el mundo de los productos hardware convertidos en productos software. Y ahora con LLMs en EoL puede ser una fiesta. ¿Tendremos un "rise of the machine"?

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Bug Bounty: De profesión "Cazarrecompensas". 2a Edición para la Era del IA.

Desde hoy está disponible el último libro de 0xWord. Es la 2a Edición del título "Bug Bounty: De profesión "cazarrecompensas"", que fue un éxito de ventas, pero que con el cambio de todos los programadas de generación de dinero, queríamos darle una vuelta. Este es un libro para los que quieren ganar dinero buscando y reportando bugs, y en el se explica en detalle cómo funcionan estos programas que se han consolidad en los últimos años, haciendo que sea un profesión ampliamente extendida la de Cazarrecompensas en el mundo del hacking. Pero esta vez en la era de la IA.

Figura 1: Nuevo libro de 0xWord -

Bug Bounty: De profesión "Cazarrecompensas".

2a Edición para la Era del IA.

Este trabajo que hacen muchos profesionales es buscar bugs que son recompensados en plataformas de Bug Bounty como son Yes, We Hack, HackerONE, BugCrowd o Intigriti, y que Pablo García ha descrito en profundidad en este nuevo libro con el que puedes descubrir que tu futuro es éste, ser un cazador de recompensas que se dedique a monetizar sus conocimientos cazando bugs en estas plataformas. Y se enseña todo en este libro.

Figura 2: Índice del libro Bug Bounty: De profesión "Cazarecompensas" 2a Edición

Los programas de Bug Bounties – o programas de recompensas – acogen bajo una misma plataforma a compañías que desean que sus sistemas informáticos sean testeados y a hackers dispuestos a reportar vulnerabilidades a cambio de una retribución. A las compañías les permite tener sus sistemas permanentemente testeados por miles de hackers, y pagar únicamente por aquellos fallos con impacto real en sus sistemas, mientras que a los hackers les proporciona un canal seguro a través del cual monetizar su tiempo y conocimientos.

Figura 3: Libro de Bug Bounty: De profesión "Cazarrecompensas"

2a Edición en 0xWord, escrito por Pablo García

En los últimos años, los hackers han conseguido ser recompensados con más de 400 Millones de USD a través de sus reportes a través de los programas de Bug Bounty, y como podéis ver el mercado se está expandiendo.

Figura 4: Más de 400 Millones de USD solo en estos programas de Bug Bounty

El crecimiento exponencial de este fenómeno en los últimos años ha provocado un efecto “fiebre del oro” dentro del sector, lo que le ha llevado a algunos profesionales de la industria de la ciberseguridad a calificarlo como “el nuevo estándar de seguridad”.

Figura 5: Índice del libro de "Bug Bounty: De profesión "Cazarrecompensas"

de 0xWord escrito por Pablo García.

Este libro pretende abordar los aspectos básicos de estos programas, como pueden ser su estructura, las principales herramientas, ciertas metodologías, o las vulnerabilidades más comunes, todo ello desde un punto de vista práctico analizando reportes públicos realizados por hackers de la comunidad.

Figura 6: Contactar con Pablo García autor del libro

"Bug Bounty: De profesión "cararrecompensas""

El libro lo ha escrito Pablo García - con el que puedes contactar en MyPublicInbox, que además este libro lleva incluidos 100 Tempos gratis -, que tras graduarse en administración de empresas por la Universidad Autónoma de Madrid, se especializó con un máster en auditoría de cuentas en CUNEF, y trabajó en PriceWaterhouseCoopers.  Después desarrolló su carrera financiera en Telefónica mientras dedica parte de su tiempo libre a la investigación y reporte de vulnerabilidades, formando parte del Hall de la Fame de compañías como Netflix, Xiaomi o Pinterest, entre otras, y del que habréis leído muchos artículos por este blog.

Usar tus Tempos de MyPublicInbox 0xWord para adquirir este libro

La idea es muy sencilla, hemos creado un Buzón Público de 0xWord en MyPublicInbox y tenemos disponible el módulo de transferencias de Tempos entre cuentas siempre que el destinatario sea un Perfil Público de la plataforma. Para que se puedan hacer estas transferencias, primero debe estar en tu Agenda el Perfil Público destinatario de la transferencia.

Figura 7: Perfil de 0xWord en MyPublicInbox. Opción de "Añadir a  la Agenda".
https://MyPublicInbox.com/0xWord

Para dar de alta un Perfil Público en tu agenda, solo debes iniciar sesión en MyPublicInbox, y con la sesión iniciada ir a la web del perfil. En este caso, a la URL del perfil público de 0xWord en MyPublicInbox, - https://MyPublicInbox.com/0xWord - donde te aparecerá la opción de "Añadir a la agenda". Cuando acabe este proceso, podrás ir a la opción Agenda de tu buzón de correo en MyPublicInbox y deberías tener el Perfil Público de 0xWord allí.

Figura 8: Cuando lo agregues estará en tu agenda

Una vez que lo tengas en la agenda, ya será tan fácil como irte a tu perfil - se accede haciendo clic en la imagen redonda con tu foto en la parte superior - y entrar en la Zona de Transferencias. Desde allí seleccionas el Buzón Público de 0xWord, el número de Tempos que quieres transferir, y en el concepto debes poner que es para recibir un código descuento para usar en la tienda de 0xWord.

Figura 9: Zona de Transferencias en el Perfil de MyPublicInbox

No te preocupes por el texto concreto, porque los procesamos manualmente como los pedidos de se hacen en la tienda. 

Canjear 500 Tempos por un código descuento de 5 €

La última opción es bastante sencilla. Solo debes irte a la sección de Canjear Tempos -> Vales para Tiendas, y "Comprar" por 500 Tempos y código de 5 €. Es lo mismo que enviar la transferencia pero en un paquete de 500 Tempos y de forma totalmente automatizada, así que solo con que le des a comprar recibirás el código descuento y lo podrás utilizar en la tienda de 0xWord.com

Figura 10: Canjear Tempos por Códigos para libros de 0xWord

Así que, si quieres conseguir nuestros libros de Seguridad Informática & Hacking aprovechando los Tempos de MyPublicInbox podrás hacerlo de forma muy sencilla y mucho, mucho, mucho más barato. Y así apoyas este proyecto tan bonito que es 0xWord.com.

Ser escritor de libros de 0xWord

Además, todos lo que queráis convertiros en escritores y hacer un proyecto de libro con nosotros. Podéis también enviarnos vuestra propuesta a través del buzón de 0xWord en MyPublicInbox, y si sois Perfiles Públicos de la plataforma, podéis entrar en la sección de Mi Perfil -> Servicios para ti y solicitar más información sobre el proceso de escribir un libro en 0xWord.

Figura 11: Si eres un Perfil Público de MyPublicInbox

puede solicitar info para escribir un libro en 0xWord

Nuestro equipo se pondrá en contacto contigo y evaluará tu proyecto de publicación de libro. Ya sabes que principalmente de Seguridad Informática & Hacking, y puede ser técnico, súper-técnico, o divulgación, y si es una novela... podemos estudiarlo también.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso) 

"Deadlock in the Lockers" por un bug de UX en el mundo físico

Siempre he sido un mal tester. Cuando me han dado a probar los productos, he tenido la suerte, el acierto o la desgracia, de tocar donde nadie esperaba que se hiciera o en el orden que nadie pensó que alguien lo hiciera. Ha sido un don toda mi vida. Me dan algo a probar, y no me funciona. Quizá porque soy más torpe, o porque me gusta probar qué pasaría si....Supongo que por eso acabé buscando bugs en el software, es una habilidad natural innata qué, a veces, me juega malas pasadas.

Figura 1: "Deadlock in the Lockers" por un bug de UX en el mundo físico 

Este "súper poder" me llevó el otro día, cuando tenía lugar el GP F1 en Madrid, a terminar en un Deadlock con los Lockers, por culpa de un fallo de UX en el sistema físico de la apertura y cierre de los mismos. Os lo cuento, por si algún día es vuestra primera vez, para que no caigáis en el mismo problema que forcé yo a la primera. Para no alargar la historía, os diré que tenía entradas para la F1 de Madrid y la carrera comenzaba a las 15:00. Yo aterrizaba en Madrid viniendo de México a las 13:15, y tenía el tiempo justo para ir hasta  un Hotel de Valdebebas y dejar mi equipaje en los Lockers para luego correr hacia la entrada del circuito y ver la carrera. Todo planificado.

Figura 2: Los Lockers

Cuando llegué a la recepción del hotel pregunté por los lockers, y una chica muy amable me dijo que estaban abajo, en el parking, pero que con la carrera no sabía si quedaría ninguno libre. Esto metió nerviosismo en mi plan, y baje un poco acelerado para ver si tenía uno disponible. No había utilizado nunca el sistema, y mi preocupación era si aceptarían tarjeta de crédito, que venía pelado, pero ahora tenía que encontrar alguno vacío para poder utilizarlo. Nervios++

Cuando llegué, me topé con todos los lockers cerrado, y mi nerviosismo empezó a crecer, pero de repente, mi ojo captó una puerta abierta de un locker, y me sentí aliviado. Corrí hacia ese locker, y puse mis cosas dentro. Me quedé con el número de la taquilla, lo cerré, y me fui hacia la pantalla para pagar el alquiler de ese locker y asegurarme que se quedaba cerrado.

Suena bien, ¿verdad?

Lo cierto es que cuando llegué a la pantalla del pago, me encontré con un menú con dos opciones. Una para alquilar un locker, y la otra para abrir un locker. Tiene sentido, pensé. Vamos a alquilar un locker, y cuando le di a esa opción, me esperaba un interfaz para poner el número de mi taquilla, pero lo que me encontré fue una lista de números de taquillas, entre las que no estaba el mío.... What? 

Seleccioné un número de los disponibles y pagué, viendo cómo se abría automáticamente el locker con ese número. Aquí iría una onomatopeya de cerebro pensando sobre qué ha pasado, pero lo cierto es que pensé: "Bueno, si la otra no la puedo cerrar, cambio las cosas y listo". Así que me fui a la taquilla donde había metido mis cosas para abrirla, pero... oh, oh... estaba cerrada y no se abría. Deadlock total.

¿Cómo era esto posible?

El tiempo corría en mi contra, así que me fui corriendo a la recepción subiendo los escalones en tiempo de record de vuelta del circuito, y le conté a la chica lo que me había pasado recortando los espacios entre las palabras. Ella me miró con cara de no entiendo nada y dijo... "¿Es un problema con los lockers?" 

"Sí, sí, sí, sí.." respondí, al tiempo que agitaba mi cabeza en vertical a 200 rpms. Y ella dijo que para los lockers, al responsable de los lockers, que precisamente venía por el hall del hotel. Gracias, gracias, gracias. Así que le asalté, y mejorando mi tiempo anterior, le conté otra vez toda la historia. Y me miró con cara de "... What?" 

Le expliqué que sí, que había un locker abierto, que yo pensé que primero elegías taquilla, luego la pagabas, y se cerraba, pero que no, que luego vi que el sistema es distinto, que primero pagas, eliges taquilla, ésta se abre, pones las cosas dentro y luego se cierra, pero que tus cosas estaban en una taquilla abierta, que alguien había pagado para cerrar, pero que se había ido y la había dejado abierto y... el resto ya os o he contado.

La persona no entendía nada, pero uso su clave de administrador de los Lockers (Modo God Locker) y me preguntó antes de abrir la taquilla por todas mis cosas, que yo le describí minuciosamente: "Un libro de Isaac Asimov, tres calzoncillos usados, una mochila de Cloudflare, unos dulces mexicanos, ....y cosas".  En el momento de comprobar que era mi equipaje, a pesar de saber que lo acababa de poner allí, estaba nervioso pensando... ¿Te imaginas que ahora hay otra cosa y es una broma de cámara oculta?

View this post on Instagram

A post shared by Chema Alonso (@chemaalonso)

Por suerte... (ya ves tú qué suerte) estaban mis cosas, y pude cambiarlas y cerrar la taquilla para irme a la carrera. Llegué, como podéis ver en el vídeo. Pero me pasé toda la carrera sin entender qué había pasado, así que cuando volví a recoger mis pertenencias vine con el modo Debug ON.

Al llegar, para abrir la taquilla, había dos opciones: "Abrir una vez" o "Abrir y terminar el alquiler". Pensé... "¿Qué opción de estas ha llevado al Deadlock en el que me quedé?" Pues parece a priori  que ninguna, o que podían ser las dos. En cualquiera de los dos casos el problema parecía el mismo. Si el usuario que termina el alquiler y se va, deja la taquilla abierta, no hay un mecanismo de cierre automático retardado para evitar que alguien, por error, o por no conocer el proceso como era mi caso, ponga sus cosas dentro. Si alguien pone algo dentro y se cierra, se acabó, ¿o no?

Figura 4: Mientras pensaba en eso, me perdí y acabé

a pie de pista sacándole una foto a mi colega Max.

Pues no, en este caso, la solución al misterio del problema era "Abrir una vez" sin terminar la sesión. Si hubiera elegido al opción de "Abrir y terminar el alquiler" cuando yo fui a pagar, esa taquilla aparecería como disponible, pero no estaba, así que la persona abrió la taquilla sin terminar la sesión y me dejo en un Deadlock. Es decir:

• Un usuario alquila una taquilla por 8 horas y le pone el código 2345
• El usuario vuelve a la hora para irse, pero abre la taquilla sin cerrar el alquiler.
• Deja la taquilla abierta.
• Un nuevo usuario que no conoce el sistema pone sus cosas dentro pensando que está disponible.
• Cierra la taquilla
• La taquilla sigue alquilada aún por 7 horas y no está disponible.
• El nuevo usuario se ha quedado sin sus cosas.

La solución, además de poner el cierre retardado automático - caro -, sería poner información contextual directamente en la taquilla: "Antes de poner sus cosas dentro asegúrese de haber pagado" o "No ponga cosas dentro de la taquilla si no la ha abierto con el panel de control" ... o cualquier otro mensaje para el usuario que no ha visto aún el proceso de pago.

Figura 5: Con la ayuda de Megatorpe

El bug es pequeño, pero como podéis ver, existe, y me acordé de los libros de ANAYA de Informática para Torpes, donde MegaTorpe hacía todo lo que nadie esperaba que hiciera. Sí, yo fui MegaTorpe, pero el issue existe, y alguien tendrá que pensar cómo subsanarlo, o delegar ese caso de uso "Corner Case" en el Modo God del Locker Admin.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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 Inteligencia Artificial está multiplicando los parches de seguridad ... ¿quién los va a instalar en tu PYME?

En este blog hemos visto durante los últimos meses hablar de un asunto muy relevante: El descubrimiento masivo de vulnerabilidades gracias al avance los modelos de IA. Hemos visto el impacto de Mythos en concreto y la IA en general, y de cómo los modelos superan cada vez más y mejor benchmarks como ExploitBench o ExploitGym que se usan para medir capacidades ofensivas en la explotación de vulnerabilidades, e incluso  de los ataques orquestados con enjambres de agentes IA. En resumen, Bugs, Exploits y Parches masivos.

Figura 1: La IA está multiplicando los parches de seguridad

...¿quién los va a instalar en tu PYME?

Y esto, para la gestión de la seguridad de una empresa, acabará siempre en el mismo sitio: Acelerar el cliclo de gestión de parches y actualizaciones de seguridad, qué es el verdadero significado de todo esto para una PYME que tiene dos ordenadores, tres móviles y ningún informático.

Figura 2: "Cybercrime in the Age of AI" de ThreatDown

Hace unos días leí el informe "Cybercrime in the Age of AI" de ThreatDown, y hay un dato que me parece mucho más importante que todos los titulares sobre exploits generados por IA. Es este: Firefox publicó 31 correcciones de seguridad en abril de 2025. En abril de 2026, después de aplicar uno de estos modelos de IA a su propio código, publicó 423. 

Figura 3:  Mozilla Firefox y 432 bugs parcheados tras auditarlo con Mythos

Leedlo otra vez. Trece veces más parches en el mismo mes del año siguiente. El problema no es el ataque sofisticado. Es el volumen.

El problema de verdad para las PYMES: El volumen de parches

Cuando hablamos de IA y Ciberseguridad todo el mundo piensa en el atacante con un modelo de lenguaje generando 0days a demanda. Y sí, eso está llegando: Google detectó en mayo de este año el primer exploit de día cero desarrollado por criminales con ayuda de IA.

Figura 4:"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

Pero para una pequeña empresa el peligro inmediato es mucho más aburrido y mucho más real. Los fabricantes están encontrando y corrigiendo fallos a una velocidad que no habíamos visto nunca, y cada parche que se publica es también un mapa para el atacante, que puede estudiarlo y construir el exploit contra todos los que todavía no lo han instalado. El que va al día está protegido. El que acumula retraso queda expuesto más tiempo, y contra más cosas.

Tener la herramienta no es lo mismo que tener quien la maneje

Este mundo nos ha dado como conclusión, que se han multiplicado por diez el número de actualizaciones pendientes en una empresa donde la ciberseguridad la lleva "el que más sabe de ordenadores" entre otras diez tareas, y ya me dirás cómo acaba eso. Aquí es donde mucha gente se confunde, y por eso os enlazo este artículo que hemos escrito en IronGate explicando la diferencia entre un EDR y un servicio MDR, que merece la pena leer entero.

Figura 5: Diferencia entre EDR y MDR

Resumiendo mucho: un EDR es la tecnología que detecta lo que pasa en los dispositivos y bloquea automáticamente lo que es evidente. Un servicio MDR es el equipo que revisa lo que no es evidente, que es la inmensa mayoría. 

Un EDR con gestión de vulnerabilidades te devuelve una lista de trescientos fallos detectados en tus equipos. Esa lista no es protección: es trabajo pendiente. Convertirla en equipos realmente actualizados exige priorizar, comprobar qué actualización puede romperte una integración en producción, avisar antes de tocar nada que pueda parar el negocio, y verificar después que cada fallo quedó cerrado.

Figura 6: Solicita un Diagnóstico gratuito a IronGate Cybersecurity

Y esto era ya así el año pasado. Con la IA metiendo décima, no es que se vuelva más difícil: es que deja de ser algo que se pueda hacer los viernes por la tarde si queda un hueco. Sabemos que "gastar" en seguridad nunca apetece cuando eres una PYME que va al día. Pero la pregunta que yo os haría no es cuánto cuesta el servicio, sino esta otra: cuando dentro de seis meses tu empresa acumule cuatrocientos parches pendientes ... ¿quién los va a instalar?

Saludos,

Figura 7: Contactar con Ricardo Fúster.

CEO y Fundador de IronGate CyberSecurity

Anthropic Cyber Jailbreak Bug Bounty & Severity Framework (Para Fable o "Mythos")

Anthopic ha puesto otra vez de regreso Fable, con mejores protecciones para evitar técnicas de Jailbreak que permitan que los usuarios consigan las capacidades de exploiting avanzadas que este modelo tiene en común con Mythos. Fue por culpa de uno de estos Jailbreaks que Fable fue baneado por el gobierno para evitar que "malos actores" pudieran utilizarlo para hacer el "cosas malas", y con este regreso al mercado, se han incrementando las medidas de seguridad.

Figura 1: Anthropic Cyber Jailbreak Bug Bounty &

 Severity Framework (Para Fable o "Mythos")

Para ello han abierto un Bug Bounty de Cyber Jailbreak, que está publicado en HackerONE, una de las plataformas utilizadas por los hackers & Security Researchers para reportar de forma responsable sus vulnerabilidades y ser recompensados por ellas.

Figura 2: Anthropic Cyber Jailbreak

Utilizar estas plataformas es algo que los Security Researchers utilizan habitualmente, como se explica en el libro de Bug Hunter, lugar donde las empresas tienen confianza para evitar sorpresas desagradables con investigadores. 

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

Este es un gran cambio en la importancia de las técnicas de Hacking IA, donde el Jailbreak "no era tan importante", como podemos aún ver en el Bug Bounty de ChatGPT, donde puedes reportar bugs, pero dentro de su programa "aún" no entran los relativos a Jailbreak.

Figura 4: Bug Bounty de OpenAI - No Jailbreaks

Sin embargo, las técnicas de Jailbreak son muy poderosas a la hora de valorar la seguridad de un modelo de Inteligencia Artificial, puesto que amplia las capacidades que un atacante tiene simplemente por tener acceso a un modelo vulnerable a una técnica de Jailbreak, algo que con la búsqueda avanzada de bugs y la generación de exploits complejos ha demostrado ser de primera necesidad.

Figura 5: Resultados empíricos de Exploitbench donde Mythos destaca

En los artículos de "ExploitBench: Un benchmark para medir las capacidades de Agentes IA en la explotación de bugs" y "ExploitGym: Mythos, GPT 5.5, Gemini Pro en un CTF & Benchmark de hacer exploits" se pude ver cómo las capacidades de Mythos son muy diferenciales con respecto al resto a la hora de vulnerar sistemas creando exploits.

Figura 6:"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

En la comunidad de Security Researchers, las técnicas de Jailbreak han sido muy importantes desde casi el primer día que se descubrieron estas capacidades, porque es fácil ver el riesgo real al que puede llevar que un atacante tenga de colaborador malicioso a un modelo de frontera, y por eso es un tema tan importante en el libro de Hacking IA que publicamos hace poco.

Anthropic Cyber Jailbreak

Para medir el impacto de estas técnicas de Jailbreak, el equipo de Anthropic ha creado el Cyber Jailbreak Severity Framework que define una serie de métricas en función de varias características de la técnica reportada por el programa de Bug Bounty.

Figura 7: Discoverability, o "es tuyo o es conocida"

Por supuesto, primero miden la "Discoverability" o lo que es lo mismo, quién la reporta, cómo se descubrió y cuanto de conocida es esta técnica. El segundo de los indicadores del framework es lo que llama la "Facilidad de Weaponizar", o si esta técnica se puede automatizar fácilmente y convertir en un framework, una aplicación o una API. 

Figura 8: Facilidad de Weaponización

Ejemplos de estos hay muchos, como los ejemplos recientes que os publicaba yo con los Asistentes de IA donde se puede weaponizar el consumo de Tokens, o la técnica de PXPIPE que os contaba ayer donde se Weaponiza el uso de imagénes para reducir los costes de Claude en Tokens. No es lo mismo que haya que ser un experto, o que se pueda construir un herramienta que funciona de manera consistente para explotar el Jailbreak. 

Figura 9: Amplitud de nuevas capacidades abiertas con el Jailbreak

El siguiente indicador de la técnica de Jailbreak es el que mide la cantidad de nuevas capacidades que abre el uso de esa técnica. Es una técnica que sirve sólo para un Prompt, un tipo de Prompts, o para todas las cosas que se le pidan después. Esto es muy relevante, por supuesto.

Figura 10: Tipos de capacidades conseguidas

Y por supuesto, el modelo está protegido por diferentes tipos de categorías, así que conocer qué capacidades en concreto son las que se obtienen con la nueva técnica de Jailbreak reportada, es fundamental.

Figura 11: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso,

Con este Cyber Jailbreak Severity Framework lo que Anthropic acaba de poner es una forma de medir las técnicas de Jailbreak que se están publicando, porque en muchos papers de estas las únicas validaciones de impacto son contra datasets y benchmarks de Prompts y Categorías bloqueadas, y ahora va a ser más fácil entender el impacto real de cada una de ellas.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)