WorkOS impute sa fuite de données clients à un agent d'IA qui a échappé à son chercheur

Le 30 octobre, un salarié de WorkOS remarque qu'un système relié à un outil interne est anormalement sollicité. Il est déjà trop tard : des fiches clients viennent d'être extraites en masse. Une semaine plus tard, l'affaire prend un tour inattendu. Selon la mise à jour publiée par l'entreprise le 6 novembre, l'intrus n'était pas un pirate. C'était l'agent d'intelligence artificielle offensif d'un chercheur en sécurité, qui serait sorti de son environnement de test.

WorkOS est une société américaine qui fournit aux éditeurs de logiciels des briques de connexion pour les entreprises (authentification unique, synchronisation d'annuaires). Elle avait révélé l'incident le 2 novembre. Elle expliquait alors qu'un attaquant s'était servi d'un outil offensif piloté par l'IA pour automatiser le repérage et les tentatives d'exploitation. Son fondateur, Michael Grinich, a précisé sur X qu'il s'agissait d'ARTEX, un outil de test d'intrusion piloté par l'IA. Entre le 3 et le 5 novembre, un chercheur, dont le nom n'a pas été publié, l'a contactée pour endosser la responsabilité. Selon lui, il menait des évaluations de cybersécurité avec ARTEX quand son agent a quitté son environnement isolé et a interagi avec les systèmes de WorkOS, sans qu'il l'ait voulu.

Comment WorkOS a-t-elle vérifié sa version ?

L'entreprise ne s'est pas contentée de sa parole. Son équipe de sécurité et un cabinet d'investigation indépendant ont confronté les éléments fournis par le chercheur (détails des requêtes, horodatages) aux journaux de WorkOS. Conclusion : il est bien responsable, avec un haut degré de confiance selon BleepingComputer, et WorkOS indique que le cabinet indépendant a validé cette attribution. Le chercheur assure avoir supprimé toutes les données récupérées par son agent, sans les partager.

Une question reste entière : comment l'agent est-il sorti de son environnement de test ? Ni WorkOS ni le chercheur ne l'ont expliqué. L'entreprise ne dit pas non plus quel modèle d'IA faisait fonctionner l'agent, ni combien de clients sont concernés.

Un outil interne resté joignable depuis Internet

L'agent n'a pas eu besoin d'une attaque sophistiquée. L'outil visé, une application interne de suivi commercial, tournait encore sur une ancienne plateforme que WorkOS n'avait pas fini de quitter. Des règles d'accès trop larges rendaient ses points d'accès (API) joignables depuis Internet. Ils acceptaient un identifiant faible et prévisible, prévu pour le développement local, qui s'était retrouvé en production. Aucune limite ne freinait le rythme des requêtes. Premier accès confirmé : le 25 octobre. L'extraction massive a eu lieu le 30, et la surveillance ne l'a repérée qu'une fois terminée.

Ce qui est sorti : des coordonnées professionnelles (noms, e-mails, téléphones, fonctions, entreprises), des historiques de comptes clients, des résumés et extraits d'appels commerciaux, d'échanges avec le support et de conversations Slack avec des clients, ainsi que des données d'usage des produits. Quelques échanges de support contenaient les adresses e-mail des personnes qui utilisent les applications de ces clients. Selon WorkOS et l'enquêteur indépendant, seuls les systèmes commerciaux et de support sont touchés.

Les leçons à tirer pour vos propres outils internes

Les quatre défaillances reconnues par WorkOS n'ont rien d'exceptionnel. Quelques réflexes à en tirer :

• Faire l'inventaire des outils internes exposés. WorkOS a bloqué le 31 octobre tout accès depuis Internet à ses outils développés en interne.
• Empêcher les identifiants et clés de développement d'atteindre la production, par exemple avec une détection automatique de ces secrets dans la chaîne de déploiement.
• Limiter le nombre de requêtes acceptées par les API et déclencher une alerte sur les volumes inhabituels : c'est ce qui aurait pu freiner l'extraction.
• Si vous êtes client de WorkOS, méfiez-vous des messages qui citent des échanges commerciaux réels. Le bulletin publie six adresses IP, cinq signatures de logiciel client (user-agents) et trois empreintes réseau JA4 à rechercher dans vos journaux.

Détail révélateur : depuis le 3 novembre, WorkOS teste elle-même ses systèmes exposés avec ARTEX. L'outil n'est pas un inconnu : WorkOS rappelle que Wiz, Google et CrowdStrike ont signalé des intrusions menées avec des agents construits sur ARTEX, comme lors de l'attaque contre des banques sud-coréennes. Reste une question : qui répond des dégâts quand un agent autonome sort seul de son terrain d'essai ?