Questo è il primo episodio di una serie di articoli sul tipo più diffuso di attacchi alla catena di fornitura del software: quelli che (ab)utilizzano un registro pubblico di componenti software, destinati a progetti open source per caricare artefatti che potrebbero essere condivisi con altri utenti. Quando i malintenzionati pubblicano lì software dannoso, utilizzando il registro come veicolo per la distribuzione del malware, si verifica un attacco alla catena di fornitura quando le organizzazioni vittime installano o eseguono il componente software infetto.
Per semplificare il discorso di cui parleremo pacchetti software:, componenti in forma confezionata prodotti da terze parti. Ciò include non solo i componenti utilizzati dai gestori di pacchetti come NPM o Poetry, ma anche componenti del sistema operativo comprese librerie e binari eseguibili, immagini del contenitore, e macchine virtuali, o estensioni degli strumenti per strumenti di sviluppo, compilazione e distribuzione. Abbiamo visto pacchetti dannosi ovunque. I criminali informatici non se ne preoccupano: sono deliziati dalle alternative fornite dalle moderne infrastrutture software e utilizzano il registro e lo strumento che meglio si adattano al loro intento. Quindi, ricordate che i pacchetti software sono una scorciatoia per immagini di container, pacchetti binari, repository open source ed estensioni o plugin di ogni tipo (IDE, CI/CD sistemi, strumenti di compilazione). Tutti sono regolarmente sotto attacco.
La serie avrà 5 episodi:
- Qual è il problema con i pacchetti Open Source? Questo è il tema di questo post. Perché criminali di ogni tipo pubblicano pacchetti dannosi? Perché dovrei preoccuparmi?
- Anatomia dei pacchetti dannosi: quali sono le tendenze? In questo episodio ci concentriamo sulla minaccia che monitoriamo giorno dopo giorno con il nostro sistema MEW. Con un grande rumore di fondo dovuto a un gran numero di pacchetti dannosi che utilizzano typosquatting o confusione di dipendenze, una percentuale minore di attacchi è molto più insidiosa e rappresenta un rischio maggiore. Come è cambiato il comportamento dei malintenzionati nei confronti del sistema operativo nel recente passato? Quali sono i numeri? Quali sono le tattiche, le tecniche e le procedure utilizzate e le azioni dannose osservate?
- Protezione dai pacchetti dannosi open source: cosa (non) funziona. La maggior parte dei professionisti attenti alla sicurezza hanno idee su come gestire questa minaccia. Abbiamo sentito responsabili della sicurezza dire senza esitazione che SCA strumenti ti dicono già quando una versione del pacchetto è un malware. O che dipendono da componenti software noti e altamente recensiti, dove qualsiasi malware verrebbe prontamente rilevato e rimosso. Che usano versioni minori/patch aperte per ottenere automaticamente correzioni di vulnerabilità, e questo è il modo corretto e consigliato per ridurre il rischio sulle dipendenze open source, seguendo il principio "patch early, patch Often". In questo episodio, esamineremo perché queste idee sono sbagliate e come tali idee sbagliate stanno contribuendo alla popolarità di questo meccanismo di attacco e a un rischio schiacciante che le organizzazioni stanno vivendo. Concluderemo con cosa funziona e quali sono gli sforzi e le risorse coinvolti.
- Pacchetti dannosi open source: l'approccio Xygeni. In questo episodio presentiamo la strategia che seguiamo in Xygeni per il nostro sistema Malware Early Warning (MEW). Come funziona questo sistema a più fasi in tempo reale quando viene pubblicata 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 confermare la natura di un candidato pacchetto dannoso? In che modo il feedback dei nostri team interni e del registro aiuta il sistema a imparare dalle prove passate raccolte per ridurre al minimo i falsi positivi. NoiE spiegheremo come stiamo aiutando NPM, GitHub, PyPI e altre infrastrutture chiave negli ecosistemi open source open source a ridurre i tempi di permanenza.
- Sfruttare l'Open Source: cosa aspettarsi dai cattivi. La serie si conclude concentrandosi sulle azioni più recenti che gli avversari stanno adottando per rendere gli attacchi più furtivi, più difficili da rilevare, più mirati contro settori specifici e per ottenere maggiori benefici da questa classe di attacchi. Gli attacchi ransomware verranno sferrati utilizzando questo veicolo? In che modo i criminali sfruttano gli strumenti di intelligenza artificiale per fornire pacchetti dannosi più sofisticati? I progetti più popolari sono in pericolo? 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). Impareremo come attacchi come il recente XZ-Utils Backdoor, o l'attacco dei vivi fuori dalla terra costruttore di elettroni nel marzo marzo 2024 stanno dimostrando che dovremmo restare vigili su come si evolvono gli avversari.
Apriamo il palco con il primo episodio: cosa sta succedendo con i pacchetti open source dannosi?
Qual è il problema con i pacchetti Open Source?
Negli ultimi anni, malfattori di ogni tipo hanno utilizzato registri di software open source open source per fornire comportamenti dannosi. Queste attività sono vecchie quanto l'open source, ma la loro frequenza è esplosa negli ultimi tre anni.
Pubblicazione di componenti dannosi nei registri pubblici (attacchi basati sulle dipendenze) è una guerriglia asimmetrica che gli autori delle minacce utilizzano per distribuire malware, sfruttando la fiducia che le organizzazioni ripongono in componenti open source provenienti da sviluppatori sconosciuti (ricordate il dipendenza xkcd fumetto?). Poiché ti fidi dei pacchetti e non ti dispiace rivedere manualmente il contenuto del pacchetto e le sue dipendenze, questi attacchi sono straordinariamente efficaci. E l’asimmetria deriva dal fatto che possono essere ampiamente automatizzati e i malintenzionati non hanno bisogno di interagire direttamente con la vittima. Caricano semplicemente il pacchetto nel registro pubblico e lo lasciano andare.
Pacchetti dannosi è aumentato di un fattore 6x nel 2022, e ha continuato a crescere di un fattore 2.5 volte nel 2023. L'anno scorso sono stati rilevati ben 245,000 pacchetti dannosi, una cifra che più che raddoppia il numero totale rispetto agli anni precedenti messi insieme. Questa è una crescita esponenziale! Dalle rimozioni di pacchetti come malware confermati a centinaia nel 2021 e a migliaia nel 2022, abbiamo notato molto più “rumore” di fondo durante il 2023, con un ritmo simile per quest’anno. E nascosti in quello sfondo causato da criminali informatici non sofisticati che seguono il “percorso della minor resistenza”, una minoranza di attacchi di alto profilo ha fatto notizia anche nei media generalisti.
Perché si tratta di un problema di tale portata? C'è un eccesso di fiducia su tutta la catena. Il software open source viene distribuito con il relativo codice sorgente e rilasciato con una determinata licenza. Sì, chiunque può controllare il codice sorgente; ma chi lo fa in generale? Chi, dopo aver verificato che il software non contenga malware, costruisce il software dai sorgenti? Chi, prima di passare il componente impacchettato (noto anche come a pacchetto) a valle del gestore pacchetti o dello strumento di compilazione, si assicura che il pacchetto non sia pieno di malware e corrisponda al presunto codice sorgente da cui dovrebbe provenire?
Perché l’infrastruttura consente attacchi così facili?
Registri dei pacchetti sono aperti e spesso richiedono una verifica minima dell'identità dell'editore. "Chiunque è benvenuto a pubblicare il proprio software qui!" Il livello per gli aggressori è basso: utilizzano indirizzi e-mail usa e getta e account GitHubgithub usa e getta per creare centinaia di pacchetti dannosi in brevi campagne simili a phishing. Solo per quelli mirati è necessaria una maggiore sofisticazione: abbiamo visto persino la creazione di un repository di sorgenti GitHub credibile con molte stelle e commitprovengono da più contributori falsi e altri parametri di popolarità e mantenimento. Ottenere osservatori delle stelle e reputazione da contributi falsi non è difficile da automatizzare. Abbiamo assistito ad abusi su infrastrutture software aperte di tutti i tipi, non solo malware, come incidente del protocollo del tè.
I gestori di pacchetti sono stati progettati per la facilità d'uso e non per la sicurezza. Possono eseguire script post-installazione pre e post-installazione (a volte è necessaria la compilazione del codice nativo per una libreria). Anche, Gestori di pacchetti installa pacchetti da più fonti e talvolta l'impostazione predefinita è utilizzare registri pubblici. Non hanno verificato la mancata corrispondenza tra i metadati nella richiesta di pubblicazione e i metadati nel pacchetto stesso.
Le dipendenze sono annidate e formano un grafico. In alcuni ecosistemi come Node (JavaScript), le dipendenze a grana piccola si accumulano in centinaia o migliaia. Una cosa è avere uno stretto controllo sulle dipendenze dirette dichiarate dai miei progetti software, ma dipendenze transitive sono più difficili da controllare. L'open source ha seguito “gli amici dei miei amici sono miei amici”. La fratellanza è la norma nel selvaggio Estremo Oriente! Gli autori delle minacce lo sanno e nascondono profondamente il comportamento dannoso in dipendenze oscure e spesso sconosciute. Questo è stato il caso del flusso di eventi incidente che ha preso di mira il Portafoglio Copay.
Questo è il modo in cui ha funzionato il software open source sin dal suo inizio. Non cambierà molto. Alcuni registri di pacchetti richiedono al massimo l'autenticazione a due fattori e spesso solo per i pacchetti più popolari. Alcuni registri forniscono ambiti, uno spazio dei nomi di proprietà di un'organizzazione controllata, ma tragicamente altri non lo supportano (PyPI) o lo rendono opzionale (NPM). È interessante notare che anche a semplice schema di screening (basato sul controllo del repository/organizzazione DNS o GitHub corrispondente all'ID del gruppo) e making Firme PGP obbligatorie per tutti gli artefatti eccetto i checksum rimuove la maggior parte del "rumore", pacchetti dannosi simili a typosquatting e limita gran parte dei confusione di dipendenza. Sono possibili attacchi sofisticati ma molto più difficili, solo pochi come il com.github.codingandcoding:maven-compiler-plugin noto per Maven Central. E non tutti i registri esperti seguono le stesse pratiche!
I controlli di sicurezza sui gestori di pacchetti possono gravare ma non impedire gli attacchi alle dipendenze. Il problema con l'autenticazione a più fattori è che per l'automazione vengono generate credenziali derivate come token di accesso o chiavi APIapi per gli account da utilizzare nelle chiamate APIapi effettuate da script di automazione, senza che l'utente interattivo di supporto fornisca un secondo fattore. L'MFA è utile per proteggere gli account utente dalla fuga di password, ma i token di accesso generati o le chiavi APIapi devono essere protetti mentre sono attivi, altrimenti il loro proprietario verrà impersonato dagli avversari. Gran parte delle campagne della catena di fornitura basate su pacchetti iniziano con una chiave/token trapelato. Ricorda solo incidenti come Ledger, 3CXe molti altri, in cui le credenziali non interattive sono state esfiltrate per la prima volta in un'intrusione preliminare per lanciare l'attacco alla catena di fornitura.
La risposta data a questa minaccia non è stata abbastanza robusta. Nel terzo episodio, ci concentreremo su cosa ha funzionato e cosa ha fallito miseramente. L'industria deve lavorare collettivamente sul standards, processi, istruzione e strumenti per mitigare i rischi per le catene di fornitura globali. Questo non è un problema che una singola organizzazione può risolvere da sola.
Per concludere questa sezione, l'equivoco cruciale: stiamo parlando di maligno pacchetti, no vulnerabile quelli. Le vulnerabilità derivano da errori di progettazione o di codifica, introdotti accidentalmente, senza cattive intenzioni. Le vulnerabilità possono essere sfruttate, ma molte non lo sono. I pacchetti dannosi sono sempre intenzionali e la sfruttabilità è del 100% se vengono eseguiti. Nessun rischio paragonabile! Quindi è paradossale vedere quanti sforzi vengono fatti per individuare e mitigare le vulnerabilità e la mancanza di misure equivalenti per i componenti dannosi.
“Prendiamo sul serio la sicurezza”
Immaginiamo il consueto Acme Corporation. Acme, uno dei principali fornitori di WileCoyote.com, ha la maggior parte del suo software proveniente da terze parti, di cui oltre l'80% proviene da progetti open source. Producono software per uso interno, ma forniscono anche software per partner, fornitori e clienti/utenti finali. Acme dispone di software scritto in Go, JavaScript, Java, C# e Python ed esegue la maggior parte del suo software sul cloud, nei cluster Kuberneteskubernetes. Acme crea le sue immagini personalizzate da immagini di base prese da Docker Hub e altri registri. Inoltre condividono alcune librerie, pacchetti e immagini di contenitori anche nei registri pubblici.
Acme prende sul serio la sicurezza. Sono abbastanza consapevoli del problema open source securitye il rischio che comporta. Tutti gli sviluppatori, i gestori di sistema e gli ingegneri DevOpsdevops utilizzano quelle graziose piccole chiavi crittografiche come autenticazione di secondo fattore. Tutto commiti repository del codice sono firmati, la protezione dei rami è abilitata con revisioni obbligatorie del codice, CI/CD bloccati, segreti archiviati in un caveau segreto e con un registro interno che rispecchia parzialmente i registri esterni in cui sono archiviati solo i componenti consentiti e inseriti nella whitelist. È necessario che il software creato da Acme debba prendere dipendenze di terze parti da questo registro.
Probabilmente la maggior parte delle organizzazioni rientra in questo profilo. Caro lettore, il tuo sicuramente va bene se sei già qui, non è vero?
Poi, un giorno sfortunato, un importante sviluppatore frontend all'Acme correva npm installa acme-cute-lib, dimenticando che @acme/cute-lib era la dipendenza con ambito corretto. L'errore esatto non è importante, molte cose possono andare storte anche quando si assume il perfetto controllo del ciclo di vita del software. Il nostro sviluppatore non sapeva che un gruppo APT stava prendendo di mira Acme e ha pubblicato un componente dannoso con quel nome, in modo astuto in modo che il comportamento dannoso si attivi solo quando il software è installato sui computer Acme. Il pacchetto non è stato rilevato per settimane dopo la sua pubblicazione.
Viene eseguito uno script di installazione che cerca le credenziali (c'erano molti token di accesso interessanti nel laptop del nostro sviluppatore), consentendo l'accesso ai repository software interni e al suddetto repository interno, che ovviamente è accessibile solo tramite VPN. Il codice dannoso è riuscito a utilizzare la connessione VPN esistente e a pubblicare un componente dannoso di seconda fase nel registro interno, colpendo una libreria di utilità comuni condivisa dalla maggior parte dei software forniti da Acme.
Alcune settimane dopo, altre organizzazioni che utilizzavano gli strumenti pubblicati da Acme hanno iniziato a vedere uno strano traffico sulle loro reti, con traffico che utilizzava il protocollo Acme ma era diretto a host simili al dominio Acme. Il traffico era crittografato ma gli strumenti di monitoraggio del sistema hanno rilevato l'accesso a file imprevisti e l'esecuzione di processi che assomigliano a comandi di sistema ma che finiscono per eseguire eseguibili scaricati.
Il resto è storia: Acme ha prima negato che tale comportamento fosse imputabile a loro e che tutte le misure di sicurezza fossero in atto. Solo dopo che i media della sicurezza informatica hanno iniziato a chiedersi perché la fonte del comportamento rilevato provenisse dai componenti di Acme e l'analisi della sicurezza ha evidenziato quanto quei componenti fossero crivellati di malware nascosto, Acme ha dovuto riconoscere l'incidente e chiamare un'azienda di risposta agli incidenti. Una campagna di marketing negativa che ha minato in un secondo la fiducia conquistata con tanta fatica. “Acme era a un'installazione npm di distanza da disaster" era un titolo comune. Poi sono seguite cause legali e contratti annullati.
Noti somiglianze con incidenti passati noti? Acme ha subito un incidente nella catena di fornitura in due fasi, utilizzando un mix di confusione delle dipendenze/typosquatting attacchi che utilizzavano una workstation di sviluppo come testa di ponte per infettare componenti che finivano in software utilizzato da terze parti. Come si potrebbe prevenire o mitigare tutto ciò?
Perché le confezioni avvelenate sono così popolari
Questo ipotetico incidente dimostra che, anche con un approccio ragionevole alla sicurezza open source, le organizzazioni necessitano di misure specifiche per evitare di cadere preda di malware nei componenti open source. Schematicamente, l’autore della minaccia può:
- Creare un nuovo pacchetto (seguendo il noto percorso del typosquatting o della confusione delle dipendenze, questo è il percorso più percorso dai malintenzionati in termini di volume);
- Prova a infettarne uno esistente, iniettandolo nel codice sorgente, cercando di mascherarlo come un collaboratore tramite pull request, o utilizzando l'ingegneria sociale per diventare un manutentore (come ha fatto "Jao Tan" nel XZ Backdoor o destra9ctrl L'utente GitHub ha fatto nel file flusso di eventi incidente nell'autunno del 2018) o acquisendo le credenziali del repository open source e impersonando il manutentore;
- Iniettare malware durante la creazione del pacchetto, eseguendo uno script di compilazione dannosoo interferire con i download dei pacchetti con intercettazioni man-in-the-middle (fortunatamente, TLS ora è sempre richiesto nella maggior parte dei registri).
- Iniettare il componente impacchettato direttamente nel registro, in genere acquisendo le credenziali del registro (l'alternativa preferita per molti attacchi sofisticati come quello di Acme, dove la workstation compromessa nella prima fase aveva il token di accesso al registro interno, ad esempio nel solito .env or ~/.m2/settings.xml: i cattivi attori sanno dove cercare i segreti). Sono state sfruttate anche le vulnerabilità dei registri.
L'avvelenamento dei registri con malware è la base per gli attacchi alle dipendenze. Niente di nuovo sotto il sole: la sua diffusione è esplosa, ma le stesse tecniche funzionano oggi come cinque anni fa.
Il pacchetto dannoso può funzionare durante l'installazione, durante la creazione del software o in fase di esecuzione. E il comportamento spazia dall'esfiltrazione di informazioni, ad esempio l'estrazione di segreti per un tentativo di seconda fase, all'estrazione del codice sorgente, con l'eliminazione di ulteriore malware. Nel prossimo episodio analizzeremo i pacchetti dannosi e il modo in cui vengono pubblicati.
Ulteriori letture
Il prossimo episodio Anatomia dei pacchetti dannosi: quali sono le tendenze? si concentrerà su casi reali che monitoriamo giorno dopo giorno con il nostro sistema Malware Early Warning. Esamineremo quali tipi di malware sono stati rilevati e quali tattiche, tecniche e procedure sono le preferite. Esamineremo l'offuscamento e il modo in cui tentano di nascondersi dai potenziali revisori, le tecniche di evasione per evitare il rilevamento e come si stanno evolvendo con la telemetria e il movimento laterale. Si prega di rimanere sintonizzati!
Bibliografia
- Collezione di coltelli di Backstabber: una revisione degli attacchi alla catena di fornitura di software open source. M. Ohm et al., maggio 2020.
- Protezione antimalware open source. Libro bianco di Xygeni.
- Software Supply Chain Security Retrospettiva: dare forma a un 2024 più sicuro. Rapporto di Xygeni.
