La vulnerabilità è emersa pochi giorni prima di Natale e, nel peggiore dei casi, consentiva agli hacker non autenticati di leggere da remoto la memoria del server. Le correzioni sono già disponibili, ma il raggio d'azione è ampio: il problema riguarda praticamente tutte le versioni di MongoDB risalenti a quasi dieci anni fa.
Denominata MongoBleed (CVE-2025-14847), la falla è una vulnerabilità pre-autenticazione nel server MongoDB. Deriva da campi di lunghezza non corrispondenti nelle intestazioni del protocollo compresse con zlib, che possono causare il ritorno da parte del server di memoria heap non inizializzata a un client non autenticato. In parole povere: se un aggressore riesce a raggiungere un'istanza MongoDB attraverso la rete, può tentare di "svuotare" il contenuto della memoria senza nemmeno effettuare il login.
Il sistema di tracciamento dei problemi di MongoDB è esplicito riguardo alla risoluzione, esortando gli utenti ad aggiornare alle versioni corrette su tutti i rami supportati (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 o 4.4.30).
Ciò che rende MongoBleed particolarmente preoccupante è la facilità con cui è possibile sfruttarlo. È già disponibile una prova di concetto pubblica che richiede poco più dell'indirizzo IP di un server MongoDB raggiungibile. Da lì, gli aggressori possono setacciare la memoria trapelata alla ricerca di segreti di alto valore, tra cui credenziali di database memorizzate in chiaro, chiavi cloud e altro materiale sensibile. L'exploit è stato appositamente progettato per cercare proprio questo tipo di segreti, abbassando drasticamente la soglia per gli abusi nel mondo reale.
Trovare MongoDB ovunque: utilizzare Vectra per identificare esposizione, rischio laterale e sfruttamento
Prima di preoccuparti dello sfruttamento, devi rispondere a una domanda molto più fondamentale:
Dove viene effettivamente eseguito MongoDB nel mio ambiente?
Sembra banale. Ma non lo è.
Tra applicazioni legacy, shadow IT, cloud , carichi di lavoro containerizzati e database "temporanei" che in qualche modo sono diventati permanenti, MongoDB ha l'abitudine di spuntare in luoghi di cui nessuno ricorda di essere proprietario. Secondo Shodan, attualmente più di 200.000 istanze MongoDB sono esposte a Internet. Questa è solo la parte visibile dell'iceberg.
La domanda più interessante (e più pericolosa) è cosa sta succedendo all'interno della tua rete:
- Istanze MongoDB raggiungibili da qualsiasi host compromesso
- Database collegati a porte non standard
- Servizi in esecuzione senza presupposti di autenticazione
- Database interni che diventano trampolini di lancio perfetti per movimenti laterali o escalation dei privilegi
È qui che la visibilità a livello di rete diventa importante, ed è qui che la piattaforma Vectra dà il meglio di sé.
Grazie alla profonda visibilità di rete e ai metadati arricchiti di Vectra, disponiamo già della materia prima necessaria per individuare MongoDB ovunque, indipendentemente dalla porta, dal protocollo o dal modello di implementazione. E quando i metadati non sono sufficienti, Vectra Match Suricata) ci consente di fare un ulteriore passo avanti con le firme sensibili al protocollo.
Analizziamo la questione.
1. Caratteristiche di un'istanza MongoDB sulla rete
Per utilizzare MongoDB in modo efficace, è necessario comprendere come si comporta sulla rete.
Caratteristiche di rete predefinite
Ad alto livello, MongoDB è un protocollo client-server basato su TCP.
Le caratteristiche comuni includono:
- Porta TCP predefinita: 27017
- Porte alternative comuni: 27018, 27019 o porte arbitrarie elevate in cloud containerizzati cloud
- Sessioni TCP di lunga durata: i client spesso mantengono aperte le connessioni
- Traffico bidirezionale di richieste/risposte: non solo brevi raffiche
Ma il rilevamento basato sulle porte è di per sé fragile: sia gli hacker che gli amministratori lo sanno bene.
Protocollo Wire MongoDB (testo in chiaro)
Quando TLS non è abilitato, il traffico MongoDB è completamente visibile sulla rete.
Caratteristiche principali del protocollo wire MongoDB:
- Protocollo binario con intestazione di messaggio standard
- I campi dell'intestazione includono:
- Lunghezza del messaggio
- ID richiesta
- Risposta all'ID
- OpCode (ad esempio, OP_MSG, OP_QUERY, operazioni legacy)
- I primi pacchetti spesso contengono:
- Handshake client (isMaster / hello)
- Metadati del driver (lingua, versione)
- Negoziazione dell'autenticazione
Dal punto di vista della rete, questo ci dà:
- Risposte chiare del server
- Struttura del protocollo identificabile
- Modelli di richiesta prevedibili durante la configurazione della connessione
In altre parole: facile da identificare, anche su porte non standard.
MongoDB con TLS abilitato
Il TLS complica le cose, ma non rende MongoDB invisibile.
Quando TLS è attivo:
- Il carico utile è crittografato
- Il contenuto del protocollo è nascosto
- Ma il comportamento della sessione e i metadati rimangono
Quello che vediamo ancora:
- Destinazione e origine TCP
- Utilizzo delle porte (anche se non standard)
- Durata della sessione
- Conteggio dei byte e direzionalità
- Metadati del certificato (se disponibili)
- Nome server
- Emittente
- Riutilizzo dei certificati su più host
Questo è fondamentale, perché la maggior parte degli ambienti reali sono misti:
- Alcune istanze MongoDB utilizzano TLS
- Altri no
- Alcuni iniziano in chiaro e poi effettuano l'aggiornamento
- Alcuni si basano su ipotesi interne relative alla "rete affidabile"
I metadati di Vectra rendono visibili queste differenze, senza decriptare il traffico.
Perché è importante per MongoBleed
MongoBleed è una vulnerabilità pre-autenticazione raggiungibile dalla rete.
Ciò significa che:
- MongoDB esposto a Internet = rischio immediato
- MongoDB accessibile internamente = miniera d'oro post-compromissione
- TLS non elimina la vulnerabilità
- L'autenticazione non elimina la vulnerabilità
Se un aggressore riesce a connettersi, può effettuare una sonda.
2. Ricerca delle istanze MongoDB utilizzando i metadati di rete
È qui che passiamo dalla teoria alla pratica.
Vectra genera continuamente metadati di rete arricchiti che ci consentono di individuare le istanze MongoDB senza fare affidamento su log, agenti o inventari delle risorse.
Individuazione delle istanze MongoDB esposte su Internet
Principali approcci alla ricerca:
- Identificare gli host interni che accettano connessioni in entrata da Internet
- Filtra per:
- Servizi TCP con comportamento simile a quello di un server
- Sessioni di lunga durata
- Connessioni in entrata ripetute da diversi indirizzi IP di origine
- Correlare con:
- Porte predefinite note di MongoDB
- Traffico in entrata ad alta entropia su porte insolite
- Certificati TLS riutilizzati su più listener MongoDB
Questo emerge immediatamente:
- cloud dimenticate
- Database di test esposti accidentalmente
- Servizi "temporanei" che sono diventati permanenti
E a differenza di Shodan, questa è la tua esposizione effettiva, non il risultato di una scansione.
SELEZIONA
id.resp_h,
nome_host_risposta,
COUNT(*) AS conteggio_connessioni
DA network.isession._all
DOVE id.resp_p = 27017
E local_orig = FALSO
E local_resp = TRUE
E timestamp TRA date_add('day', -14, now()) E now()
RAGGRUPPARE PER id.resp_h, resp_hostname.name
ORDINA PER connection_count DESC
LIMITE 100
In questo scenario, ci concentriamo sull'identificazione dei server MongoDB che funzionano su TLS, indipendentemente dalla porta TCP in uso. Poiché l'ispezione del payload non è possibile con il traffico crittografato, ci affidiamo al fingerprinting TLS, in particolare JA3 e JA4, che vengono calcolati automaticamente dalla piattaforma Vectra per ogni sessione TLS osservata e arricchiti nei metadati di rete.
JA3 e JA4 identificano il comportamento dei client TLS tramite l'hashing delle caratteristiche dell'handshake TLS, quali suite di cifratura supportate, estensioni e versioni di protocollo. Le loro controparti lato server, JA3S e JA4S, acquisiscono l'impronta digitale della risposta del server TLS, rendendole particolarmente utili per identificare le tecnologie server senza decrittografare il traffico.
In pratica, questo ci permette di individuare i server TLS MongoDB in base al modo in cui negoziano il TLS, anche quando funzionano su porte non standard o sono altrimenti indistinguibili a livello di trasporto.
È importante notare, tuttavia, che le impronte digitali JA3S e JA4S non sono univoche a livello globale. Impronte digitali simili possono essere condivise tra diversi stack di server e librerie, il che significa che sono possibili collisioni e che il contesto continua ad avere importanza.
Detto questo, i test effettuati su più versioni di MongoDB dimostrano che le impronte digitali JA3S e JA4S sono altamente coerenti tra le diverse versioni, rendendole un segnale affidabile se combinate con il comportamento della rete, i modelli di sessione e endpoint .
Ricerca dei server MongoDB su porte non standard
L'identificazione dei server MongoDB che non sono associati a una porta nota richiede ulteriori analisi e contestualizzazioni. In questi casi, il semplice filtraggio basato sulle porte non è sufficiente ed è necessario affidarsi a indicatori di livello superiore derivati dai metadati di rete.
Un approccio efficace consiste nell'esaminare gli identificatori lato server, come il nome host del risponditore o l'indicazione del nome del server TLS (SNI), e cercare modelli che suggeriscano l'infrastruttura del database. I nomi host che fanno riferimento a ruoli, cluster, shard o set di repliche del database possono fornire indizi significativi sul fatto che il servizio in questione sia un backend MongoDB, anche quando è in ascolto su una porta inaspettata.
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
DA network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
E local_orig = FALSO
E local_resp = TRUE
E timestamp TRA date_add('day', -14, now()) E now()
ORDINA PER timestamp DESC
LIMITE 1000
Se aggiungiamo anche il porto di destinazione:
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
DA network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
E id.resp_p = 27017
E local_orig = FALSO
E local_resp = TRUE
E timestamp TRA date_add('day', -14, now()) E now()
ORDINA PER timestamp DESC
LIMITE 1000
Nota: MongoDB non viene fornito con certificati TLS o chiavi private predefiniti. Quando TLS è abilitato, gli amministratori devono fornire esplicitamente il proprio certificato e le proprie chiavi. Inoltre, MongoDB utilizza TLS 1.3 come impostazione predefinita quando TLS è attivo, il che significa che i certificati tradizionali e i metadati x.509 non vengono esposti nella telemetria di rete.
Ricerca delle istanze interne di MongoDB
Il MongoDB interno è spesso più pericoloso dell'esposizione esterna.
Perché?
- Gli hacker non hanno bisogno di scansionare Internet
- Gli host compromessi possono enumerare liberamente
- I database interni spesso non sono sufficientemente protetti
I modelli di caccia includono:
- Servizi TCP est-ovest che fungono da server persistenti
- Connessioni ripetute dai livelli dell'applicazione
- Modelli comportamentali noti di MongoDB (durata della sessione, cadenza delle richieste)
- Servizi raggiungibili da molti host interni diversi
Questo rivela rapidamente:
- Database accessibili da qualsiasi luogo
- Problemi relativi alla progettazione di reti piatte
- Obiettivi ideali per il movimento laterale
SELEZIONA
id.resp_h,
nome_host_risposta,
COUNT(*) AS conteggio_connessioni
DA network.isession._all
DOVE id.resp_p = 27017
E local_orig = FALSO
E local_resp = TRUE
E timestamp TRA date_add('day', -14, now()) E now()
RAGGRUPPARE PER id.resp_h, resp_hostname.name
ORDINA PER connection_count DESC
LIMITE 100
Anche qui possiamo usare JA3S e JA4S:
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
DA network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
E local_orig = TRUE
E local_resp = TRUE
E timestamp TRA date_add('day', -14, now()) E now()
ORDINA PER timestamp DESC
LIMITE 1000
Se aggiungiamo anche il porto di destinazione:
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
DA network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
E id.resp_p = 27017
E local_orig = TRUE
E local_resp = TRUE
E timestamp TRA date_add('day', -14, now()) E now()
ORDINA PER timestamp DESC
LIMITE 1000
Alla ricerca di potenziali vulnerabilità MongoBleed
Anche senza visibilità sul payload, i tentativi di sfruttamento lasciano tracce.
Cose da cercare:
- Tentativi di connessione insoliti ai servizi MongoDB
- Connessioni di breve durata e ripetute da host inaspettati
- Nuovo comportamento del client MongoDB da parte di sistemi che non lo hanno mai utilizzato prima
- Picchi improvvisi nelle connessioni
- Traffico MongoDB proveniente da sistemi non applicativi (workstation, jump host, server compromessi)
Questi sono i classici sintomi di:
- Ricognizione
- Test di exploit
- Rilevamento automatico della memoria
La visione incentrata sull'entità di Vectra lo rende immediatamente evidente, specialmente se combinato con l'identità e il contesto dell'host.
SELEZIONA
id.orig_h,
id.resp_h,
id.resp_p,
durata,
conn_state,
timestamp,
orig_ip_bytes,
byte_ip_risposta
DA network.isession._all
DOVE conn_state IN ('SF')
AND duration < 5000
E orig_ip_bytes = 44
E first_orig_resp_data_pkt = 'LAAAAAEAAAAAAAAA3AcAAA=='
E timestamp TRA date_add('day', -14, now()) E now()
ORDINA PER timestamp DESC
LIMITE 100
Questa query è un esempio di come cercare il traffico MongoDB non crittografato in cui il primo pacchetto ha una dimensione di 44 byte con un'intestazione MongoDB che definisce un messaggio compresso.
Il formato dell'intestazione MongoDB è definito come segue:
Il PoC pubblicato utilizza una lunghezza di 44 byte con un codice operativo (opCode) pari a 2012 (dati compressi).
3. Approfondimento con Vectra Match Suricata)
I metadati ci consentono di ottenere grandi risultati. Vectra Match ci Match essere precisi.
Utilizzando le firme basate su Suricata, possiamo identificare in modo esplicito il traffico MongoDB e i modelli di sfruttamento. Il Match Vectra Match si basa sul set di regole commerciale ETPro e contiene le seguenti due regole per MongoBleed. La prima serve a rilevare i tentativi di autenticazione in entrata e la seconda a rilevare lo sfruttamento stesso. Entrambe sono incluse nel set di regole Vectra Match .
Rilevamento dell'uso potenziale di exploit
Per MongoBleed in particolare, le firme possono avere come obiettivo:
- Lunghezze di protocollo malformate o anomale
- Ripetuti tentativi di handshake senza autenticazione
- Anomalie di protocollo compatibili con tentativi di divulgazione della memoria
- Comportamento di sondaggio ad alta frequenza nei confronti dei servizi MongoDB
Questo non si basa solo su payload specifici CVE, ma si concentra sul comportamento, che è molto più difficile da eludere per gli aggressori.
avviso tcp qualsiasi qualsiasi -> $HOME_NET 27017 (msg:"ET INFO Autenticazione SASL MongoDB rilevata"; flusso:stabilito,to_server; flowbits:set,ET.MongoDB_Auth_Attempt; flowbits:noalert; contenuto:"|dd 07 00 00|"; offset:12; profondità:4; contenuto:"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)"; flusso:stabilito,to_server; flowbits:non impostato,ET.MongoDB_Auth_Attempt; contenuto:"|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:affected_product MongoDB, attack_target Server, created_at 2025_12_29, cve CVE_2025_14847, deployment Perimeter, deployment Internal, confidence Low, signature_severity Major, updated_at 2025_12_29; target:dest_ip;)
Testo in chiaro, TLS e porte non standard — Coperti
Da tutte queste ricerche emerge una conclusione semplice:
- MongoDB in chiaro: protocollo + metadati + firme
- TLS MongoDB: metadati + analisi comportamentale + certificati
- Porte non standard: il comportamento batte sempre le porte
Agli aggressori non interessa su quale porta sia in esecuzione MongoDB, e nemmeno ai difensori dovrebbe interessare.
Cosa segnalare e cosa cercare
Chiamare il medico di guardia quando
- MongoDB connesso a Internet riceve picchi di traffico in entrata da indirizzi IP sconosciuti
- I server MongoDB interni subiscono tempeste di connessioni simili a quelle degli scanner.
- I nuovi clienti iniziano a comunicare con il protocollo MongoDB su porte non standard
Caccia quando
- Vedi il protocollo MongoDB su porte non standard (Livello 2)
- Vedi tentativi di autenticazione da fonti insolite (Livello 3)
- Si osserva un picco nelle connessioni di breve durata, anche senza visibilità del payload (Livello 2)
Mitigazione (perché il rilevamento non sostituisce l'applicazione delle patch)
La guida alla risoluzione di MongoDB è chiara: eseguire l'aggiornamento alle versioni corrette (8.2.3 / 8.0.17 / 7.0.28 / 6.0.27 / 5.0.32 / 4.4.30). (jira.mongodb.org)
NVD riassume la vulnerabilità come una discrepanza nel campo della lunghezza nelle intestazioni zlib che consente letture non autenticate dell'heap. (NVD)
Esiste un PoC pubblico, che riduce lo sforzo dell'autore dell'attacco. (GitHub)
Perché è importante?
MongoBleed è solo l'ultimo promemoria del fatto che i database non sono infrastrutture passive. Sono superfici di attacco attive.
Se non riesci a rispondere:
- Dove viene eseguito MongoDB?
- Chi può raggiungerlo?
- Chi lo sta toccando adesso?
... allora la sola applicazione di patch non sarà sufficiente.
Vectra AI ti offre la visibilità necessaria per rispondere a queste domande, oltre alla capacità di ricerca e rilevamento che ti consente di agire prima che il "bleeding memory" si trasformi in una violazione su larga scala.