Une faille OTP critique a été trouvée par un agent IA sur le site d'un grand assureur : le code de connexion était redirigeable.

Une faille OTP critique vient d’être mise au jour sur le site de production d’un grand assureur. Elle n’a pas été trouvée par un humain. En effet, un agent IA de test d’intrusion l’a repérée seul, lors d’une évaluation autorisée. Le cas est instructif à deux titres. Ainsi, la vulnérabilité est très simple. Pourtant, la démontrer proprement sur un site réel a été le vrai défi.

Une faille OTP découverte par un agent IA en production

L’agent travaillait dans le cadre d’un audit de sécurité encadré. Il a analysé le parcours de connexion du site. Ensuite, il a identifié un contournement complet de l’authentification. Aucune intervention humaine n’a été nécessaire pour la détection.

Le point notable tient au contexte. L’agent ne testait pas un laboratoire ni une application volontairement vulnérable. Il évoluait en effet sur un site en production, exposé à de vrais clients. Par conséquent, cela change la nature de l’exercice.

Par ailleurs, la sévérité retenue est critique. Un contournement d’authentification ouvre en effet la porte aux comptes des utilisateurs. Il neutralise également la protection censée vérifier leur identité.

Un bug simple : l’utilisateur choisit la destination du code

Le mécanisme est presque banal. Lors de la connexion, le site envoie un code à usage unique (OTP) pour confirmer l’identité. Normalement, ce code part vers un contact déjà enregistré. Il s’agit du numéro ou de l’adresse du titulaire du compte.

Or, ici, une seule requête de connexion permettait de choisir la destination du code. Autrement dit, le client pouvait indiquer lui-même où l’envoyer. Un attaquant n’avait donc qu’à saisir sa propre adresse ou son propre numéro.

Il recevait alors le code censé protéger la victime. Ainsi, le second facteur ne prouvait plus rien. Il validait simplement que l’attaquant contrôlait le canal qu’il avait lui-même désigné.

Cette erreur de conception est classique. Le serveur fait confiance à une donnée fournie par le client. Pourtant, elle devrait venir de ses propres enregistrements. La logique du code est sans doute correcte. En revanche, c’est la confiance accordée au paramètre qui pose problème.

Prouver l’attaque : la partie la plus difficile

Selon le récit de cette évaluation, l’attaque elle-même était la partie facile. Le plus complexe consistait à la prouver sur un site en production. Cette difficulté mérite donc qu’on s’y arrête.

Sur un environnement réel, un testeur ne peut pas agir sans retenue. D’abord, il doit rester dans le périmètre autorisé. Ensuite, il doit éviter de toucher aux données de vrais clients. Enfin, il doit produire une preuve assez solide pour convaincre l’équipe concernée.

Une simple intuition ne suffit pas. Il faut montrer que le contournement fonctionne, sans causer de dommage. Cet équilibre entre démonstration et prudence reste délicat, même pour un expert humain.

Pour un agent autonome, la question est encore plus sensible. Il doit comprendre les limites de sa mission. Il doit aussi documenter ses actions de façon claire et vérifiable. C’est pourquoi la qualité de la preuve compte autant que la détection.

Ce cas montre également que ces outils progressent vite. Ils ne se contentent plus de lancer des scanners. En effet, ils raisonnent sur la logique d’une application. Or, c’est là que se cachent les failles les plus graves.

Comment corriger une faille OTP de ce type

La correction est heureusement bien connue. Elle repose sur un principe simple. Le serveur décide seul de la destination du code. Par conséquent, le client n’a aucun droit de regard sur ce point.

• Ne jamais accepter de destinataire dans la requête. Le canal d’envoi doit provenir uniquement des données enregistrées pour le compte.
• Lier le code à une session précise. Un OTP ne doit être valable que pour l’identifiant qui l’a demandé.
• Limiter les tentatives et la durée de vie. Une expiration courte et un nombre d’essais plafonné réduisent ainsi le risque.
• Journaliser les envois. Un code expédié vers un contact inhabituel doit donc déclencher une alerte.
• Tester la logique métier. Les scanners classiques passent en effet souvent à côté de ce genre d’erreur.

Ce qu’il faut retenir

• Un agent IA a découvert seul une faille critique sur le site de production d’un grand assureur.
• La requête de connexion laissait l’utilisateur choisir où le code à usage unique était envoyé.
• L’attaque était simple. En revanche, la démontrer en production, de façon sûre et autorisée, était le plus difficile.
• Les équipes doivent donc vérifier que la destination d’un OTP n’est jamais fournie par le client.
• Les audits doivent également cibler la logique d’authentification, et pas seulement les vulnérabilités connues.

Source : An AI Agent Found a Critical OTP Bypass in Production. The Attack Was the Easy Part.