Il 23 maggio 2023, Barracuda ha annunciato una vulnerabilità (CVE-2023-2868) nel proprio dispositivo Email Security Gateway che era stata sfruttata già nell'ottobre 2022. Il 15 giugno 2023, Mandiant ha pubblicato un'analisi dettagliata delle attività e degli autori delle minacce coinvolti nella campagna che sfruttava attivamente CVE-2023-2868. Successivamente, il team Emerging Threats di Proofpoint ha rilasciato una regola di rilevamento Suricata (SID 2046280) per rilevare i tentativi di sfruttamento della vulnerabilità segnalata. Durante un incontro con un Vectra AI , è stata sollevata la preoccupazione che la regola esistente potesse non funzionare come previsto. Dopo aver condotto i test iniziali, abbiamo scoperto che la regola non riusciva ad avvisare di uno specifico exploit proof-of-concept, nonostante la consegna riuscita del payload dell'exploit.
Abbiamo analizzato la regola e l'exploit correlato e identificato la specifica lacuna di rilevamento, causata da un ordinamento non deterministico dei contenuti correlati all'exploit all'interno del payload dell'exploit (maggiori dettagli sono forniti nella sezione "Breve panoramica sull'exploit proof-of-concept" riportata di seguito). Una volta identificata la lacuna, siamo stati in grado di riscrivere una regola per fornire la copertura di rilevamento necessaria. Dopo aver inviato i nostri risultati al team EmergingThreats di Proofpoint, è stata rilasciata una nuova regola di rilevamento M2. Questo rapporto fornisce una spiegazione dell'analisi e del processo di scrittura della regola utilizzato per la regola di rilevamento M2 che ha eliminato il falso negativo confermato.
TL;DR
La regola ET di Proofpoint è imperfetta perché si basa sul presupposto che tutti rispettino le regole, anche chi non lo fa. In questa analisi, abbiamo riscontrato un archivio TAR manipolato che elude la regola di rilevamento ET per CVE-2023-2868 perché l'autore dell'exploit non ha seguito le regole. E anche con una regola di rilevamento migliorata, la preoccupazione rimane: se domani dovessimo riscontrare un'altra struttura di file manipolata, potrebbe eludere nuovamente le regole di rilevamento ET?
1. Anatomia di CVE-2023-2868
Il rapporto di Mandiant fornisce una spiegazione della vulnerabilità, ma per comodità l'abbiamo riassunta nell'illustrazione sottostante. Come si può vedere, alcune versioni di Barracuda Email SecurityAppliance sono vulnerabili a un attacco di tipo injection.
Per identificare questo payload dannoso, il team di ricerca Emerging Threats ha sviluppato una sala di rilevamento che cercava i caratteri "`" (virgoletta singola, back tick) e "`" (back tick, virgoletta singola) in particolari tipi di pacchetti. Come vedremo, il loro metodo di costruzione delle regole ha permesso ad alcuni Proof of Concept di passare inosservati.
2. Una breve panoramica sull'exploit proof-of-concept
Passando all'exploit della vulnerabilità proof of concept (PoC), disponibile qui, abbiamo iniziato a identificare quale payload sottostante viene utilizzato e dovrebbe attivare la regola di rilevamento delle minacce emergenti. Come mostrato di seguito, la variabile "CMD" utilizza la stessa struttura di comando di base descritta nel rapporto di Mandiant:
Si noti che la variabile "PAYLOAD" inizia con l'apice singolo e il back tick e termina la variabile "CMD" con il back tick e l'apice singolo. Questo è ciò che attiverà l'iniezione del comando.
Uno sguardo al PoC over the wire in esadecimale
Ecco il risultato di una rappresentazione esadecimale dell'archivio tar generato contenente il payload mostrato sopra:
I "PAYLOAD", ovvero i modelli di iniezione, sono evidenziati in rosso. La stringa di comando assegnata alla variabile "CMD" è evidenziata in blu:]
Si noti nella parte superiore dell'archivio che sono presenti alcuni residui della variabile CMD, oltre ai modelli di iniezione \x60\x27 (back tick, virgoletta singola). Torneremo su questo importante aspetto più avanti.
Una normale struttura di archivio Tar
Prima di approfondire i difetti della regola di rilevamento, è importante comprendere la struttura di un normale archivio tar. Gli archivi tar sono organizzati in blocchi di 512 byte. Fondamentalmente, il formato di un archivio tar è:
- "Header" contiene il nome del file, oltre ad alcuni metadati aggiuntivi.
- Il "contenuto" contiene i dati effettivi all'interno del file.
Uno sguardo a un normale archivio Tar in rete in esadecimale
Un archivio Tar "normale" è un file creato da un'utilità che segue le regole e rispetta il formato TAR dei sistemi UNIX o il formato USTAR definito dallo standard POSIX 1003.1. Questo è un dump esadecimale di un normale archivio tar contenente tre file regolari denominati 1, 2 e 3, utilizzando l'utilità tar:
Possiamo vedere il file denominato 1, seguito da alcuni codici byte e poi dal contenuto del file "hello 1", seguito dal file denominato 2 e così via. Chiaramente, l'utilità di creazione dell'archivio tar inserisce i dati dell'intestazione e del contenuto in ordine decrescente in base ai nomi dei file. In altre parole, tiene conto delle regole dettate dallo standard del formato file e le rispetta.
Da notare che la struttura dei file è diversa da quella generata dall'exploit e presentata nella prima sezione. L'exploit PoC contiene una serie di comandi nell'intestazione invece dei nomi dei file come ci si aspetterebbe. Per rendere possibile ciò, l'autore dell'exploit ha dovuto ricorrere a qualche accorgimento.
Analisi dell'exploit R7
L'exploit scritto dal team di ricercatori di sicurezza Rapid7 ha una parte dedicata, con commenti, alla classe Ruby "TarWriter":
Questo exploit sovrascrive i controlli sulla dimensione del nome del file originariamente eseguiti dalla funzione "split_name()" qui:
3 istruzioni "if" sono state rimosse dalla funzione originale. Queste 3 istruzioni generano "TooLongFileName" per verificare se:
1. Il percorso del file è troppo lungo
2. Il nome del file è troppo lungo
3. Il percorso di base del file è troppo lungo
Osservando il payload dell'exploit e contando i caratteri, si ottiene un totale di 129 byte:
In base al codice nel PoC, se il comando da eseguire supera i 100 byte, il comando verrà suddiviso in più "voci di file" nell'archivio tar. Abbiamo messo "voci di file" tra virgolette perché l'archivio tar dannoso non contiene effettivamente file, ma una sequenza di escape e comandi incorporati che l'autore dell'attacco desidera eseguire.
Rivedendo l'hexdump dell'archivio tar dannoso, ora possiamo capire perché la prima voce nell'archivio tar è un `' (back tick, virgoletta singola) sospeso e la fine della variabile CMD, che dovrebbe trovarsi alla fine del comando.
Poiché il comando supera il limite di 100 byte imposto alla struttura del nome del file per l'intestazione di un file, il comando è stato suddiviso in due voci di file, con la seconda voce contenente solo il suffisso p”`’ (lettera p, virgolette doppie, back tick, virgolette singole). Tale voce di file appare all'inizio dell'archivio tar perché il contenuto dell'archivio tar è ordinato in ordine decrescente e una stringa p”`’ (lettera p, virgolette doppie, apostrofo, virgolette singole) precede una stringa ‘`s (virgolette singole, apostrofo, lettera s) quando ordinata in ordine decrescente:
Sebbene l'ordine all'interno di un archivio tar sia coerente, l'ordine della sequenza di escape e dei contenuti dei comandi del payload dell'exploit non sarà deterministico dal punto di vista della regola di rilevamento, poiché l'ordine varierà a seconda della lunghezza complessiva e dei caratteri utilizzati nei comandi incorporati nel payload.
3. Spiegazione di alto livello della regola di rilevamento:
Una volta acquisita una migliore comprensione della vulnerabilità, di ciò che serve per sfruttarla e confermato quali modelli devono essere discriminati all'interno dell'exploit, abbiamo rivolto la nostra attenzione alla regola di rilevamento dal file emerging-exploit.rules:
Per semplificare, questa regola cerca 3 modelli:
1. Qualsiasi pacchetto SMTP proveniente da qualsiasi luogo e destinato a qualsiasi server SMTP contenuto nella mappatura $SMTP_SERVERS. Si noti che, per impostazione predefinita, Suricata mappa $SMTP_SERVERS su $HOME_NET, quindi qualsiasi server SMTP interno sarà coperto dalla regola.
a. Che contenga un allegato tar archive valido; l'allegato deve corrispondere ai numeri magici di un archivio TAR.
b. Che contiene al suo interno questi due schemi "|27 60|" e "|60 27|".
Le parole chiave cercate sono la rappresentazione esadecimale dei seguenti caratteri ASCII "`" (virgoletta singola, back tick) e "`" (back tick, virgoletta singola). I caratteri "`" (virgoletta singola, back tick) vengono utilizzati per attivare l'esecuzione del comando, come spiegato in precedenza. Di seguito è riportata la rappresentazione esadecimale dell'exploit con i 3 pattern evidenziati che la regola di rilevamento sta cercando:
Guardando indietro alla regola, vediamo che ci sono anche i parametri "distanza" e "all'interno" che possono essere abbinati per mettere a punto una regola. I parametri sono utilizzati come segue:
- Distanza: imposta il cursore nel punto in cui iniziare l'analisi.
- Distanza: 0 significa che il modello può trovarsi ovunque dopo la corrispondenza precedente +0 byte. Quindi subito dopo \x27\x60 nel nostro esempio sopra.
- Entro: limita il periodo di tempo successivo all'ultima corrispondenza che la regola deve considerare.
- Entro: 500 significa che ci sarà una corrispondenza solo se il contenuto corrisponde al payload entro 500 byte.
I parametri within e distance sono spiegati nella documentazione di Suricata.
4. Difetti osservati nella regola originale rispetto al nostro exploit
Come dice il proverbio, "un'immagine vale più di mille parole": il dump riportato di seguito mostra come si comporta la regola di rilevamento nell'exploit Rapid7:
Questo frammento della regola:
Il dump sopra riportato illustra chiaramente perché la regola di rilevamento non si attiva mai: nel nostro esempio, non troverà mai l'altro pattern poiché questo si trova all'inizio dell'archivio.
5. Una regola di rilevamento M2 variante per questo exploit non rilevato
Alla luce dei risultati sopra riportati, il 29 settembre il team Emerging Threats di Proofpoint ha pubblicato una nuova regola di rilevamento M2, revisione 2, con codice SID 2048146:
Di seguito è riportato un riepilogo di ciò che controlla la regola di rilevamento M2, utilizzando la stessa rappresentazione esadecimale dello stesso exploit dell'archivio tar di prima:
6. Risoluzione
Alla luce delle evidenti carenze della regola ET originale di Proofpoint (SID 2046280), risulta chiaro che affidarsi esclusivamente a regole e standard fissi ha i suoi limiti nel panorama in continua evoluzione della sicurezza informatica. La saggezza senza tempo del generale MacArthur, "Le regole sono fatte principalmente per essere infrante", serve a ricordarci che gli attori malintenzionati sfrutteranno qualsiasi vulnerabilità, compresi i rigidi insiemi di regole.
Attraverso questa analisi, abbiamo assistito a un esempio lampante dei limiti di questo approccio, tramite la manipolazione di una struttura di archivio TAR che ha consentito a un payload di eludere il rilevamento iniziale di ET per CVE-2023-2868. Questo evento sottolinea l'urgenza di adottare una strategia di sicurezza più adattabile e dinamica.
Guardando al futuro, è fondamentale spostare la nostra attenzione dalla rigidità e abbracciare un paradigma di sicurezza più olistico e proattivo. Invece di limitarci a riflettere sulle probabilità di un'altra violazione delle regole, dovremmo impegnarci attivamente per migliorare le nostre misure di sicurezza informatica, evolvendo costantemente i nostri meccanismi di rilevamento e difesa. Riconoscendo i limiti delle regole fisse, possiamo prepararci meglio a un futuro incerto in cui le minacce informatiche sono in continua evoluzione. In questo modo, possiamo rafforzare la nostra posizione di sicurezza e proteggerci meglio dagli attori malintenzionati che cercano costantemente di aggirare le regole. L'adozione di una strategia che va oltre il semplice affidamento a tecnologie basate su regole non solo è in linea con l'approccio multilivello della difesa in profondità, ma invita anche il lettore ad abbracciare le strategie attualmente più efficaci, tra cui il Zero Trust .
Al fine di fornire una raccomandazione immediatamente attuabile, offriamo le seguenti indicazioni:
Per le implementazioni Suricata che utilizzano il file emerging-all.rules e dispongono di una gestione automatizzata degli aggiornamenti dei set di regole, la regola di rilevamento revisionata dovrebbe essere già in vigore, supponendo che l'aggiornamento sia stato eseguito dopo il 29/09/23. Per verificare che il set di regole attualmente applicato contenga la regola di rilevamento revisionata, cercare "2048146" nei file del set di regole locale. Se il SID 2048146 non è presente in nessuno dei set di regole attualmente applicati, aggiornare i set di regole all'ultima versione disponibile da Emerging Threats.
Cronologia:
- 19/09/23: Invio dei risultati tramite il portale ET. Non è stata ricevuta alcuna conferma di ricezione.
- 21/09/23: Inviata un'e-mail all'indirizzo support@emergingthreats.net per registrare la segnalazione e informare il team Emerging Threat della politica di divulgazione responsabile di Google che verrà seguita in questo caso.
- 21/09/23: Il ricercatore di sicurezza ET mi ha risposto via e-mail e ha accettato di rilasciare una versione M2 della regola di rilevamento come parte della loro pubblicazione quotidiana, oggi alle 19:00 ET.
- 21/09/23: Abbiamo notato che la nuova regola di rilevamento della variante M2 non attiva alcun avviso contro l'exploit R7.
- 21/09/23: Inviata un'e-mail al ricercatore di ET Security in merito alla mancata rilevazione del payload dell'exploit con la nuova regola di rilevamento M2.
- 29/09/23: Una revisione 2 della regola variante M2 rilasciata alle 19:00 ET rileva con successo il payload dell'exploit R7.
Riferimento:
Documentazione Suricata: https://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords
https://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords.html#distance
Github POC exploit: https://github.com/cfielding-r7/poc-cve-2023-2868/blob/main/poc_cve_2023_2868.rb
Spiegazione dello sfruttamento: https://www.mandiant.com/resources/blog/barracuda-esg-exploited-globally
Regola ET: http://rules.emergingthreats.net/open/suricata-5.0/emerging-all.rules