HTTP Terminator a généré, évalué et militarisé des milliers d’hypothèses de désynchronisation HTTP et a fait apparaître une nouvelle technique que ni l’IA ni son opérateur humain n’auraient trouvé seuls.
Découvrez HTTP Terminator, un nouveau système d’IA qui a identifié des centaines de sites Web vulnérables à la contrebande de requêtes HTTP, les a piratés en direct à grande échelle et a même identifié une « véritable nouvelle classe » de vulnérabilité, surnommée « confusion de l’analyseur partagé ».
Mais il n’y est pas parvenu seul ; il a été guidé par un humain tout le temps, ce qui est peut-être la découverte la plus intéressante de toutes.
Un chercheur de la société de sécurité PortSwigger a utilisé ses propres processus pour concevoir et construire l’IA, HTTP Terminator, a posé des questions précises et de grande valeur, a exclu les réponses faibles, a appliqué une logique de détection d’anomalies, a utilisé un code déterministe pour restreindre le comportement des agents et a appliqué les résultats aux recherches ultérieures en « cascade ».
« Cela inverse le récit accepté en montrant qu’un expert peut être un amplificateur massif pour un système de recherche sur l’IA », a expliqué James Kettle, directeur de recherche de PortSwigger, dans un livre blanc. « Un humain impliqué dans la boucle peut toujours ajouter une valeur significative, au lieu de simplement construire la boucle, puis de prendre du recul. »
Perturbation du flux de requêtes HTTP
Les attaques de désynchronisation HTTP, également connues sous le nom de contrebande de requêtes HTTP, interfèrent avec la façon dont les sites Web traitent les requêtes HTTP de divers utilisateurs. Dans cette architecture, les utilisateurs envoient des requêtes à un serveur frontal, qui les transmet ensuite aux serveurs back-end.
Le problème réside dans l’isolation intrinsèquement « faible » des requêtes, a souligné Kettle : le serveur frontal envoie généralement plusieurs requêtes à la fois via la même connexion réseau back-end pour améliorer les performances et l’efficacité.
« Les requêtes HTTP sont envoyées les unes après les autres, et le serveur de réception doit déterminer où se termine une requête et où commence la suivante », a-t-il expliqué. Mais les systèmes front-end et back-end doivent « se mettre d’accord » sur l’endroit où se termine chaque requête, sinon les attaquants peuvent envoyer des messages ambigus qui sont interprétés comme deux requêtes par le back-end.
Grâce à l’empoisonnement des requêtes de réponse (RQP), ces attaquants peuvent injecter de fausses informations dans des requêtes ultérieures ou manipuler les flux de données de manière à ce que les systèmes perdent la trace de l’origine des réponses. Ils peuvent alors intercepter les réponses destinées aux autres utilisateurs, qui peuvent parfois inclure des informations sensibles, des identifiants ou des clés API.
Bien que la contrebande de requêtes soit généralement associée aux requêtes HTTP/1, les sites Web prenant en charge HTTP/2 peuvent également être vulnérables, en fonction de leur architecture back-end, a noté Kettle.
« Les vulnérabilités liées au trafic de requêtes sont souvent de nature critique, permettant à un attaquant de contourner les contrôles de sécurité, d’obtenir un accès non autorisé à des données sensibles et de compromettre directement d’autres utilisateurs d’applications », a-t-il déclaré.
Méthodologie de HTTP Terminator
Kettle a construit HTTP Terminator autour de ses propres méthodologies de recherche.
La phase initiale est l’idéation : elle génère de manière autonome des attaques RQP hypothétiques et testables, telles que, par exemple, des déclencheurs de désynchronisation, des modèles ou des techniques d’armement.
L’étape suivante est l’évaluation : les hypothèses sont testées à grande échelle pour identifier celles qui ont réellement fonctionné. HTTP Terminator utilisait des sites Web en direct qui permettaient des tests de sécurité via des programmes de bug bounty et de divulgation de vulnérabilités (VDP). Une couche de détection d’anomalies intégrée a signalé les réponses inhabituelles.
Vient ensuite une phase de militarisation, qui détermine si les découvertes ont réellement un impact réel.
Dans certains cas, ils l’ont fait : HTTP Terminator a initialement généré 30 000 vecteurs d’attaque uniques qu’il a testés en continu, identifiant rapidement 700 cibles vulnérables, notamment des institutions financières et des infrastructures gouvernementales. Le système a même volé une clé API active à l’une de ces banques, et d’autres violations ont été attribuées à des failles dans des produits d’entreprise populaires tels qu’Apache Traffic Server, Citrix NetScaler et BeyondTrust.
Enfin, il y a une étape que Kettle appelle « cascade ». Chaque découverte peut être un indice sur une cible ou un chemin de détection négligé. « Lorsque vous découvrez quelque chose, si vous explorez en remontant l’arbre, vous découvrirez peut-être d’autres branches non découvertes », a-t-il expliqué.
Par exemple : comment pourriez-vous détecter un comportement similaire ailleurs ? Et ce comportement pourrait-il permettre d’autres types d’attaques ? Essentiellement, chaque découverte devient « la graine de la suivante ».
« Cela ne semble peut-être pas grand-chose, mais cela crée une boucle de rétroaction positive qui peut se transformer en une cascade de découvertes vous emmenant au-delà des découvertes prévisibles, vers l’inconnu », a déclaré Kettle.
En fin de compte, « j’ai réalisé que l’autonomie par rapport à l’humain n’était pas le bon cadre », a-t-il expliqué. « Il est préférable de définir la conception du système comme étant l’IA, le code et l’humain. »
Un nouvel outil pour les équipes de sécurité
HTTP Terminator a pu inventer et prouver plusieurs nouveaux déclencheurs de désynchronisation, un nouveau modèle de désynchronisation et une technique d’armement de désynchronisation.
Cependant, l’étude a notamment identifié une nouvelle technique de « confusion de l’analyseur partagé » qui permet aux attaquants d’analyser les requêtes et les réponses et ainsi d’augmenter leur surface d’attaque.
« Cela, en soi, est absolument énorme », a déclaré Kettle. Mais, souligne-t-il, « cette découverte n’était pas totalement autonome : HTTP Terminator l’a proposée et je l’ai validée. Aucun de nous ne l’aurait découvert seul. »
Kettle propose un HTTP Terminator open source avec son plan de recherche afin que d’autres équipes de sécurité puissent « transformer leur propre méthodologie et leurs instincts en une arme de recherche autonome ».
Le chercheur a conseillé d’aborder les tâches en quatre étapes : fixer un objectif, créer une stratégie d’évaluation, établir des sources d’inspiration et explorer des voies en cascade pour de nouvelles découvertes.
« L’évaluation est la première étape concrète tant pour la conception que pour la mise en œuvre », a-t-il déclaré, « car tout problème qui en résulterait ferait dérailler l’ensemble du projet ».
Il est également important d’identifier et de résoudre « de manière agressive » les problèmes de qualité des données, car ceux-ci seront difficiles à corriger par la suite. De plus, posez des questions de grande valeur sans être trop large ; examiner les résultats des tests initiaux et les utiliser pour exclure les hypothèses de faible valeur ; et rappelez-vous que « chaque phrase supplémentaire risque d’être contaminée par le contexte », a déclaré Kettle.
Lorsqu’un système est entièrement piloté par l’IA et dépend également du code construit par l’IA, il est presque impossible de s’améliorer au fil du temps, a-t-il déclaré. Il est préférable de commencer rapidement avec une approche basée sur l’IA, puis de transférer la responsabilité vers un code déterministe pour plus de rapidité et de précision.
« La recherche entièrement autonome est réelle », a reconnu Kettle. Cependant, « les humains sont un énorme amplificateur de puissance pour les systèmes de recherche en IA ».
