Il 23 maggio 2023, Barracuda ha annunciato una vulnerabilità (CVE-2023-2868) nella sua appliance Email Security Gateway che è stata sfruttata in modo selvaggio già nell'ottobre del 2022. Il 15 giugno 2023, Mandiant ha pubblicato un'analisi dettagliata delle attività e degli attori 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 una riunione con un cliente Vectra AI , è stato sollevato il dubbio che la regola esistente non funzionasse come previsto. Dopo aver condotto i test iniziali, abbiamo scoperto che la regola non è riuscita ad avvisare su uno specifico exploit proof-of-concept, nonostante la consegna del payload dell'exploit sia avvenuta con successo.
Abbiamo analizzato la regola e l'exploit correlato e abbiamo identificato la specifica lacuna di rilevamento, causata da un ordine non deterministico del contenuto correlato all'exploit all'interno del payload dell'exploit (maggiori dettagli sono forniti nella sezione "Breve sguardo all'exploit proof-of-concept"). Una volta identificata la lacuna, siamo stati in grado di riscrivere una regola per fornire la copertura di rilevamento necessaria. Dopo aver presentato i nostri risultati al team EmergingThreats di Proofpoint, è stata rilasciata una nuova regola di rilevamento M2. Questo report fornisce una spiegazione del processo di analisi e scrittura delle regole utilizzato per la regola di rilevamento M2 che ha eliminato il falso negativo confermato.
TL;DR
La regola ET di Proofpoint è difettosa a causa del presupposto che tutti seguano le regole, anche quelli che non le seguono. In questa analisi, abbiamo riscontrato un archivio TAR manipolato che fa scivolare un payload oltre la regola di rilevamento di ET per CVE-2023-2868 perché l'autore dell'exploit non ha seguito le regole. Anche con una regola di rilevamento migliorata, la preoccupazione rimane: se domani incontriamo un'altra struttura di file manipolata, potrebbe eludere nuovamente le regole di rilevamento di ET?
1. Anatomia di CVE-2023-2868
Il rapporto di Mandiant fornisce una spiegazione della vulnerabilità, ma per comodità l'abbiamo riassunta con l'illustrazione seguente. Come si può vedere, alcune versioni di Barracuda Email SecurityAppliance sono vulnerabili a una vulnerabilità di tipo injection.
Per identificare questo payload dannoso, il team di ricerca sulle minacce emergenti ha sviluppato una sala di rilevamento che ha cercato il "'`" (virgolette singole, tick indietro) e "`'" (virgolette, virgolette singole) in particolari tipi di pacchetti. Come vedremo, il loro metodo di costruzione delle regole ha permesso che alcune Proof of Concepts non venissero rilevate.
2. Un breve sguardo all'exploit proof-of-concept
Se si presta attenzione all'exploit della vulnerabilità proof of concept (PoC), disponibile qui, si è iniziato a identificare il payload sottostante utilizzato, che 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 la virgoletta singola e il segno di spunta e termina la variabile "CMD" con la virgoletta singola e il segno di spunta. Questo è ciò che innesca l'iniezione del comando.
Uno sguardo al PoC via cavo in esagono
Ecco l'output di una rappresentazione esadecimale dell'archivio tar generato contenente il payload mostrato sopra:
"PAYLOAD", che sono i modelli di iniezione, sono evidenziati in rosso. La stringa di comando assegnata alla variabile "CMD" è evidenziata in blu:]
Si noti che nella parte superiore dell'archivio sono presenti alcuni residui della variabile CMD, nonché i modelli di iniezione \x60\x27 (tick posteriore, virgolette singole). Torneremo su questa parte importante più avanti.
Una normale struttura di archivio Tar
Prima di addentrarci nei difetti della regola di rilevamento, è importante capire la struttura di un normale archivio tar. Gli archivi tar sono organizzati in blocchi di 512 byte. Fondamentalmente, il formato di un archivio tar è:
- "L'intestazione contiene il nome del file e alcuni metadati aggiuntivi.
- Il "Contenuto" contiene i dati effettivi del file.
Una sbirciatina a un normale archivio Tar via cavo in esadecimale
Un archivio Tar "normale" è un file creato da un'utility 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 il contenuto del file "hello 1", seguito dal file denominato 2 e così via. Chiaramente, l'utilità di creazione di archivi tar mette i dati di intestazione e di contenuto in ordine decrescente in base ai nomi dei file. In altre parole, è consapevole delle regole dettate dallo standard del formato dei 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 previsto. Per renderlo possibile, l'autore dell'exploit ha dovuto ingegnarsi un po'.
Dissezione dell'exploit R7
L'exploit scritto dal team di Rapid7 Security Researcher ha una parte dedicata, con commenti, alla classe Ruby "TarWriter":
Questo exploit sovrascrive il controllo della dimensione del nome del file che viene originariamente effettuato dalla funzione "split_name()" :
3 dichiarazioni "if" sono state rimosse dalla funzione originale. Queste 3 istruzioni sollevano "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 ottengono 129 byte:
In base al codice del PoC, se il comando da eseguire è superiore a 100 byte, il comando verrà suddiviso in più "voci di file" nell'archivio tar. Abbiamo messo "voci di file" tra virgolette doppie perché l'archivio tar dannoso non contiene effettivamente file, ma una sequenza di escape e comandi incorporati che l'aggressore vuole eseguire.
Rivedendo l'hexdump dell'archivio tar maligno, possiamo ora capire perché la prima voce nell'archivio tar è un "dangling" (segno di spunta, virgolette singole) e la fine della variabile CMD, che dovrebbe arrivare alla fine del comando.
Poiché il comando supera il limite di 100 byte imposto alla struttura dei nomi dei file per l'intestazione di un file, il comando è stato suddiviso in due voci di file con la seconda voce contenente solo la desinenza p"`' (lettera p, doppie virgolette, segno di spunta, virgolette singole). Questa 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, segno di spunta, virgolette singole) viene prima di una stringa '`s (virgolette singole, segno di spunta, lettera s) quando è ordinata in ordine decrescente:
Mentre l'ordine all'interno di un archivio tar è coerente, l'ordine della sequenza di escape e dei comandi contenuti nel payload dell'exploit non è deterministico dal punto di vista della regola di rilevamento, poiché l'ordine varia a seconda della lunghezza combinata e dei caratteri utilizzati nei comandi incorporati nel payload.
3. Spiegazione ad alto livello della regola di rilevamento:
Una volta acquisita una migliore comprensione della vulnerabilità, di ciò che occorre per sfruttarla e confermati gli schemi da discriminare all'interno dell'exploit, abbiamo rivolto la nostra attenzione alla regola di rilevamento del file emerging-exploit.rules:
Per semplificare, questa regola cerca 3 modelli:
1. Qualsiasi pacchetto SMTP proveniente da qualsiasi luogo, 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 contiene un allegato valido di un archivio tar; l'allegato deve corrispondere ai numeri magici dei file di un archivio TAR.
b. Che contiene al suo interno i due modelli "|27 60|" e "|60 27|".
Le parole chiave ricercate sono la rappresentazione esadecimale dei seguenti caratteri ASCII"'`" (virgolette singole, segno di spunta posteriore) e "`'" (virgolette, virgolette singole). I caratteri "'`" (virgolette singole, segno di spunta) sono 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:
Tornando alla regola, si nota che esistono anche un parametro "distanza" e un parametro "entro" che possono essere accoppiati per perfezionare una regola. I parametri sono utilizzati come segue:
- Distanza: imposta il cursore sul punto di partenza dell'analisi.
- Distanza: 0 significa che il modello può trovarsi ovunque dopo la corrispondenza precedente +0byte. Quindi subito dopo \x27\x60 nell'esempio precedente.
- Entro: Limita la distanza dall'ultima partita che la regola deve guardare in avanti.
- 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 l'adagio, "un'immagine vale più di mille parole", il dump qui sotto mostra il comportamento della regola di rilevamento nell'exploit Rapid7:
Questo frammento della regola:
Il dump qui sopra illustra facilmente il motivo per cui la regola di rilevamento non si attiva mai: nel nostro esempio, non troverà mai l'altro schema perché è posizionato all'inizio dell'archivio.
5. Una variante della regola di rilevamento M2 per questo exploit non rilevato
Alla luce di queste scoperte, il 29 settembre il team Emerging Threats di Proofpoint ha pubblicato una nuova regola di rilevamento M2, revisione 2, con il codice SID 2048146:
Di seguito è riportato un riepilogo di ciò che la regola di rilevamento M2 controlla, utilizzando la stessa rappresentazione esadecimale dell'exploit dell'archivio tar come in precedenza:
6. Risoluzione
Alla luce delle evidenti carenze della regola ET originale di Proofpoint (SID 2046280), appare chiaro che affidarsi esclusivamente a regole e standard fissi ha i suoi limiti nel panorama in continua evoluzione della sicurezza informatica. L'intramontabile saggezza del generale MacArthur, "Le regole sono per lo più fatte per essere infrante", serve a ricordare che i malintenzionati sono pronti a sfruttare qualsiasi vulnerabilità, compresi i set di regole rigide.
Attraverso questa analisi, abbiamo assistito a un esempio lampante dei limiti di questo approccio, attraverso la manipolazione della struttura di un archivio TAR che ha permesso 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 domani, è imperativo 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 si evolvono continuamente. 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 vada oltre l'affidamento alle sole tecnologie basate su regole non solo si allinea all'approccio multilivello di Defense-inDepth, ma invita anche il lettore ad abbracciare le strategie attualmente più efficaci, tra cui il modello Zero Trust .
Al fine di fornire una raccomandazione immediatamente attuabile, offriamo le seguenti indicazioni:
Per le distribuzioni di Suricata che utilizzano il file emerging-all.rules e che dispongono di una gestione automatica degli aggiornamenti del ruleset, la regola di rilevamento modificata dovrebbe essere già presente, a condizione che il programma di aggiornamento sia stato eseguito dopo il 29 settembre 2013. Per verificare che il set di regole attualmente applicato contenga la regola di rilevamento modificata, cercare "2048146" nei file del set di regole locali. Se il SID 2048146 non è presente in nessuno dei set di regole attualmente applicati, aggiornare i set di regole all'ultima fonte disponibile di Emerging Threats.
Cronologia:
- 19/9/23: Presentazione dei risultati tramite il portale ET. Non ho ricevuto alcuna risposta di conferma dell'invio.
- 21/9/23: Inviata un'e-mail a support@emergingthreats.net per registrare l'invio e informare il team Minaccia emergente della politica di divulgazione responsabile di Google che sarà seguita in questo caso.
- 21/9/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 sua pubblicazione quotidiana, oggi 7 PM ET.
- 21/9/23: notato che la regola di rilevamento della variante M2 pubblicata di recente non attiva un avviso contro l'exploit R7.
- 21/9/23: inviato un'e-mail al ricercatore di ET Security in merito al mancato rilevamento del payload dell'exploit con la nuova regola di rilevamento M2.
- 29/09/23: Una revisione 2 della regola della variante M2 è stata rilasciata alle 7PM ET e rileva con successo il payload dell'exploit R7.
Riferimento:
Documentazione sulla Suricata: https://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords
html#withinhttps://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords.html#distance
POC Github exploit: https://github.com/cfielding-r7/poc-cve-2023-2868/blob/main/poc_cve_2023_2868.rb
Exploit spiegato: https://www.mandiant.com/resources/blog/barracuda-esg-exploited-globally
Regola ET: http://rules.emergingthreats.net/open/suricata-5.0/emerging-all.rules