Analisi degli attacchi alla catena di fornitura del software
3CX è una nota azienda che fornisce prodotti VoIP e Unified Communications. Sostiene di avere oltre 600,000 installazioni e 12 milioni di utenti giornalieri. Senza dubbio un bersaglio allettante per i malintenzionati.
Entro la fine di marzo, 3CX ha subito il 3CX Supply Chain Attack, un sofisticato attacco alla supply chain del software, che è riuscito a iniettare malware nel loro software desktop. Il malware mira a rubare informazioni, ma rilascia anche una backdoor.
In questo post, esamineremo questo attacco alla supply chain, seguendo la sequenza degli eventi da diversi punti di vista. Nel processo, potremmo scoprire come bloccare o mitigare l'attacco.
Sommario
Come è stato compiuto l'attacco
I malintenzionati hanno prima compromesso un pacchetto software, X_TRADER, di una società denominata Tecnologie di trading con sede a Chicago, IL. Il software conteneva malware ( SEGNALE VELO backdoor) iniettato. Il programma di installazione è stato firmato digitalmente con un certificato di firma del codice valido. È possibile che i cattivi attori siano entrati nella costruzione pipeline entro il 2021 e modificato il software prima che venga confezionato e firmato. Questo è stato il primo salto nell’attacco alla catena di approvvigionamento concatenata. Entro marzo 2022 questo era segnalati nel contesto delle operazioni DreamJob alias BLINDINGCAN and Mela Gesù, prendendo di mira le organizzazioni con sede negli Stati Uniti nei settori dei media, dell'IT, delle criptovalute e del fintech.
Questo software è stato ritirato nel 2020 (!), ma era disponibile per il download dal 2022. Un dipendente 3CX lo ha installato su un personal computer. I malintenzionati hanno rubato le credenziali aziendali del dipendente dal computer compromesso. È interessante notare che il SEGNALE VELO utilizzato un URL nel sito Web di Trading Technologies per comando e controllo (una tattica spesso utilizzata per evitare il rilevamento).
Due giorni dopo la compromissione iniziale, i malintenzionati hanno utilizzato la VPN aziendale per accedere ai sistemi interni di 3CX. Hanno utilizzato il proxy inverso FRP, uno strumento pubblico che potrebbe essere utilizzato nel bene e nel male, per spostarsi lateralmente. Sapevano cosa fare con il punto d'appoggio guadagnato: hanno compromesso i sistemi di build Windows e macOS. Ogni ambiente con strumenti diversi. Ad esempio, hanno utilizzato lo strumento SigFlip per inserire lo shellcode crittografato RC4 nell'appendice della firma del d3dcompiler_47.dll.
Gli aggiornamenti software per l'app desktop 3CX per Windows e macOS erano infetti. Questo è stato il secondo salto in questo (primo?) attacco alla catena di approvvigionamento in più fasi. L'aggiornamento software per Windows, anch'esso opportunamente firmato con un certificato di firma codice 3CX, rilascia due file dannosi, ffmpeg.dll and d3dcompiler_47.dll (con equivalente .dylib librerie per macOS), che sono state caricate ed eseguite dal benign 3CXDesktopApp eseguibile (tramite la tecnica di caricamento side-DLL). Lo shellcode crittografato nella seconda DLL carica un'altra DLL da cui viene scaricato IconStorages Repository GitHub un file .ico contenente il server Command and Control (C2) crittografato.
Sono stati predisposti oltre 20 domini per questa operazione, il che dimostra come l'attacco alla supply chain del software sia stato pianificato con cura.
Le connessioni dai PC delle vittime ai domini C2 sono iniziate il 06 marzo 2023 e sono terminate il 29 marzo.
Tieni presente che (1) nessun codice sorgente in un repository di codici è stato modificato ma, invece, il payload del malware è stato iniettato durante la creazione, (2) un codice legittimo ffmpeg Il DDL è stato sostituito con uno dannoso e caricato tramite caricamento side-DLL e (3) una popolare app VoIP è stata trasformata in un'arma con malware multistadio.
Come è stato gestito l'incidente
Sembra che il 29 marzo 3CX abbia ricevuto segnalazioni da terze parti di un attore malintenzionato che “sfruttava una vulnerabilità nel proprio prodotto”. Le piattaforme anti-malware hanno fatto (parzialmente) il loro lavoro.
Il 30 marzo 2023 il 3CX CISO, Pierre Jourdan, ha pubblicato un allarme di sicurezza informare clienti e partner che la loro app Electron (client desktop) è stata spedita dopo un aggiornamento con malware. Il post elenca le versioni interessate (per Windows e Mac), una breve dichiarazione sulle misure di contenimento iniziali adottate e una rapida raccomandazione a continuare a lavorare con il client Web anziché con il client desktop contaminato.
Secondo me la comunicazione iniziale, anche se un po' concisa, era pertinente. Non è facile per nessun fornitore riconoscere che esiste un serio problema di sicurezza che potrebbe colpire molti clienti. L'azienda ha riconosciuto il problema e ha immediatamente indicato un potenziale colpevole:
"Vale la pena menzionarlo: sembra che si tratti di un attacco mirato da parte di una Advanced Persistent Threat, forse addirittura sponsorizzata dallo stato, che ha eseguito un complesso attacco alla catena di fornitura e ha scelto chi avrebbe scaricato le fasi successive del loro malware."
L'azienda ha offerto un'alternativa per mantenere il prodotto funzionante: utilizzare il Applicazione Web progressiva o PWA, invece dell'app desktop, in base a elettrone struttura.
“Ti consigliamo vivamente di utilizzare invece la nostra app PWA. L'app PWA è completamente basata sul Web e fa il 95% di ciò che fa l'app Electron. Il vantaggio è che non richiede alcuna installazione o aggiornamento e la sicurezza web di Chrome viene applicata automaticamente.
Il motivo per cui abbiamo due app è che quando abbiamo avviato l'app Electron, la tecnologia PWA non era ancora disponibile. Ora è maturo e funziona davvero bene”.
Ebbene, anche l'app Web potrebbe essere infetta e una PWA per definizione potrebbe eseguire codice nei service operator (codice JavaScript) con accesso (limitato) alle risorse locali. Il post affermava che la PWA non era infetta in quel momento. Possiamo capire perché, in molti degli oltre 277 commenti al post, alcuni hanno chiesto se l'alternativa PWA menzionata o il software del server PBX stesso fossero compromessi.
Lo stesso giorno, 3CX ha incaricato Mandiant di indagare, con ulteriori istruzioni. Fondamentalmente, installa l'aggiornamento per
App desktop Win/Mac durante l'installazione in sede, disinstalla l'app Electron per le versioni interessate e vai all'alternativa PWA. Ciò non è necessariamente sufficiente, poiché il malware potrebbe avere accesso ai sistemi interessati, persistere o addirittura spostarsi lateralmente. La rimozione completa del malware non è così semplice. Possiamo capire che, data l’urgenza, non sempre si trova il modo migliore per affrontare un incidente… a meno che lo scenario non sia stato precedentemente immaginato e non siano state identificate adeguate misure correttive.
Migliori post successivo, ora dal CEO dell'azienda, cerca di rassicurare i clienti con l'annuncio di un aggiornamento esclusivamente di sicurezza per DesktopApp. Sono state implementate alcune tecniche di protezione di base, come l'hashing delle password ("Meglio che mai è tardi; non avere mai successo sarebbe un periodo troppo lungo.", Chaucer dixit nel 1386.) Protezioni specifiche e implementate sono migliori delle buone intenzioni e dei piani progettati... Ma come venivano archiviate le password in precedenza?
Ad ogni modo, Google ha invalidato il certificato di firma del codice 3CX esistente e i fornitori di antivirus hanno bloccato anche qualsiasi software firmato con quel certificato. I programmi di installazione MSI per l'aggiornamento DesktopApp dovevano essere rigenerati con un nuovo certificato di firma del codice, operazione che ha richiesto alcune ore. Questo era prevedibile!
3CX ha implementato preventivamente un nuovo server di build. Ciò è ragionevole: senza analisi, non si sapeva come fosse stato iniettato il malware.
Lo stesso 1 aprile, l'amministratore delegato ha pubblicato a Aggiornamento sull'incidente di sicurezza. Il post racconta cosa stava facendo l'azienda (conducendo un'indagine completa e convalidando l'intero codice sorgente del software lato client). La sicurezza non può aspettare nemmeno il sabato.
Una volta analizzato l'incidente e conosciuta l'infrastruttura dell'aggressore, il repository GitHub e i domini per i server C2 utilizzati dall'APT sono stati rimossi, eliminando di fatto il malware.
Ad aprile 11th, il CISO ha pubblicato il primi risultati dell’analisi dell’incidente. L’APT UNC4736 collegato alla Corea del Nord è stato citato per primo.
Venerdì 20 aprile Mandiant ha pubblicato il prima analisi dell’accaduto. Sono state pubblicate le regole di rilevamento YARA e Snort.
Lo stesso giorno, il CEO di 3CX ha pubblicato un nuovo post, dal nome suggestivo “Azioni, non parole: il nostro piano d’azione per la sicurezza in 7 fasi!”. Il sottotitolo è piuttosto interessante: “Garantire il futuro di 3CX dopo un progetto a cascata unico nel suo genere attacco alla catena di fornitura software-in-software.” Le fasi della carta della sicurezza redatta sono:
- Rafforzare più livelli di sicurezza della rete.
-
Il rinnovamento crea sicurezza.
-
Revisione continua della sicurezza del prodotto.
-
Miglioramento delle funzionalità di sicurezza del prodotto.
-
Esecuzione di test di penetrazione continui.
-
Perfezionamento della gestione delle crisi e del piano di gestione delle allerte.
-
Istituzione di un nuovo dipartimento per le operazioni di rete e la sicurezza.
Gli analisti terranno d’occhio questo lodevole programma, anzi…
Conseguenze: come ha reagito l’industria
Sono passate solo poche settimane da quando l'incidente è stato pubblicato. Ma l’industria sta reagendo.
CVE-2023-29059 è stato assegnato. Ad oggi, ha un punteggio di rischio CVSSv7.8 di 3 (ALTO). I prodotti 3CX hanno solo 16 CVE elencati, il che sembra buono se confrontato con i vendor con livelli di implementazione simili. Ma questo incidente non è la solita vulnerabilità in effetti. Questo è un attacco mirato attivo da parte di una minaccia persistente attiva (APT), come il CISIl più riconosciuto degli O.
Migliori CWE-506 "Embedded Malicious Code" che categorizza questo incidente non ci aiuta molto a capire come prevenire tali attacchi alla supply chain del software. Sfortunatamente, i cattivi hanno molti modi per distribuire malware, con gli attacchi alla supply chain come nuovo gioiello della corona nel loro arsenale. CWE-506 dovrebbe essere migliorato per riflettere gli scenari attuali, inclusi quelli basati sulla violazione del sistema di build.
L'APT, denominato UNC4736 da Mandiant, utilizza tattiche e tecniche simili al noto Lazarus Group (APT38), creato dallo Stato nordcoreano e dagli autori della campagna ransomware WannaCry del 2017. Tali legami tra cattivi attori negli stati stalinisti con orari di lavoro regolari sono difficili da stabilire, ma i ricercatori CrowdStrike and ESET hanno scoperto che le tattiche, le tecniche e le procedure (TTP) utilizzate assomigliano a quelle di uso comune da Lazarus APT38. Comprendere come operano è essenziale per l’individuazione, la prevenzione e l’eradicazione.
Conoscere i propri obiettivi, avvolti nel mistero, è ancora più difficile.
Questo attacco è abbastanza importante che CISA, l'Agenzia statunitense per la sicurezza informatica, ha emesso un consultivo con i post del fornitore e i link a più analisi sull'attacco alla supply chain. Leggerli è importante per i professionisti della sicurezza informatica.
L'incidente ci ricorda l'attacco SolarWinds. Dato l’enorme impatto, molti fornitori si sono affrettati ad analizzare i programmi di installazione dei prodotti desktop VoIP infetti. Ma questo è l'ultimo passo. Sono necessari ulteriori dettagli per comprendere cosa non ha funzionato con la sicurezza dei sistemi di build delle due organizzazioni interessate e quali misure hanno intrapreso i malintenzionati per influenzare tali sistemi di build e sono riusciti a inserire il malware durante la build. Altrimenti, questo incidente si ripeterà ancora e ancora.
E ora, lezioni apprese!
Praticare uno sport di squadra ascoltando qualcuno della tua squadra che spiega ogni minuto di gioco successivo distrugge lo spirito più temperato. Ma qui in Spagna tutti sono allenatori della nazionale di calcio! Quindi lasciatemi interpretare Pep Guardiola, José Mourinho, Alex Ferguson e Arrigo Sacchi tutti insieme.
Agisci come se il tuo sistema di costruzione fosse sotto il fuoco dell'artiglieria pesante. Forse non è possibile impedire a un dipendente di installare software non autorizzato sui PC di lavoro. Probabilmente, i team di ingegneri potrebbero richiedere politiche più rigorose. Ma sii vigile durante la creazione e la distribuzione pipeline. Se fornisci software ai clienti, la sicurezza su come crei il software dovrebbe essere importante quanto la sicurezza del prodotto software.
Preparazione agli incidenti. È difficile, forse sterile, prevedere gli scenari più probabili per incidenti di sicurezza. Dovrei imparare a usare un defibrillatore? No, a meno che non viva con una propensione a tessereiac arresto. Ma per l'amor del cielo! Preparatevi a "ricostruire la vostra build" da zero, con revoca + rinnovo di chiavi, token di accesso, coppie di chiavi pubbliche e certificati.
I sistemi di costruzione devono avere determinate caratteristiche: L'attuale tendenza verso costruzioni in ambienti effimeri e con strutture isolate/prive di parametri/ermetiche e persino riproducibili potrebbe costituire il quadro per prevenire attacchi come quello su 3CX Supply Chain Attack quando integrati con requisiti aggiuntivi su altri sistemi nella build e distribuzione pipeline. Vedere Requisiti di creazione di Google SLSA per riferimento.
La corretta comunicazione è fondamentale. La trasparenza è obbligatoria. Minimizzare il problema o nasconderlo sotto il tappeto è la cosa peggiore che qualsiasi organizzazione possa fare. Gli incidenti di sicurezza spesso colpiscono più duramente la reputazione che altre risorse e una cattiva comunicazione dopo la violazione potrebbe essere catastrofica.
Trasformare i problemi in opportunità. Un buon incidente può innescare miglioramenti nei controlli di sicurezza che non sono mai stati inseriti nel rigido piano di prodotto. Anche cose essenziali come l'hashing corretto delle password e la documentazione sulla configurazione/rafforzamento della sicurezza potrebbero essere pianificate a breve termine. Ma per gli attacchi alla catena di fornitura, il rafforzamento dei sistemi di creazione e l'aggiunta di attestazioni e controlli di integrità in ogni fase della creazione e distribuzione pipelinesono essenziali. Non dovrebbe essere così facile per un utente malintenzionato impiantare tali modifiche nel sistema di build.
Preparatevi. Altrimenti, la vostra organizzazione potrebbe trovarsi di fronte a una minaccia esistenziale, come l'attacco alla supply chain del software 3cx.





