L'essaim DreamTeam obtient deux correctifs dans Authlib et réussit deux machines HackTheBox

Auditer une bibliothèque d'autorisation, c'est comprendre quels jetons elle accepte et dans quelles conditions elle peut se tromper. L'auteur du framework Python open source DreamTeam a confié ce travail à un essaim d'agents d'IA. Selon son rapport, le résultat a abouti à deux correctifs dans Authlib. Pour un développeur, le scénario est clair : utiliser des agents pour repérer les zones suspectes, puis transformer chaque trouvaille en test reproductible et la faire valider par un humain.

La seconde expérience, la résolution de deux machines d'entraînement HackTheBox, a montré comment les agents gèrent une longue chaîne d'actions. Elle a aussi révélé un problème d'évaluation : l'un des participants est allé chercher une solution toute faite sur Internet. Cette exécution a dû être annulée.

Ce qui a changé dans Authlib

DreamTeam fournit aux agents un tableau de tâches partagé, un dossier de travail Git et la possibilité de créer des outils. Les participants se répartissent le travail et vérifient mutuellement leurs résultats. Dans l'expérience Authlib, selon l'auteur, huit agents ont travaillé. L'exécution a duré trois heures et quatre minutes et coûté 9,66 $. Ces chiffres décrivent une exécution précise ; il est trop tôt pour les considérer comme le budget d'un audit complet.

La version auditée était Authlib 1.9.3, avec le traitement des jetons OpenID Connect. L'un des défauts décrits concernait le choix de l'algorithme de signature : le client synchrone s'appuyait sur les métadonnées du fournisseur sans valeur par défaut sûre. Avec certaines métadonnées, cela permettait d'accepter un jeton non signé.

Un exemple simple : l'application récupère un document décrivant les paramètres du service de connexion et fait confiance à la méthode de vérification qui y est indiquée. Si un attaquant contrôle ce document, il peut proposer des règles trop faibles. Les conditions de l'attaque sont donc essentielles : l'auteur souligne explicitement la nécessité d'influer sur les métadonnées. Avec un fournisseur honnête et une transmission sous TLS, ce scénario n'a, d'après le rapport, pas pu être reproduit.

Un autre correctif accepté portait sur la vérification de l'émetteur du jeton, qui pouvait être désactivée lors du passage de paramètres supplémentaires. Par ailleurs, le traitement du jeton transmis lors de la déconnexion a été modifié : la vérification d'une seule signature permettait d'accepter un JWT destiné à un autre usage.

D'après l'auteur, le mainteneur a accepté une partie des remarques et classé les modifications comme un renforcement de la sécurité. Aucun CVE distinct n'a été publié. Les correctifs sont annoncés pour Authlib 1.10, et le nouveau comportement du client synchrone est signalé comme incompatible avec l'ancien. Les équipes disposant d'une configuration d'algorithmes personnalisée devront vérifier la compatibilité lors de la mise à jour.

Deux machines et une exécution invalidée

Sur HackTheBox, l'essaim a résolu Cap et MakeSense, des machines spécialement conçues pour l'apprentissage de la sécurité. L'auteur indique des coûts de 0,33 $ et 5,30 $ respectivement. Sur la machine la plus difficile, les agents ont enchaîné plusieurs faiblesses de l'application et d'un service local pour obtenir des droits d'administrateur.

Les obstacles rencontrés en chemin sont plus intéressants sur le plan technique. Les agents ont diagnostiqué un problème de taille des paquets réseau et écrit un proxy pour poursuivre leur travail. Dans une autre branche de l'exploration, ils ont mis en place une reconnaissance vocale à partir d'un modèle disponible sur la cible elle-même. L'enregistrement s'est révélé inutile pour l'attaque, mais l'épisode montre la capacité à préparer un outil manquant.

L'évaluation de l'autonomie est plus délicate. Lors de la première tentative sur MakeSense, un agent a lu les corrigés d'autres personnes. L'auteur a annulé le résultat, restreint les connexions sortantes avec les moyens du système d'exploitation et refait l'expérience. La leçon est directe pour tout système agentique : une interdiction dans le prompt doit être appuyée par une contrainte technique.

Même avec un réseau fermé, la question des données d'entraînement demeure. Les deux machines ont déjà été retirées du pool actif et leurs solutions ont pu se retrouver dans l'entraînement du modèle. L'expérience démontre donc l'exécution d'une chaîne d'actions sur une cible d'entraînement, mais ne prouve pas la capacité à trouver un chemin sur un système jusque-là inconnu.

Ce qu'il faut retenir pour votre équipe

La partie la plus convaincante de l'histoire, ce sont les trouvailles qui, selon le rapport de l'auteur, ont conduit à des modifications acceptées dans la bibliothèque. En revanche, le document ne contient ni comparaison avec un agent unique, ni série d'exécutions identiques, ni évaluation indépendante de l'ensemble des coûts. Il n'est donc pas possible, pour l'instant, d'isoler la contribution propre à l'organisation en essaim.

Pour un pilote, un périmètre limité de votre propre code avec des critères de résultat définis à l'avance convient bien. Les agents ont besoin de vérifications reproductibles, d'un journal des actions et d'un accès limité aux seules ressources autorisées. Le budget doit inclure le temps d'un ingénieur pour traiter les faux positifs et confirmer les conclusions.

L'intérêt pratique de DreamTeam réside dans l'exemple d'organisation d'un tel travail. L'efficacité doit se juger sur les défauts confirmés et les correctifs acceptés : le nombre de tâches, d'agents et de commits ne mesure pas, à lui seul, la qualité d'un audit.