Die Sicherheitslücke wurde nur wenige Tage vor Weihnachten entdeckt und ermöglichte es im schlimmsten Fall nicht authentifizierten Angreifern, den Server-Speicher aus der Ferne auszulesen. Es gibt bereits Korrekturen, aber der Schaden ist groß: Das Problem betrifft praktisch alle MongoDB-Versionen der letzten fast zehn Jahre.
Die als MongoBleed (CVE-2025-14847) bezeichnete Schwachstelle ist eine Vorab-Authentifizierungsschwachstelle im MongoDB-Server. Sie entsteht durch nicht übereinstimmende Längenfelder in zlib-komprimierten Protokoll-Headern, wodurch der Server nicht initialisierten Heap-Speicher an einen nicht authentifizierten Client zurückgeben kann. Einfach ausgedrückt: Wenn ein Angreifer über das Netzwerk auf eine MongoDB-Instanz zugreifen kann, kann er versuchen, Speicherinhalte zu „bleeden“, ohne sich jemals anzumelden.
Der Issue Tracker von MongoDB enthält klare Angaben zur Behebung des Problems und fordert die Benutzer dringend auf, auf alle unterstützten Versionen (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 oder 4.4.30) zu aktualisieren.
Was MongoBleed besonders besorgniserregend macht, ist, wie leicht es auszunutzen ist. Ein öffentlicher Proof-of-Concept ist bereits verfügbar und erfordert kaum mehr als die IP-Adresse eines erreichbaren MongoDB-Servers. Von dort aus können Angreifer den ausgelaufenen Speicher nach wertvollen Geheimnissen durchsuchen – darunter in Klartext gespeicherte Datenbank-Anmeldedaten, cloud und andere sensible Daten. Der Exploit wurde speziell für die Suche nach genau diesen Geheimnissen entwickelt, was die Hürde für einen Missbrauch in der Praxis drastisch senkt.
MongoDB überall finden: Mit Vectra Risiken, laterale Gefahren und Missbrauch erkennen
Bevor Sie sich Gedanken über Ausbeutung machen können, müssen Sie eine viel grundlegendere Frage beantworten:
Wo läuft MongoDB tatsächlich in meiner Umgebung?
Das klingt trivial. Ist es aber nicht.
Zwischen Legacy-Anwendungen, Schatten-IT, cloud , containerisierten Workloads und „temporären“ Datenbanken, die irgendwie dauerhaft geworden sind, taucht MongoDB häufig an Orten auf, an denen sich niemand daran erinnert, es jemals installiert zu haben. Laut Shodan sind derzeit mehr als 200.000 MongoDB-Instanzen im Internet zugänglich. Das ist jedoch nur die Spitze des Eisbergs.
Die interessantere (und gefährlichere) Frage ist, was innerhalb Ihres Netzwerks geschieht:
- MongoDB-Instanzen, die von jedem kompromittierten Host aus erreichbar sind
- Datenbanken, die an nicht standardmäßige Ports gebunden sind
- Dienste, die ohne Authentifizierungsannahmen ausgeführt werden
- Interne Datenbanken, die sich perfekt als Sprungbrett für laterale Bewegungen oder die Ausweitung von Berechtigungen eignen
Hier kommt es auf die Transparenz auf Netzwerkebene an – und hier glänzt die Vectra-Plattform.
Dank der umfassenden Netzwerktransparenz und den angereicherten Metadaten von Vectra verfügen wir bereits über das erforderliche Rohmaterial, um MongoDB überall aufzuspüren, unabhängig von Port, Protokoll oder Bereitstellungsmodell. Und wenn Metadaten nicht ausreichen, können wir mit Vectra Match Suricata) dank protokollbewusster Signaturen noch einen Schritt weiter gehen.
Lassen Sie uns das einmal genauer betrachten.
1. Eigenschaften einer MongoDB-Instanz im Netzwerk
Um MongoDB effektiv zu nutzen, müssen wir verstehen, wie es sich auf der Leitung verhält.
Standard-Netzwerkeigenschaften
Auf hoher Ebene ist MongoDB ein TCP-basiertes Client-Server-Protokoll.
Zu den gemeinsamen Merkmalen gehören:
- Standard-TCP-Port: 27017
- Gängige alternative Ports: 27018, 27019 oder beliebige hohe Ports in Container- und cloud
- Langlebige TCP-Sitzungen: Clients halten Verbindungen oft offen
- Bidirektionaler Anfrage-/Antwortverkehr: nicht nur kurze Bursts
Aber die portbasierte Erkennung allein ist anfällig – das wissen sowohl Angreifer als auch Administratoren.
MongoDB-Wire-Protokoll (Klartext)
Wenn TLS nicht aktiviert ist, ist der MongoDB-Datenverkehr vollständig sichtbar.
Wichtige Merkmale des MongoDB-Wire-Protokolls:
- Binärprotokoll mit einem Standard-Nachrichtenkopf
- Die Kopfzeilenfelder umfassen:
- Nachrichtenlänge
- Anfrage-ID
- Antwort auf ID
- OpCode (z. B. OP_MSG, OP_QUERY, Legacy-Operationen)
- Frühe Pakete enthalten oft:
- Client-Handshake (isMaster / hello)
- Treiber-Metadaten (Sprache, Version)
- Authentifizierungsaushandlung
Aus Sicht des Netzwerks ergibt sich daraus Folgendes:
- Serverantworten löschen
- Identifizierbare Protokollstruktur
- Vorhersehbare Anforderungsmuster während des Verbindungsaufbaus
Mit anderen Worten: Einfach zu identifizieren, selbst bei nicht standardmäßigen Ports.
MongoDB mit aktiviertem TLS
TLS macht die Sache komplizierter – aber es macht MongoDB nicht unsichtbar.
Wenn TLS aktiv ist:
- Die Nutzlast ist verschlüsselt.
- Der Inhalt des Protokolls ist ausgeblendet.
- Das Sitzungsverhalten und die Metadaten bleiben jedoch erhalten.
Was wir noch sehen:
- TCP-Ziel und -Quelle
- Port-Nutzung (auch wenn nicht standardmäßig)
- Sitzungsdauer
- Byteanzahl und Richtung
- Zertifikat-Metadaten (sofern verfügbar)
- Servername
- Emittent
- Wiederverwendung von Zertifikaten über Hosts hinweg
Dies ist von entscheidender Bedeutung, da die meisten realen Umgebungen gemischt sind:
- Einige MongoDB-Instanzen verwenden TLS.
- Andere tun dies nicht.
- Einige beginnen im Klartext und rüsten auf
- Einige verlassen sich auf interne Annahmen über ein „vertrauenswürdiges Netzwerk“.
Die Metadaten von Vectra machen diese Unterschiede sichtbar – ohne den Datenverkehr zu entschlüsseln.
Warum dies für MongoBleed wichtig ist
MongoBleed ist eine vor der Authentifizierung auftretende, über das Netzwerk erreichbare Schwachstelle.
Das bedeutet:
- Im Internet exponierte MongoDB = unmittelbares Risiko
- Intern erreichbare MongoDB = Goldgrube nach Kompromittierung
- TLS beseitigt die Ausnutzbarkeit nicht.
- Die Authentifizierung beseitigt nicht die Ausnutzbarkeit.
Wenn ein Angreifer eine Verbindung herstellen kann, kann er auch sondieren.
2. MongoDB-Instanzen mithilfe von Netzwerk-Metadaten suchen
Hier gehen wir von der Theorie zur Praxis über.
Vectra generiert kontinuierlich angereicherte Netzwerk-Metadaten, die es uns ermöglichen, MongoDB-Instanzen zu suchen , ohne auf Protokolle, Agenten oder Bestandsverzeichnisse angewiesen zu sein.
Internet-exponierte MongoDB-Instanzen finden
Wichtige Ansätze für die Jagd:
- Identifizieren Sie interne Hosts, die eingehende Verbindungen aus dem Internet akzeptieren.
- Filter auf:
- TCP-Dienste mit serverähnlichem Verhalten
- Langlebige Sitzungen
- Wiederholte eingehende Verbindungen von verschiedenen Quell-IPs
- Korrelieren mit:
- Bekannte Standardports von MongoDB
- Inbound-Datenverkehr mit hoher Entropie auf ungewöhnlichen Ports
- TLS-Zertifikate, die für mehrere MongoDB-Listener wiederverwendet werden
Das kommt sofort zum Vorschein:
- Vergessene cloud
- Testdatenbanken versehentlich offengelegt
- „Befristete“ Dienstleistungen, die dauerhaft wurden
Und im Gegensatz zu Shodan handelt es sich hierbei um Ihre tatsächliche Exposition und nicht um ein Scan-Ergebnis.
AUSWÄHLEN
id.resp_h,
resp_hostname.name,
COUNT(*) AS connection_count
FROM network.isession._all
WO id.resp_p = 27017
UND local_orig = FALSE
UND local_resp = TRUE
UND Zeitstempel ZWISCHEN date_add('day', -14, now()) UND now()
GROUP BY id.resp_h, resp_hostname.name
ORDER BY connection_count DESC
BEGRENZUNG 100
In diesem Szenario konzentrieren wir uns darauf, MongoDB-Server zu identifizieren, die über TLS laufen – unabhängig vom verwendeten TCP-Port. Da eine Überprüfung der Nutzdaten bei verschlüsseltem Datenverkehr nicht möglich ist, stützen wir uns auf TLS-Fingerprinting, insbesondere JA3 und JA4, die von der Vectra-Plattform für jede beobachtete TLS-Sitzung automatisch berechnet und in Netzwerk-Metadaten angereichert werden.
JA3 und JA4 ermitteln das Verhalten von TLS-Clients anhand von Hash-Eigenschaften des TLS-Handshakes, wie beispielsweise unterstützte Verschlüsselungssuiten, Erweiterungen und Protokollversionen. Ihre serverseitigen Pendants – JA3S und JA4S – erfassen den Fingerabdruck der TLS-Serverantwort und sind daher besonders nützlich, um Servertechnologien zu identifizieren, ohne den Datenverkehr zu entschlüsseln.
In der Praxis können wir so MongoDB-TLS-Server anhand ihrer TLS-Verhandlung erkennen, selbst wenn sie auf nicht standardmäßigen Ports laufen oder auf der Transportschicht nicht zu unterscheiden sind.
Es ist jedoch wichtig zu beachten, dass JA3S- und JA4S-Fingerabdrücke nicht global eindeutig sind. Ähnliche Fingerabdrücke können über verschiedene Serverstacks und Bibliotheken hinweg gemeinsam genutzt werden, was bedeutet, dass Kollisionen möglich sind und der Kontext weiterhin eine Rolle spielt.
Allerdings zeigen Tests mit mehreren MongoDB-Versionen, dass JA3S- und JA4S-Fingerabdrücke zwischen den Releases sehr konsistent sind, sodass sie in Kombination mit Netzwerkverhalten, Sitzungsmustern und endpoint ein zuverlässiges Signal darstellen.
Suche nach MongoDB-Servern auf nicht standardmäßigen Ports
Die Identifizierung von MongoDB-Servern, die nicht an einen bekannten Port gebunden sind, erfordert zusätzliche Analysen und Kontextinformationen. In diesen Fällen reicht eine einfache portbasierte Filterung nicht aus, und wir müssen uns auf übergeordnete Indikatoren stützen, die aus Netzwerk-Metadaten abgeleitet werden.
Ein effektiver Ansatz besteht darin, serverseitige Identifikatoren wie den Hostnamen des Responders oder die TLS Server Name Indication (SNI) zu untersuchen und nach Mustern zu suchen, die auf eine Datenbankinfrastruktur hindeuten. Hostnamen, die auf Datenbankrollen, Cluster, Shards oder Replikatsätze verweisen, können starke Hinweise darauf liefern, dass es sich bei dem betreffenden Dienst um ein MongoDB-Backend handelt – selbst wenn er auf einem unerwarteten Port lauscht.
SELECT id.orig_h, id.resp_h, id.resp_p, Servername, Verschlüsselung, Version, ja3s, ja4s, Zeitstempel
FROM network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
UND local_orig = FALSE
UND local_resp = TRUE
UND Zeitstempel ZWISCHEN date_add('day', -14, now()) UND now()
ORDER BY Zeitstempel DESC
BEGRENZUNG 1000
Wenn wir zusätzlich den Zielhafen berücksichtigen:
SELECT id.orig_h, id.resp_h, id.resp_p, Servername, Verschlüsselung, Version, ja3s, ja4s, Zeitstempel
FROM network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
UND id.resp_p = 27017
UND local_orig = FALSE
UND local_resp = TRUE
UND Zeitstempel ZWISCHEN date_add('day', -14, now()) UND now()
ORDER BY Zeitstempel DESC
BEGRENZUNG 1000
Hinweis: MongoDB wird nicht mit Standard-TLS-Zertifikaten oder privaten Schlüsseln ausgeliefert. Wenn TLS aktiviert ist, müssen Administratoren ausdrücklich ihre eigenen Zertifikate und Schlüssel bereitstellen. Darüber hinaus verwendet MongoDB standardmäßig TLS 1.3, wenn TLS aktiv ist, was bedeutet, dass herkömmliche Zertifikate und x.509-Metadaten nicht in der Netzwerktelemetrie angezeigt werden.
Interne MongoDB-Instanzen finden
Interne MongoDB-Datenbanken sind oft gefährlicher als externe Datenlecks.
Warum?
- Angreifer müssen das Internet nicht scannen.
- Kompromittierte Hosts können frei auflisten
- Interne Datenbanken sind oft nicht ausreichend gesichert.
Zu den Jagdmustern gehören:
- Ost-West-TCP-Dienste, die als persistente Server fungieren
- Wiederholte Verbindungen aus Anwendungsebenen
- Bekannte Verhaltensmuster von MongoDB (Sitzungsdauer, Anforderungsfrequenz)
- Dienste, die von vielen verschiedenen internen Hosts erreichbar sind
Dies zeigt schnell:
- Von überall aus erreichbare Datenbanken
- Probleme beim Entwurf flacher Netzwerke
- Ideale Ziele für seitliche Bewegungen
AUSWÄHLEN
id.resp_h,
resp_hostname.name,
COUNT(*) AS connection_count
FROM network.isession._all
WO id.resp_p = 27017
UND local_orig = TRUE
UND local_resp = TRUE
UND Zeitstempel ZWISCHEN date_add('day', -14, now()) UND now()
GROUP BY id.resp_h, resp_hostname.name
ORDER BY connection_count DESC
BEGRENZUNG 100
Auch hier können wir JA3S und JA4S verwenden:
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
FROM network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
UND local_orig = TRUE
UND local_resp = TRUE
UND Zeitstempel ZWISCHEN date_add('day', -14, now()) UND now()
ORDER BY Zeitstempel DESC
BEGRENZUNG 1000
Wenn wir zusätzlich den Zielhafen berücksichtigen:
SELECT id.orig_h, id.resp_h, id.resp_p, Servername, Verschlüsselung, Version, ja3s, ja4s, Zeitstempel
FROM network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
UND id.resp_p = 27017
UND local_orig = TRUE
UND local_resp = TRUE
UND Zeitstempel ZWISCHEN date_add('day', -14, now()) UND now()
ORDER BY Zeitstempel DESC
BEGRENZUNG 1000
Auf der Suche nach potenziellen MongoBleed-Exploits
Auch ohne Sichtbarkeit der Nutzlast hinterlassen Ausnutzungsversuche Spuren.
Was Sie beachten sollten:
- Ungewöhnliche Verbindungsversuche zu MongoDB-Diensten
- Kurzlebige, wiederholte Verbindungen von unerwarteten Hosts
- Neues Verhalten des MongoDB-Clients bei Systemen, die ihn zuvor noch nie verwendet haben
- Plötzliche Spitzen bei den Verbindungen
- MongoDB-Datenverkehr, der von Nicht-Anwendungssystemen stammt (Workstations, Jump-Hosts, kompromittierte Server)
Dies sind klassische Anzeichen für:
- Aufklärungsarbeit
- Exploit-Test
- Automatisierte Speicherprüfung
Die entitätszentrierte Sichtweise von Vectra macht dies schnell deutlich – insbesondere in Kombination mit Identitäts- und Hostkontext.
AUSWÄHLEN
id.orig_h,
id.resp_h,
id.resp_p,
Dauer,
conn_state,
Zeitstempel,
orig_ip_bytes,
Antwort-IP-Bytes
FROM network.isession._all
WHERE conn_state IN ('SF')
AND duration < 5000
UND orig_ip_bytes = 44
UND first_orig_resp_data_pkt = 'LAAAAAEAAAAAAAAA3AcAAA=='
UND Zeitstempel ZWISCHEN date_add('day', -14, now()) UND now()
ORDER BY Zeitstempel DESC
BEGRENZUNG 100
Diese Abfrage ist ein Beispiel dafür, wie man nach unverschlüsseltem MongoDB-Datenverkehr sucht, bei dem das erste Paket eine Größe von 44 Byte hat und einen MongoDB-Header enthält, der eine komprimierte Nachricht definiert.
Das MongoDB-Header-Format ist wie folgt definiert:
Der veröffentlichte PoC verwendet eine Länge von 44 Byte mit einem Opcode von 2012 (komprimierte Daten).
3. Vertiefung mit Vectra Match Suricata)
Metadaten bringen uns weit. Mit Vectra Match wir präzise arbeiten.
Mithilfe von Suricata-basierten Signaturen können wir MongoDB-Datenverkehr und Ausnutzungsmuster eindeutig identifizieren. Der Vectra Match basiert auf dem kommerziellen ETPro-Regelsatz und enthält die folgenden zwei Regeln für MongoBleed. Die erste dient zur Erkennung eingehender Authentifizierungsversuche, die zweite zur Erkennung des Exploits selbst. Beide sind im Vectra Match Ruleset enthalten.
Erkennen potenzieller Exploit-Nutzung
Speziell für MongoBleed können Signaturen auf Folgendes abzielen:
- Fehlerhafte oder abnormale Protokoll-Längen
- Wiederholte Handshake-Versuche ohne Authentifizierung
- Protokollanomalien, die mit Versuchen der Speicheroffenlegung übereinstimmen
- Hochfrequentes Sondierungsverhalten gegenüber MongoDB-Diensten
Dies stützt sich nicht allein auf CVE-spezifische Payloads, sondern konzentriert sich auf das Verhalten, das für Angreifer weitaus schwieriger zu umgehen ist.
alert tcp any any -> $HOME_NET 27017 (msg:"ET INFO MongoDB SASL-Authentifizierung erkannt"; flow:established,to_server; flowbits:set,ET.MongoDB_Auth_Attempt; flowbits:noalert; content:"|dd 07 00 00|"; offset:12; depth:4; content:"saslstart"; fast_pattern; nocase; distance:0; reference:url,www.alienfactory.co.uk/articles/mongodb-scramsha1-over-sasl; classtype:misc-activity; sid:2066500; rev:1; metadata:affected_product MongoDB, attack_target Server, created_at 2025_12_29, deployment Perimeter, confidence High, signature_severity Informational, updated_at 2025_12_29; target:dest_ip;)
alert tcp any any -> $HOME_NET 27017 (msg:"ET EXPLOIT MongoDB Unauthenticated Memory Leak (CVE-2025-14847)"; flow:established,to_server; flowbits:isnotset,ET.MongoDB_Auth_Attempt; content:"|dc 07 00 00 dd 07 00 00|"; fast_pattern; offset:12; depth:8; content:"|02|"; distance:4; within:1; threshold:type threshold, track by_src, count 10, seconds 120; reference:url,bigdata.2minutestreaming.com/p/mongobleed-explained-simply; reference:cve,2025-14847; classtype:attempted-admin; sid:2066501; rev:1; metadata:betroffenes_Produkt MongoDB, Angriffsziel Server, erstellt_am 2025_12_29, cve CVE_2025_14847, Bereitstellung Perimeter, Bereitstellung Intern, Vertrauenswürdigkeit Niedrig, signature_severity Schwerwiegend, aktualisiert_am 2025_12_29; Ziel:dest_ip;)
Klartext, TLS und nicht standardmäßige Ports – abgedeckt
Bei all diesen Jagden ist die wichtigste Erkenntnis einfach:
- Klartext-MongoDB: Protokoll + Metadaten + Signaturen
- TLS MongoDB: Metadaten + Verhaltensanalyse + Zertifikate
- Nicht standardmäßige Ports: Verhalten schlägt Ports jedes Mal
Angreifern ist es egal, auf welchem Port MongoDB läuft – und Verteidigern sollte es das auch sein.
Was soll man melden und was soll man suchen?
Rufen Sie den Bereitschaftsdienst an, wenn
- Das mit dem Internet verbundene MongoDB hat eingehende Bursts von unbekannten IPs.
- Interne MongoDB-Server erhalten „scannerähnliche“ Verbindungsstürme.
- Neue Clients beginnen, das MongoDB-Protokoll auf ungewöhnlichen Ports zu verwenden.
Jagen, wenn
- Sie sehen das MongoDB-Protokoll auf nicht standardmäßigen Ports (Tier 2).
- Sie sehen Authentifizierungsversuche aus ungewöhnlichen Quellen (Tier 3).
- Sie sehen einen Anstieg kurzlebiger Verbindungen, auch ohne Sichtbarkeit der Nutzlast (Stufe 2).
Abmilderung (da Erkennung kein Ersatz für Patching ist)
Die Fehlerbehebungsanleitung von MongoDB ist einfach: Führen Sie ein Upgrade auf die korrigierten Versionen durch (8.2.3 / 8.0.17 / 7.0.28 / 6.0.27 / 5.0.32 / 4.4.30). (jira.mongodb.org)
NVD fasst die Schwachstelle als Längenfeld-Diskrepanz in zlib-Headern zusammen, die nicht authentifizierte Heap-Lesevorgänge ermöglicht. (NVD)
Es gibt einen öffentlichen PoC, der den Aufwand für Angreifer verringert. (GitHub)
Warum ist das wichtig?
MongoBleed ist nur die jüngste Erinnerung daran, dass Datenbanken keine passive Infrastruktur sind. Sie sind aktive Angriffsflächen.
Wenn Sie nicht antworten können:
- Wo läuft MongoDB?
- Wer kann es erreichen?
- Wer berührt es gerade?
…dann wird Ihnen das Patchen allein nicht helfen.
Die Vectra AI bietet Ihnen die nötige Transparenz, um diese Fragen zu beantworten – und die Such- und Erkennungsfunktionen, um zu handeln, bevor „Bleeding Memory“ zu einer vollständigen Sicherheitsverletzung führt.
Möchten Sie mehr erfahren? Nehmen Sie an unserer nächsten Attack Lab-Sitzung teil, in der wir Ihnen erklären, wie MongoBleed funktioniert und wie Sie Risiken in MongoDB schnell aufspüren und validieren können: LINK ZUR REGISTRIERUNGSSEITE