Google ha introdotto il framework SLSA (Supply-chain Levels for Software Artifacts), che riassume l'esperienza esistente nella protezione dell'infrastruttura di sviluppo dagli attacchi effettuati nelle fasi di codifica, test, assemblaggio e distribuzione di un prodotto.
I processi di sviluppo stanno diventando sempre più complessi e dipendenti da strumenti di terze parti, il che crea condizioni favorevoli per attacchi che non sono legati all'identificazione e allo sfruttamento delle vulnerabilità del prodotto finale, ma piuttosto alla compromissione del processo di sviluppo stesso (attacchi alla supply chain, in genere mirati a introdurre modifiche dannose durante il processo di scrittura del codice, sostituendo componenti distribuiti e dipendenze).
Il framework prende in considerazione otto tipi di attacchi associati alle minacce di introduzione di modifiche dannose durante lo sviluppo del codice, l'assemblaggio, il test e la distribuzione di un prodotto.
- A. Includere modifiche al codice sorgente che contengono backdoor o errori nascosti che portano a vulnerabilità.
Пример атаки: «Hypocrite Commits» — попытка продвижения в ядро Linux патчей с уязвимостями.
Metodo di protezione suggerito: revisione indipendente di ogni modifica da parte di due sviluppatori.
- B. Compromissione della piattaforma di gestione del codice sorgente.
Esempio di attacco: inserimento di commit dannosi con una backdoor nel repository Git di un progetto PHP dopo aver fatto trapelare le password degli sviluppatori.
Metodo di protezione proposto: rafforzamento della sicurezza della piattaforma di gestione del codice (nel caso di PHP, l'attacco è stato effettuato tramite un'interfaccia HTTPS raramente utilizzata, che consentiva di inviare modifiche durante l'accesso con una password senza controllare la chiave SSH, nonostante il fatto che per l'hashing della password fosse stato utilizzato il debole MD5).
- C. Apportare modifiche nella fase di trasferimento del codice al sistema di build o di integrazione continua (viene creato un codice che non corrisponde al codice del repository).
Esempio di attacco: introduzione di una backdoor in Webmin mediante modifiche all'infrastruttura di build che hanno portato all'utilizzo di file di codice diversi da quelli presenti nel repository.
Metodo di protezione proposto: controllo dell'integrità e identificazione della fonte del codice sulla linea di assemblaggio server.
- D. Compromesso della piattaforma di assemblaggio.
Esempio di attacco: l'attacco SolarWinds, che ha introdotto una backdoor nel prodotto SolarWinds Orion durante la fase di build.
Metodo di protezione proposto: implementazione di misure di sicurezza estese per la piattaforma di assemblaggio.
- E. Promuovere codice dannoso tramite dipendenze di scarsa qualità.
Un esempio di attacco: l'introduzione di una backdoor nella popolare libreria event-stream aggiungendo una dipendenza innocua e poi includendo codice dannoso in un aggiornamento di tale dipendenza (la modifica dannosa non si rifletteva nel repository git, ma era presente solo nel pacchetto MNP finito).
Il metodo di protezione proposto consiste nell'applicare ricorsivamente i requisiti SLSA a tutte le dipendenze (nel caso di event-stream, il controllo avrebbe rilevato la build del codice che non corrisponde al contenuto del repository Git principale).
- F. Caricamento di artefatti non creati nel sistema CI/CD.
Un esempio di attacco è stata l'aggiunta di codice dannoso a uno script CodeCov, che ha consentito agli aggressori di estrarre informazioni archiviate negli ambienti dei sistemi di integrazione continua dei clienti.
Il metodo di protezione proposto consiste nel controllare la fonte e l'integrità degli artefatti (nel caso di CodeCov, si potrebbe scoprire che lo script Bash Uploader fornito dal sito web codecov.io non corrisponde al codice del repository del progetto).
- G. Compromissione del repository del pacchetto.
Esempio di attacco: i ricercatori sono riusciti a distribuire mirror di alcuni repository di pacchetti popolari per distribuire pacchetti dannosi attraverso di essi.
Metodo di protezione proposto: verifica che gli artefatti distribuiti siano compilati a partire dal codice sorgente dichiarato.
- H. Confondere l'utente installando il pacchetto sbagliato.
Un esempio di attacco: l'utilizzo del typosquatting (NPM, RubyGems, PyPI) per posizionare pacchetti in repository con una scrittura simile a quella delle applicazioni più diffuse (ad esempio, coffe-script invece di coffee-script).
Per bloccare le minacce identificate, SLSA offre una serie di raccomandazioni e strumenti per automatizzare la creazione di metadati di audit. SLSA riassume i metodi di attacco tipici e introduce il concetto di livelli di protezione. Ogni livello impone requisiti infrastrutturali specifici per garantire l'integrità degli artefatti utilizzati nello sviluppo. Maggiore è il livello SLSA supportato, maggiori sono le protezioni implementate e migliore è la protezione dell'infrastruttura dagli attacchi tipici.
- SLSA 1 richiede che il processo di build sia completamente automatizzato e che generi metadati ("provenienza") su come vengono creati gli artefatti, incluse informazioni sul codice sorgente, sulle dipendenze e sul processo di build (GitHub Actions fornisce un esempio di generatore di metadati di audit). SLSA 1 non include funzionalità antimanomissione, ma fornisce semplicemente l'identificazione di base del codice e metadati per la gestione delle vulnerabilità e l'analisi dei rischi.
- SLSA 2 amplia il primo livello richiedendo l'utilizzo di un sistema di controllo delle versioni e di servizi di build che generano metadati autenticati. L'utilizzo di SLSA 2 consente la tracciabilità del codice e impedisce modifiche non autorizzate al codice quando si utilizzano servizi di build attendibili.
- SLSA 3 conferma che il codice sorgente e la piattaforma di build sono conformi a standard che garantiscono la verificabilità del codice e l'integrità dei metadati forniti. L'obiettivo è che gli auditor siano in grado di certificare la conformità delle piattaforme agli standard.
- SLSA 4 è il livello più alto e integra i livelli precedenti con i seguenti requisiti:
- Revisione obbligatoria di tutte le modifiche da parte di due sviluppatori diversi.
- Tutti i passaggi di compilazione, il codice e le dipendenze devono essere dichiarati in modo completo, tutte le dipendenze devono essere recuperate e verificate separatamente e il processo di compilazione deve essere eseguito senza accesso alla rete.
- Utilizzando un processo di build ripetibile è possibile ripetere autonomamente il processo di build e garantire che il file eseguibile venga compilato a partire dal codice sorgente fornito.
Fonte: opennet.ru
