MongoBleed Detector

Offline MongoDB-Analyse-Tool für CVE-2025-14847 (MongoBleed)

Ein eigenständiges Linux-Kommandozeilen-Tool, das MongoDB-Daten analysiert, um eine wahrscheinliche Ausnutzung von CVE-2025-14847 mithilfe mehrerer Erkennungsmodule zu identifizieren.

Inhaltsverzeichnis

• Übersicht
• Erkennungsmodule
• Anforderungen
• Installation
• Zwei Betriebsmodi
• Modus 1: Lokale Analyse
• Modus 2: Remote-Erfassung
• Kommandozeilenoptionen
• Vertrauenswürdigkeitsstufen
• Beispielausgabe
• Testen
• Einschränkungen und Hinweise
• Referenzen und Danksagungen
• Lizenz

Übersicht

MongoBleed (CVE-2025-14847) ist eine Schwachstelle zur Offenlegung von Speicherinhalten in der zlib-Dekomprimierung von MongoDB, die es Angreifern ermöglicht, sensible Daten – Anmeldeinformationen, Sitzungstoken, personenbezogene Daten (PII) – direkt aus dem Serverspeicher auszulesen, ohne sich zu authentifizieren.

Dieses Tool hilft Incident-Respondern, Ausnutzungsversuche mithilfe mehrerer Beweisquellen zu erkennen:

• Modul A: Log-Korrelation (Verbindungsereignisse, fehlende Metadaten)
• Modul B1: Analyse der Assert-Zähler (serverStatus.asserts-Momentaufnahmen)
• Modul B2: FTDC-Spike-Erkennung (diagnostic.data-Zeitreihen)

Hauptmerkmale

• Multi-Modul-Erkennung – Korreliert mehrere Datenquellen für höhere Sicherheit
• Offline & Agentenlos – Keine Netzwerkverbindung während der Analyse erforderlich
• Auto-Erkennung – Erkennt automatisch verfügbare Datenquellen
• Remote-Erfassung – Sammelt Daten von mehreren Hosts per SSH
• Kombinierte Bewertung – HIGH/MEDIUM/LOW-Verdikte
• Streaming-Verarbeitung – Effiziente Verarbeitung großer Logdateien

Erkennungsmodule

Modul A: Log-Korrelation

Analysiert MongoDB-JSON-Logs, um Ausnutzungsmuster zu erkennen:

Wichtige Erkenntnis: Legitime MongoDB-Treiber senden immer Client-Metadaten. Der MongoBleed-Exploit stellt eine Verbindung her, extrahiert Speicher und trennt die Verbindung – sendet jedoch niemals Metadaten.

Modul B1: Assert-Zähler

Analysiert Momentaufnahmen von db.serverStatus().asserts, um ungewöhnliche Muster in den asserts.user-Zählern zu erkennen:

• Mehrere Momentaufnahmen: Vergleicht Momentaufnahmen im Zeitverlauf, um plötzliche Anstiege der Benutzer-Asserts zu erkennen.
• Einzel-Momentaufnahmen-Heuristik: Wenn nur eine Momentaufnahme verfügbar ist, erkennt es verdächtige Muster durch Vergleich von asserts.user mit anderen Assert-Typen. Wenn Benutzer-Asserts überproportional hoch sind (Verhältnis ≥250x) oder alle anderen Typen null sind, wird dies als verdächtig eingestuft (MEDIUM-Vertrauen).

Hinweis: Kumulative Zähler können falsch positive Ergebnisse liefern. Für beste Ergebnisse in Kombination mit FTDC (Modul B2) verwenden.

Modul B2: FTDC-Spike-Erkennung

Analysiert die Full-Time Diagnostic Data Capture (FTDC)-Dateien von MongoDB, um zeitlich lokalisierte Spitzen in Assert-Zählern zu erkennen. FTDC testet serverStatus regelmäßig, was eine präzise zeitliche Zuordnung möglicher Angriffe ermöglicht.

Anforderungen

Shell-Skript (mongobleed-detector.sh)

• Linux oder macOS (bash 4+)
• jq – JSON-Prozessor
• awk (gawk empfohlen)
• gzip – Für unterstützte komprimierte Logs

Python-Komponenten (optional, für FTDC-Dekodierung)

• Python 3.8+
• pymongo – Für FTDC-Dateidekodierung

Remote-Scanner (mongobleed-remote.py)

• Python 3.8+
• Nativer SSH-Client (ssh, scp-Befehle)
• Keine zusätzlichen Python-Pakete für den Basisbetrieb erforderlich

Abhängigkeiten installieren

# Shell script dependencies
# Debian/Ubuntu
apt-get install jq gawk gzip

# RHEL/CentOS/Fedora
dnf install jq gawk gzip

# macOS
brew install jq gawk

# Python dependencies (for FTDC decoding)
pip install -r requirements.txt

Installation

# Clone the repository
git clone https://github.com/your-org/mongobleed-detector.git
cd mongobleed-detector

# Make scripts executable
chmod +x mongobleed-detector.sh
chmod +x mongobleed-remote.py
chmod +x ftdc-decode.py

# Install Python dependencies (optional, for FTDC support)
pip install -r requirements.txt

Zwei Betriebsmodi

Modus 1: Lokale Analyse

Analysiert Daten, die manuell von MongoDB-Hosts gesammelt wurden.

Modus 2: Remote-Erfassung

Sammelt automatisch Daten von mehreren Hosts per SSH und analysiert sie dann lokal.

Modus 1: Lokale Analyse

Schritt 1: Daten sammeln

Sammeln Sie Daten von Ihren MongoDB-Hosts und organisieren Sie sie in dieser Struktur:

./collected-data/
├── logs/                    # MongoDB-JSON-Logs
│   ├── mongod.log
│   ├── mongod.log.1
│   └── mongod.log.2.gz
├── assert-counts/           # serverStatus().asserts-Momentaufnahmen
│   ├── asserts-2025-01-01.json
│   └── asserts-2025-01-02.json
└── ftdc-files/              # FTDC diagnostic.data-Inhalte
    ├── metrics.2025-01-02T10-00-00Z-00000
    └── metrics.interim

Logs sammeln

# Copy from remote host
scp user@mongohost:/var/log/mongodb/mongod.log* ./collected-data/logs/

Assert-Zähler sammeln

Führen Sie diesen Befehl auf dem MongoDB-Host aus (erfordert mongosh-Zugriff):

mongosh --quiet --eval 'JSON.stringify({
  timestamp: new Date().toISOString(),
  hostname: db.hostInfo().system.hostname,
  asserts: db.serverStatus().asserts,
  uptime: db.serverStatus().uptime
})' > asserts-$(date +%Y%m%d-%H%M%S).json

Kopieren Sie die resultierende JSON-Datei nach ./collected-data/assert-counts/.

Tipp: Führen Sie diesen Befehl mehrmals aus (z. B. stündlich), um eine Basislinie zu erstellen und Spitzen zu erkennen.

FTDC-Dateien sammeln

FTDC-Dateien befinden sich unter:

• mongod: <storage.dbPath>/diagnostic.data/ (üblich /var/lib/mongodb/diagnostic.data/)
• mongos: Abgeleitet von systemLog.path (z. B. /var/log/mongodb/mongos.diagnostic.data/)

# Copy FTDC files (may require sudo)
sudo cp /var/lib/mongodb/diagnostic.data/metrics.* ./collected-data/ftdc-files/

Schritt 2: Analyse ausführen

# Auto-discovery mode - analyzes all available data
./mongobleed-detector.sh --data-dir ./collected-data/

# With custom thresholds
./mongobleed-detector.sh --data-dir ./collected-data/ \
    -t 1440 \              # 24-hour lookback
    -c 50 \                # Lower connection threshold
    --spike-threshold 50   # Lower spike threshold

Legacy-Modus (nur Logs)

Aus Gründen der Rückwärtskompatibilität können Sie Logs auch direkt analysieren:

# Scan default paths
./mongobleed-detector.sh

# Scan specific log files
./mongobleed-detector.sh -p /path/to/logs/*.json

# Forensic mode (analyze multiple hosts)
./mongobleed-detector.sh --forensic-dir /evidence/

Modus 2: Remote-Erfassung

Sammelt automatisch Daten von mehreren Hosts und analysiert sie:

# Create hosts file
cat > hosts.txt << EOF
mongo-prod-01.example.com
mongo-prod-02.example.com
mongo-staging.example.com
EOF

# Collect and analyze
./mongobleed-remote.py --hosts-file hosts.txt --user admin --output-dir ./collected-data/

Optionen des Remote-Scanners

# Use specific SSH key
./mongobleed-remote.py --hosts-file hosts.txt --user admin --key ~/.ssh/mongodb_key

# Parallel execution
./mongobleed-remote.py --hosts-file hosts.txt --user admin --parallel 10

# Skip FTDC collection (faster)
./mongobleed-remote.py --hosts-file hosts.txt --user admin --skip-ftdc

# Collect only, analyze later
./mongobleed-remote.py --hosts-file hosts.txt --user admin --collect-only

# Pass SSH options (e.g., jump host)
./mongobleed-remote.py --hosts-file hosts.txt --user admin \
    -o "ProxyJump=bastion.example.com"

# Use sudo for privileged file access (FTDC files are often restricted)
./mongobleed-remote.py --hosts-file hosts.txt --user admin --sudo

# Debug mode to troubleshoot connection issues
./mongobleed-remote.py --hosts-file hosts.txt --user admin --debug

Hinweis zu FTDC-Berechtigungen: FTDC-Dateien in /var/lib/mongodb/diagnostic.data/ gehören normalerweise dem Benutzer mongodb und sind für normale Benutzer nicht lesbar. Wenn Sie Warnungen zu „FTDC Permission Issues“ sehen, verwenden Sie das Flag --sudo. Dies setzt voraus, dass der Remote-Benutzer über passwortlosen sudo-Zugriff verfügt (NOPASSWD in sudoers).

Was gesammelt wird

Kommandozeilenoptionen

mongobleed-detector.sh

mongobleed-remote.py

Exit-Codes

Vertrauenswürdigkeitsstufen

Das Tool liefert ein kombiniertes Vertrauensvotum basierend auf allen verfügbaren Beweisen:

Modulspezifische Risikostufen

Für die Log-Korrelation (Modul A) werden einzelne IPs wie folgt klassifiziert:

Beispielausgabe

INFO: Auto-discovery mode: analyzing ./collected-data/
INFO: Module A: Analyzing 3 log file(s)...
INFO: Module B1: Analyzing assert-counts...

╔══════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗
║                              MongoBleed (CVE-2025-14847) Detection Results                                       ║
╚══════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝

Module Status:
  [✓] Module A (Log Correlation): 3 log file(s) found
  [✓] Module B1 (Assert Counts): 4 snapshot(s) found
  [−] Module B2 (FTDC Spikes): No FTDC files or decoder unavailable

Analysis Parameters:
  Time Window:        4320 minutes
  Connection Thresh:  100
  Burst Rate Thresh:  400/min
  Metadata Rate:      0.10
  Spike Threshold:    100
  User Ratio Thresh:  250x

Module A - Log Correlation Findings:

Risk     SourceIP                                  ConnCount  MetaCount  DiscCount    MetaRate%    BurstRate/m FirstSeen (UTC)        LastSeen (UTC)        
-------- ---------------------------------------- ---------- ---------- ---------- ------------ -------------- ---------------------- ----------------------
HIGH     137.137.137.137                                8172          0       8172        0.00%         490.32 2025-12-27T12:55:52Z   2025-12-27T13:12:32Z  

Module B1 - Assert Counts Analysis:
  Analyzed 4 snapshots from 2025-01-01T10:00:00Z to 2025-01-01T11:30:00Z
    asserts.user: 100 -> 860 (delta: 760)
  SPIKE DETECTED: 2025-01-01T10:30:00Z to 2025-01-01T11:00:00Z
    Delta: +740 user asserts (110 -> 850)

═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Combined Verdict:
  MEDIUM CONFIDENCE - Investigation recommended
    - Suspicious connection patterns but FTDC data unavailable for correlation

⚠ IMPORTANT: If exploitation is confirmed, patching alone is insufficient.
  - Rotate all credentials that may have been exposed
  - Review accessed data for sensitive information disclosure
  - Check for lateral movement from affected systems
  - Preserve logs for forensic analysis

Caveats:
  - Connection metadata absence is PoC-specific and can be evaded
  - Assertion counters are cumulative - false positives possible without baseline
  - FTDC provides timing but not perfect attribution
  - Patch + rotate secrets remains mandatory regardless of detection results

Testen

Das Repository enthält eine Testsuite zur Validierung des Detektors.

Beispielhafte echte Daten

Das Verzeichnis example-data/ enthält echte Daten einer MongoDB 8.0.16-Instanz, die mit dem MongoBleed-PoC angegriffen wurde:

example-data/
├── logs/                    # Echte MongoDB-Logs mit Angriffsmustern
│   ├── mongod.log
│   └── mongod.log.1.gz
├── assert-counts/           # Post-Angriff serverStatus().asserts-Momentaufnahme
│   └── asserts-post-attack.json
└── ftdc-files/              # Echte FTDC-Diagnosedatendateien
    └── metrics.*

Diese Daten zeigen:

• 16.344 Verbindungen vom Angreifer-IP 137.137.137.137 mit 0 % Metadaten
• 37.384 Benutzer-Asserts, die während des Angriffs angesammelt wurden
• FTDC-Dateien, die das Angriffsfenster abdecken

Synthetische Testdaten generieren

./test/generate-test-logs.sh

Dies erstellt zusätzliche synthetische Testdaten mit verschiedenen Mustern:

• Logdateien mit HIGH/MEDIUM/LOW/INFO-Risikomustern
• Assert-Counts-JSON-Momentaufnahmen (mit und ohne Spitzen)
• Randfälle (IPv6, fehlerhafte Eingabe usw.)

Tests ausführen

./test/test-detector.sh

Erwartete Ausgabe:

╔════════════════════════════════════════════════════════╗
║       MongoBleed Detector Test Suite                   ║
╚════════════════════════════════════════════════════════╝

Module A Tests (Log Correlation):
✓ PASS: Exit code is 1 (findings detected)
✓ PASS: Detected source IP 137.137.137.137
...

Module B1 Tests (Assert Counts):
✓ PASS: Shows Module B1 status
✓ PASS: Detected assert spike
...

Auto-Discovery Mode Tests:
✓ PASS: Shows Module A status
✓ PASS: Shows combined verdict
...

Results:
  Passed: 24
  Failed: 0

All tests passed!

Einschränkungen und Hinweise

⚠️ Wichtige Einschränkungen

Erkennungseinschränkungen

1. PoC-spezifische Erkennung: Die Erkennung fehlender Metadaten basiert auf dem bekannten Verhalten des MongoBleed-PoC. Ein ausgefeilter Angreifer könnte den Exploit modifizieren, um gefälschte Metadaten zu senden, was jedoch die Ausnutzungsgeschwindigkeit verringern würde.

2. Kumulative Zähler: asserts.user ist seit dem Neustart von mongod kumulativ. Ohne Basis-Momentaufnahmen können hohe Werte bei langlebigen Instanzen normal sein. Mehrere Momentaufnahmen im Zeitverlauf verbessern die Genauigkeit erheblich.

3. FTDC-Zeitsteuerung: FTDC liefert zeitliche Informationen, aber keine perfekte Zuordnung. Für beste Ergebnisse in Verbindung mit Log-Korrelation verwenden.

4. Log-Aufbewahrung: Es können nur vorhandene Logs analysiert werden. Aggressive Rotation oder das Löschen von Logs durch Angreifer zerstört Beweise.

Technische Anforderungen

1. JSON-Protokollierung erforderlich: MongoDB 4.4+ protokolliert standardmäßig im JSON-Format. Legacy-Textlogs werden nicht unterstützt.

2. FTDC-Decoder: Die FTDC-Dekodierung erfordert Python 3 mit pymongo. Ohne diesen ist Modul B2 nicht verfügbar.

3. mongosh-Zugriff: Zum Sammeln von Assert-Zählern ist mongosh mit entsprechenden Berechtigungen erforderlich.

Maßnahmen nach der Erkennung

Wenn HIGH- oder MEDIUM-Ergebnisse bestätigt werden:

1. Beweise sichern – Kopieren Sie Logs, bevor sie rotieren
2. Anmeldeinformationen rotieren – Rotieren Sie alle MongoDB-Anmeldeinformationen und alle Geheimnisse, die möglicherweise im Speicher waren
3. Daten prüfen – Bewerten Sie, welche sensiblen Daten möglicherweise offengelegt wurden
4. Laterale Bewegung – Prüfen Sie auf Bewegungen des Angreifers zu anderen Systemen
5. Sofort patchen – Wenden Sie MongoDB-Sicherheitsupdates an
6. Melden – Befolgen Sie Ihre Incident-Response-Verfahren

Referenzen und Danksagungen

Erkennungsforschung

Die Erkennungslogik in diesem Tool basiert auf Forschung von Eric Capuano und Tamir Zimerman:

• Hunting MongoBleed (CVE-2025-14847) – Eric Capuanos Artikel über die Schwachstelle und Erkennungsmethodik
• A Different MongoBleed Perspective – Tamir Zimermans Analyse der Assert-basierten Erkennung

MongoDB-Dokumentation

• serverStatus-Befehl – Dokumentation des asserts-Feldes
• Full Time Diagnostic Data Capture – FTDC-Speicherorte
• What is MongoDB FTDC – Hintergrund zum FTDC-Format

Betroffene Versionen

Lizenz

Siehe Datei LICENSE.

Mitwirken

Beiträge sind willkommen! Bitte reichen Sie Issues und Pull-Requests ein.

Wenn Sie dieses Tool mit Produktionsdaten testen, freuen wir uns besonders über Feedback zu:

• Falsch-Positiv-Raten
• Legitimen Traffic-Mustern
• Randfällen oder Parsing-Fehlern
• FTDC-Dekodierungsproblemen