Fuite IDScan : 153 millions de permis et la faille KYC

Ce que l’on sait du cas IDScan

D’après Krebs on Security, le service « Nexus » proposait :

• 153 millions de permis de conduire (États-Unis et Canada), soit environ 63 % des permis américains ;
• 3 millions de documents de voyage ;
• une base en croissance continue, avec près de 400 000 permis ajoutés en une journée, signe d’un accès qui continuait à alimenter la base.

Krebs a pu vérifier son propre permis et ceux de neuf proches. Des hauts responsables américains figuraient dans les données. Le service a disparu peu après la publication. IDScan a publié une notification d’incident ; les sources citées ne détaillent pas le vecteur d’intrusion, et nous ne le supposerons pas ici.

Le point qui doit retenir l’attention d’un éditeur est l’ingestion continue : l’attaquant ne revendait pas un vieux dump, il disposait d’un accès qui lui remontait des pièces fraîches chaque jour.

La faille : une base KYC est un point de concentration

Un éditeur de vérification d’identité reçoit des photos recto verso, des selfies, des numéros de document et des adresses. Ces données servent une seule fois, au moment du contrôle, mais elles restent souvent stockées des années. Trois défauts reviennent :

1. Rétention illimitée. Les images restent dans un bucket ou une base alors que seul le résultat du contrôle (« vérifié le ... ») est utile ensuite.
2. Accès trop large. Une clé d’API partagée par tous les clients, un compte de support qui voit toutes les pièces, un bucket sans politique : un seul secret volé ouvre tout le stock.
3. Identifiants prévisibles. Des URL de type /documents/184523.jpg ou des liens signés sans expiration permettent d’énumérer les pièces une par une.

Un permis est aussi une clé de jointure : son numéro apparaît dans d’autres bases. Rapproché d’une adresse et d’une photo, il transforme une ligne anonyme en profil exploitable pour l’usurpation, la fraude au crédit ou le renseignement. Les fuites d’Anthem, d’Equifax ou de l’Office of Personnel Management ont été citées à ce titre.

Le schéma n’est pas propre à IDScan. AU10TIX, 5CA (le prestataire de vérification d’âge de Discord) ou National Public Data ont connu des incidents du même ordre. Voir aussi notre analyse de la fuite de passeports chez Revolut et celle des 200 000 permis du DMV de Floride.

Comment l’attaque se déroule en pratique

Sans présumer du cas IDScan, les chemins classiques vers une base de pièces d’identité sont :

• IDOR sur l’API de consultation : l’application cliente appelle GET /api/verifications/{id} et le serveur renvoie la pièce sans vérifier que l’appelant est bien le client propriétaire. C’est la faille décrite dans notre article sur les BOLA et IDOR.
• Clé d’intégration volée : une clé d’API d’éditeur KYC qui donne accès à l’historique complet, retrouvée dans un dépôt Git, un bundle JavaScript ou un poste infecté.
• Bucket mal configuré : listage public ou lecture anonyme sur le stockage des images.
• Compte interne compromis : un outil de back-office qui permet de chercher n’importe quel document, sans journalisation ni limite de volume.

Dans les quatre cas, l’exfiltration est lente et discrète si personne ne surveille le volume de consultations.

Comment le tester

Si vous stockez ou faites transiter des pièces d’identité, vérifiez ces points avec deux comptes de test distincts (jamais avec de vraies pièces) :

1. Énumération. Récupérez l’URL ou l’identifiant d’un document de test du compte A. Depuis le compte B, puis sans session, appelez la même ressource et l’identifiant voisin. Toute réponse autre que 403 ou 404 est une faille.
2. Liens signés. Notez la durée de validité des URL de téléchargement. Rouvrez-en une le lendemain. Au-delà de quelques minutes, le lien est une clé permanente.
3. Stockage. Tentez un listage anonyme du bucket (aws s3 ls s3://<bucket> --no-sign-request ou l’équivalent de votre fournisseur) et une lecture directe d’un objet connu.
4. Rétention. Cherchez la date du plus ancien document conservé. S’il précède largement la durée prévue par votre politique, la purge ne fonctionne pas.
5. Clés d’intégration. Vérifiez qu’aucune clé de votre prestataire KYC n’apparaît dans le code client, les variables NEXT_PUBLIC_* ou l’historique Git.
6. Journalisation. Consultez dix documents de test d’affilée depuis un compte support. Une alerte doit se déclencher, ou au moins une trace exploitable doit exister.

Comment corriger

• Ne gardez que le résultat. Après le contrôle, conservez le statut, la date et un identifiant, puis supprimez les images selon une durée courte et documentée.
• Cloisonnez par client. Une clé d’API par client, limitée à ses propres vérifications, et un contrôle d’autorisation côté serveur sur chaque lecture.
• Liens courts. URL signées de quelques minutes, jamais d’identifiants séquentiels exposés.
• Chiffrement avec une clé dédiée pour les pièces, et accès back-office soumis à un motif et journalisé.
• Seuils d’alerte sur le volume de consultations par compte et par clé.
• Auditez vos sous-traitants : demandez à votre prestataire KYC quelles données il garde, où et combien de temps.

Ce que ça change quand un agent IA y a accès

De plus en plus d’équipes branchent un agent IA sur le support client ou la conformité, avec un outil du type get_customer_documents. Si cet outil accepte un identifiant client choisi par le modèle, la frontière d’autorisation devient le prompt. Un e-mail ou un ticket contenant une instruction cachée peut amener l’agent à appeler l’outil pour un autre client, puis à résumer la pièce dans sa réponse ou à la joindre à un message sortant.

Le contrôle doit donc rester dans l’outil : l’identité de l’utilisateur authentifié fixe le périmètre, jamais un paramètre rempli par le modèle. Et l’agent ne devrait recevoir que le statut de vérification.

Un agent relié à des données d’identité mérite d’être attaqué avant d’être mis en production. C’est l’objet du Red Team Agent Express : cinq jours pour tenter de lui faire sortir ce qu’il ne doit pas montrer.