Problème 7909

ChatGPT Operator est un agent de prévisualisation de recherche d'OpenAI qui permet à ChatGPT d'utiliser un navigateur web. Il exploite ses capacités de vision et de raisonnement pour effectuer des tâches telles que la recherche de sujets, la réservation de voyages, la commande de courses, ou, comme le démontrera cet article, le vol de vos données !

Actuellement, il est uniquement disponible pour les utilisateurs de ChatGPT Pro. J'ai décidé d'investir 200 $ pour un mois afin de le tester.

Risques et menaces

---

OpenAI met en évidence trois catégories de risques dans sa Fiche système des opérateurs :

• L'utilisateur peut être mal aligné (l'utilisateur demande une tâche malveillante),

• Le modèle peut être mal aligné (le modèle commet une erreur préjudiciable), ou

• Le site web peut être mal aligné (le site web est malveillant d'une manière ou d'une autre).

Si vous connaissez mes recherches, vous savez que c'est ainsi que j'envisage également les menaces liées aux incitations. Voici une capture d'écran d'une de mes présentations :  Et pour information, ici se trouve ma présentation au Chaos Communication Congress sur l'injection de prompts.

Pour revenir à l'approche d'OpenAI, mon seul commentaire concerne l'utilisation potentiellement excessive du terme « désaligné ». Cela a tendance à minimiser la gravité du problème, alors qu'il peut s'agir de véritables attaques ayant de graves conséquences sur la confidentialité, l'intégrité et la disponibilité, comme nous le verrons dans cet article.

C'est formidable de voir qu'OpenAI partage cette vision des risques et des menaces ! Voilà un exemple concret de modélisation des menaces.

Mesures d'atténuation et de défense

Les mesures d'atténuation pratiques que j'ai observées sont à plusieurs niveaux et se résument à trois techniques principales rencontrées lors de mes tests :

Mesure d'atténuation 1 : Surveillance de l'utilisateur

L'utilisateur est invité à « surveiller » les actions de l'opérateur : le texte saisi et les boutons sur lesquels il clique.

On ignore sur quelles pages cet écran apparaît. Pour l'instant, mes tests se sont principalement concentrés sur GitHub et Outlook, mais je suppose qu'il repose sur un modèle de classification des données capable de détecter les informations personnelles de l'utilisateur à l'écran, plutôt que sur des noms de domaine spécifiques.

Mesure d'atténuation 2 : Demandes de confirmation intégrées

Au cours de la conversation, l'opérateur peut demander à l'utilisateur si une action doit être effectuée ou lui demander des précisions.

La capture d'écran ci-dessus illustre une exploitation complète de la vulnérabilité par injection de message. L'opérateur a été détourné, la page « Définir le statut » a été ouverte et le texte contrôlé par l'attaquant a même été saisi dans la barre de statut. Cependant, avant de cliquer sur « Définir le statut », une confirmation s'affiche dans le chat.

Il est important de noter que lors de mon tout premier essai de cette exploitation par injection de message avec modification du statut, celui-ci a été validé sans confirmation ! Je n'ai malheureusement pas réussi à reproduire ce comportement.

Mesure d'atténuation 3 : Demandes de confirmation hors bande

Ces demandes de confirmation surviennent généralement lorsque l'opérateur navigue entre différentes pages du site web et effectue des actions impliquant des requêtes complexes. Il s'agit de la boîte de dialogue de confirmation la plus intrusive. L'utilisateur peut alors mettre l'opération en pause ou la reprendre.

La capture d'écran ci-dessus présente les messages les plus détaillés que j'ai reçus. Elle informe précisément l'utilisateur de ce qui va se passer et de la raison d'être de cette boîte de dialogue. Cependant, la plupart du temps, la confirmation est un message assez générique indiquant que les sites web peuvent contenir des instructions incompatibles avec celles d'Operator, ce qui ne permet pas d'identifier clairement les instructions ou le contenu potentiellement malveillants.

Avant l'affichage de cette boîte de dialogue de confirmation, une pause notable se produit – parfois assez longue, de l'ordre de 20 secondes ou plus – avant l'affichage de l'écran de confirmation. Il est donc probable que d'autres processus de raisonnement et de validation soient effectués en arrière-plan pour déterminer s'il convient de demander une confirmation à l'utilisateur.

Enfin, des structures de données relatives au moniteur d'injection d'invite sont également présentes dans les requêtes et réponses HTTP. Cela signifie que les API envoient de nombreuses informations au client concernant le moniteur, mais je n'ai pas approfondi cette question.

Ne faites confiance à aucune IA - Un principe toujours d'actualité

Il est évident qu'Operator ne peut être totalement digne de confiance et ces mesures d'atténuation (qui sont nécessaires) empêcheront la création d'agents autonomes. Consultez mon article sur l'injection de prompts et la triade CIA si vous ne l'avez pas encore lu.

Les risques liés à l'injection de prompts demeurent un obstacle majeur, ce qui est vraiment dommage. Nous souhaiterions tous des systèmes autonomes fiables capables d'effectuer des tâches pour notre compte.

Il semble probable que nous collaborerons davantage avec les agents, plutôt que de les laisser être totalement autonomes.

Note connexe : Si vous souhaitez découvrir comment une fonctionnalité similaire d'« utilisation d'ordinateur » d'Anthropic Claude peut être exploitée dans des scénarios de C2 avancés, consultez mon article sur les « IA zombies ».

Démonstrations d'exploitation de la faille d'injection d'invite d'Operator

---

Explorons maintenant quelques failles d'injection d'invite d'Operator. Afin de démontrer qu'un adversaire motivé peut contourner le système de surveillance des injections d'invite, j'ai créé deux démonstrations que j'ai partagées avec OpenAI il y a environ trois semaines. Je souhaitais ainsi les alerter et leur permettre de contrer cette technique.

Configuration - Un scénario complexe

Le scénario que j'ai choisi d'explorer consiste à faire naviguer Operator vers un autre site où l'utilisateur est connecté, puis à extraire des données de ce site, idéalement des informations personnelles. Un scénario de démonstration d'exploitation basique a rapidement été découvert en divulguant les informations de profil personnel de l'utilisateur depuis des sites web : adresse e-mail, adresse postale et numéro de téléphone.

Lors de mes recherches, j'ai constaté qu'Operator suit facilement les hyperliens ; il semble particulièrement enclin à cliquer dessus !

Deuxièmement, j'ai observé que lorsqu'il soumet des formulaires, une question de confirmation apparaît souvent, soit sous forme de question contextuelle, soit via la boîte de dialogue de confirmation de l'interface utilisateur décrite précédemment. Par conséquent, demander directement à Operator de cliquer sur le bouton « Mettre à jour » s'est avéré infructueux.

Fuite de données furtive

Cependant, la simple saisie de texte ne déclenche quasiment jamais de confirmation.

Fort de cette observation, j'ai créé une page web sur un serveur tiers qui envoie directement au serveur tout ce que l'utilisateur saisit, sans qu'il soit nécessaire de soumettre un formulaire ou de cliquer sur un bouton.

Avec le recul, je trouve un peu malhonnête d'avoir créé cet outil. Cependant, il est courant et important que les utilisateurs comprennent que le simple fait de saisir des informations sur un site web, sans cliquer sur « Envoyer », permet déjà au site de récupérer ces données.

L'idée est de tromper Operator pour qu'il utilise cette page afin de résoudre un problème, mais en réalité, cela provoque une fuite de données.

Relier les points de l'attaque...

Si vous vous demandez encore quel est le plan, voici une brève explication de la tactique, de la technique et des procédures (TTP) :

• Nous allons détourner l'opérateur via une injection de texte dans une invite de commande sur un site web.

• Nous l'amènerons à accéder à une page de paramètres utilisateur authentifiée.

• Nous lui demanderons de copier des informations personnelles (PII) depuis cette page, puis :

• Nous collerons/saisirons ces informations sur le site web de fuite de données furtif décrit précédemment.

Pour démontrer cette technique, je l'ai testée sur plusieurs sites web : The Guardian, YC Hacker News, Booking.com et quelques autres. Elle a fonctionné sur tous. J'ai choisi cette méthode car un bouton « Envoyer » déclenchait plus fréquemment l'une des mesures d'atténuation de l'injection d'invite de commande décrites.

Pour cette explication, je prendrai le scénario le plus simple : la fuite de l'adresse e-mail d'un utilisateur de YC Hacker News, accessible uniquement à l'administrateur.

Voici les informations d'un compte sentinelle de démonstration :

Remarque : Il ne s'agit pas d'une vulnérabilité sur les sites cibles. Cependant, cela soulève une question intéressante : les sites web devraient-ils pouvoir empêcher des IA « bien intentionnées » d'accéder à certains sites sensibles ? L'en-tête User-Agent devrait-il indiquer que le client est un agent d'IA ?

Examinons maintenant les détails de l'injection de requête.

Hébergement de la charge utile d'injection de requête

La charge utile d'injection de requête est hébergée sur GitHub, sous forme de ticket. C'est un scénario d'attaque réaliste, à mon avis. Étant donné que des inconnus peuvent créer des tickets sur la plupart des projets GitHub, et que les agents IA seront de plus en plus utilisés pour lire et traiter ces tickets, voici le ticket GitHub utilisé :

Pour simuler l'interaction d'un développeur avec le ticket GitHub, j'ai d'abord simplement collé l'URL dans Operator. Cela a également fonctionné avec des phrases comme « Examiner ce ticket GitHub ». Le succès dépend de la réponse de l'utilisateur ; il est donc important de souligner que les attaques comme les défenses sont probabilistes.

Détournement de compte

L'opérateur se rend rapidement sur les tickets GitHub et s'active pour apporter son aide. Il repère l'outil malveillant « combine » et, sans hésiter, clique sur le lien qui le redirige vers la page.

Lors de quelques tests, il saisit un message de test dans le champ texte, lequel est immédiatement envoyé au serveur tiers.

Voici maintenant la partie intéressante : l'opérateur retourne sur les tickets GitHub et se concentre sur sa tâche principale : accéder à la page des paramètres du compte news.ycombinator.com, copier l'adresse e-mail privée, puis retourner sur la page web malveillante pour coller les données, permettant ainsi à l'attaquant de récupérer les informations.

Voici une image illustrant certaines étapes clés de la démo YC Hacker News :

L'opérateur récupère l'adresse e-mail de l'utilisateur (qui n'est pas publique) et la colle dans le formulaire de fuite de données.

L'attaquant a maintenant les données ! Incroyable ! Voici une vidéo complète, au cas où l'explication ci-dessus n'aurait pas été suffisamment claire.

Cette technique fonctionne avec différents sites web. Voici un exemple avec booking.com, où l'injection de requête détourne Operator et divulgue des données utilisateur, notamment l'adresse et le numéro de téléphone.

Il est crucial de surveiller de près les actions d'Operator, car si le navigateur est authentifié sur les sites web, des problèmes graves peuvent survenir.

Défenses probabilistes

Bien que les démonstrations aient parfois fonctionné du premier coup, les injections de requête ne sont pas fiables à 100 %, et les défenses ne le sont pas non plus. De nombreuses mesures d'atténuation agissent comme des défenses probabilistes, réduisant le risque sans toutefois l'éliminer. Ces démonstrations sont représentatives, mais non exhaustives.

Il a été observé que les mesures d'atténuation se déclenchent généralement au dernier moment, juste avant une action dangereuse. Autrement dit, l'injection de code malveillant n'est pas empêchée, mais l'accent est mis sur la détection des actions dangereuses, ce qui semble indiquer qu'il n'existe aucune solution à l'injection de code malveillant elle-même. Les agents seront comparables à des employés potentiellement malveillants au sein des entreprises, bien que je n'aie pas encore trouvé d'analogie pertinente pour un usage personnel.

Implications

---

Cette démonstration a plusieurs implications plus larges :

• Confidentialité et sécurité des utilisateurs

L'opérateur peut être amené à naviguer vers des sites malveillants, ce qui met en évidence les risques d'hameçonnage. Les données personnelles des utilisateurs, y compris les informations personnelles sensibles, peuvent être exposées par inadvertance si les mesures de protection adéquates ne sont pas appliquées de manière systématique. Je déconseille d'autoriser l'opérateur à accéder à des sites web sensibles, comme votre messagerie principale. Envisagez d'utiliser des comptes distincts pour les tests, ou de créer des comptes spécifiques à chaque cas d'utilisation.

• Solution côté serveur : préoccupations supplémentaires en matière de confidentialité et de sécurité De plus, les sessions de l’opérateur s’exécutent côté serveur. Cela signifie que, techniquement, le personnel d'OpenAI a accès à toutes les données saisies, ainsi qu'aux cookies de session, aux jetons d'autorisation, etc. Une extension Chrome personnalisée pour l'opérateur et des serveurs web locaux sont exécutés sur l'hôte de l'opérateur (par exemple, http://localhost:8080/events). L'utilité exacte de ces points de terminaison est floue, mais certains collectent probablement des données de télémétrie. Je n'ai trouvé aucune documentation à ce sujet.

• Conception et amélioration d'agents d'IA plus sûrs

Il est important d'améliorer ces mesures d'atténuation afin de réduire la probabilité de contournement des injections d'invites. Mes tests ayant également déclenché le système de surveillance des injections d'invites, j'ai attendu quelques jours avant de réessayer. Cependant, le système n'avait pas encore détecté l'attaque que j'avais menée et mes nouvelles tentatives ont souvent fonctionné du premier coup, car la charge utile de l'attaque était affinée de mon côté au fur et à mesure de mon apprentissage. À mesure que les défenses s'améliorent, les attaques évoluent également. J'ai également partagé ces scénarios de démonstration de faisabilité avec OpenAI.

• Confiance dans les systèmes automatisés et les logiciels libres

Contournements des mesures d'atténuation des injections d'invites comme ceux-ci L'exploitation malveillante de certaines techniques peut éroder la confiance dans les systèmes automatisés. Il est donc important de maintenir et d'améliorer la transparence quant à la manière dont les agents d'IA valident et protègent les données. Un outil comme le moniteur d'injection de prompts pourrait-il être open source ?

Tests visant à faire cliquer l'opérateur sur les boutons « Mettre à jour » - Échec !

J'ai également effectué quelques tests en modifiant directement des informations sur des sites web, en demandant à l'opérateur ChatGPT de cliquer sur les boutons « Mettre à jour » lors d'attaques par injection de prompts.

Ces tests ont généralement échoué et déclenché une demande de confirmation interne. Cependant, au début de mes recherches, cela a fonctionné une fois. Le scénario qui a fonctionné consistait à mettre à jour le statut de mon compte GitHub via une injection de prompts à partir d'une issue GitHub. Il est également important de souligner que certaines applications modernes ne nécessitent plus de cliquer sur les boutons de mise à jour ; elles enregistrent automatiquement les informations.

Il reste beaucoup à explorer et à tester dans ce domaine, et de nombreuses possibilités de tromper l'opérateur, des techniques classiques d'usurpation d'interface utilisateur, comme le clickjacking, aux techniques modernes de LLM. Les vecteurs d'attaque potentiels sont nombreux.

Responsabilité Divulgation

Il y a environ trois semaines, j'ai fourni à OpenAI les détails des contournements du système de surveillance par injection de prompts décrits dans cet article, y compris des vidéos des premières démonstrations d'exploitation avec booking.com et theguardian.com. Jusqu'à il y a une semaine environ, les démonstrations fonctionnaient de manière fiable. Cependant, le scénario d'attaque spécifique présenté dans cet article ne semble plus fonctionner. Les détails de la solution de contournement restent inconnus.

Il est important de souligner qu'il existe très probablement d'autres contournements et techniques que les attaquants peuvent exploiter pour détourner l'opérateur via des instructions sur des sites web. Soyez donc vigilants et surveillez l'activité de l'opérateur.

Conclusion

Cet article a exploré comment l'opérateur ChatGPT peut être détourné par le biais d'exploitations d'injection de prompts sur des pages web, entraînant une fuite de données personnelles non autorisée.

L'opérateur est un outil très intéressant et utile qui offre un aperçu d'un futur proche. J'aime le regarder explorer et accomplir des tâches !

Cependant, en présentant des scénarios d'exploitation concrets, cet article met en évidence des vulnérabilités. de l'opérateur (et d'autres agents informatiques). Il est encourageant de constater les investissements d'OpenAI pour rendre le système plus fiable et sécurisé, même s'il reste du travail à accomplir. Il semble admis que l'injection de prompts est insoluble en soi et qu'il est nécessaire de surveiller les actions et les comportements pour déterminer si un agent agit de manière malveillante. Les risques d'erreur sont nombreux.

Enfin, il serait précieux que le système de surveillance des injections de prompts, ou au moins certaines de ses parties, soit open source, ou qu'OpenAI partage davantage de détails sur son approche. Cela permettrait aux chercheurs de l'évaluer plus efficacement et d'aider d'autres à tirer profit de l'expertise et de l'approche d'OpenAI. À mesure que les systèmes d'IA évoluent en termes d'échelle, de raisonnement et de vitesse, une approche proactive de la sécurité sera essentielle.

Merci de votre lecture.

-- Johann

Références

• Fiche système de l'opérateur

• [Trust No AI: Prompt Injection Along the Triade de sécurité de la CIA

• Conférence CCC - Nouvelle instruction importante

• IA zombies : de l’injection d’invites au C2 avec Claude Computer Use