Montrer plutôt que promettre : ce que Evo Continuous Offensive Security a découvert dans un véritable SaaS d’entreprise

Les attaques autonomes par IA ne se limitent plus aux démonstrations de recherche qui ont tant impressionné tout le monde : elles sont désormais entrées dans les pratiques courantes. Pour quiconque suit suffisamment le sujet, ce n’est pas forcément une nouvelle : en juin, l’alliance Five Eyes avertissait déjà que l’IA contournerait la cybersécurité en quelques mois, et non en quelques années, les délais de percée des adversaires se mesurant désormais en secondes. Gartner a lui aussi fait une prédiction similaire, estimant que le délai avant exploitation pourrait être réduit de moitié dès l’année prochaine.

Découvrez ce que les attaquants peuvent trouver avant eux.

L’annonce de la disponibilité de Evo Continuous Offensive Security est donc plus que jamais pertinente et opportune. Nous proposons une sécurité offensive autonome qui attaque en continu vos applications et vos systèmes d’IA, comme le ferait une équipe rouge humaine de premier plan, grâce à trois fonctionnalités intégrées : AI Pentesting, Agent Red Teaming et Dynamic Testing (DAST).

COS est conçu pour être le testeur d’intrusion IA le plus précis et le plus fiable du marché. Avant de vous être communiquée, chaque découverte est validée par un « évaluateur indépendant », pour ainsi dire, afin de vérifier qu’elle est réellement exploitable et reproductible. Ainsi, votre rapport ne contient que des vulnérabilités qu’un attaquant pourrait effectivement exploiter.

Mais plutôt que de nous contenter de vous dire ce que notre solution peut faire, nous voulons vous le montrer. Tout ce qui suit est tiré de l’évaluation réelle de l’application d’un client, avec deux des vulnérabilités bien réelles qu’elle a découvertes et dont elle a prouvé l’existence.

Évaluation réelle de l’application SaaS mutualisée d’un client

L’un de nos clients a utilisé COS pour évaluer une application SaaS d’entreprise mutualisée. Celle-ci se composait d’une application monopage (SPA) côté frontend, utilisée comme client web, qui consommait à son tour une suite de centaines de points de terminaison de microservices constituant sa logique métier.

Cette application est particulièrement intéressante, car son évaluation pose plusieurs difficultés aux testeurs d’intrusion humains comme aux outils déterministes, tels que les scanners DAST :

Pour les humains, il est très difficile d’assurer une couverture complète des autorisations et de la logique métier de centaines de microservices. Pour les machines, le problème n’est pas l’accès. Les scanners DAST modernes, comme Snyk API & Web (la fonctionnalité de Dynamic Testing intégrée à Evo COS), s’authentifient dans les SPA et énumèrent sans trop de difficulté les points de terminaison qui se trouvent derrière. La difficulté concerne presque tout ce qui vient ensuite : les failles d’autorisation et de logique métier ne correspondent à aucune signature. Déterminer si un rôle donné doit pouvoir appeler un point de terminaison précis, ou si une séquence de requêtes individuellement valides aboutit à un résultat que l’application n’a jamais prévu, exige de savoir à quoi sert l’application et ce que chaque acteur est censé pouvoir faire. Imaginez cela à l’échelle de centaines de microservices : vous comprendrez qu’il s’agit bien davantage d’un problème de raisonnement que de couverture. Et c’est précisément ce que les tests dynamiques n’ont pas encore automatisé.

La solution agentique de COS a « exploré » l’application de manière méthodique (et guidée), en tirant parti de la puissance des LLM :

• Vérifications préalables : le système a testé les identifiants fournis à l’aide d’un navigateur sans interface graphique, puis vérifié que toutes les ressources requises de l’application étaient accessibles et que celle-ci se trouvait dans un état permettant de la tester.

• Reconnaissance initiale : un sous-agent dédié a identifié la pile technologique de l’application, les différents points de terminaison existants et des informations pertinentes pour la sécurité, comme l’utilisation d’un WAF, la présence d’agents LLM accessibles par des interfaces de chat, le flux d’authentification, etc. Cette étape a également permis, de manière cruciale, de comprendre le modèle économique de l’application. Dans ce cas, le système a correctement déduit l’objectif du produit, ses utilisateurs et les flux de travail présentant une réelle valeur commerciale. Il s’est appuyé uniquement sur un environnement de préproduction, peu documenté et ne contenant que des données de test préchargées. Cette déduction a permis d’évaluer tout ce qui suivait selon l’impact métier, plutôt que la gravité technique.

• Recherche et validation des vulnérabilités : des sous-agents spécialisés ont été lancés pour rechercher des classes de vulnérabilités précises, en s’appuyant sur les résultats de la reconnaissance. Des sous-agents adversariaux ont vérifié indépendamment chaque découverte afin de s’assurer qu’elle pouvait être reproduite et de réduire le risque de faux positifs.

• Chaînage et validation des vulnérabilités : les vulnérabilités individuelles ont été associées de façon logique afin de vérifier si elles pouvaient être combinées pour accroître l’impact métier. Des sous-agents adversariaux ont également vérifié et reproduit les chaînes de vulnérabilités.

• Compilation du rapport : les découvertes ont été compilées dans un document reproduisant le format d’un rapport d’équipe humaine, avec un résumé destiné à la direction et une liste d’actions hiérarchisées pour réduire les risques.

Cette évaluation a été menée selon une approche entièrement en boîte noire, c’est-à-dire sans accès au code source. Nous pouvons aussi adopter une approche en boîte grise, en utilisant l’accès au code source pour améliorer la détection et l’efficacité, mais nous avons choisi de ne pas le faire dans ce cas. Quoi qu’il en soit, nous mettons l’accent sur la composante dynamique des tests : attaquer l’application comme le ferait un véritable attaquant, de l’extérieur vers l’intérieur.

Quels sont donc les avantages que nous avons constatés avec cette approche ?

1. La capacité à discerner les objectifs métier des applications représente un réel avantage, en particulier lorsqu’ils ne sont pas évidents. Il s’agissait d’un environnement de test « chaotique », contenant peu de données réelles, ce qui compliquait la tâche, même pour un humain. L’identification des objectifs métier aide la flotte d’agents à mieux interpréter l’impact métier de certaines vulnérabilités.

2. Nos agents pilotent un véritable navigateur et s’adaptent aux mécanismes d’authentification de l’application, sans script propre à chaque cible. Lors d’une évaluation, la connexion du client était protégée par une authentification à deux facteurs basée sur le temps. Nous avons donc fourni la clé secrète TOTP, et l’agent a généré lui-même des codes à usage unique pour comprendre comment se connecter, sans que nous ayons eu à le configurer spécifiquement pour cela. L’intérêt tient moins à cette fonctionnalité qu’à la fiabilité qu’elle apporte : l’authentification est l’étape où les tests automatisés échouent le plus souvent sans le signaler, et une évaluation qui ne dépasse jamais la page de connexion ne vaut rien, quelle que soit la qualité des tests.

3. Grâce à une approche multi-agents guidée et méthodique, nous tirons parti de la créativité d’agents qui raisonnent comme des humains, tout en assurant la couverture des tests et en testant systématiquement chaque microservice à la recherche de failles d’autorisation, d’authentification et de logique métier.

Les vulnérabilités découvertes

Dans cette application, nous avons découvert 33 vulnérabilités confirmées au total, allant de problèmes à faible impact, comme l’utilisation de bibliothèques jQuery obsolètes ou non sécurisées, à plusieurs vulnérabilités critiques. Parmi elles : une politique CORS non sécurisée permettant à des sites malveillants quelconques de dérober des jetons d’autorisation et d’agir au nom d’un utilisateur sans aucune interaction de sa part, ainsi que des failles de niveau d’autorisation permettant à n’importe quel utilisateur de s’octroyer les droits d’administrateur de son locataire.

Pour aller à l’essentiel, nous allons présenter deux découvertes qui illustrent ensemble les deux aspects qui distinguent cette approche : trouver ce que d’autres outils ne peuvent structurellement pas détecter, et communiquer le véritable impact de ce qu’ils peuvent trouver.

1. Compromission de tout un locataire par affectation de masse et défaut d’autorisation au niveau des fonctions

Voilà le type de découverte qu’un scanner DAST ne peut structurellement pas produire, et qu’un testeur d’intrusion humain ne pourrait trouver qu’en connaissant très bien l’application. Aucun contenu injecté renvoyé n’est à détecter, et aucune erreur évidente à suivre : la faille se trouve entièrement dans la logique d’autorisation de l’application, sur un ancien point de terminaison d’administration qui gère la configuration de tout un locataire.

Notre agent a identifié un ancien point de terminaison JSON, utilisé pour enregistrer les paramètres de compte à l’échelle du locataire. Celui-ci effectuait une opération d’insertion ou de mise à jour clé-valeur sans aucune limite, sans vérification du rôle ou des autorisations côté serveur, et sans appliquer les paramètres signature / timestamp de type HMAC qu’il semblait exiger. L’agent a ensuite raisonné sur les conséquences et les a enchaînées : le rôle disposant du moins de privilèges — exactement celui attribué à chaque employé ordinaire à sa connexion, et qui ne permet même pas d’accéder à l’interface d’administration — pouvait modifier arbitrairement des paramètres critiques pour la sécurité de tout le locataire. Plusieurs de ces paramètres pouvaient entraîner une compromission totale.

Tout le processus, de la découverte à la validation d’une chaîne reproduite de manière indépendante, s’est déroulé au cours d’une seule exécution sans supervision humaine. Une équipe humaine aurait généralement besoin de plusieurs jours pour se familiariser avec l’application et parvenir à la même conclusion.

Voici un extrait légèrement expurgé du rapport de l’agent (tous les détails propres au client et permettant d’identifier le produit ont été généralisés) :

Un ancien point de terminaison d’administration « save account settings » effectue une opération d’insertion ou de mise à jour clé-valeur sans aucune limite dans le magasin de paramètres à l’échelle du locataire, sans vérification du rôle ou des autorisations côté serveur et sans validation des paramètres de requête de type HMAC signature / timestamp qui l’accompagnent. Tout utilisateur authentifié du locataire, y compris celui disposant du rôle le moins privilégié (qui ne peut même pas accéder à l’interface d’administration), peut appeler ce point de terminaison avec un jeton d’accès Bearer standard et modifier arbitrairement des paramètres critiques pour la sécurité de tout le locataire.

[...]

Les clés concernées comprennent :

• Politique de mot de passe : complexité, longueur minimale, nombre de mots de passe précédents conservés et durée de validité maximale.

• Politique de verrouillage après échecs d’authentification : seuil de tentatives infructueuses et durée du verrouillage.

• Liste de blocage des types de fichiers exécutables lors des téléversements.

• Sources supplémentaires pour la Content-Security-Policy.

• Domaine d’expédition des e-mails sortants du locataire.

• Paramètres d’intégration OAuth d’une intégration d’entreprise tierce (ID client, secret client, URL de connexion, ressource et indicateur d’activation).

• Nouvelles clés définies librement par l’attaquant.

Causes profondes :

1. Absence de vérification du rôle ou des autorisations sur la méthode d’écriture. 2. Absence de liste d’autorisation des clés modifiables : le point de terminaison accepte n’importe quelle chaîne de caractères comme clé. 3. Absence d’application des paramètres de requête signature / timestamp de type HMAC, que le point de terminaison semble exiger. Un test réalisé avec une signature volontairement invalide a tout de même abouti.

Le rapport détaille ensuite les étapes nécessaires pour reproduire cette vulnérabilité et consacre une section à son impact métier, reproduite ici (et généralisée) :

Impact :

Un utilisateur disposant du rôle le moins privilégié ayant un contrôle total en lecture et en écriture sur les paramètres de sécurité à l’échelle du locataire, un seul compte compromis ou malveillant (ou tout initié disposant légitimement d’un accès peu privilégié) peut :

1. Prendre le contrôle de tous les comptes du locataire en affaiblissant la politique de mot de passe (par exemple, longueur minimale de 1 caractère, aucune exigence de complexité) et en désactivant le verrouillage après échec, puis en essayant en ligne de deviner les mots de passe sur le point de terminaison de connexion du locataire.

2. Distribuer des logiciels malveillants au sein du locataire en vidant la liste de blocage des fichiers exécutables et en téléversant des exécutables natifs via l’interface de téléversement de contenu, déjà accessible aux utilisateurs disposant de peu de privilèges. Les fichiers téléversés sont ensuite diffusés à tous les utilisateurs qui consultent le contenu partagé du locataire.

3. Permettre des attaques XSS en ajoutant des origines contrôlées par l’attaquant à la liste d’autorisation de la Content-Security-Policy, élargissant ainsi script-src et connect-src pour le locataire.

4. Exploiter les e-mails sortants en réécrivant le domaine de l’expéditeur, afin que les notifications destinées aux locataires semblent provenir d’un domaine contrôlé par un attaquant (et permettent ainsi de lancer des campagnes d’hameçonnage interne très convaincantes, signées et conformes à SPF/DKIM grâce à l’infrastructure du locataire).

5. Détourner l’intégration OAuth tierce en réécrivant son URL de connexion, son ID client et ses paramètres de ressource, pour rediriger l’échange du code ou du jeton OAuth vers l’infrastructure de l’attaquant et récupérer les identifiants OAuth que le locataire transmet à ce qu’il croit être son fournisseur d’identité.

6. Persister d’une session à l’autre. Les modifications subsistent au-delà de la durée de vie d’environ 30 minutes du jeton OIDC de l’attaquant. Le locataire reste donc dans cette configuration affaiblie jusqu’à ce qu’un administrateur détecte et rétablisse manuellement chaque clé.

7. Rendre les pages d’administration indisponibles en enregistrant une configuration mal formée qui provoque le plantage de l’interface d’administration lors de son analyse ultérieure.

Le seul prérequis est un jeton d’accès OIDC doté du niveau de privilèges minimal, exactement celui qui est attribué à la connexion à chaque utilisateur réel du tenant (y compris à tous les employés ordinaires). Aucun contrôle supplémentaire, aucun privilège d’administrateur ni aucune signature ne sont requis.

C’est le niveau de raisonnement que les scanners traditionnels ne peuvent pas atteindre : repérer une écriture sans contrôle d’accès, comprendre ce que chaque paramètre implique pour l’entreprise et en combiner quelques-uns pour compromettre l’ensemble du locataire.

2. Réflexion de l’origine CORS : une faille « triviale » rendue incontestable

Les erreurs de configuration du partage des ressources entre origines (CORS) comptent parmi les vulnérabilités web les plus courantes. Presque tous les scanners et tout testeur compétent signaleront un point de terminaison qui renvoie l’origine de la requête Origin dans Access-Control-Allow-Origin, tout en retournant Access-Control-Allow-Credentials: true. La détection n’est pas le plus difficile.

Le plus difficile relève de l’un des problèmes les plus persistants du secteur, et pourtant les moins abordés : une vulnérabilité est signalée, mais personne en aval ne parvient à traduire ce qu’elle signifie réellement pour l’entreprise. Cela s’explique par le fait que les niveaux de gravité se transmettent facilement et donnent une idée de l’urgence, mais que les conséquences concrètes, elles, sont rarement communiquées.

Une faille est présentée sous la forme d’un nom de catégorie et d’un score CVSS. L’équipe qui la reçoit doit alors en évaluer l’importance à partir d’informations qui n’expliquent jamais les conséquences potentielles. Elle se rabat donc sur l’analyse la plus simple et se fie uniquement au chiffre.

Tout ce qui est qualifié de gravité moyenne passe après tout ce qui est qualifié de gravité élevée. Résultat : non seulement les interventions sont retardées, mais les efforts sont mal répartis. Les risques réels restent enfouis dans le backlog tandis que les équipes corrigent les failles les plus faciles à comprendre. Une évaluation des risques ne vaut que par l’analyse d’impact qui l’alimente. Or, dans la plupart des outils, cette analyse est laissée à l’interprétation du lecteur.

Cette faille en est un parfait exemple. Dans le rapport d’un scanner classique, elle apparaît comme une simple ligne de gravité moyenne concernant un en-tête trop permissif. En réalité, n’importe quel site web visité par un utilisateur connecté pouvait lire sa session à son insu et voler les jetons permettant d’agir en son nom, sans aucune interaction ni tentative d’hameçonnage.

L’erreur de configuration se trouvait sur le fournisseur d’identité, s’appliquait à tous les points de terminaison de l’application et les jetons d’accès étaient renvoyés dans le corps des réponses inter-origines. Il ne s’agissait donc pas d’un simple problème de configuration des en-têtes, mais d’une prise de contrôle complète du compte de tout utilisateur qui consultait la « mauvaise » page. Pourtant, la faille était classée dans la catégorie « moyenne ».

Ce qui a le plus impressionné notre client et partenaire de conception, ce n’est pas seulement la découverte de la faille, mais aussi ce que l’agent a fait ensuite. Au-delà de la description du problème et de son impact sur l’entreprise, il a créé en quelques minutes une preuve de concept pleinement fonctionnelle, reproduisant l’attaque de bout en bout dans un navigateur Chrome standard : ouvrez la page et voyez votre propre jeton d’accès exfiltré vers une origine contrôlée par un attaquant.

Un développeur de l’équipe du client pouvait, sans proxy, sans connaissances en sécurité ni outils spécialisés, voir immédiatement — au lieu de simplement se l’entendre dire — que cette faille permettait réellement de compromettre des comptes. Au bout du compte, c’est ce qui fait la différence entre une faille qui est simplement évaluée et une faille qui est corrigée.

Il est également possible d’interroger directement les failles dans la plateforme Evo : l’utilisateur peut demander à une faille de s’expliquer en termes simples ou de proposer une correction. La démonstration et la solution se trouvent ainsi au même endroit.

C’est là que réside la différence qui nous importe : il ne s’agit pas de détecter les problèmes CORS, ce qui est trivial, mais de réduire l’écart entre une faille facile à repérer et une démonstration incontestable de son impact dans le monde réel.

Deux failles, deux atouts distincts

Cela montre en quoi COS se démarque : sa capacité à aller plus loin et à communiquer clairement l’impact.

En matière de profondeur, il s’agit de repérer une faille d’autorisation qu’un scanner ne peut pas détecter et qu’un humain mettrait des jours à découvrir. Quant à la communication, l’objectif est de partir d’une faille détectable par n’importe quel outil et de rendre son impact dans le monde réel incontestable.

Pour un modèle performant, trouver des vulnérabilités est la partie facile. Le plus difficile est de les communiquer clairement, sans bruit, de façon à ce que le public visé puisse agir. C’est là que se concentrent une grande partie de nos efforts d’ingénierie.

Voir en action

Tout ce qui précède provient d’une seule exécution sans supervision sur une application réelle. Plutôt que de nous croire sur parole, mieux vaut le constater par vous-même.

Pour comprendre comment le pentest par IA, le red teaming d’agents et les tests dynamiques fonctionnent ensemble, et pourquoi une couverture continue est préférable à un pentest réalisé une ou deux fois par an, consultez notre annonce de lancement et inscrivez-vous à notre webinaire à venir, « Une couverture de niveau pentest à la vitesse de l’IA », le 2 septembre.