Zusammenfassung
Eine Kryptobörse mit dem Namen NCX hat angeblich eine interne MongoDB-Instanz ohne Authentifizierung im öffentlichen Internet veröffentlicht. Die Datenbank war monatelang erreichbar, enthielt ~1 GB an Daten und mehr als 5 Millionen Datensätze, darunter Namen, E-Mails, Geburtsdaten, Links zu KYC-Dokumenten, gehashte Passwörter, 2FA-Seeds/URLs, interne API-Schlüssel, IP-Historie, Wallet-Adressen und Transaktionsprotokolle.(Tägliche Sicherheitsüberprüfung) Dies ist nicht nur ein "PII-Leck". Es handelt sich um eine umfassende Kompromittierung: Identitätsdiebstahl, KYC-Betrug, Kontoübernahme, gezielte Angriffe auf die Kette, gesetzliche Vorschriften und die Verpflichtung zur Reaktion auf Vorfälle im Rahmen moderner Datenschutzregelungen, die eine Offenlegung innerhalb von 72 Stunden vorschreiben.(GDPR)

In diesem Artikel wird der NCX-ähnliche Verstoß aus zwei Blickwinkeln betrachtet:

1. Offensives Testen / Red-Team-Realität - wie diese Fehlkonfiguration zu einer aktiven Ausnutzung wird.
2. Compliance und Reaktion - was Sie tun müssen, wenn Sie wissen, dass Sie die Kontrolle über Kundenidentitätsdaten und Multifaktor-Geheimnisse verloren haben.

Wir werden auch darlegen, wie eine kontinuierliche offensive Testplattform wie Penligent genau diese Fehlermöglichkeiten aufdecken und simulieren kann, bevor es ein Regulierer, Angreifer oder Journalist tut.

Überblick über den Vorfall: Was durchgesickert ist und warum es wichtig ist

Das gemeldete Problem ist einfach in der Formulierung und brutal in den Konsequenzen: eine MongoDB-Instanz mit Internetanschluss ohne Autorisierung. Jeder, der die IP und den Port kannte (oder erraten/scannen konnte), konnte Sammlungen im Klartext durchsuchen.(Tägliche Sicherheitsüberprüfung)

Offengelegte Datentypen

Der Offenlegung zufolge enthielt der NCX-Datensatz (pro Datensatz, über Millionen von Zeilen):

• Vollständiger Name / E-Mail / Geburtsdatum
• KYC-Bild oder Dokumentenverknüpfungen (Reisepass, ID-Scans)
• 2FA-Startwerte und Anmelde-URLs
• Gehashte Passwörter
• IP-Adressverlauf und Metadaten zur Anmeldung
• Interne API-Schlüssel / Dienst-Tokens
• Wallet-Adressen, Ein- und Auszahlungshistorie, Kettenaktivität
• Kennzeichen für den Kontostatus (Sperre / Einfrieren / Risiko)
• Support-Ticket-Protokolle

Dies ist aus drei Gründen ungewöhnlich schlecht:

1. Identitätsübernahme in großem Maßstab
   Wenn ein Angreifer Ihren rechtmäßigen Namen + DoB + Passbild hat, kann er anderswo Konten eröffnen, mit Hilfe von Social-Engineering "Konten wiederherstellen" oder die KYC bei schwächeren Stellen umgehen. Das ist ein Hebel für Identitätsdiebstahl wie aus dem Lehrbuch.(Tägliche Sicherheitsüberprüfung)
2. MFA-Umgehung durch 2FA-Seed-Exposition
   Wenn zeitbasierte Einmalpasswort-Seeds (TOTP-Seeds) gespeichert und weitergegeben werden, kann ein Angreifer bei Bedarf gültige 2FA-Codes generieren und sich als Sie anmelden - selbst wenn Sie Ihr Passwort nie mitgeteilt haben. Kompromittierte 2FA-Seeds sind im Wesentlichen "vorgefertigte Sitzungs-Tokens".(Tägliche Sicherheitsüberprüfung)
3. Lagerhaltung + Zielgruppenansprache in der Kette
   Anhand von Wallet-Adressen und Transaktionsverläufen kann ein Angreifer feststellen, welche Nutzer tatsächlich Geld bewegen. Diese hochwertigen Ziele können dann mit Phishing ("Ihre Abhebung ist blockiert, bitte unterschreiben Sie hier") oder SIM-Swapping angegriffen werden. Wir haben gesehen, dass Kryptoplattformen Nutzer, die verletzt wurden, davor gewarnt haben, dass sie mit personalisiertem Phishing rechnen müssen, bei dem genau dieses Schema angewandt wird.(Tägliche Sicherheitsüberprüfung)

Problem der Nichtbeantwortung

Die Forscher, die die offene MongoDB gefunden haben, haben Berichten zufolge mehrfach versucht, die Verantwortlichkeiten offenzulegen, und haben keine rechtzeitige Antwort erhalten.(Tägliche Sicherheitsüberprüfung)
Aus regulatorischer Sicht ist das katastrophal: Regelungen der GDPR-Klasse und viele nationale Datenschutzbehörden erwarten eine schnelle Eindämmung, Beweissicherung, Benachrichtigung der Aufsichtsbehörden über den Verstoß innerhalb von 72 Stunden und in vielen Fällen auch eine Benachrichtigung der Nutzer, wenn das Risiko für die Nutzer hoch ist.(GDPR)

Angriffskette: Wie ein rotes Team "Open MongoDB" in eine vollständige Account-Kompromittierung verwandelt

Dieser Abschnitt ist wie ein Bericht über einen Penetrationstest geschrieben, denn so würde ein Angreifer (oder ein verantwortungsbewusster Prüfer) vorgehen.

Schritt 1: Aufzählung der offenen MongoDB

• Scannen Sie weite Teile des Cloud-Adressraums nach klassischen MongoDB-Ports (27017/27018).
• Erfassen Sie den Banner-/Serverstatus, um den unauthentifizierten Zugriff zu bestätigen.
• Datenbanken und Sammlungen auflisten (db.getCollectionNames() usw.).
• Deponieren Sie hochwertige Sammlungen: Benutzer, Autorisierung, kyc, Brieftasche, Transaktionen, apiKeys, Eintrittskarten.

Mit anderen Worten, es handelt sich nicht um einen "0-Day". Es handelt sich um eine Fehlkonfiguration auf dem Stand der 1990er Jahre: Datenbank im Internet, keine Authentifizierung, keine Firewall. CISA und NIST warnen wiederholt, dass Datenspeicher im Internet ohne Authentifizierung nach wie vor einer der häufigsten Einbruchsstellen sind.Europäische Kommission)

Hier ist eine vereinfachte Pseudo-Sitzung, die ein Angreifer von einem Testsystem aus ausführen könnte (führen Sie diese nicht auf Systemen aus, die Sie nicht besitzen oder für die Sie keine Berechtigung haben, sie zu überprüfen; ein unberechtigter Zugriff ist illegal):

# Offene MongoDB-Hosts ermitteln (nur Beispiellogik)
nmap -p 27017 --open  -oG mongo_hosts.txt

# Verbinden mit einem gefundenen Host ohne Anmeldeinformationen
mongosh --host :27017 --eval "db.adminCommand('listDatabases')"

# Auflisten von Sammlungen in einer Ziel-DB
mongosh --host :27017 --eval "use ncx_users; db.getCollectionNames()"

# Benutzerbezogene Dokumente dumpen
mongosh --host :27017 --eval "use ncx_users; db.users.find().limit(5).pretty()"

Für ein echtes rotes Team ist das ein gefundenes Fressen. Für eine Aufsichtsbehörde oder einen Anwalt des Klägers ist dies ein schlagender Beweis dafür, dass das System "keine angemessenen Sicherheitskontrollen" hatte.

Schritt 2: Sammeln von Geheimnissen und Authentifizierungsmaterial

Einmal drinnen, zieht ein Angreifer:

• passwort_hash oder gleichwertig
• totp_seed / 2fa_geheimnis
• Api_Schlüssel / api_geheimnis
• KYC-Datei URLs

Das ist der Jackpot. Passwort-Hashes können offline geknackt werden; mit TOTP-Seeds können Sie gültige MFA-Codes fälschen; API-Schlüssel können mit internen Verwaltungs- oder Handels-Backends kommunizieren.

Sicherheitsforscher und DFIR-Teams haben wiederholt festgestellt, dass durchgesickerte 2FA-Seeds und "wiederverwendbare" API-Zugangsdaten eine hochwertige Beute darstellen, da sie zur direkten Übernahme von Konten und zu lateralen Bewegungen führen.(Tägliche Sicherheitsüberprüfung)

Schritt 3: Simulierte Kontoübernahme

Mit einem Benutzernamen/E-Mail + Passwort (oder einem offline geknackten Hash) + gestohlenem TOTP-Seed kann ein Angreifer lokal gültige 6-stellige Codes erzeugen. Das bedeutet, dass er sich vollständig anmelden kann, ohne das Telefon des Opfers jemals zu berühren.

Wenn die Börse das Zurücksetzen des Passworts per E-Mail und 2FA unterstützt und beides kompromittiert ist, kann der Angreifer den Benutzer vollständig aussperren. Dieses Szenario - die Umgehung der MFA mit gestohlenen TOTP- oder Reset-Faktor-Daten - ist genau der Grund, warum die Leitfäden zur Reaktion auf Krypto-Verletzungen den betroffenen Nutzern raten, ihre Anmeldedaten sofort zu ändern, die MFA neu zu registrieren und Abhebungen zu überwachen.(CCN.com)

Schritt 4: KYC und Identitätsmissbrauch

Da die Links zu den KYC-Bildern und die ID-Scans Berichten zufolge unverschlüsselt sind (oder sich hinter erratbaren/langlebigen URLs befinden), können Angreifer sie nutzen:

• anderswo als jemand anderes neue Wechselkonten zu eröffnen;
• Social-Engineering-Kundenservice bei anderen Diensten ("Ich schicke Ihnen jetzt meinen Reisepass, bitte entsperren");
• um hochwertige Nutzer mit sehr persönlichen Details zu phishen ("Hi, per AML haben wir Ihre Abhebung eingefroren...").

Wir erleben bereits, dass Krypto-Plattformen öffentlich davor warnen, dass durchgesickerte KYC-Artefakte zum Treibstoff für maßgeschneidertes Phishing und Betrug werden.(Tägliche Sicherheitsüberprüfung)

Schritt 5: On-Chain-Targeting

Anhand von Wallet-Adressen und Transaktionsprotokollen können Sie erkennen, wer tatsächlich ein großes Volumen bewegt. Diese Liste ist Gold wert:

• Spear-Phishing ("Sicherheitsüberprüfungs"-Betrug),
• Erpressungsdrohungen,
• Abstaubungsangriffe und Genehmigungsbetrug (unterschreiben Sie das, verlieren Sie Geld).

Die Angreifer sind vom "Stehlen von Passwörtern für Geldbörsen" zum "Ausnutzen von durchgesickerten Finanzdaten" übergegangen, weil sich dies besser skalieren und sozialer gestalten lässt.(Tägliche Sicherheitsüberprüfung)

Checkliste für Abwehr- und Abhilfemaßnahmen (technisch)

Das ist es, was NCX (oder jede Krypto-Börse, Fintech-Wallet oder KYC-lastige Plattform) sofort nach der Entdeckung eines offenen MongoDB-Lecks tun sollte.

Grundlegende Sicherheit der Datenbank

• Öffentliche Bloßstellung jetzt beenden: Entfernen Sie die Instanz vom öffentlichen Routing oder sperren Sie sie hinter Firewall-Regeln / VPC-only-Zugang.
• Autorisierung anfordern: Aktivieren Sie die MongoDB-Authentifizierung und den rollenbasierten Zugriff; erlauben Sie niemals anonyme Lesezugriffe aus dem Internet.
• TLS überall: Erzwingt verschlüsselten Transport, nicht Klartext.
• Grundsatz des geringsten Rechtsanspruchs: Benutzerorientierte Microservices sollten nur die Sammlungen sehen, die sie unbedingt benötigen.
• Protokollierung und Alarmierung: Führen Sie kontinuierliche Prüfprotokolle über Zugriffsversuche und anomale Abfragen. NIST und EU-Aufsichtsbehörden erwarten Aufzeichnungen, aus denen hervorgeht, wer, wann, während und nach einem Verstoß auf was zugegriffen hat.(Europäische Kommission)

Geheimhaltung und Schlüsselverwaltung

• API-Schlüssel rotieren gefunden werden, gehen Sie davon aus, dass sie kompromittiert sind.
• Langlebige "private URLs" ungültig machen zu KYC-Images; verschieben Sie diese Assets hinter kurzlebige signierte URLs mit strenger ACL (z. B. vorsignierte S3-URLs mit minutengenauem Ablauf, IP-Limits und Audit).
• Interne Verwalter-APIs härten auf die die durchgesickerten Schlüssel treffen könnten: z. B. gegenseitiges TLS, IP-Zulassungslisten, Gerätestatus.

2FA / MFA-Rücksetzung im großen Maßstab

• Behandeln Sie alle exponierten TOTP-Seeds als verbrannt. Erzwingen Sie die erneute Registrierung der betroffenen Konten.
• Erfordert eine neue 2FA-Einrichtung mit neuen Seeds, die niemals im Klartext gespeichert werden.
• Bei Hochrisikokonten (z. B. bei hohen Guthaben) sollten Sie vorübergehend eine zusätzliche Überprüfung für Abhebungen und Passwortänderungen einführen. Sicherheitsteams und sogar Aufsichtsbehörden ermutigen zu einer "adaptiven Reibung" nach einem Einbruch bei hochwertigen Operationen.(CCN.com)

Handhabung von KYC-Daten

• Verschieben Sie KYC-Dokumente in einen verschlüsselten Speicher mit strikter Zugangskontrolle und kurzlebigen Abruf-Tokens, nicht mit permanenten öffentlichen Links.
• Hinzufügen einer Zugriffsprotokollierung auf der Objektebene (wer hat Pass X zum Zeitpunkt Y angesehen).
• Minimieren Sie die Aufbewahrung - die Datenschutz-Grundverordnung verlangt Datenminimierung und Zweckbindung. Wenn Sie einen Pass-Scan in voller Auflösung nicht für immer brauchen, sollten Sie ihn nicht ewig aufbewahren.(GDPR)

Forensik + Disziplin der Reaktion auf Vorfälle

• Machen Sie einen Schnappschuss des exponierten DB zu Beweiszwecken.
• Erfassen Sie Zugriffsprotokolle vor und nach der Abschaltung, um die Zeitachse zu rekonstruieren.
• Starten Sie den Workflow für die Benachrichtigung bei Verstößen:
  • Benachrichtigen Sie die Datenschutzbehörde innerhalb von 72 Stunden nach Bekanntwerden, es sei denn, Sie können ein geringes Risiko nachweisen;
  • die betroffenen Nutzer "unverzüglich" zu benachrichtigen, wenn ein hohes Risiko für sie besteht (Identitätsdiebstahl, Kontoübernahme ist eindeutig ein solches Risiko).GDPR)
• Dokumentieren Sie die gesamte Überwachungskette. Sowohl die GDPR als auch die meisten Cyber-Versicherer erwarten, dass Sie Beweise und Abhilfemaßnahmen aufbewahren.(Perkins Coie)

Nachfolgend finden Sie einen vereinfachten Zeitplan für die Behebung des Problems, den Sie in den ersten 48 Stunden nach der Entdeckung des Problems durchführen sollten:

Regulierungsbehörden wie die EU-DSGVO und die britische ICO weisen ausdrücklich darauf hin, dass die Meldung von Sicherheitsverletzungen an die Behörden in der Regel innerhalb von 72 Stunden nach Bekanntwerden erfolgen muss und dass Sie auch bereit sein müssen, betroffene Personen zu benachrichtigen, wenn für sie ein "hohes Risiko" besteht.(GDPR)

Abbildung der Einhaltung: GDPR, SOC 2 / SOC 3 und Krypto-spezifische Erwartungen

GDPR/Datenschutz nach EU-Vorbild

Gemäß Artikel 33 und Artikel 34 der Datenschutz-Grundverordnung müssen Sie bei einer Verletzung des Schutzes personenbezogener Daten, die eine Gefahr für die Rechte und Freiheiten von Personen darstellt, handeln:

1. die Aufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden zu informieren und
2. die betroffenen Nutzer "ohne unangemessene Verzögerung" zu informieren und zu beschreiben, was aufgedeckt wurde und was Sie dagegen unternehmen.(GDPR)

Bei Kryptowährungen ist das Durchsickern von KYC- und Identitätsdokumenten, Login-Metadaten und 2FA-Seeds für den Einzelnen absolut "hochriskant". Es ermöglicht Identitätsbetrug, finanzielle Verluste und Social Engineering - die Aufsichtsbehörden werden dies nicht stillschweigend hinnehmen.

Kontrollen im Stil von SOC 2 / SOC 3

In der Sprache von SOC 2 / SOC 3 (Sicherheit, Verfügbarkeit, Vertraulichkeit) ist eine offene, nicht authentifizierte Produktionsdatenbank ein klarer Verstoß gegen die Erwartungen in Bezug auf Zugangskontrolle, Netzwerksicherheit und Änderungsmanagement. Sie können ein ausgereiftes SOC-Audit nicht bestehen, wenn "kritische Kunden-PII und Geheimnisse auf einer öffentlichen IP ohne Authentifizierung liegen".

Meldung von Sicherheitsverletzungen und Krypto-Vertrauen

Krypto-Börsen befinden sich in einer seltsamen Zone: Einige sind keine voll lizenzierten Banken, verwalten aber dennoch Kundengelder, Pässe und AML/KYC-Daten. Das bedeutet:

• Sie werden sowohl wie ein Fintech-Verwahrer (Schutz von Kundenguthaben, Betrugsprävention) als auch wie ein Datenverantwortlicher (Schutz personenbezogener Daten, Meldung von Verstößen) beurteilt.(Tägliche Sicherheitsüberprüfung)
• Wenn Sie keine Meldung machen, riskieren Sie nicht nur Geldstrafen. Sie riskieren eine dauerhafte Schädigung der Marke innerhalb der Krypto-Gemeinschaften, die nach jahrelangen Börsenhacks und Rug Pulls bereits paranoid sind.(CCN.com)

Wie man "NCX-Class"-Fehler abfängt, bevor es das Internet tut (Penligent View)

Seien wir ehrlich: "öffentliche MongoDB ohne Autorisierung, die mehr als 5 Millionen Datensätze preisgibt" ist die Art von Dingen, die eine anständige offensive Testschleife lange vor den Journalisten erkennen sollte.Tägliche Sicherheitsüberprüfung)

Penligent (https://penligent.ai/) geht dies als kontinuierliche, automatisierte gegnerische Tests an - im Grunde genommen ein ständig verfügbares rotes Team. Das sieht folgendermaßen aus:

Kartierung von Vermögenswerten und Überwachung der Exposition

Die Agenten von Penligent bilden kontinuierlich externe Angriffsflächen ab (IP-Bereiche in der Cloud, Subdomains, durchgesickerte Dienste) und markieren dem Internet zugewandte Datenspeicher wie nicht authentifizierte MongoDB, Redis, Elasticsearch, Objektspeicher-Buckets usw. Dies ist genau die Art von Fehlkonfiguration, die zu der NCX-Enthüllung führte.(Tägliche Sicherheitsüberprüfung)

Simulation sensibler Daten/Schlüsselerkennung

Innerhalb des genehmigten Rahmens versucht Penligent, hochwertige "Kronjuwelen" in exponierten Diensten zu identifizieren:

• 2FA/TOTP-Saatgut
• API-Schlüssel und Service-Tokens
• KYC-Dokument-Verknüpfungen oder -Bereiche
• Metadaten zur Brieftasche / Abhebung

Die Plattform konstruiert dann einen Exploit-Pfad ("mit diesem Seed können wir MFA-Codes generieren", "mit diesem Schlüssel können wir auf die interne Admin-API zugreifen"), was echte Angreifer auch tun würden - allerdings in einer kontrollierten Sandbox, anstatt tatsächlich Konten zu kapern. Dies schafft eine beweisgestützte Risikoerzählung, die Sicherheitsteams an die Führung weitergeben können.

MFA- und Rückzugspfad-Tests

Penligent kann eine bedingte Kontoübernahme simulieren: "Könnte sich ein Angreifer, der diesen Samen gestohlen hat, anmelden? Könnten sie sich ohne manuelle Überprüfung abmelden? Könnten sie ihre E-Mail zurücksetzen?" So erhalten Sie eine geordnete Liste von Problemlösungen anstelle einer Panikspirale.

Compliance-Berichterstattung

Schließlich ordnet Penligent die Ergebnisse den 72-Stunden-Pflichten bei GDPR-Verletzungen, SOC 2 / SOC 3-Kontrollversagen und Krypto-Verwahrungsrisiken zu. Das ist wichtig, denn Sie müssen nicht nur den Fehler beheben, sondern auch nachweisen, dass Sie einen Prozess hatten, dass Sie Maßnahmen ergriffen haben und dass Sie die Aufsichtsbehörden informieren können.GDPR)

In der Praxis ist das der Unterschied zwischen "wir hatten monatelang keine Ahnung, dass unsere DB öffentlich war" und "wir haben eine kontinuierliche Entdeckung, wir haben es entdeckt, wir haben es eingedämmt, hier ist das Protokoll".

FAQ (für Sicherheit, GRC und Technik)

Q1. Was ist die häufigste MongoDB-Fehlkonfiguration, die zu Sicherheitslücken wie NCX führt?

Öffentlich routbare MongoDB ohne Authentifizierung und ohne Netzwerk-ACL. Oft werden Dev-/Test-Instanzen zu "temporären Prod-Instanzen" befördert und nie gesperrt. CISA/NIST warnen seit Jahren davor, dass ungeschützte Datenbanken ohne Authentifizierung eine häufige Ursache für groß angelegte Lecks sind.(Europäische Kommission)

Q2. Kann sich ein Angreifer als ich anmelden, wenn ein 2FA/TOTP-Seed durchsickert?

Ja, wenn der Angreifer auch Ihren Benutzernamen/Ihre E-Mail-Adresse und entweder Ihr Passwort oder einen geknackten Hash hat. Mit dem Seed können sie unendlich viele gültige 6-stellige Codes generieren. Deshalb heißt es in der Anleitung nach einem Einbruch immer: MFA zurücksetzen, nicht nur das Passwort.(Tägliche Sicherheitsüberprüfung)

Q3. Wie sollten KYC-Bilder und ID-Scans gespeichert werden?

Sie sollten verschlüsselt und zugriffskontrolliert sein und nur über kurzlebige signierte URLs, die an eine autorisierte Sitzung gebunden sind, abrufbar sein - keine statischen Links, die ewig leben. Jeder Zugriff sollte protokolliert werden. Die GDPR erwartet auch eine "Datenminimierung": Horten Sie nicht mehr personenbezogene Daten, als Sie benötigen.(GDPR)

Q4. Wie schnell müssen wir Regulierungsbehörden und Nutzer benachrichtigen?

Nach den Regelungen der Datenschutz-Grundverordnung (DSGVO) müssen Sie die zuständige Behörde im Allgemeinen innerhalb von 72 Stunden nach Bekanntwerden eines Verstoßes, der ein Risiko für Einzelpersonen darstellt, benachrichtigen, und Sie müssen die betroffenen Nutzer "ohne unangemessene Verzögerung" informieren, wenn das Risiko für sie hoch ist.GDPR)

Unterm Strich

"Falsch konfigurierte MongoDB" klingt wie ein Anfängerfehler. In der Kryptowelt ist er existenziell.
Wenn Sie mehr als 5 Millionen Benutzerdatensätze mit KYC-IDs, gehashten Passwörtern, IP-Protokollen, Wallets und sogar TOTP-Seeds durchsickern lassen, verlieren Sie nicht nur E-Mails, sondern auch Identität, Liquidität und Vertrauen.(Tägliche Sicherheitsüberprüfung)

Aus der Sicht des roten Teams ist dies ein fast automatischer Weg zur Übernahme.
Aus der Sicht der Einhaltung von Vorschriften ist es eine Uhr, die man nicht anhalten kann.(GDPR)

Aus diesem Grund werden kontinuierliche, automatisierte, beweisgestützte Offensivtests (Asset Discovery → Exploit-Simulation → Compliance Mapping) schnell zur Pflicht für jede Kryptoplattform, die KYC speichert und Nutzergelder verwahrt. Und wenn Sie ein Nutzer einer Börse sind, bei der ein solcher Verstoß stattgefunden hat? Ändern Sie Ihre Passwörter, setzen Sie 2FA ein, gehen Sie davon aus, dass gezieltes Phishing bevorsteht, und ziehen Sie ernsthaft in Betracht, die Plattform zu verlassen.(CCN.com)