Quisieron hacerlo bien y acabó en un RCE: ¿qué falla en el nuevo y ambicioso proyecto de IBM?

IBM lanzó en beta cerrada su propio agente de IA para desarrollo, diseñado para ayudar a escribir código y al mismo tiempo cumplir los requisitos de seguridad corporativos. En la descripción de la empresa suena casi como el compañero ideal: entiende las intenciones del desarrollador, conoce el repositorio y cumple las normas. Pero la verificación reveló un detalle desagradable: si un atacante suministra al agente un texto correctamente diseñado, este puede acabar ejecutando un script malicioso.

Se trata de la herramienta Bob, que IBM anunció en octubre y está probando en dos formatos: como línea de comandos y como IDE, es decir, un modo de agente separado para la terminal y una integración dentro del entorno de desarrollo. Los investigadores de PromptArmor estudiaron Bob antes del lanzamiento público y afirmaron que la interfaz de línea de comandos (CLI) puede ser vulnerada mediante inyección de indicaciones de forma que, al final, en la máquina de la víctima se ejecute una carga arbitraria. Y la IDE, según ellos, es vulnerable a escenarios típicos de fugas de datos en aplicaciones de IA, cuando la información puede exfiltrarse a través de peculiaridades del renderizado y de solicitudes de red.

El problema no está solo en un producto de IBM. Los sistemas de IA tipo agente a los que se les da acceso a herramientas y se les permite actuar paso a paso hace tiempo se consideran riesgosos. Investigadores como Johann Reberger han mostrado en varias ocasiones, por ejemplo en un vídeo, cómo esos agentes pueden romperse mediante la sustitución de instrucciones, jailbreaks o vulnerabilidades clásicas que derivan en ejecución de código. En la práctica muchos proveedores lo reconocen de forma indirecta, proponiendo una medida simple: que una persona confirme manualmente las acciones peligrosas.

IBM, según la documentación, también cuenta con ello. En los materiales de la empresa hay una advertencia: si se permite al agente ejecutar automáticamente comandos de una lista de riesgo, esto puede conducir a operaciones maliciosas. Como medida se propone usar una lista de permitidos y evitar patrones con comodines, esperando que en casos dudosos el agente pregunte al usuario si puede ejecutar el comando.

Pero PromptArmor afirma que la protección resultó ser demasiado permeable. Los investigadores proporcionaron a Bob un repositorio donde en el README.md se ocultaba un script malicioso. El archivo fingía ser una instrucción para entrenamiento de phishing y contenía una secuencia de comandos que el agente debía ejecutar. Los primeros comandos parecían inofensivos y se reducían a echo. Bob, de hecho, pedía permiso: ejecutar una vez, permitir siempre o proponer editar. Y a partir de ahí entraba en juego la costumbre. El tercer comando, en apariencia otro echo, ya intentaba descargar y ejecutar un script malicioso. Si antes el usuario había puesto echo en modo "permitir siempre", el paso siguiente podía ejecutarse sin confirmación adicional, y la carga maliciosa se instalaba automáticamente.

Formalmente, incluso en ese modo Bob debería tener salvaguardas adicionales. Por ejemplo, prohíbe la sustitución de comandos como "$(command)". Sin embargo, según los investigadores, el agente no comprueba la sustitución de procesos, y esto se encontró en el código JavaScript minificado del proyecto. Además, según se afirma, el sistema no siempre detecta que a un comando permitido se le han encadenado otras subcomandas mediante redirección con >, convirtiendo la apariencia en una llamada segura y la esencia real en un conjunto de acciones peligrosas.

En consecuencia, como explicó el director ejecutivo de PromptArmor, Shankar Krishnan, la confirmación humana valida de hecho solo el comando incluido en la lista de permitidos, aunque en la misma línea se ejecuten otras operaciones no autorizadas. Los investigadores compararon esto con el comportamiento de soluciones competidoras y afirmaron que, por ejemplo, Claude Code en un caso similar requeriría un consentimiento separado para todo el conjunto compuesto de comandos, incluso si el primer comando de la cadena está en la lista de permiso automático.

Si un atacante consigue que el agente entregue y ejecute un script shell arbitrario, los escenarios son evidentes: desde extorsiones y robo de credenciales hasta la toma completa del dispositivo. PromptArmor subraya que el riesgo se manifiesta en situaciones de trabajo habituales, cuando el desarrollador interactúa con contenido no confiable.

El agente puede leer páginas web, y entonces la inyección puede llegar desde documentación ajena o debates en foros. Puede leer la salida de comandos del terminal, y la sugerencia maliciosa puede aparecer en datos de una herramienta externa. En su ejemplo, los investigadores eligieron la opción de un repositorio de código abierto desconocido como la más realista y autosuficiente. Los especialistas aseguran que la compañía ya fue notificada de los hallazgos.