La tecnologia software si è evoluta e con essa gli hacker. La corsa agli armamenti con i malintenzionati si è limitata per lo più alle vulnerabilità e agli attacchi diretti al software utilizzato. Attaccare la catena di fornitura del software, anche se non invisibile, non era l'obiettivo principale dei malintenzionati...
L'attacco che molti hanno considerato l'inizio di un cambiamento nel modus operandi delle minacce persistenti avanzate (APT) è stato il Attacco SolarWinds. Non il primo, ma con un impatto tale da fare notizia e prendere d'assalto ITsec.
Esempi: SolarWinds, Codecov, Kaseya
SolarWinds è un importante fornitore di software che fornisce strumenti per il monitoraggio della rete e dell'infrastruttura. Uno dei prodotti dell'azienda è Orion, una piattaforma di monitoraggio e gestione delle infrastrutture. Viene utilizzato da oltre 30,000 organizzazioni pubbliche e private per gestire le proprie risorse IT. Orion accede ai sistemi IT per ottenere dati di registro e prestazioni del sistema.
Nel dicembre 2019 gli hacker hanno avuto accesso alle reti, ai sistemi e ai dati di migliaia di clienti SolarWinds. Hanno attaccato la catena di fornitura del software inserendo codice dannoso nella piattaforma. Successivamente, SolarWinds ha distribuito il malware backdoor come aggiornamento del software Orion, al quale gli hacker potevano accedere e impersonare utenti e account delle organizzazioni vittime. La violazione di SolarWinds presupponeva un risveglio della sicurezza informatica per tutte le organizzazioni che operano nel mondo nativo del cloud.
Questo attacco alla catena di fornitura è stato seguito da altri come Codecov, uno strumento di copertura del codice software. Nel gennaio 2021, an l'aggressore ha estratto una credenziale memorizzato per errore nell'immagine Docker di Codecov, che l'attore ha utilizzato per modificare uno script di caricamento nello strumento. L'attore ha semplicemente inserito una singola riga di codice che ha inviato tutte le variabili di ambiente del CI al server controllato dall'aggressore quando lo script è stato eseguito. Per mesi, i malintenzionati hanno ottenuto un potenziale accesso ai sistemi che utilizzavano lo script Codecov modificato.
Successivamente, il 2 luglio 2021, il attacco a Kaseya si è verificato. La sua piattaforma VSA viene utilizzata da molti MSP che forniscono servizi IT ad altre aziende per eseguire la gestione delle patch e il monitoraggio dei clienti. Gli hacker hanno attaccato la catena di fornitura di Kaseya VSA, compromettendone l'infrastruttura e successivamente rilasciando aggiornamenti dannosi sui server locali di VSA per infettare i sistemi delle società gestite, crittografando i loro dati e chiedendo un riscatto. Ransomware tramite uno strumento trojanizzato utilizzato dagli MSP sulle società gestite, che sono gli obiettivi finali. Che intelligenza!
Dall’incidente di SolarWinds si sono verificati sempre più attacchi contro la catena di fornitura del software, colpendo l’immagine e l’economia di aziende come Samsung, Uber, Nissan, Nvidia, tra molte altre. Secondo Gartner, “entro il 2025, il 45% delle organizzazioni in tutto il mondo avrà subito attacchi alle proprie catene di fornitura di software, un aumento di tre volte rispetto al 2021”.
Una nuova generazione di attacchi alla catena di fornitura del software
Attaccare le applicazioni proprietarie o gli ambienti di produzione di un'azienda genera una sola vittima. Questo, unito al fatto che la stragrande maggioranza delle aziende ha già implementato protezioni AppSec come AST, SCA o strumenti WAF, ha portato all'emergere di una nuova generazione di aggressori che mirano allo sviluppo del software pipeline. Gli attacchi alla supply chain possono colpire migliaia di aziende con un solo semplice attacco: l’amplificatore ideale.
L'infrastruttura di sviluppo è un bersaglio facile per gli aggressori. La sua ampia superficie di attacco fornisce accesso all'ambiente di produzione e ai suoi dati. L'intera infrastruttura degli strumenti DevOps: repository, sistemi di gestione del controllo del codice sorgente, strumenti di build, strumenti di deployment, template IAC (Infrastructure as Code), container, file di script, ecc., è piuttosto estesa e vulnerabile. Inoltre, tutti questi strumenti sono lontani dal controllo dell'area sicurezza e sono gestiti dai team di sviluppo e produzione. Gli hacker lo sanno e sfruttano queste debolezze.
Il nuovo obiettivo
Spesso gli sviluppatori scrivono segreti nel codice sorgente come credenziali e chiavi per i test durante lo sviluppo. Questi vengono archiviati in file spesso sotto controllo della versione e possono essere trovati dagli aggressori in futuro, anche se i file o i segreti vengono rimossi. Ciò consentirà agli aggressori di installare backdoor, leggere il codice sorgente, inserire codice dannoso, estrarre dati sensibili, ecc… Una volta che gli autori malintenzionati hanno validi login credenziali possono muoversi lateralmente attraverso il SDLCQueste credenziali consentono loro di passare ad altri strumenti e di ottenere privilegi utente avanzati per cercare informazioni di valore più elevato.
Gli hacker possono utilizzare le credenziali per violare il SDLC, ma possono anche infiltrarsi in repository o strumenti configurati in modo non corretto o non sicuri, mettendo a rischio sistemi e dati.
Gli attacchi prendono di mira anche i pacchetti open source. Conosciamo tutti storie dell'orrore sugli attacchi che sfruttano vulnerabilità note, come Log4j. D’altro canto, gli attacchi alla catena di fornitura sono diversi: gli aggressori inseriscono codice dannoso nei popolari pacchetti open source per un successivo utilizzo nel processo di creazione da parte di molte organizzazioni nel mondo.
In breve: gli hacker possono sfruttare l'accesso privilegiato, le configurazioni errate e le vulnerabilità nel CI/CD pipeline infrastruttura come vettore per inserire malware in un software che potrebbe essere utilizzato da molti.
Come proteggere il nostro SDLC dagli attacchi alla catena di fornitura del software?
Il numero di attacchi alla catena di fornitura è in costante crescita e il mercato sta reagendo a questo scenario. Alcune organizzazioni hanno stabilito delle strutture per affrontare questo problema software supply chain security, come il Secure Software Development Framework (SSDF) del NIST e il Supply Chain Levels for Software Artifacts (SLSA) di Google. Tuttavia, non sono molte le aziende che attribuiscono una priorità alla protezione degli strumenti e dell’infrastruttura DevOps per evitare attacchi alla propria catena di fornitura. Infatti, L’82% dei CIO ritiene che sarà vulnerabile nei loro confronti.
Le aziende non devono preoccuparsi solo di proteggere le proprie applicazioni, ma anche l'infrastruttura software e gli artefatti che ne fanno parte. SDLC poiché i cattivi attori stanno prendendo di mira la supply chain. L'ampiezza della superficie di attacco, la mancanza di consapevolezza da parte dei team di sviluppo di questo tipo di attacco e la mancanza di strumenti di sicurezza specializzati stanno consentendo agli aggressori di concentrarsi sulla supply chain del software.
Osservazioni conclusive
Proteggere il nostro pipeline sta diventando ogni giorno più urgente e una priorità per CISOs, che deve garantire che i team di sicurezza prestino attenzione alla supply chain e lavorino insieme ai team Devops per proteggere SDLC da questo tipo di attacco.
Utilizzando strumenti che ci aiutano a proteggere il nostro SDLC, identificare backdoor, comportamenti sospetti e fermare gli attacchi alla supply chain è necessario per mantenere il nostro ambiente DevOps privato e sicuro. I primi strumenti per proteggere software supply chain security cominciano ad emergere. Alcuni sono più concentrati sul lato sviluppo e altri sul lato operativo. E alcuni, come Xygeni, hanno la missione di proteggere l'integrità e la sicurezza dell'ecosistema software nell'intero DevOps.
Per saperne di più |
|
|
|
|








