Les intelligences artificielles font beaucoup parler d’elles ces derniers temps : elle répondent aux questions, corrigent et écrivent du code, rédigent des textes techniques complexes, imitent les grands maîtres… Mais elles possèdent des failles qui peuvent permettre à des attaquants de récupérer les informations personnelles de leurs utilisateurs !
Le 24 mars dernier, ChatGPT a été mis hors ligne plusieurs heures afin de corriger une vulnérabilité signalée par Nagli, chasseur de bugs.
À cause d’une librairie Open Source utilisée par ChatGPT, il était possible d’accéder à l’historique des chats avec l’IA ainsi qu’à des informations très sensibles d’autres utilisateurs comme leur access token. Avec ces informations, un attaquant pouvait même prendre entièrement le contrôle d’un compte visé.
💡 Système de mise en cache
Commençons par un peu de contexte sur ce type d’attaque : lorsqu’on fait une requête à un site web, la requête est transportée sur le réseau jusqu’au serveur web et passe souvent par un CDN (Content Delivery Network). L’objectif du CDN est de stocker des copies du contenu de sites web à proximité des utilisateurs afin de réduire le temps de chargement des pages. C’est ce qu’on appelle la mise en cache. Seul le contenu statique est concerné, comme par exemple les images, les fichiers CSS, et les documents PDF.
Ces données enregistrées en cache ne doivent pas contenir d’informations sensibles : contrairement aux serveurs des applications, les serveurs de cache n’ont pas de protection pour authentifier les utilisateurs et empêcher l’accès à des données non autorisées.
Il est cependant possible de tromper le CDN pour lui faire mettre en cache des données qui ne devraient pas l’être, et c’est le cas de la faille qui nous intéresse ici : on nomme ce type d’attaque Web Cache Deception.
🕵️ Explication de l'attaque
Lors d’une connexion à une session personnelle de ChatGPT, l’application renvoie au navigateur les informations de l'utilisateur connecté au format JSON, ce qui constitue une cible intéressante pour des attaquants de ChatGPT. La réponse de cette route https[://]chat.openai[.]com/api/auth/session contient les informations suivantes :
- Id utilisateur
- Nom
- Image de profil
- Groupes
- Access token
C’est ce dernier élément qui permet de prendre possession du compte de la victime.
Voyons maintenant comment forcer le CDN à mettre en cache cette session ! La route /auth/session n’est pas mise en cache puisqu’elle retourne des données dynamiques et pas des fichiers statiques. Or, Cloudflare, sur lequel repose ce système de mise en cache, se base uniquement sur l’extension des fichiers (si le comportement n’est pas modifié par un header Cache-Control). Cela signifie que le contenu de ce qui est stocké n’est pas vérifié, et qu’il peut ne pas correspondre à ce que l’extension indique, sans que cela ne soit détecté.
L’objectif est donc de faire croire au CDN que la session renvoyée est un fichier de style en ajoutant .css à la route. Un premier appel que l’on peut tenter consiste à simplement ajouter l’extension .css à l’appel initial, soit https[://]chat[.]openai[.]com/api/auth/session.css. Cette méthode échoue et la route renvoie une erreur 400. Il faut essayer autre chose.
Autre tentative : compléter le chemin de la route, en faisant comme si session était un dossier, et en allant chercher un fichier statique (par exemple craftedPath.css) à l’intérieur de ce dossier. La route devient donc : https[://]chat[.]openai[.]com/api/auth/session/craftedPath.css. En lançant ce deuxième appel sur ChatGPT, l’attaquant constate que la réponse à cet endpoint contient bien les données renvoyées normalement par /session.
Il reste à vérifier qu’il est possible de récupérer le fichier mis en cache, ce qui en l’occurrence est bien le cas, et on dispose à présent d’un lien en .css pour récupérer le contenu de l’endpoint /api/auth/session.
Il suffit ensuite de distribuer le lien et d’attendre qu’il soit visité.
🛡 Comment se protéger ? Sans laisser de trou dans la cotte de mailles !
Avertie de la faille, l’entreprise OpenAI, qui développe ChatGPT, a réagi promptement en fermant les serveurs et en mettant en production la correction moins de deux heures après avoir été notifiée.
Pour corriger cette faille, il y avait deux protections possibles côté serveur présentées par le chasseur de bugs qui avait découvert la faille :
- Imposer manuellement au serveur de cache de ne pas mettre en cache la route en se basant sur une regex - on vérifie que le texte de la requête a une forme convenable
- Ne pas retourner de réponse sauf si la demande est faite directement à la route désirée
OpenAI a choisi la première solution, et… a fait une erreur d'implémentation ! Il y avait en effet plusieurs moyens de contourner la contrainte de la regex, comme cela a été détecté par d’autres chasseurs de bugs. Pour régler définitivement le problème, ils ont finalement utilisé la fonctionnalité Cache Deception Armor de Cloudflare afin de ne pas dépendre d’une regex créée manuellement. Cette fonctionnalité permet de vérifier que l’extension indiquée dans l’URL correspond bien au type de fichier, donc à son Content-Type : lorsque ce n’est pas le cas, Cloudflare ne met pas en cache le fichier.
Côté utilisateur, afin d’éviter d’être victime de ce type d’attaque, on peut suivre les recommandations suivantes :
- Privilégier la navigation directe plutôt que de passer par un lien partagé via les réseaux sociaux ou un email
- Vérifier l’url en vérifiant au minimum :
- Que le lien semble bien provenir du site originel - le domaine, notamment, est le même que d’habitude
- L’absence d’extension au milieu de l’url - un url contenant /dossier/fichier.php/…/fichier2.css est par exemple très suspect
🏹 Pour aller plus loin
- Feed Twitter du Bug Bounty Hunter Nagli qui a découvert la faille
- Article d’OpenAI qui décrit l’attaque
- Article sur le type d’attaque Web Cache Deception
- Notre Newsletter qui porte sur le Cache Poisoning
Nous avons pour ambition de sécuriser le web, et pour atteindre cet objectif, nous avons besoin de vous ! Si vous avez des questions, des suggestions ou le moindre doute, n'hésitez pas à contacter notre équipe sécurité, par mail security@theodo.fr.
