Résumé
Une bourse de crypto-monnaies identifiée comme NCX aurait laissé une instance MongoDB interne exposée sur l'internet public sans authentification. La base de données était accessible pendant des mois, contenait environ 1 Go de données et plus de 5 millions d'enregistrements, dont des noms, des courriels, des dates de naissance, des liens vers des documents KYC, des mots de passe hachés, des graines/URL 2FA, des clés API internes, des historiques IP, des adresses de portefeuilles de comptes et des journaux de transactions.Revue quotidienne de sécurité) Il ne s'agit pas seulement d'une "fuite d'informations personnelles". Il s'agit d'une compromission totale : usurpation d'identité, fraude KYC, prise de contrôle de compte, ciblage sur la chaîne, exposition à la réglementation et obligations de réponse aux incidents dans le cadre des régimes modernes de protection des données qui exigent une divulgation dans les 72 heures.(GDPR)

Cet article aborde la violation de type NCX sous deux angles :

1. Tests offensifs / réalité de l'équipe rouge - comment cette mauvaise configuration se transforme en exploitation active.
2. Conformité et réponse - ce que vous devez faire une fois que vous savez que vous avez perdu le contrôle des données d'identité des clients et des secrets à plusieurs facteurs.

Nous verrons également comment une plateforme de tests offensifs continus comme Penligent peut mettre en évidence et simuler ces modes de défaillance exacts avant qu'un régulateur, un attaquant ou un journaliste ne le fasse.

Aperçu de l'incident : Ce qui a fuité et pourquoi c'est important

Le problème signalé est simple dans sa formulation et brutal dans ses conséquences : une instance MongoDB orientée vers l'internet sans authentification. Toute personne connaissant (ou pouvant deviner/scanner) l'IP et le port pouvait parcourir les collections en clair.(Revue quotidienne de sécurité)

Types de données exposés

Selon la divulgation, l'ensemble de données NCX contenait (par enregistrement, sur des millions de lignes) :

• Nom complet / courriel / date de naissance
• Image KYC ou liens vers des documents (scans de passeport, de carte d'identité)
• Valeurs d'amorçage 2FA et URL d'inscription
• Mots de passe hachés
• Historique des adresses IP et métadonnées de connexion
• Clés API internes / jetons de service
• Adresses des portefeuilles, historique des dépôts et des retraits, activité de la chaîne
• Indicateurs de l'état du compte (interdiction / gel / risque)
• Journaux des tickets d'assistance

Cette situation est exceptionnellement mauvaise pour trois raisons :

1. Reprise d'identité à grande échelle
   Si un pirate dispose de votre nom légal, de votre carte d'identité et de votre photo de passeport, il peut ouvrir des comptes ailleurs, procéder à une "récupération de compte" par ingénierie sociale ou passer le KYC dans des lieux plus faibles. Il s'agit là d'un moyen d'action classique contre le vol d'identité.Revue quotidienne de sécurité)
2. Contournement de l'AMF par l'exposition de la graine de l'AMF
   Si des semences de mots de passe à usage unique basés sur le temps (TOTP) sont stockées et font l'objet d'une fuite, un pirate peut générer des codes 2FA valides à la demande et se connecter en votre nom, même si vous n'avez jamais communiqué votre mot de passe. Les codes 2FA compromis sont essentiellement des "jetons de session précuits".Revue quotidienne de sécurité)
3. Ciblage en garde + en chaîne
   Les adresses des portefeuilles et l'historique des transactions permettent à un adversaire de déterminer quels utilisateurs déplacent réellement de l'argent. Ces cibles de grande valeur peuvent ensuite être hameçonnées ("Votre retrait est bloqué, veuillez signer ici") ou faire l'objet d'un SIM-swap. Nous avons vu des plateformes de crypto-monnaie avertir les utilisateurs victimes d'une brèche qu'ils devaient s'attendre à un hameçonnage personnalisé utilisant exactement ce scénario.Revue quotidienne de sécurité)

Problème de non-réponse

Les chercheurs qui ont découvert la base de données ouverte MongoDB auraient tenté à plusieurs reprises d'obtenir une divulgation responsable, mais n'auraient pas reçu de réponse en temps utile.Revue quotidienne de sécurité)
D'un point de vue réglementaire, c'est catastrophique : Les régimes de type GDPR et de nombreuses autorités nationales de protection des données s'attendent à un confinement rapide, à la préservation des preuves, à la notification de la violation aux régulateurs dans les 72 heures et, dans de nombreux cas, à la notification de l'utilisateur si le risque pour les utilisateurs est élevé.(GDPR)

Chaîne d'attaques : comment une équipe rouge transforme "Open MongoDB" en une compromission totale de compte

Cette section est rédigée comme le récit d'un test de pénétration, car c'est ainsi qu'un attaquant (ou un testeur responsable) la parcourrait.

Étape 1 : Enumération des bases de données MongoDB exposées

• Scanner les ports de l'espace d'adressage du nuage à la recherche des ports classiques de MongoDB (27017/27018).
• Saisir la bannière / l'état du serveur pour confirmer l'accès non authentifié.
• Lister les bases de données et les collections (db.getCollectionNames() etc.)
• Déposer les collections de grande valeur : utilisateurs, authentification, kyc, portefeuille, transactions, clés api, billets.

En d'autres termes, il ne s'agit pas d'un "0-day". Il s'agit d'une mauvaise configuration digne des années 1990 : base de données sur l'internet, pas d'authentification, pas de pare-feu. La CISA et le NIST ne cessent de répéter que les banques de données exposées à l'internet sans authentification restent l'un des points d'entrée les plus courants dans les brèches.Commission européenne)

Voici une pseudo-session simplifiée qu'un attaquant pourrait exécuter à partir d'une boîte de test (ne l'exécutez pas contre des systèmes dont vous n'êtes pas propriétaire ou que vous n'avez pas le droit d'évaluer ; l'exécution d'un accès non autorisé est illégale) :

# Découvrir les hôtes MongoDB ouverts (logique d'exemple uniquement)
nmap -p 27017 --open  -oG mongo_hosts.txt

# Se connecter à un hôte découvert sans informations d'identification
mongosh --host :27017 --eval "db.adminCommand('listDatabases')"

# Énumérer les collections d'une base de données cible
mongosh --host :27017 --eval "use ncx_users ; db.getCollectionNames()"

# Vider les documents relatifs aux utilisateurs
mongosh --host :27017 --eval "use ncx_users ; db.users.find().limit(5).pretty()"

Pour une véritable équipe rouge, il s'agit d'un enjeu de taille. Pour un régulateur ou un avocat, il s'agit d'une preuve irréfutable que le système ne disposait pas de "contrôles de sécurité raisonnables".

Étape 2 : Récolter les secrets et le matériel d'authentification

Une fois à l'intérieur, un attaquant tire :

• password_hash ou équivalent
• totp_seed / 2fa_secret
• clé_api / secret_api
• URL des fichiers KYC

C'est le jackpot. Les hachages de mots de passe peuvent être craqués hors ligne ; les graines TOTP vous permettent de monnayer des codes MFA valides ; les clés API peuvent communiquer avec des backends d'administration ou de négociation internes.

Les chercheurs en sécurité et les équipes de la DFIR ont noté à maintes reprises que les graines 2FA et les identifiants API "réutilisables" qui ont fuité constituent un butin de grande valeur parce qu'ils permettent de prendre directement le contrôle d'un compte et d'effectuer des mouvements latéraux.Revue quotidienne de sécurité)

Étape 3 : Simulation de la prise de contrôle d'un compte

Avec un nom d'utilisateur/email + un mot de passe (ou un hash craqué hors ligne) + une graine TOTP volée, un attaquant peut générer localement des codes valides à 6 chiffres. Cela signifie une connexion complète sans jamais toucher le téléphone de la victime.

Si la bourse prend en charge la réinitialisation du mot de passe par courrier électronique et le 2FA, et que les deux sont compromis, l'attaquant peut bloquer complètement l'utilisateur. Ce scénario - le contournement du MFA à l'aide de données TOTP ou de facteurs de réinitialisation volés - est exactement la raison pour laquelle les guides d'intervention en cas de violation de crypto-monnaie indiquent aux utilisateurs concernés de changer immédiatement d'identifiants, de réinscrire le MFA et de surveiller les retraits.(CCN.com)

Étape 4 : KYC et abus d'identité

Les liens vers les images KYC et les analyses d'identité étant apparemment en clair (ou derrière des URL devinables ou à longue durée de vie), les attaquants peuvent les utiliser :

• d'ouvrir de nouveaux comptes d'échange ailleurs en tant que quelqu'un d'autre ;
• d'utiliser l'ingénierie sociale pour l'assistance à la clientèle d'autres services ("Je vous envoie mon passeport maintenant, déverrouillez-le s'il vous plaît") ;
• pour hameçonner des utilisateurs de grande valeur en leur donnant des détails très personnels ("Bonjour, conformément à la loi sur la lutte contre le blanchiment d'argent, nous avons gelé vos retraits...").

Nous voyons déjà des plateformes de crypto-monnaies avertir publiquement que la fuite d'artefacts KYC alimente le phishing et la fraude sur mesure.Revue quotidienne de sécurité)

Étape 5 : Ciblage en chaîne

Les adresses des portefeuilles et les journaux de transactions permettent de savoir qui gère des volumes importants. Cette liste est de l'or pour :

• le spear-phishing (escroquerie par "vérification de sécurité"),
• des menaces d'extorsion,
• les attaques par dépoussiérage et les escroqueries par détournement d'approbation (signez ceci, perdez vos fonds).

Les attaquants sont passés du "vol de mots de passe d'échange" à "l'utilisation de métadonnées financières divulguées" parce qu'ils peuvent s'adapter et qu'ils sont plus efficaces en termes d'ingénierie sociale.Revue quotidienne de sécurité)

Liste de contrôle des mesures défensives et correctives (technique)

C'est ce que NCX (ou toute bourse de crypto-monnaies, portefeuille fintech ou plateforme à forte composante KYC) devrait faire immédiatement après avoir découvert une fuite ouverte de MongoDB.

Base de sécurité des bases de données

• Tuer l'exposition publique dès maintenantLes règles de routage : retirer l'instance du routage public ou l'enfermer derrière des règles de pare-feu / un accès VPC uniquement.
• Demande d'authentificationles utilisateurs doivent : activer l'authentification MongoDB et l'accès basé sur les rôles ; ne jamais autoriser les lectures anonymes à partir d'internet.
• TLS partoutLes règles suivantes s'appliquent : forcer le transport crypté, et non le texte en clair.
• Principe du moindre privilègeLes microservices en contact avec l'utilisateur ne doivent voir que les collections dont ils ont absolument besoin.
• Journalisation et alerteLes systèmes d'archivage des données : les systèmes d'archivage des données sont des systèmes d'archivage en continu des tentatives d'accès et des requêtes anormales. Le NIST et les régulateurs de l'UE attendent des enregistrements montrant qui a accédé à quoi, quand, pendant et après une violation.Commission européenne)

Gouvernance des secrets et des clés

• Rotation des clés API trouvés dans la décharge, on peut supposer qu'ils sont compromis.
• Invalider les "URL privés" de longue durée aux images KYC ; déplacer ces actifs derrière des URL signés de courte durée avec un ACL strict (par exemple, des URL S3 présignés avec une expiration à l'échelle de la minute, des limites d'IP et un audit).
• Renforcer les API internes de l'administration que les fuites de clés pourraient atteindre : par exemple, exiger un protocole TLS mutuel, des listes d'autorisation IP, la posture de l'appareil.

Réinitialisation de 2FA / MFA à l'échelle

• Traiter toutes les graines TOTP exposées comme brûlées. Forcer la réinscription des comptes concernés.
• Nécessité d'une nouvelle configuration 2FA avec de nouvelles graines qui ne sont jamais stockées en clair.
• Pour les comptes à haut risque (par exemple, les soldes importants), ajouter temporairement une vérification progressive pour les retraits et les changements de mot de passe. Les équipes de sécurité et même les autorités de réglementation encouragent la "friction adaptative" après une violation pour les opérations de grande valeur.(CCN.com)

Traitement des données KYC

• Transférer les documents KYC dans un espace de stockage crypté avec un contrôle d'accès strict et des jetons de récupération de courte durée, et non des liens publics permanents.
• Ajouter la journalisation des accès au niveau de l'objet (qui a consulté le passeport X à l'heure Y).
• Minimiser la conservation - Le GDPR exige la minimisation des données et la limitation des finalités. Si vous n'avez pas besoin d'un scan complet de votre passeport pour toujours, ne le conservez pas indéfiniment.GDPR)

Discipline de la criminalistique et de la réponse aux incidents

• Prendre un cliché de la DB exposée pour servir de preuve.
• Saisir les journaux d'accès avant/après le démontage pour reconstituer la chronologie.
• Commencer le processus de notification de la violation :
  • notifier l'autorité de protection des données dans les 72 heures suivant la prise de connaissance, à moins que vous ne puissiez prouver que le risque est faible ;
  • informer les utilisateurs concernés "sans délai excessif" s'ils courent un risque élevé (l'usurpation d'identité, la prise de contrôle d'un compte entrent clairement dans cette catégorie).GDPR)
• Documentez l'ensemble de la chaîne de contrôle. Le GDPR et la plupart des assureurs cybernétiques attendent de vous que vous conserviez les preuves et les étapes de remédiation.(Perkins Coie)

Vous trouverez ci-dessous un calendrier simplifié des mesures correctives à mettre en œuvre dans les 48 heures suivant la découverte de l'incident :

Les régulateurs tels que les autorités de protection des données de l'UE et l'ICO du Royaume-Uni rappellent explicitement que la notification d'une violation aux autorités doit généralement avoir lieu dans les 72 heures suivant la prise de conscience, et que vous devez également être prêt à notifier les personnes affectées s'il existe un "risque élevé" pour elles.GDPR)

Cartographie de la conformité : GDPR, SOC 2 / SOC 3, et attentes spécifiques aux crypto-monnaies

GDPR / Protection des données dans l'UE

En vertu des articles 33 et 34 du GDPR, si vous êtes victime d'une violation de données à caractère personnel qui risque de porter atteinte aux droits et libertés des personnes, vous devez :

1. notifier l'autorité de contrôle dans les 72 heures après en avoir pris connaissance, et
2. informer les utilisateurs concernés "sans délai injustifié", en décrivant ce qui a été exposé et ce que vous faites à ce sujet.GDPR)

Pour les cryptomonnaies, la fuite des documents KYC et d'identité, des métadonnées de connexion et des semences 2FA est absolument "à haut risque" pour les individus. Elle permet l'usurpation d'identité, la perte financière et l'ingénierie sociale - les régulateurs n'accepteront pas le silence.

Contrôles de type SOC 2 / SOC 3

Dans le langage SOC 2 / SOC 3 (sécurité, disponibilité, confidentialité), une base de données de production ouverte et non authentifiée constitue une violation directe du contrôle d'accès, de la sécurité du réseau et des attentes en matière de gestion du changement. Vous ne pouvez pas réussir un audit SOC mature si "des IIP et des secrets de clients critiques se trouvent sur une IP publique sans authentification".

Notification des violations et confiance dans les cryptomonnaies

Les bourses de crypto-monnaies se trouvent dans une zone étrange : certaines d'entre elles ne sont pas des banques agréées à part entière, mais gèrent l'argent des clients, les passeports et les données AML/KYC. Cela signifie que :

• Vous êtes jugé à la fois comme un dépositaire fintech (protéger les soldes des clients, prévenir la fraude) et comme un responsable du traitement des données (protéger les données personnelles, notifier les violations).(Revue quotidienne de sécurité)
• Si vous ne notifiez pas, vous ne risquez pas seulement des amendes. Vous risquez d'endommager définitivement votre marque au sein des communautés cryptographiques, qui sont déjà paranoïaques après des années de piratages d'échanges et d'arrachages de tapis.(CCN.com)

Comment détecter les défaillances de classe NCX avant qu'Internet ne le fasse (Penligent View)

Soyons francs : "MongoDB public sans authentification exposant plus de 5 millions d'enregistrements" est le genre de chose qu'une boucle de test offensif digne de ce nom devrait détecter bien avant que les journalistes ne le fassent.Revue quotidienne de sécurité)

Penligent (https://penligent.ai/) aborde cette question sous la forme de tests contradictoires automatisés et continus - en fait, une équipe rouge toujours active. Voici comment cela se présente :

Cartographie des actifs et surveillance de l'exposition

Les agents de Penligent cartographient en permanence la surface d'attaque externe (plages d'IP dans le nuage, sous-domaines, services fuités) et signalent les datastores orientés vers l'internet comme MongoDB, Redis, Elasticsearch, les buckets de stockage d'objets non authentifiés, etc. C'est exactement le type de mauvaise configuration qui a conduit à l'exposition de NCX.Revue quotidienne de sécurité)

Données sensibles / simulation de découverte de clés

Dans le cadre du champ d'application autorisé, Penligent tente d'identifier les "joyaux de la couronne" de grande valeur dans les services exposés :

• Semences 2FA/TOTP
• Clés API et jetons de service
• Liens ou groupes de documents KYC
• Métadonnées relatives aux portefeuilles et aux retraits

La plateforme construit ensuite un chemin d'exploitation ("avec cette graine, nous pouvons générer des codes MFA", "avec cette clé, nous pouvons accéder à l'API d'administration interne"), ce que les vrais attaquants feraient - mais ils le font dans un bac à sable contrôlé au lieu de détourner réellement les comptes. Cela crée un récit de risque étayé par des preuves que les équipes de sécurité peuvent présenter aux dirigeants.

Test de l'AMF et du chemin de retrait

Penligent peut simuler une prise de contrôle conditionnelle d'un compte : "Si un attaquant volait cette graine, pourrait-il se connecter ? Pourrait-il effectuer un retrait sans contrôle manuel ? Pourrait-il réinitialiser l'adresse électronique ?" Cela permet d'obtenir une liste de solutions ordonnées au lieu d'une spirale de panique.

Rapport de conformité

Enfin, Penligent met en correspondance les résultats avec les obligations de violation du GDPR dans les 72 heures, les défaillances de contrôle SOC 2 / SOC 3 et le risque de conservation des crypto-monnaies. Cela est important car vous ne devez pas simplement corriger le bug - vous devez prouver que vous aviez un processus, que vous avez pris des mesures et que vous pouvez informer les régulateurs.(GDPR)

Dans la pratique, c'est la différence entre "nous n'avions aucune idée que notre base de données était publique pendant des mois" et "nous avons une découverte continue, nous l'avons détectée, nous l'avons contenue, voici le journal".

FAQ (pour la sécurité, le GRC et l'ingénierie)

Q1. Quelle est la configuration erronée la plus courante de MongoDB qui conduit à des violations telles que NCX ?

MongoDB publiquement routable sans authentification et sans ACL réseau. Souvent, les instances dev/test sont promues au rang de "prod temporaire" et ne sont jamais verrouillées. CISA/NIST avertissent depuis des années que les bases de données exposées sans authentification sont une cause récurrente de fuites à grande échelle.Commission européenne)

Q2. En cas de fuite d'une graine 2FA/TOTP, un pirate peut-il se connecter en mon nom ?

Oui, si l'attaquant dispose également de votre nom d'utilisateur/email et de votre mot de passe ou d'un hash craqué. Avec la graine, ils peuvent générer des codes à 6 chiffres valides à l'infini. C'est pourquoi les conseils post-fraude disent toujours : réinitialisez le MFA, pas seulement le mot de passe.Revue quotidienne de sécurité)

Q3. Comment les images KYC et les scans de pièces d'identité doivent-ils être stockés ?

Ils doivent être cryptés, leur accès doit être contrôlé et ils ne doivent pouvoir être consultés que par l'intermédiaire d'URL signées de courte durée, liées à une session authentifiée - et non par des liens statiques qui sont éternels. Chaque accès doit être enregistré. Le GDPR prévoit également la "minimisation des données" : n'accumulez pas plus de données personnelles que vous n'en avez besoin.GDPR)

Q4. Dans quel délai devons-nous légalement informer les régulateurs et les utilisateurs ?

Dans le cadre des régimes similaires au GDPR, vous devez généralement notifier l'autorité compétente dans les 72 heures après avoir pris connaissance d'une violation présentant un risque pour les personnes, et vous devez informer les utilisateurs concernés "sans délai excessif" si le risque pour eux est élevé.(GDPR)

Résultat final

"Une mauvaise configuration de MongoDB" semble être une erreur de débutant. Dans le domaine de la cryptographie, c'est une question existentielle.
Lorsque vous divulguez plus de 5 millions d'enregistrements d'utilisateurs avec des identifiants KYC, des mots de passe hachés, des journaux IP, des portefeuilles et même des semences TOTP, vous ne divulguez pas seulement des courriels, mais aussi l'identité, la liquidité et la confiance de l'utilisateur.Revue quotidienne de sécurité)

Du point de vue de l'équipe rouge, il s'agit d'une prise de contrôle quasi automatique.
Du point de vue de la conformité, il s'agit d'une horloge réglementaire que l'on ne peut pas arrêter.GDPR)

C'est pourquoi les tests offensifs continus, automatisés et fondés sur des preuves (découverte d'actifs → simulation d'exploit → cartographie de la conformité) deviennent rapidement obligatoires pour toute plateforme de crypto-monnaies qui stocke le KYC et détient des fonds d'utilisateurs. Et si vous êtes un utilisateur d'une bourse qui a subi une telle violation ? Changez les mots de passe, faites tourner le 2FA, supposez que le phishing ciblé est à venir, et envisagez sérieusement de partir.(CCN.com)