Una falla crítica en Dialogflow CX de Google podría permitir que un atacante con privilegios de edición para un agente habilitado para bloques de código comprometa a otros agentes habilitados para bloques de código en el mismo proyecto de Google Cloud.
Desde allí, el bot puede leer conversaciones en vivo, robar datos compartidos por los usuarios y hacer que envíe mensajes escritos por el atacante que incluyen solicitudes de reingreso de contraseña.
La empresa de seguridad Varonis lo descubrió y lo llamó Agente Rogue. Esta falla solo afectó a las organizaciones que crearon agentes utilizando los manuales y bloques de código personalizados de Dialogflow, que permiten a los desarrolladores agregar su propio Python. Y no fue un ataque remoto y no autenticado.
Para hacer esto, necesitaba el permiso Dialogflow.playbooks.update en uno de esos agentes. Esto limita a los atacantes realistas a personas internas maliciosas o cuentas de desarrolladores comprometidas, en lugar de extraños en Internet. Pero a partir de ese punto de apoyo, su alcance se expandió para incluir a todos los agentes dentro del proyecto.
Google solucionó el problema y tanto Varonis como Google dicen que no hay evidencia de que la falla se haya utilizado en un ataque real.
Un archivo grabable ejecuta bloques de código para todos los agentes
Los bloques de código de Dialogflow permiten a los desarrolladores agregar Python personalizado al flujo de conversación de un chatbot para verificar la entrada, controlar el comportamiento y llamar a herramientas definidas. Ese código se ejecuta en un entorno Cloud Run administrado por Google y todos los agentes que utilizan el bloque de código en el mismo proyecto de Google Cloud comparten una única instancia del mismo.
Google gestiona ese entorno y los clientes no tienen visibilidad ni control sobre él. Varonis también descubrió que no existía un aislamiento real entre los agentes dentro del entorno.
Cuando el agente ejecuta el bloque de código, el código del desarrollador se agrega al código de configuración interno y se pasa a la función exec() de Python. Su código de configuración define variables y funciones a las que puede acceder el bloque. Las variables incluyen el estado de todo el historial de conversaciones y detalles de la sesión, como el ID de la sesión. La función incluye respuesta() que hace que el bot responda con la cadena especificada.
Varonis descubrió que el archivo code_execution_env.py que realiza este ajuste se encuentra en un entorno compartido al que tiene acceso de escritura.
Este archivo se podía escribir, por lo que podía reemplazarlo con un solo bloque de código. Este bloque descarga un code_execution_env.py modificado desde un servidor controlado por un atacante y sobrescribe el code_execution_env.py original en el contenedor en ejecución.
A partir de entonces, cada vez que se ejecuta el bloque de código en todos los agentes que comparten ese entorno, se ejecuta la versión del atacante. Tiene el mismo alcance que el código normal y tiene el mismo acceso al historial, estado y respuesta().
Esto les permite leer cada conversación, enviarla silenciosamente al servidor del atacante y hacer que el bot publique mensajes que el atacante ha creado. Un ejemplo es el phishing. El bot le pide al usuario que vuelva a confirmar su inicio de sesión y el atacante recopila lo que escribe el usuario.
Para cubrir sus huellas, el atacante restaura el bloque de código original en la consola de Dialogflow. Esto sólo cambia lo que se muestra en la consola. El archivo sobrescrito ya se estaba ejecutando dentro del contenedor y seguirá ejecutándose en él.
Sandbox se filtró de dos formas adicionales
Varonis informó dos problemas relacionados, ninguno de los cuales requirió sobrescritura de archivos. En primer lugar, el entorno Code Block permitía el acceso saliente a Internet sin restricciones. Los investigadores utilizaron la biblioteca urllib incorporada para poder enviar datos directamente a un servidor externo y recibir comandos.
Según Varonis, esto evita los controles de servicio VPC, el perímetro de Google Cloud que evita que los datos abandonen los servicios protegidos. Este entorno está fuera del perímetro y tiene acceso a Internet abierto, proporcionando un canal tanto para el robo de datos como para el control remoto.
En segundo lugar, y menos grave, este entorno expuso el Servicio de metadatos de instancia (IMDS), un punto final interno que normalmente distribuye credenciales en la nube. La consulta devolvió un token para una cuenta de servicio administrada por Google.
Esta cuenta tenía pocos privilegios, por lo que el riesgo inmediato era limitado. El verdadero punto es que el entorno limitado de ejecución de código no debería poder acceder a IMDS en absoluto.
Casi nada llegó al registro.
La anulación se produjo dentro del entorno de Google y no fue visible para el cliente, y Cloud Logging no registró los cambios en el archivo ni el código inyectado.
Eso hace que sea difícil, si no imposible, resolverlo desde el lado del cliente. La acción de configuración todavía deja un rastro y las comprobaciones siguientes dependen de ello.
Varonis reveló esta falla en noviembre de 2025 a través del Programa de recompensa por vulnerabilidades de Google. Google envió la primera solución en abril de 2026 y la resolvió por completo en junio de 2026, aproximadamente 7 meses desde el informe hasta la resolución. No se asignó ningún CVE.
Cosas que se deben comprobar al utilizar bloques de código
Si estaba ejecutando un agente de Dialogflow CX usando un manual de bloques de código antes de la corrección y desea asegurarse de que no esté siendo atacado, comience con Access.
El permiso Dialogflow.playbooks.update es para todo el punto de entrada, por lo tanto, audite qué función y cuenta lo posee.
después:
Consulte el registro de auditoría DATA_WRITE de la API de Dialogflow para ver si hay actualizaciones inesperadas del manual y correlacionelas con usuarios, direcciones IP o tiempos de acceso inusuales. Ejecute consultas de Cloud Logging para solicitudes de usuarios fallidas. Los mensajes de error pueden revelar excepciones generadas por bloques de código malicioso. En la consola de Dialogflow, abra el libro de jugadas de cada agente y verifique que todos los bloques de código sean los que usted aprueba.
Otro tipo de falla de la IA
Muchas fallas de seguridad recientes de la IA funcionan engañando al modelo.
El propio Reprompt y SearchLeak de Varonis convirtieron un solo clic en Copilot de Microsoft en robo de datos. ForcedLeak de Noma Security ocultó instrucciones para extraer datos de CRM en un formulario web de Salesforce.
Los investigadores de Microsoft han demostrado que la inyección rápida se convierte en ejecución de código en un marco de kernel semántico. Rogue Agent no tocó el modelo en absoluto. Esto aprovechó la funcionalidad normal del desarrollador y un tiempo de ejecución oculto compartido al que se puede acceder con privilegios normales de edición única.
En tal configuración, lo que parecen ser permisos de edición de contenido son en realidad permisos de ejecución de código. Cualquiera que pueda agregar bloques de código puede ejecutar Python arbitrario dentro de un entorno compartido que los clientes no pueden inspeccionar.
Trate los permisos de edición del agente como controles de tiempo de ejecución. Incluso si un proveedor dice que no es necesario arreglar nada, los clientes todavía no tienen forma de mirar dentro de ese tiempo de ejecución por sí mismos.
Source link
