MongoBleed Detector

Outil d'analyse MongoDB hors ligne pour CVE-2025-14847 (MongoBleed)

Un outil Linux autonome en ligne de commande qui analyse les données MongoDB afin d'identifier une exploitation probable de CVE-2025-14847 à l'aide de multiples modules de détection.

Table des matières

• Aperçu
• Modules de détection
• Prérequis
• Installation
• Deux modes de fonctionnement
• Mode 1: Analyse locale
• Mode 2: Collecte à distance
• Options de la ligne de commande
• Niveaux de confiance
• Exemple de sortie
• Tests
• Mises en garde et limites
• Références et crédits
• Licence
• Contribution

Aperçu

MongoBleed (CVE-2025-14847) est une vulnérabilité de divulgation de mémoire dans la décompression zlib de MongoDB qui permet aux attaquants d'extraire des données sensibles — identifiants, jetons de session, données personnelles — directement depuis la mémoire du serveur sans authentification.

Cet outil aide les répondants aux incidents à détecter les tentatives d'exploitation à partir de multiples sources de preuves :

• Module A : Corrélation de journaux (événements de connexion, absence de métadonnées)
• Module B1 : Analyse des compteurs d'assertions (instantanés serverStatus.asserts)
• Module B2 : Détection de pics FTDC (séries temporelles diagnostic.data)

Fonctionnalités clés

• Détection multi-module - Corrèle plusieurs sources de données pour une plus grande fiabilité
• Hors ligne et sans agent - Aucune connectivité réseau requise pendant l'analyse
• Découverte automatique - Détecte automatiquement les sources de données disponibles
• Collecte à distance - Collecte les données de plusieurs hôtes via SSH
• Score combiné - Verdicts de confiance ÉLEVÉ/MOYEN/FAIBLE
• Traitement en flux - Gère efficacement les grands fichiers journaux

Modules de détection

Module A : Corrélation de journaux

Analyse les journaux JSON MongoDB pour détecter les schémas d'exploitation :

Point clé : Les pilotes MongoDB légitimes envoient toujours des métadonnées client. L'exploit MongoBleed se connecte, extrait la mémoire et se déconnecte — mais n'envoie jamais de métadonnées.

Module B1 : Compteurs d'assertions

Analyse les instantanés de db.serverStatus().asserts pour détecter des schémas inhabituels dans les compteurs asserts.user :

• Instantanés multiples : Compare les instantanés dans le temps pour détecter des pics soudains d'assertions utilisateur
• Heuristique d'instantané unique : Lorsqu'un seul instantané est disponible, détecte les schémas suspects en comparant asserts.user aux autres types d'assertions. Si les assertions utilisateur sont disproportionnellement élevées (ratio ≥250x) ou si tous les autres types sont à zéro, signale comme suspect (confiance MOYENNE)

Remarque : Les compteurs cumulés peuvent produire des faux positifs. À utiliser en combinaison avec FTDC (module B2) pour de meilleurs résultats.

Module B2 : Détection de pics FTDC

Analyse les fichiers de capture de données de diagnostic en continu (FTDC) de MongoDB pour détecter des pics localisés dans le temps des compteurs d'assertions. FTDC échantillonne l'état du serveur périodiquement, permettant un minutage précis des attaques potentielles.

Prérequis

Script shell (mongobleed-detector.sh)

• Linux ou macOS (bash 4+)
• jq - Processeur JSON
• awk (gawk recommandé)
• gzip - Pour la prise en charge des journaux compressés

Composants Python (facultatifs, pour le décodage FTDC)

• Python 3.8+
• pymongo - Pour le décodage des fichiers FTDC

Scanneur à distance (mongobleed-remote.py)

• Python 3.8+
• Client SSH natif (commandes ssh, scp)
• Aucun paquet Python supplémentaire requis pour le fonctionnement de base

Installer les dépendances

# 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

Deux modes de fonctionnement

Mode 1: Analyse locale

Analysez les données collectées manuellement à partir des hôtes MongoDB.

Mode 2: Collecte à distance

Collectez automatiquement les données de plusieurs hôtes via SSH, puis analysez-les localement.

Mode 1: Analyse locale

Étape 1 : Collecter les données

Collectez les données de vos hôtes MongoDB et organisez-les selon cette structure :

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

Collecte des journaux

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

Collecte des compteurs d'assertions

Exécutez cette commande sur l'hôte MongoDB (nécessite un accès mongosh) :

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

Copiez le fichier JSON résultant dans ./collected-data/assert-counts/.

Astuce : Exécutez cette commande plusieurs fois (par exemple, toutes les heures) pour établir une référence et détecter les pics.

Collecte des fichiers FTDC

Les fichiers FTDC se trouvent à :

• mongod : <storage.dbPath>/diagnostic.data/ (généralement /var/lib/mongodb/diagnostic.data/)
• mongos : Dérivé de systemLog.path (par exemple, /var/log/mongodb/mongos.diagnostic.data/)

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

Étape 2 : Exécuter l'analyse

# 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

Mode hérité (journaux uniquement)

Pour la compatibilité ascendante, vous pouvez toujours analyser les journaux directement :

# 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/

Mode 2: Collecte à distance

Collectez automatiquement les données de plusieurs hôtes et analysez-les :

# 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/

Options du scanneur à distance

# 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

Remarque sur les permissions FTDC : Les fichiers FTDC dans /var/lib/mongodb/diagnostic.data/ appartiennent généralement à l'utilisateur mongodb et ne sont pas lisibles par les utilisateurs ordinaires. Si vous voyez des avertissements « Problèmes de permission FTDC », utilisez l'option --sudo. Cela nécessite que l'utilisateur distant dispose d'un accès sudo sans mot de passe (NOPASSWD dans sudoers).

Ce qui est collecté

Options de la ligne de commande

mongobleed-detector.sh

mongobleed-remote.py

Codes de sortie

Niveaux de confiance

L'outil fournit un verdict de confiance combiné basé sur toutes les preuves disponibles :

Niveaux de risque par module

Pour la corrélation de journaux (module A), les IP individuelles sont classées :

Exemple de sortie

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

Tests

Données d'exemple réelles

Le répertoire example-data/ contient des données réelles provenant d'une instance MongoDB 8.0.16 attaquée à l'aide du PoC MongoBleed :

example-data/
├── logs/                    # Real MongoDB logs with attack patterns
│   ├── mongod.log
│   └── mongod.log.1.gz
├── assert-counts/           # Post-attack serverStatus().asserts snapshot
│   └── asserts-post-attack.json
└── ftdc-files/              # Real FTDC diagnostic data files
    └── metrics.*

Ces données montrent :

• 16 344 connexions depuis l'IP de l'attaquant 137.137.137.137 avec 0 % de métadonnées
• 37 384 assertions utilisateur accumulées pendant l'attaque
• Fichiers FTDC couvrant la fenêtre de l'attaque

Générer des données de test synthétiques

./test/generate-test-logs.sh

Cela crée des données de test synthétiques supplémentaires avec divers schémas :

• Fichiers journaux avec des schémas de risque ÉLEVÉ/MOYEN/FAIBLE/INFO
• Instantanés JSON des compteurs d'assertions (avec et sans pics)
• Cas limites (IPv6, entrée malformée, etc.)

Exécuter les tests

./test/test-detector.sh

Sortie attendue :

╔════════════════════════════════════════════════════════╗
║       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!

Mises en garde et limites

⚠️ Limitations importantes

Limites de détection

1. Détection spécifique au PoC : La détection de l'absence de métadonnées repose sur le comportement connu du PoC MongoBleed. Un attaquant sophistiqué pourrait modifier l'exploit pour envoyer de fausses métadonnées, mais cela réduirait la vitesse d'exploitation.
2. Compteurs cumulés : asserts.user est cumulé depuis le redémarrage de mongod. Sans instantanés de référence, des valeurs élevées peuvent être normales pour des instances fonctionnant depuis longtemps. Plusieurs instantanés dans le temps améliorent considérablement la précision.
3. Minutage FTDC : FTDC fournit des informations de minutage mais pas une attribution parfaite. À utiliser conjointement avec la corrélation de journaux pour de meilleurs résultats.
4. Conservation des journaux : Seuls les journaux existants peuvent être analysés. Une rotation agressive ou l'effacement des journaux par un attaquant détruira les preuves.

Exigences techniques

1. Journalisation JSON requise : MongoDB 4.4+ utilise les journaux JSON par défaut. Les journaux texte hérités ne sont pas pris en charge.
2. Décodeur FTDC : Le décodage FTDC nécessite Python 3 avec pymongo. Sans cela, le module B2 est indisponible.
3. Accès mongosh : La collecte des compteurs d'assertions nécessite mongosh avec les permissions appropriées.

Actions après détection

Si des résultats ÉLEVÉ ou MOYEN sont confirmés :

1. Préserver les preuves - Copiez les journaux avant leur rotation
2. Rotation des identifiants - Renouvelez tous les identifiants MongoDB et tous les secrets qui ont pu se trouver en mémoire
3. Examen des données - Évaluez quelles données sensibles ont pu être exposées
4. Mouvement latéral - Vérifiez si l'attaquant s'est déplacé vers d'autres systèmes
5. Corriger immédiatement - Appliquez les mises à jour de sécurité MongoDB
6. Signaler - Suivez vos procédures de réponse aux incidents

Références et crédits

Recherche sur la détection

La logique de détection de cet outil est basée sur les recherches d'Eric Capuano et de Tamir Zimerman :

• Hunting MongoBleed (CVE-2025-14847) - Article d'Eric Capuano sur la vulnérabilité et la méthodologie de détection
• A Different MongoBleed Perspective - Analyse par Tamir Zimerman de la détection basée sur les assertions

Documentation MongoDB

• Commande serverStatus - Documentation du champ asserts
• Capture de données de diagnostic en continu - Emplacements de stockage FTDC
• Qu'est-ce que MongoDB FTDC - Contexte du format FTDC

Versions concernées

Licence

Voir le fichier LICENSE.

Contribution

Les contributions sont les bienvenues ! N'hésitez pas à soumettre des issues et des pull requests.

Si vous testez cet outil sur des données de production, nous apprécierions particulièrement vos retours sur :

• Taux de faux positifs
• Schémas de trafic légitimes
• Cas limites ou échecs d'analyse
• Problèmes de décodage FTDC