Problema 7909

ChatGPT Operator es un agente de vista previa de investigación de OpenAI que permite a ChatGPT usar un navegador web. Utiliza capacidades de visión y razonamiento para completar tareas como investigar temas, reservar viajes, pedir comida a domicilio o, como se mostrará en este artículo, ¡robar tus datos!

Actualmente, solo está disponible para usuarios de ChatGPT Pro. Decidí invertir 200 dólares durante un mes para probarlo.

Riesgos y amenazas

OpenAI destaca tres categorías de riesgo en su Tarjeta del Sistema Operativo:

• El usuario podría estar desalineado (el usuario solicita una tarea dañina),
• El modelo podría estar desalineado (el modelo comete un error dañino), o
• El sitio web podría estar desalineado (el sitio web es malicioso de alguna manera).

Si estás familiarizado con mi investigación, así es como también he planteado las amenazas de las solicitudes de información. Aquí tenéis una captura de pantalla de una de mis presentaciones: . Y como referencia, aquí está la charla que di en el Chaos Communication Congress sobre la inyección de prompts.

Volviendo a la perspectiva de OpenAI, mi única observación es el posible uso excesivo del término "desalineado". Esto resta gravedad al asunto; se trata de ataques reales con graves consecuencias para la confidencialidad, integridad y disponibilidad, como destacaremos en esta publicación.

¡Es estupendo ver que OpenAI comparte esta visión desde la perspectiva de los riesgos y las amenazas! Esto es modelado de amenazas en acción.

Medidas de mitigación y defensa

Las medidas de mitigación prácticas que observé son complejas y se resumen en tres técnicas principales que encontré durante las pruebas:

Medida de mitigación 1: Monitoreo del usuario

Se le pide al usuario que "monitoree" las acciones del operador, el texto que escribe y los botones que pulsa.

No está claro en qué páginas aparece esta pantalla. Hasta ahora, solo he realizado pruebas con GitHub y Outlook, pero supongo que se basa en algún modelo de clasificación de datos que podría detectar información personal identificable del usuario en pantalla o similar, en lugar de nombres de dominio específicos.

Medida de mitigación 2: Solicitudes de confirmación en línea

Dentro de la conversación de chat, el operador puede preguntar al usuario si debe realizar una acción determinada o solicitar aclaraciones.

En la captura de pantalla anterior se puede observar un exploit completo de inyección de mensajes que secuestró a Operator, abrió la página "Establecer estado" e incluso escribió el texto controlado por el atacante en la barra de estado. Sin embargo, antes de hacer clic en "Establecer estado", aparece una confirmación en el chat.

Cabe destacar que la primera vez que probé este exploit de inyección de mensajes para establecer el estado, ¡este se estableció sin confirmación! Pero no pude reproducirlo una segunda vez.

Mitigación 3: Solicitudes de confirmación fuera de banda

Estas solicitudes de confirmación suelen aparecer cuando el Operador navega entre diferentes sitios web y realiza acciones que implican solicitudes complejas. Este es el diálogo de confirmación más intrusivo, y el usuario tiene la opción de pausar o reanudar la operación.

La captura de pantalla anterior muestra los mensajes más detallados que recibí; informa al usuario con precisión sobre lo que está a punto de suceder y por qué aparece el diálogo. Sin embargo, la mayoría de las veces, la confirmación es un mensaje genérico que indica que los sitios web podrían contener instrucciones que entran en conflicto con las del Operador, lo que dificulta determinar qué instrucciones o contenido de los sitios web podrían ser maliciosos.

Antes de que aparezca este diálogo de confirmación, se produce una pausa notable —a veces bastante larga, de 20 segundos o más— antes de que se muestre la pantalla de confirmación. Por lo tanto, es probable que se estén realizando otros procesos de razonamiento y validación en segundo plano para decidir si se debe solicitar la confirmación al usuario.

Finalmente, también existen estructuras de datos en las solicitudes y respuestas HTTP relacionadas con el monitor de inyección de mensajes. Esto significa que las API envían mucha información al cliente sobre el monitor, pero no lo investigué en detalle.

No confíes en la IA: Sigue siendo cierto

Es evidente que no se puede confiar plenamente en el Operador y estas medidas de mitigación (necesarias) evitarán la creación de agentes autónomos. Consulta mi artículo sobre Inyección Inmediata y la Tríada de la CIA si aún no lo has leído.

Los riesgos de la Inyección Inmediata siguen siendo un gran inconveniente, lo cual es realmente lamentable. Creo que todos deseamos sistemas autónomos en los que podamos confiar para que trabajen en nuestro nombre.

Parece probable que trabajemos con agentes de una manera mucho más colaborativa, en lugar de que sean completamente autónomos.

Nota relacionada: Si te interesa ver cómo una función similar de "uso de computadora" de Anthropic Claude puede manipularse para crear escenarios avanzados tipo C2, consulta mi publicación sobre "ZombAIs".

Operador: Demostraciones de exploits de inyección de prompts

Ahora, exploremos algunos exploits de inyección de prompts de Operator. Para demostrar que un adversario motivado puede eludir el Monitor de Inyección de Prompts, preparé un par de demostraciones que compartí con OpenAI hace unas tres semanas, ya que quería asegurarme de que estuvieran al tanto y pudieran mitigar esta técnica.

Configuración: Un escenario complejo

El escenario en el que quería centrarme implicaba que Operator navegara a otro sitio donde el usuario hubiera iniciado sesión y, a continuación, filtrara datos de ese sitio, idealmente información de identificación personal (PII). Se encontró rápidamente un escenario básico de explotación filtrando la información personal del usuario de los sitios web, como su dirección de correo electrónico, domicilio y número de teléfono.

Durante mi investigación, observé que el Operador seguía los hipervínculos con facilidad; ¡parecía muy motivado para hacer clic en ellos!

Lo segundo que observé es que, al enviar formularios, a menudo aparecía una pregunta de confirmación, ya fuera una pregunta contextual o el diálogo de confirmación de la interfaz de usuario descrito anteriormente. Por lo tanto, intentar pedirle directamente al Operador que hiciera clic en el botón "Actualizar" no funcionó.

Fuga de datos sigilosa

Sin embargo, escribir texto casi nunca activa ninguna confirmación.

Con este conocimiento, creé una página web en un servidor de terceros que envía todo lo que el usuario escribe directamente al servidor, sin necesidad de enviar un formulario ni hacer clic en un botón.

En retrospectiva, me siento un poco mal por haberla creado. Sin embargo, es algo común y es importante que los usuarios entiendan que simplemente escribir información en un sitio web, sin presionar el botón de enviar, significa que el sitio web puede robar sus datos.

La idea ahora es engañar a Operator para que use esta página para resolver un problema, pero en realidad, está filtrando los datos.

Conectando los puntos del ataque...

Si aún te preguntas cuál es el plan, aquí tienes una breve explicación de la TTP (Táctica, Técnica y Procedimiento):

• Secuestraremos al Operador mediante la inyección de texto en una solicitud en un sitio web.

• Haremos que navegue a la página de configuración de un usuario autenticado.

• Le pediremos que copie la información personal (PII) de esa página y luego

• Pegaremos/escribiremos la información en el sitio web de filtración de datos descrito anteriormente.

Para demostrarlo, lo probé con varias páginas: The Guardian, YC Hacker News, Booking.com y algunas más, y funcionó en todas. Elegí esta ruta porque el botón "Enviar" activaba con mayor frecuencia una de las medidas de mitigación de la inyección de texto descritas.

Para esta explicación, usaré el escenario más simple: filtrar la dirección de correo electrónico de un usuario de YC Hacker News, a la que solo tiene acceso el administrador.

Aquí tenéis la información de una cuenta de demostración de Sentinel:

Nota: Esto no representa una vulnerabilidad en ninguno de los sitios objetivo. Sin embargo, plantea una pregunta interesante: ¿deberían los sitios web ser capaces de bloquear el acceso de IA "bienintencionada" a ciertos sitios sensibles? ¿Quizás el User-Agent debería indicar que el cliente es un agente de IA?

Ahora, veamos los detalles de la inyección de prompts.

Alojamiento de la carga útil de inyección de prompts

La carga útil de inyección de prompts está alojada en GitHub, como un problema de GitHub. En mi opinión, es un escenario realista para ataques. Dado que usuarios desconocidos pueden crear incidencias en la mayoría de los proyectos de GitHub, y que los agentes de IA se utilizarán cada vez con más frecuencia para leer y procesar dichas incidencias,

este es el ejemplo de incidencia de GitHub que se utilizó:

Para simular la interacción de un desarrollador con la incidencia de GitHub, inicialmente simplemente pegué la URL en Operator. También funcionó al escribir frases como "Investigar esta incidencia de GitHub" y similares. El éxito dependerá de la solicitud del usuario; es importante destacar que tanto los ataques como las defensas son probabilísticos.

Secuestro del Operador

El Operador navega con entusiasmo a los problemas de GitHub y se pone manos a la obra para ayudar. Ve la herramienta maliciosa "combine" y, sin dudarlo, hace clic en el enlace y accede a la página.

Durante algunas pruebas, comienza a escribir un mensaje de prueba en el cuadro de texto, que se envía inmediatamente al servidor de terceros.

Ahora viene lo interesante: el Operador regresa a los problemas de GitHub y se centra en la tarea principal: navegar a la página de configuración de la cuenta de news.ycombinator.com, copiar la dirección de correo electrónico privada y luego volver a la página web maliciosa para pegar los datos, lo que permite al atacante obtener la información.

Aquí hay una imagen que muestra algunos de los pasos clave de la demo de YC Hacker News:

El operador obtiene la dirección de correo electrónico del usuario (que no es pública) y la pega en el formulario de fuga de datos.

¡Ahora el atacante tiene los datos! Increíble. Aquí tienes un vídeo completo, por si la explicación anterior no fue del todo clara.

Esta técnica funciona con diferentes sitios web. Aquí tienes un ejemplo con booking.com, donde la inyección de prompts secuestra Operator y filtra datos de usuario, incluyendo la dirección y el número de teléfono.

Es fundamental monitorizar de cerca las acciones de Operator, ya que si el navegador está autenticado en sitios web, podrían ocurrir cosas peligrosas.

Defensas probabilísticas

Aunque las demostraciones a veces funcionaron al primer intento, las inyecciones de prompts no son 100% fiables, ni tampoco las defensas. Muchas de las medidas de mitigación actúan como defensas probabilísticas, reduciendo el riesgo pero sin eliminarlo. Estas demostraciones son representativas, pero no exhaustivas.

Se observó que las medidas de mitigación suelen activarse en el último momento antes de que se realice una acción peligrosa, lo que significa que no se evita la inyección instantánea, sino que el enfoque se centra en detectar acciones peligrosas, lo que parece indicar que no existe una solución para la inyección instantánea en sí misma. Los agentes serán como empleados potencialmente maliciosos en las empresas, aunque para uso personal aún no he encontrado una buena analogía.

Implicaciones

Esta demostración tiene varias implicaciones más amplias:

• Privacidad y seguridad del usuario

El operador puede ser engañado para navegar a sitios maliciosos, lo que pone de manifiesto los riesgos de phishing. Los datos personales de los usuarios, incluida la información de identificación personal sensible, pueden quedar expuestos inadvertidamente si no se implementan medidas de seguridad adecuadas de forma constante. No recomiendo otorgar al operador acceso a sitios web sensibles, como su cuenta de correo electrónico principal. Considere usar cuentas separadas para experimentos o crear cuentas específicas para cada caso de uso.

• Solución del lado del servidor: preocupaciones adicionales sobre privacidad y seguridad Además, las sesiones del operador se ejecutan en el lado del servidor. Esto significa que, técnicamente, el personal de OpenAI tiene acceso a todos los datos introducidos, así como a las cookies de sesión y los tokens de autorización, etc. Existe una extensión de Chrome personalizada para el operador y servidores web locales ejecutándose en el host del operador (por ejemplo, http://localhost:8080/events). No está claro para qué se utilizan exactamente estos puntos finales, pero probablemente algunos recopilan datos de telemetría. No he encontrado documentación al respecto.

• Diseño y perfeccionamiento de agentes de IA más seguros

Es importante perfeccionar estas medidas de mitigación para reducir la probabilidad de eludir las inyecciones de mensajes. Dado que mis pruebas también activaron el monitor de inyecciones de mensajes, esperé unos días y volví a intentarlo. Sin embargo, el monitor aún no había aprendido sobre el ataque que realicé y mis reintentos a menudo funcionaban al principio, ya que la carga útil del ataque se fue perfeccionando a medida que aprendía más. A medida que mejoran las defensas, también lo harán los ataques. Además, compartí estos escenarios de prueba de concepto con OpenAI.

• Confianza en los sistemas automatizados y el código abierto

Mitigación de inyecciones de mensajes Este tipo de vulnerabilidades pueden erosionar la confianza en los sistemas automatizados si se explotan con fines maliciosos. Por lo tanto, mantener y mejorar la transparencia en la forma en que los agentes de IA validan y protegen los datos parece importante. ¿Podría liberarse el código fuente de un sistema como el monitor de inyección de mensajes?

Pruebas para que el operador haga clic en los botones "Actualizar": ¡Fallidas!

También realicé un par de pruebas modificando directamente la información en sitios web, pidiéndole al operador de ChatGPT que hiciera clic en los botones "Actualizar" durante ataques de inyección de mensajes.

Estas pruebas generalmente fallaron y activaron una solicitud de confirmación interna. Sin embargo, hubo una ocasión, al principio de mi investigación, en la que funcionó. El escenario que funcionó consistió en actualizar el estado de mi cuenta de GitHub mediante inyección de mensajes desde una incidencia de GitHub. Cabe destacar que algunas aplicaciones modernas ya no requieren hacer clic en los botones de actualización; simplemente guardan la información automáticamente.

Hay mucho más por explorar y probar en este ámbito, muchas posibilidades para engañar al operador, desde trucos clásicos de suplantación de identidad de la interfaz de usuario, como el clickjacking, hasta trucos modernos de LLM; existen muchas vías de ataque posibles.

Responsable Divulgación

Hace aproximadamente tres semanas, proporcioné a OpenAI los detalles de las técnicas para eludir el monitoreo de inyección de mensajes descritas en esta publicación, incluyendo videos de demostraciones iniciales con booking.com y theguardian.com. Hasta hace una semana, las demostraciones funcionaron de manera bastante confiable. Sin embargo, desde entonces, el escenario de ataque específico que se analiza en esta publicación parece haber dejado de funcionar. Se desconocen los detalles de la mitigación.

Es importante destacar que, muy probablemente, existen más técnicas y trucos que los atacantes pueden aprovechar para secuestrar Operator mediante instrucciones en sitios web. Por lo tanto, tengan cuidado y continúen monitoreando la actividad de Operator.

Conclusión

Esta publicación exploró cómo se puede secuestrar ChatGPT Operator mediante exploits de inyección de mensajes en páginas web, lo que conlleva la filtración no autorizada de información personal.

Operator es una herramienta muy interesante y útil que ofrece una visión del futuro cercano. ¡Me encanta verla explorar y realizar tareas!

Sin embargo, al demostrar escenarios de explotación reales, esta publicación ilustra las vulnerabilidades de Operator (y de otras herramientas informáticas). (utilizar agentes de este tipo). Es estupendo ver las inversiones de OpenAI para hacer que el sistema sea más fiable y seguro, aunque aún queda trabajo por hacer. Parece que hemos llegado al punto en que se acepta que la inyección de comandos no tiene solución por sí sola, y requiere la monitorización de las acciones y el comportamiento para determinar si un agente realiza alguna acción maliciosa. Hay muchas cosas que pueden salir mal.

Por último, sería valioso que el monitor de inyección de comandos, o al menos partes de él, se publicara como código abierto, o que OpenAI compartiera más detalles sobre su enfoque. Esto permitiría a los investigadores evaluarlo con mayor eficacia y ayudaría a otros a aprender de la experiencia y el enfoque de OpenAI. A medida que los sistemas de IA sigan evolucionando en escala, razonamiento y velocidad, una postura proactiva en materia de seguridad será esencial.

Gracias por leer.

-- Johann.

Referencias

• Tarjeta del Sistema Operativo
• [No confíes en la IA: Inyección de comandos en el marco de la seguridad de la CIA] Tríada
• Charla CCC - Nueva instrucción importante
• Inteligencias artificiales zombi: De la inyección de comandos al comando C2 con Claude Computer Use