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 nella fase di scrittura del codice, 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 l’avanzamento di attacchi legati non all’identificazione e allo sfruttamento delle vulnerabilità nel prodotto finale, ma alla compromissione del processo di sviluppo stesso (attacchi alla catena di fornitura, solitamente mirati a introduzione di modifiche dannose nel processo di scrittura del codice, sostituzione di componenti distribuiti e dipendenze).
Il framework prende in considerazione 8 tipologie di attacchi legati alla minaccia di apportare modifiche dannose nella fase di sviluppo del codice, assemblaggio, test e distribuzione del prodotto.
- R. Incluse modifiche al codice sorgente che contengono backdoor o errori nascosti che portano a vulnerabilità.
Esempio di attacco: "Hypocrite Commits" - un tentativo di promuovere patch con vulnerabilità nel kernel Linux.
Metodo di sicurezza suggerito: revisione indipendente di ogni modifica da parte di due sviluppatori.
- B. Compromissione della piattaforma di controllo del codice sorgente.
Esempio di attacco: inserimento di commit dannosi con una backdoor nel repository Git di un progetto PHP dopo che sono state divulgate le password degli sviluppatori.
Metodo di protezione suggerito: Maggiore sicurezza della piattaforma di gestione del codice (nel caso di PHP l'attacco è stato effettuato tramite un'interfaccia HTTPS poco utilizzata, che permetteva di inviare modifiche al momento dell'accesso tramite password senza verificare la chiave SSH, nonostante il fatto che MD5 inaffidabile sia stato utilizzato per eseguire l'hashing delle password).
- C. Apportare modifiche nella fase di trasferimento del codice al sistema di compilazione o di integrazione continua (viene creato il codice che non corrisponde al codice del repository).
Esempio di attacco: inserimento di una backdoor in Webmin apportando modifiche all'infrastruttura di creazione, con conseguente utilizzo di file di codice diversi dai file nel repository.
Metodo di protezione proposto: verifica dell'integrità e identificazione della fonte del codice sull'assembly server.
- D. Compromissione della piattaforma di assemblaggio.
Esempio di attacco: l'attacco SolarWinds, durante il quale è stata garantita l'installazione di una backdoor nel prodotto SolarWinds Orion in fase di assemblaggio.
Metodo di protezione proposto: implementazione di misure di sicurezza avanzate per la piattaforma di montaggio.
- E. Promozione di codice dannoso attraverso dipendenze di bassa qualità.
Un esempio di attacco: l'introduzione di una backdoor nella popolare libreria di flussi di eventi aggiungendo una dipendenza innocua e quindi includendo codice dannoso in uno degli aggiornamenti di questa dipendenza (la modifica dannosa non si è riflessa nel repository git, ma è stata presente solo nella confezione MNP finita).
Metodo di protezione suggerito: applicare ricorsivamente i requisiti SLSA a tutte le dipendenze (nel caso di event-stream, il controllo rivelerebbe l'assemblaggio di codice che non corrisponde al contenuto del repository Git principale).
- F. Caricamento di artefatti non creati nel sistema CI/CD.
Esempio di attacco: aggiunta di codice dannoso allo script CodeCov, che ha consentito agli aggressori di estrarre informazioni archiviate negli ambienti del sistema di integrazione continua del cliente.
Metodo di protezione proposto: controllo sulla fonte e sull'integrità degli artefatti (nel caso di CodeCov, potrebbe essere rivelato che lo script Bash Uploader inviato dal sito codecov.io non corrisponde al codice dal repository del progetto).
- G. Compromissione del repository dei pacchetti.
Esempio di attacco: i ricercatori sono riusciti a implementare mirror di alcuni repository di pacchetti popolari per distribuire attraverso di essi pacchetti dannosi.
Metodo di protezione suggerito: verifica che gli artefatti distribuiti siano compilati dai codici sorgente dichiarati.
- H. Confondere l'utente inducendolo a installare il pacchetto sbagliato.
Esempio di attacco: utilizzare typosquatting (NPM, RubyGems, PyPI) per inserire pacchetti in repository che sono simili nella scrittura alle applicazioni più diffuse (ad esempio, coffe-script invece di coffee-script).
Per bloccare le minacce segnalate, SLSA offre una serie di raccomandazioni, nonché strumenti per automatizzare la creazione di metadati di controllo. SLSA riassume i metodi di attacco comuni e introduce il concetto di livelli di sicurezza. Ogni livello impone determinati requisiti infrastrutturali per garantire l'integrità degli artefatti utilizzati nello sviluppo. Maggiore è il livello SLSA supportato, maggiore è il numero di protezioni implementate e migliore è la protezione dell'infrastruttura dagli attacchi comuni.
- SLSA 1 richiede che il processo di compilazione sia completamente automatizzato e generi metadati ("provenienza") su come vengono costruiti gli artefatti, comprese informazioni su origini, dipendenze e processo di compilazione (per le azioni GitHub viene fornito un generatore di metadati di esempio per il controllo). SLSA 1 non include elementi di protezione contro modifiche dannose, ma identifica semplicemente il codice e fornisce metadati per la gestione delle vulnerabilità e l'analisi dei rischi.
- SLSA 2: estende il primo livello richiedendo l'uso di servizi di controllo della versione e di assemblaggio che generano metadati autenticati. L'utilizzo di SLSA 2 consente di risalire all'origine del codice e impedisce modifiche non autorizzate al codice nel caso di build services attendibili.
- SLSA 3 - conferma che il codice sorgente e la piattaforma di compilazione soddisfano i requisiti degli standard che garantiscono la capacità di verificare il codice e garantire l'integrità dei metadati forniti. Si presuppone che i revisori possano certificare le piattaforme rispetto ai requisiti degli 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 diversi sviluppatori.
- Tutti i passaggi di compilazione, il codice e le dipendenze devono essere dichiarati completamente, tutte le dipendenze devono essere estratte e verificate separatamente e il processo di compilazione deve essere eseguito offline.
- L'utilizzo di un processo di compilazione ripetibile ti consente di ripetere tu stesso il processo di compilazione e garantire che l'eseguibile venga creato dal codice sorgente fornito.
Fonte: opennet.ru