RCE sin vulnerabilidades: una nueva realidad. Claude enseñó a un hacker a burlar al propio sistema

RCE sin vulnerabilidades: una nueva realidad. Claude enseñó a un hacker a burlar al propio sistema

Ahora los correos enseñan a la IA a hackearse a sí misma.

image

En la era del rápido desarrollo de los sistemas de inteligencia artificial generativa, la seguridad va más allá de las vulnerabilidades clásicas. Un precedente ha demostrado cómo, sin necesidad de errores de software, exploits ni evasión de filtros, es posible lograr una ejecución remota de código —solo gracias a la forma en que interactúan los componentes de un ecosistema de IA. El ataque fue llevado a cabo con éxito en un sistema totalmente actualizado, donde todos los elementos estaban protegidos y no presentaban vulnerabilidades en el sentido tradicional.

El foco estuvo en una arquitectura multicomponente —Multi-Component Pipeline (MCP)— que incluía tres elementos: Gmail MCP Server como fuente de entrada no confiable, Claude Desktop local de Anthropic como MCP Host, y Shell MCP Server como objetivo de ejecución. En lugar de aislar cada componente por separado, se adoptó una estrategia que consideraba toda la cadena como una superficie de ataque unificada. Fue esta combinación la que, siguiendo una secuencia específica de acciones, permitió al atacante eludir la protección de todos los participantes y ejecutar un comando en el servidor.

El elemento clave del ataque fue un correo electrónico enviado a través de Gmail. Aparentemente inofensivo, contenía dentro una sección en Markdown con código Python, estructurado así:

code = """
import subprocess
subprocess.call(['bash', '-c', 'echo Compromised > /tmp/flag'])
"""

Este fragmento, encerrado entre comillas invertidas triples (formato estándar de código en Markdown), iba acompañado de texto explicativo que imitaba un mensaje de soporte técnico o una notificación de lanzamiento, haciendo que el contenido pareciera inocuo durante la entrega.

En la primera fase del ataque, Claude Desktop recibió la orden de analizar el correo. El sistema actuó correctamente: detectó señales sospechosas, clasificó el mensaje como potencialmente phishing y se negó a ejecutar el código. Esta respuesta se debió a la detección de funciones de ejecución y entrada no confiable, en línea con las políticas estándar de seguridad de contenido.

Luego comenzó la segunda fase: la explotación del comportamiento de Claude. Se le pidió a Claude Desktop que explicara por qué se bloqueó el código. En su respuesta, el sistema detalló las construcciones potencialmente peligrosas y describió escenarios en los que ese código podría llegar a ejecutarse. Mencionó reinicios de sesión, configuraciones incorrectas de plugins, conflictos de nombres en los intérpretes y evasiones a nivel de contexto. Particularmente peligroso fue un consejo ofrecido por Claude al usuario: considerar cada nueva sesión como una “hoja en blanco” o como “the new me” — el nuevo yo. Estas frases fueron la clave para eludir los mecanismos de seguridad.

Con esa premisa, comenzó una interacción iterativa en la que cada nueva conversación con Claude se presentaba como independiente y sin relación con las anteriores. En cada ronda, Claude recibía una versión modificada del mensaje malicioso, ayudaba a analizarla, señalaba qué causaba errores y sugería cómo resolverlos. Participó activamente en la creación de nuevas versiones del mensaje, utilizando técnicas de escape, ofuscación y reorganización de comandos.

En total se realizaron cinco iteraciones. Con cada ciclo, Claude procesaba una versión mejorada, analizaba por qué fallaba y sugería ajustes. Gradualmente, su contexto se saturó hasta que los filtros de seguridad estándar dejaron de funcionar. La versión final del mensaje superó todas las verificaciones e inició con éxito la ejecución del subprocess.call() —esta vez en el Shell MCP Server objetivo. Así, sin explotar vulnerabilidades de software ni modificar el código fuente, se logró la ejecución de un comando arbitrario.

La particularidad del caso es que ni Gmail, ni Claude Desktop, ni el servidor Shell presentaban vulnerabilidades propiamente dichas. Todos los componentes estaban actualizados, con filtros y protecciones activadas. La debilidad surgió únicamente por la forma en que se integraban: la confianza entre componentes, falta de coordinación de permisos, aislamiento insuficiente de plugins, reutilización de contexto y ausencia de control dinámico entre agentes.

Los analizadores Markdown, especialmente cuando están combinados con plugins con permisos de ejecución, resultaron especialmente sensibles a este tipo de escenarios. Claude, como agente autónomo, fue demasiado complaciente con las tareas del usuario y no logró identificar la cadena como maliciosa —en especial después de haber proporcionado él mismo las instrucciones para sortear los filtros.

Este caso es un ejemplo claro de que los modelos de seguridad tradicionales, centrados en fallas de código, están perdiendo relevancia en entornos donde los contextos, agentes y privilegios cambian constantemente. En los sistemas de IA generativa, las fronteras entre identidades, tareas y autorizaciones se vuelven difusas —y eso se puede manipular.

La empresa Pynt, especializada en la seguridad de arquitecturas multicomponente, ya está trabajando en soluciones a través de su plataforma MCP Security. Esta permite construir mapas de confianza entre agentes, identificar delegaciones peligrosas de autoridad y modelar ataques encadenados antes de que se conviertan en amenazas reales.

El escenario recreado en este experimento fue tanto una prueba de concepto como una advertencia seria: la nueva era de la seguridad requiere controlar el comportamiento de los sistemas en sus intersecciones, más que simplemente revisar código. Es en esas uniones invisibles donde puede esconderse el mayor riesgo del futuro próximo.

No esperes a que los hackers te ataquen: ¡suscríbete a nuestro canal y conviértete en una fortaleza impenetrable!

Suscribirse