Google search engine
Inicio Noticias y Actualidad Seguridad y Legal Basta con pedirle a Claude Code que resuma una web para que...

Basta con pedirle a Claude Code que resuma una web para que ejecute código del atacante

0
18
Claude Code ejecutara código de un atacante pidiéndole simplemente que resumiera una web

De todo lo que se ha publicado esta semana sobre la demostración de Johann Rehberger, la frase que me ha quitado el sueño no es suya: es de Anthropic. Cuando el investigador reportó que podía hacer que Claude Code ejecutara código de un atacante pidiéndole simplemente que resumiera una web, la compañía cerró el caso como informativo y respondió que Auto Mode es una función de conveniencia respaldada por un clasificador de mejor esfuerzo, no una garantía de seguridad. Y tienen razón. Ese es exactamente el problema.

Llevo semanas escribiendo sobre Auto Mode en clave de productividad, porque desde el 14 de agosto es el modo por defecto en Pro, Max y Team y porque, sinceramente, se trabaja mejor así. Hoy toca escribir la otra mitad, y mi postura es incómoda de sostener para alguien que factura automatizando cosas: hemos estado tratando como un límite de seguridad algo que su propio fabricante describe como una comodidad. La diferencia entre esas dos palabras es la que separa un pipeline con riesgo asumido de un pipeline con riesgo ignorado, y yo he estado del lado equivocado más tiempo del que me gustaría admitir.

Al agente no lo engañaron: lo convencieron

Los hechos, los justos. Rehberger monta una web maliciosa disfrazada de archivo de logs y pide a Claude Code, con Opus 5 en Auto Mode, que la resuma. Nada más. El servidor responde a WebFetch con un error 415, así que la herramienta legítima falla y el agente, razonando como razonaría cualquiera de nosotros, tira de curl desde Bash. La web redirige a un ZIP que contiene documentos codificados, un binario decodificador de señuelo y un fichero llamado struct.py. Y aquí llega el momento que convierte esto en algo más que otra prueba de concepto: Claude se niega a ejecutar el binario desconocido por precaución y decide escribir su propio decodificador en Python, ejecutándolo desde la carpeta que acaba de extraer.

Ese decodificador hace import base64. Python busca módulos primero en el directorio actual. base64 importa internamente struct, y en el directorio actual hay un struct.py que no es el de la biblioteca estándar. El código ofuscado se ejecuta durante el propio import, lanza un intérprete aislado para no entrar en recursión, descarga la segunda fase y termina abriendo la calculadora del sistema como prueba visible de que hay ejecución nativa y un canal de mando abierto. Las tasas medidas: 60% en dos variantes y 80% en la que además escribe ficheros fuera del espacio de trabajo.

La frase del investigador que resume por qué esto no se parece a lo que llamábamos inyección de prompts hace un año es esta: el ataque no le dice al modelo qué hacer, solo hace que el camino malicioso sea el que merece la pena seguir. No hay una orden oculta en texto blanco sobre fondo blanco. Hay una secuencia de obstáculos razonables ante los cuales un agente competente toma, uno tras otro, la decisión más sensata. Y el resultado de encadenar seis decisiones sensatas es un compromiso completo de la máquina.

El clasificador bloqueó el binario sospechoso. El modelo, obediente, escribió uno equivalente desde cero. Esa es toda la historia.

Me detengo ahí porque es el núcleo de mi argumento. Un clasificador de comandos peligrosos protege contra un atacante que necesita que el agente ejecute su comando. No protege contra un atacante que solo necesita que el agente llegue a la conclusión de que hace falta un comando así. La defensa filtra cadenas de texto; la capacidad que tiene enfrente sabe reescribir la cadena. Cuanto mejor sea el modelo programando, más fácil le resulta reconstruir por su cuenta justo lo que el filtro acaba de rechazar. Defensa y capacidad no crecen en la misma dirección, y en cada versión la brecha se ensancha un poco.

Un 0,00% que solo mide los ataques que ya conocías

La parte que me parece más criticable no es técnica, es de comunicación. Anthropic publicó en su día una cifra redonda para Auto Mode: 0,00% de éxito en inyección de prompts, medido sobre 72 escenarios con diez ejecuciones cada uno. Es un dato real y está bien medido. También es, después de esta semana, un dato que describe con precisión milimétrica los 72 ataques que a alguien se le ocurrieron antes de que existiera este.

Un 0,00% no se lee como «no encontramos estos ataques concretos». Se lee como «resuelto». Yo lo leí así, y sospecho que buena parte de la gente que activó Auto Mode sin pensarlo dos veces también. Ahí es donde una cifra honesta se convierte en un problema: cuando el número que publicas es tan limpio que sustituye al criterio de quien lo lee. Prefiero mil veces una métrica sucia con su intervalo de confianza que un cero que invita a dejar de pensar.

Y conste que no estoy pidiendo que Anthropic resuelva la inyección de prompts. No sé si tiene solución dentro del modelo, y hay gente mucho más lista que yo convencida de que no la tiene. Lo que sí les pido es coherencia entre el marketing y la letra pequeña. Si internamente la posición es que la frontera real de seguridad son el aislamiento del sistema operativo y el control de salida de red —que es literalmente lo que respondieron al reporte—, esa frase debería estar en el mismo sitio donde estaba el 0,00%, y no en la respuesta a un investigador que tuvo que dedicar semanas a demostrarlo.

Dónde esto deja de ser una curiosidad y llega a tu factura

Si usas Claude Code para picar código en un repo tuyo, en tu portátil, mirando la pantalla, este ataque es interesante pero manejable: verías la secuencia rara y pararías. El problema aparece cuando el agente deja de tener a alguien delante. Y ese es justo el escenario que muchos hemos construido este año: un flujo de n8n que dispara Claude Code para investigar algo, resumir una fuente, revisar un plugin o auditar un sitio, y que después escribe en el WordPress de un cliente. Ahí hay dos ingredientes que este ataque necesita y que nosotros servimos en bandeja: una URL que no controlamos y un agente que no está siendo observado.

Añade el detalle de la variante con 80% de éxito, la que escribe ficheros fuera del espacio de trabajo. En mi portátil, «fuera del espacio de trabajo» significa las claves SSH con las que despliego, los ficheros de credenciales de los hostings de mis clientes y el .env de tres proyectos. No es un escenario hipotético de laboratorio: es el contenido real del directorio personal de cualquier freelance que trabaje con más de un cliente. Que el agente corriera con mi usuario me parecía cómodo hasta esta semana.

⚠️ Revisa esto hoy, no el lunes: busca en tus workflows de n8n cualquier paso que pase una URL externa —de un RSS, de un formulario, de un scraping, de un correo— a un agente que después tenga permiso de escritura. Ese es el patrón exacto que se explota aquí. Si tienes uno solo, ya tienes deberes.

Lo que cambio en mis pipelines a partir de hoy

No voy a cerrar con «ten cuidado con la IA». Cuatro cosas concretas, todas baratas, todas disponibles ya.

  • Separar el agente que lee del agente que escribe. El que toca URL externas va con --restricted, sin herramientas de ejecución y sin WebFetch, y devuelve texto. El que escribe en producción solo recibe ese texto, nunca la URL ni el fichero. Es la mitad del trabajo y arregla el 90% del riesgo.
  • Contenedor, siempre, para cualquier agente desatendido. Con su propio usuario, sin el directorio personal montado, sin claves SSH ni credenciales de nube a la vista. Si el agente se compromete, que se comprometa una carpeta vacía.
  • Lista blanca de dominios. En los agentes gestionados existe allowed_domains para web_search y web_fetch. Con lo que se ha visto esta semana, restringir a qué sitios puede llegar tu agente deja de ser paranoia y pasa a ser configuración por defecto.
  • Control de salida de red. La segunda fase del ataque se descarga. Si el contenedor no puede hablar con internet salvo con los dominios que tú digas, la cadena se rompe en el paso cinco por mucho que los cuatro anteriores hayan funcionado.

Y una quinta que no es técnica: dejar de contarle al cliente que el agente «revisa» su web. Revisar implica criterio y responsabilidad. Lo que hace es procesar contenido que no controlamos con una herramienta que su fabricante define como conveniente. Esa frase, dicha a tiempo, vale más que cualquier cláusula.

Me quedo con la imagen del agente negándose a ejecutar el binario sospechoso y, acto seguido, escribiendo uno equivalente porque le pareció lo profesional. No hubo malicia, ni fallo, ni alucinación. Hubo competencia. El mismo rasgo por el que le pagamos —que sea capaz de resolver el obstáculo que se le pone delante— es el que lo convierte en un vector. No creo que eso se arregle con un clasificador mejor, y no creo que Anthropic piense lo contrario; lo que pasa es que la responsabilidad de ponerle paredes al agente ha aterrizado en nuestro tejado sin que nadie nos lo dijera con la misma claridad con la que nos vendieron la comodidad.

Así que la pregunta que te dejo no es si confías en Claude Code. Yo confío, y lo sigo usando todos los días. Es esta otra: si mañana tu agente hiciera exactamente lo que hizo el de Rehberger, ¿te enterarías? Si la respuesta es que no, el problema ya no está en el modelo ni en el modo por defecto. Está en tu arquitectura, y esa sí la firmas tú.

DEJA UNA RESPUESTA

Por favor ingrese su comentario!
Por favor ingrese su nombre aquí