Alla fine di marzo 2023, i ricercatori di sicurezza hanno scoperto l'identità di un autore di minacce attacco complesso alla catena di fornitura del software sul software di comunicazione aziendale di 3CX, principalmente l'app desktop per chiamate vocali e videochiamate dell'azienda. I ricercatori hanno avvertito che l'app era in qualche modo trojanizzata e che il suo utilizzo avrebbe potuto esporre l'organizzazione a un possibile piano di esfiltrazione da parte di un autore di minacce. L'attacco è stato soprannominato "Smooth Operator" e ci sono alcune prove che suggeriscono che sia in corso da mesi.
Allora, cosa è successo esattamente, in che modo l'utilizzo di questa versione con trojan ti mette a rischio e come si sarebbe potuto prevenirlo utilizzando la firma e la verifica del software?
Per prima cosa: cos’è 3CX?
3CX è un PBX IP (Private Branch Exchange) basato su software e standard aperti che sostituisce un PBX hardware tradizionale. È progettato per consentire alle aziende di effettuare e ricevere chiamate utilizzando la tecnologia VoIP (Voice over Internet Protocol), che trasmette comunicazioni vocali su Internet. 3CX include anche funzionalità avanzate come videoconferenza, presenza, messaggistica istantanea e altro ancora e può essere implementato on-premise o nel cloud. Windows, macOS e Linux sono solo alcuni dei sistemi operativi più diffusi su cui è disponibile l'app. Inoltre, il client è accessibile tramite browser grazie a un'estensione Chrome e il client ha anche una versione PWA, oltre ad essere disponibile come applicazione mobile per dispositivi Android e iOS.
Puoi farti un’idea dei potenziali effetti di un attacco alla catena di fornitura del software dal sito web 3CX, che vanta 600,000 aziende che utilizzano la loro app con oltre 12 milioni di utenti giornalieri.
Un'anteprima dell'attacco: cosa devi sapere
Questo è un po' complesso, quindi lo suddivideremo in passaggi:
- Scarichi un versione con trojan dell'app desktop oppure l'hai già installata e aggiornala semplicemente con una versione con trojan.
- L'eseguibile 3CXDesktopApp.exe carica una libreria di collegamento dinamico (DLL) dannosa chiamata ffmpeg.dll.
- ffmpeg.dll viene utilizzato per estrarre un payload crittografato da d3dcompiler_47.dll ed eseguirlo.
- Il malware scarica quindi file di icone dall'aspetto innocente ospitati su GitHub che contengono stringhe codificate Base64 aggiunte alla fine delle immagini.
- Tali dati codificati vengono quindi decodificati e utilizzati per scaricare un'altra fase, contenente il server C&C crittografato a cui si connette la backdoor per recuperare il possibile carico utile finale.
- Nella fase finale viene messa in pratica la funzionalità di info-stealer, inclusa la raccolta di dati di sistema e dati del browser dai browser Chrome, Edge, Brave e Firefox. Ciò può includere l'esecuzione di query sulla cronologia di navigazione e sulle informazioni dalla tabella Luoghi, nonché potenzialmente l'esecuzione di query sulla tabella Cronologia.
Inizialmente, 3CX ha minimizzato l'attacco ma in seguito ha ammesso che si trattava di una vera minaccia e ha suggerito di disinstallare e reinstallare l'app con le loro istruzioni specifiche e di utilizzare nel frattempo la versione PWA finché l'azienda non riuscirà a districare l'incidente e mitigarlo.
Un altro fattore molto importante da tenere a mente è che la compromissione include un certificato di firma del codice utilizzato per firmare i file binari infettati dal trojan. Beh, non esattamente: in realtà utilizza una vulnerabilità nota chiamata CVE-2013-3900 (originariamente pubblicato nel 2013 ma aggiornato nel 2022 e di nuovo questa settimana) per farcela apparire legittimamente firmato.
Déjà Vu: questo è già successo prima
Se questa storia di a La versione con trojan di 3CX suona familiare perché è già accaduta in precedenza.
In questo caso, sei tuNon è chiaro se una libreria upstream open source utilizzata dall'azienda sia stata infettata o se un attacco effettivo abbia violato l'ambiente di sviluppo dell'azienda.
In altri attacchi famosi, da "Kingslayer" (2016) a "CCleaner" (2017), "VestaCP" (2018), "WIZVERA VeraPort" (2020) e fino a "SolarWinds" (2020), si tratta di un pratica comune degli autori di minacce per tentare di compromettere i server di un'azienda, l'ambiente di creazione o il relativo eseguibile scaricabile. Dopotutto, mascherare qualcosa di brutto e pericoloso come qualcosa di cui ti puoi fidare è un ottimo modo per convincere le persone a fidarsi e scaricare il tuo carico utile.
Questo fa parte della definizione di a attacco alla catena di fornitura del software – gli aggressori hanno compromesso la catena di fornitura del software per distribuire software dannoso a un gran numero di vittime. In ciascuno di questi famosi casi, gli aggressori sono riusciti a inserire codice dannoso in pacchetti software legittimi, che sono stati poi distribuiti agli utenti. Gli aggressori sono spesso riusciti a farlo compromettendo un fornitore o fornitore di software affidabile, come un server di aggiornamento software o un certificato di firma del codice.
Facendo sì che clienti ignari scarichino una versione modificata di un'applicazione legittima, gli aggressori possono essenzialmente nascondere quasi qualsiasi cosa al suo interno.
Ed ecco il problema principale: "ignaro". Dopotutto, l'eseguibile, il binario o l'immagine provengono dall'azienda creatrice, apparentemente approvati da questa, e contengono anche un certificato firmato. Cos'altro può fare un cliente? Dovrebbero chiamare l'azienda per verificare ogni aggiornamento? Scansionare il codice (se disponibile) per l'esistenza di backdoor? Ciò è assurdo e irrealistico. Ma lì is qualcosa che può essere fatto.
Come è possibile aggiungere un livello di fiducia oltre un certificato?
Il modello proposto è abbastanza semplice e si basa sulla stessa idea dei certificati di firma del codice. Un certificato di firma del codice è un certificato digitale emesso da una terza parte utilizzato per firmare digitalmente software o codice. Quando il software viene firmato con un certificato di firma del codice, consente agli utenti di verificare l'autenticità e l'integrità del software prima di installarlo o eseguirlo.
I certificati di firma sono emessi da terze parti fidate autorità di certificazione (CA), che verificano l'identità dell'editore del software e l'integrità del codice del software. L'autorità di certificazione utilizza algoritmi crittografici per creare una firma digitale del software, che viene poi inclusa nel codice firmato. Quando un utente tenta di installare o eseguire il software, il suo sistema controllerà la firma digitale per garantire che corrisponda alla firma generata dall'autorità di certificazione. Se le firme corrispondono, il software è considerato autentico e non è stato manomesso da quando è stato firmato.
Questo sistema si basa sulla crittografia a chiave pubblica, nota anche come crittografia asimmetrica, un metodo di crittografia che utilizza due chiavi diverse, una chiave pubblica e una chiave privata, per crittografare e decrittografare i dati. Nel contesto della firma del codice, per firmare software e codice viene utilizzata una coppia di chiavi pubblica-privata.
In questo processo, l’editore del software genera una coppia di chiavi pubblica-privata, in cui la chiave privata viene mantenuta segreta e la chiave pubblica viene resa disponibile ad altri. L'editore del software utilizza quindi la propria chiave privata per creare una firma digitale del software o del codice che desidera firmare. Questa firma digitale è un valore hash generato eseguendo il software o il codice attraverso un algoritmo matematico e quindi crittografando il valore hash risultante con la chiave privata dell'editore.
Quando un utente scarica il software o il codice firmato, il suo sistema utilizza la chiave pubblica dell'editore del software per decrittografare la firma digitale e verificare che corrisponda al valore hash del software o del codice scaricato. Se la firma digitale è valida, l'utente può essere certo che il software o il codice non sono stati manomessi da quando sono stati firmati dall'editore del software.
Sulla base di questo semplice concetto, la soluzione proposta è firmare ogni nuova versione, file binario e immagine direttamente con la chiave dell'azienda o con la chiave della pipeline di creazione e chiedere semplicemente all'utente di verificare la firma quando scarica o aggiorna il software.
Naturalmente le cose non sono sempre così semplici. Se i malintenzionati si sono infiltrati nel server di build, firmare la build lì è già inutile. Se l’infrastruttura chiave è stata compromessa, l’intero esercizio è altrettanto inutile.
Ma chiedere agli utenti di verificare una firma, qualcosa di veloce e semplice che può essere fatto automaticamente, è un piccolo prezzo da pagare per aiutare a prevenire il prossimo attacco alla catena di fornitura del software.
Ma aspetta, potresti dire, e se fosse effettivamente una libreria open source a monte la fonte della contaminazione? In tal caso, firmare una build è, ancora una volta, inutile poiché il codice compromettente è "integrato".
È qui che dobbiamo iniziare a considerare un ecosistema di fiducia basato sulla firma e sulla verifica di queste firme. Se questi pacchetti open source fossero firmati e le firme fossero verificate quando sono state incorporate nel codice dell'azienda, ciò potrebbe ridurre la probabilità di una violazione.
Dove entra in gioco lo scriba
Scriba ha implementato uno strumento chiamato Valente che consente di firmare e verificare file, cartelle e immagini. Senza la necessità di mantenere complicati sistemi PKI, lo strumento implementa un nuovo approccio che prevede l'utilizzo della tua identità verificata già stabilita (come ad esempio la tua identità Google, Microsoft, GitHub o AWS) per firmare l'artefatto desiderato. Successivamente potrai utilizzare lo stesso strumento per verificare che l'artefatto sia stato firmato e quale fosse l'identità utilizzata per firmarlo.
Supponiamo che la pipeline di compilazione produca un'immagine del contenitore come artefatto finale. Subito dopo aver creato l'immagine, dovresti firmarla e caricare la versione firmata nel repository dove i tuoi clienti potranno scaricarla. Una volta firmata, l'immagine non può più essere modificata: è bloccata. Chi vuole può verificare sia che sia firmato sia che l'identità del firmatario corrisponda a quanto pubblicato dall'azienda.
Questo strumento è solo una parte delle capacità concesse implementando il Soluzione SaaS di Scribe per la tua organizzazione Con l'obiettivo di migliorare sia la sicurezza della catena di fornitura del software che la trasparenza generale, ci sono tutte le ragioni per andare a verificare ciò che Scribe può offrirti.
Questo contenuto è offerto da Scribe Security, un fornitore leader di soluzioni di sicurezza end-to-end per la catena di fornitura di software, che offre sicurezza all'avanguardia per artefatti di codice e processi di sviluppo e distribuzione del codice attraverso le catene di fornitura di software. Per saperne di più.
Post Correlati
