Questo è il quarto episodio della serie di post sui componenti dannosi, dove presentiamo il Xygeni approccio per gestire questa minaccia, come parte della nostra copertura per Open Source Security.
Abbiamo visto che l'eccesso di fiducia nei componenti open source di origine incerta viene sfruttato da malfattori di ogni tipo per ottenere comportamenti inaspettati da eseguire nelle macchine degli sviluppatori, CI/CD sistemi, o incorporato nel software dell'organizzazione vittima, in modo che venga trasmesso ai clienti dell'organizzazione. Abbiamo sezionato in episodio n. 2 gli attacchi che utilizzano registri pubblici per distribuire malware e ciò che abbiamo imparato dopo aver osservato come operano i malintenzionati e in precedenza episodio n. 3 sono stati esaminati i controlli che funzionano (e quelli che falliscono) contro questa minaccia.
Ora è il momento di esaminare il nostro approccio al problema. In questo episodio presentiamo qual è la strategia che seguiamo in Xygeni per il nostro Avviso tempestivo di malware (MEW). Come funziona questo sistema a più fasi in tempo reale quando viene rilasciata una nuova versione del pacchetto, come vengono acquisite prove da diverse fonti, come viene eseguito il triage, quali criteri di classificazione stiamo seguendo e perché sono ancora necessarie alcune analisi manuali per confermarne la natura di un candidato pacchetto dannoso. Spiegheremo anche come stiamo aiutando NPM, GitHub, PyPI e altre infrastrutture chiave negli ecosistemi open source a ridurre il tempo di permanenza del malware.
Migliori pipeline
Xygeni Malware Early Warning (MEW) elabora continuamente componenti, ovvero pacchetti tarball per librerie e framework per ecosistemi di programmazione supportati come JavaScript/Node o Python, immagini di contenitori Docker/OCI o estensioni e plugin per strumenti come IDE o CI/CD sistemi. Tali componenti sono pubblicati in registri pubblici con diversi livelli di verifica degli utenti.
Di seguito è riportato uno schema di funzionamento del sistema:
Migliori scopritore il processo ottiene il feed degli eventi di pubblicazione. Un evento di pubblicazione è la creazione di una nuova versione di un componente nuovo o esistente. Poiché i registri popolari non forniscono un meccanismo pub-sub per i consumatori interessati, ciò viene spesso fatto interrogando il registro per gli eventi recenti. Un eccellente progetto dell'OSSF, feed di pacchetti, Di supporto registri popolari come PyPI o Maven Central e forniscono un'interfaccia unificata basata sui feed. In MEW abbiamo aggiunto alcune implementazioni specifiche che riducono i tempi di attesa, ad esempio con una replica del database CouchDB utilizzato da NPM che è sincronizzato con il database del registro pubblico.
In Xygeni abbiamo un inventario[1] di tutti i componenti (direttamente o indirettamente) utilizzati dai software dei nostri clienti. Le coordinate dei componenti dei clienti vengono regolarmente fornite a MEW per dare priorità alle analisi: i componenti utilizzati dai nostri clienti vengono elaborati prima. La priorità si basa anche sulla reputazione dell'editore e sulla criticità del componente, quindi viene data priorità anche ai componenti provenienti da editori con bassa reputazione.
Migliori Gli analizzatori quindi consumare i componenti in sospeso nella coda di priorità. Quando la versione di un componente viene selezionata per l'analisi, il relativo file tar viene scaricato dal registro. Si noti che viene analizzato il componente binario confezionato: la maggior parte dei componenti open source proviene in genere da un repository open source, spesso su github.com, che viene utilizzato solo per il contesto, e il malware viene sempre cercato nel tarball del componente perché gli autori delle minacce sistematicamente mentono sulle fonti che affermano di aver utilizzato per creare il componente tarball che rilasciano.
Dal punto di vista dell'utente
Ti sento pensare: come posso trarre vantaggio dalla conoscenza anticipata di una versione di un pacchetto dannoso? Nell'episodio "Anatomia dei pacchetti dannosi: quali sono le tendenze?" abbiamo visto che il tempo di permanenza totale è dell'ordine dei giorni, mentre la prima notifica da parte di MEW ai clienti che utilizzano il componente interessato è dell'ordine dei minuti. Con un semplice guardrail[2] puoi bloccare la build (ci sono due livelli di avviso, uno completamente automatizzato quando il motore conclude che esiste un potenziale malware e una notifica successiva quando il nostro team di sicurezza conferma tramite ispezione manuale la presenza di malware). Aspettare che il registro confermi il malware e lo rimuova dal registro è in genere troppo tardi a causa della lunga finestra di esposizione.
L'organizzazione può utilizzare un guardrail che controlla se è presente un componente con potenziale malware (in uno qualsiasi dei due livelli di avviso) o, tramite API, sapere rapidamente se una qualsiasi delle dipendenze dirette o indirette in un progetto software utilizza un componente dannoso.
Come funziona MEW: dettagli interni
Il nucleo: motore di rilevamento malware
L'analizzatore utilizza diversi rilevatori per acquisire prove di illeciti. I rilevatori combinano analisi statica, analisi delle capacità e analisi del contesto[3], come descritto nel post precedente di questa serie.
In Xygeni abbiamo un team di ingegneri con una lunga esperienza nell'analisi statica, e questa è la differenza principale con altre soluzioni anti-malware. Tieni presente che per alcuni ecosistemi il tarball impacchettato contiene codice sorgente (ad esempio codice JavaScript o TypeScript per pacchetti NPM, sorgenti Python per pacchetti PyPI) o codice compilato sufficientemente vicino al codice sorgente per l'analisi statica (ad esempio bytecode nei file JAR per Maven) . Per altri, come le immagini del contenitore, gli eseguibili binari sono comuni, quindi l'inferenza delle capacità è la tecnica utilizzata, insieme al rilevamento convenzionale del malware basato sulle regole YARA e sulle firme del malware.
Tieni presente che tecnologie semplici come le espressioni regolari o le firme non sono appropriate per rilevare comportamenti dannosi. Immagina di rilevare un dropper o un downloader: parte del codice o del file binario si trova nel pacchetto o è scaricato da un dominio esterno, non correlato al componente (potrebbe essere uno da un dominio esterno) ampio elenco di domini acquistati dall'autore della minaccia[4] dominio legittimo per eludere il rilevamento). Quel codice viene quindi eseguito utilizzando una delle funzioni per quello. Il codice può essere trasformato per nascondere l'URL di download o la funzione utilizzata per eseguire il codice scaricato. Per rilevarlo è necessaria un'analisi completa del flusso di dati, utilizzando l'intero meccanismo dell'analisi statica o un'esecuzione in modalità sandbox (se le condizioni per l'esecuzione di un comportamento dannoso sono effettivamente soddisfatte) potrebbe rilevarlo nel caso generale.
Gli autori delle minacce seguono le stesse tecniche e per loro sono stati progettati e implementati rilevatori. Esistono anche alcuni passaggi di pre-elaborazione, ad esempio per rimuovere l'offuscamento, spesso necessari per scoprire il comportamento nascosto.
Aggiunta di contesto
Alcuni rilevatori utilizzano informazioni di contesto. Ad esempio, una mancata corrispondenza tra la versione nel registro del componente e il tag/release nel repository GitHub associato costituisce una prova evidente che forse un malintenzionato ha ottenuto credenziali di pubblicazione per il registro ma non per il repository GitHub. Attacchi come quello che ha colpito il venditore di portafogli crittografici Ledger potrebbe essere facilmente rilevato da questa mancata corrispondenza.
A punteggio di malizia (MS) viene calcolato dai risultati dei rilevatori, in base alla forza delle prove acquisite. Non tutti i risultati sono uguali e l'ordine di esecuzione è rilevante.
Reputazione degli utenti e dei componenti
Non tutti gli sviluppatori open source sono uguali!
Uno sviluppatore rispettabile potrebbe subire il dirottamento del suo account NPM (questo accade anche a persone attente alla sicurezza) e il malware pubblicato utilizzando quell'account. Ovviamente la reputazione dovrebbe cadere bruscamente e tornare alla gloria passata solo quando l'account violato viene recuperato e lo sviluppatore risolve le condizioni che hanno portato alla presa del controllo dell'account. La reputazione è difficile da guadagnare ma può essere persa in un istante.
Noi di MEW abbiamo implementato un sistema completo di gestione della reputazione per premiare i comportamenti positivi e penalizzare le attività sospette. Questo sistema inizia con i nuovi utenti in una posizione neutrale e adatta la loro reputazione in base alle loro attività in corso.
La reputazione di un utente migliora attraverso azioni positive come il mantenimento di account di social media attivi, l'abilitazione dell'autenticazione a più fattori, il contributo regolare ai progetti e la firma commits con chiavi verificabili. Al contrario, la reputazione si deteriora a causa di azioni ostili come la pubblicazione di malware, l’utilizzo di indirizzi e-mail usa e getta e la mancata firma commits, o esibire modelli insoliti nei contributi.
L'obiettivo principale del nostro sistema è garantire un ambiente sicuro e affidabile. Ciò si ottiene adattando dinamicamente la reputazione degli utenti in base a vari fattori, rispettando al tempo stesso le preoccupazioni sulla privacy e le limitazioni dei diversi registri.
Viene calcolato un punteggio di reputazione interna per l'utente (unendosi al registro e all'account github quando possibile) e insieme al punteggio di dannosità utilizzato durante la classificazione del componente in analisi e per qualificare meglio chi si trova nella pubblicazione del componente.
Sono state trovate prove di comportamenti dannosi. E allora? Il processo di revisione manuale
L'attuale classificatore imposta la versione del componente analizzata in una delle categorie "dannoso confermato", "probabilmente dannoso", "ad alto rischio", "a basso rischio" o "non dannoso" in base alle soglie dei punteggi che condensano i risultati e la reputazione dell'utente/componente. Una classificazione nelle categorie “ad alto rischio” o “probabilmente dannoso” attiva la revisione manuale e la prima notifica. La categoria "dannosa confermata" viene impostata dopo la revisione manuale o quando le prove corrispondono alle stesse prove per una versione precedente che è stata confermata dannosa.
Quando esistono prove sufficienti di un potenziale comportamento dannoso, viene emesso un primo avviso (avviso di quarantena) alle organizzazioni interessate. Come accennato in precedenza, ciò potrebbe bloccare l'installazione o la creazione di software che dipende dal componente in quarantena.
Ciò crea un problema all’interno del MEW dashboard pertanto gli analisti della sicurezza possono avviare il processo di revisione manuale del componente. Il team dispone di strumenti specializzati (sandbox, deoffuscatori, distribuzione per la ricerca di malware, strumenti di segnalazione di malware) per valutare rapidamente la natura della versione del componente sotto indagine. La maggior parte del malware ("le acciughe" o componenti dannosi non sofisticati) viene esaminata
Il risultato della revisione si conclude in entrambi sicura, quindi il motore di analisi automatica ha rilevato un falso positivo che viene utilizzato come feedback al classificatore di apprendimento automatico per apprendere il modello; O confermato dannoso, pertanto il componente viene responsabilmente segnalato come dannoso al registro pubblico, seguendo il processo di segnalazione. Una seconda notifica viene inviata alle organizzazioni interessate, che a loro volta possono farlo rimuovere la quarantena dal componente o bloccarlo definitivamente dal processo di aggiornamento della versione o dal firewall del componente utilizzato nel registro interno.
Questa impostazione ci consente di analizzare decine di migliaia di nuove versioni ogni giorno e identificare le decine probabilmente dannose, che poi esamineremo manualmente. Ricorda dall'episodio precedente che uno su diecimila è il tasso di componenti dannosi che vediamo attualmente in circolazione.
Segnalazione al Registro
Abbiamo scoperto che la maggior parte dei registri pubblici, una delle colonne portanti dell’infrastruttura open source, fornisce meccanismi piuttosto limitati per segnalare problemi di sicurezza e, in particolare, componenti dannosi. Stiamo lottando per migliorare l’organizzazione alla base del processo di reporting. In genere riceviamo al massimo un'e-mail di feedback dal team di sicurezza del registro che conferma che il componente è stato rimosso dal registro.
A volte si abusa del registro, infrangendo i termini di utilizzo, ma senza causare comportamenti dannosi nel software fornito. Anche questo viene segnalato all'anagrafe, ma non viene notificato alle organizzazioni per limitare il rumore.
Lavoro futuro
Molti miglioramenti sono attualmente sulla tabella di marcia. Innanzitutto, a portale pubblico per l'integrità dei componenti del sistema operativo, in particolare relativo alle prove rilevate per potenziali attività dannose, è attualmente in fase di sviluppo. Questo è inteso come un modesto contributo alla comunità open source. Rimani sintonizzato.
Un altro sviluppo in corso è un miglioramento classificatore di apprendimento automatico. MEW imparerà dalle classificazioni passate. Il vettore di risultati dai rilevatori del motore, più il punteggio di malevolenza derivato e il punteggio di reputazione sia per il componente che per l'editore ("le prove trovate") vengono utilizzati come input per un sistema di apprendimento automatico che aggiorna il modello di classificazione. La variabile di output è semplicemente se il registro ha confermato se il componente era malevolo. Questo è il nome in codice "l'Oracolo" e aiuterà con un precise qualificatore, progettato per essere valido (elevato richiamo, ovvero non tralasciare componenti dannosi) ma con meno falsi positivi (non segnalare componenti sicuri come dannosi).
A punteggio di criticità verranno aggiunti per criteri di priorità, oltre che per l'appartenenza all'insieme delle dipendenze dei clienti e per la scarsa reputazione dell'editore. È chiaro che i progetti con maggiore influenza e importanza dovrebbero essere considerati prima per l'analisi. Non reinventeremo la ruota qui e seguiremo il Punteggio di criticità del progetto Open Source.
Il supporto per ulteriori ecosistemi è in fase di sviluppo. Tecnologie e strumenti diffusi come PHP o plugin Jenkins sono nella tabella di marcia.
Stiamo anche esplorando se il processo di revisione manuale possa essere aiutato con l’intelligenza artificiale per semplificare l’analisi per i pochi componenti dannosi più sofisticati.
Nella puntata successiva e finale di questa serie, “Sfruttare l'Open Source: cosa aspettarsi dai cattivi", ci concentreremo sulle ultime modalità adottate dagli avversari per rendere gli attacchi più furtivi, più difficili da rilevare, più mirati a settori specifici e più redditizi. Gli attacchi ransomware verranno sferrati utilizzando questo veicolo? In che modo i malintenzionati sfruttano gli strumenti di intelligenza artificiale per distribuire malware più sofisticati? I progetti più popolari sono a rischio? Questo per dare ai lettori un’idea di questa corsa agli armamenti e di cosa aspettarsi a breve termine (seconda metà del 2024) e a medio termine (2025).
Concluderemo con alcune riflessioni su quali piccoli passi la comunità potrebbe compiere senza cambiare troppo l'apertura del mondo open source. Ad esempio, un meccanismo più efficiente per segnalare malware ai registri pubblici e condividere prove di componenti potenzialmente dannosi con i registri e la comunità rappresenterebbe un piccolo passo nella giusta direzione verso l’obiettivo di chiudere le porte agli autori delle minacce.
Il malware presente nei componenti open source non dovrebbe interrompere gli enormi vantaggi che la comunità open source ha apportato alla nostra società.
- [1] Il nostro scanner rileva i componenti open source a cui fanno riferimento i progetti software analizzati, quindi è noto il grafico delle dipendenze completamente aggiornato, almeno per i progetti che vengono scansionati regolarmente. L'OSS Xygeni espone un'API che i clienti possono utilizzare anche durante l'inserimento nella whitelist di un componente di interesse, comprese informazioni su vulnerabilità e prove dannose.
- [2] Un guardrail potrebbe interrompere la costruzione se viene rilevata una condizione che corrisponde a problemi di sicurezza. Risultati di sicurezza come una vulnerabilità critica e raggiungibile o l'uso di un componente in quarantena potrebbero essere considerati sufficientemente gravi da interrompere la build del software interessato.
- [3]I nostri analisti della sicurezza eseguono il componente o i relativi script di installazione in un ambiente sandbox quando necessario. Tuttavia, MEW non esegue analisi dinamiche, principalmente perché il comportamento dannoso non viene sempre eseguito in attacchi mirati e a causa della logica di evasione utilizzata dagli autori delle minacce per eludere l'analisi dinamica.
- [4] A questa tecnica è stato dato un nome, Registered Domain Generation Algorithms o RDGA, e nuovi autori di minacce come i cosiddetti Coniglio di rivoltella ha investito fino a 1 milione di dollari in 500 domini, dimostrando quanto sia redditizio il settore del crimine informatico.
