L'azienda Google ha presentato il framework SLSA (Supply-chain Levels for Software Artifacts), che riassume l'esperienza esistente nella protezione dell'infrastruttura di sviluppo contro gli attacchi, effettuati durante la scrittura del codice, testing, assemblaggio e distribuzione del prodotto.
I processi di sviluppo stanno diventando sempre più complessi e dipendenti da strumenti di terze parti, creando condizioni favorevoli per la promozione di attacchi non mirati a identificare e sfruttare vulnerabilità nel prodotto finale, ma a compromettere il processo di sviluppo stesso (attacchi 'supply chain', generalmente mirati all'inserimento di modifiche dannose durante la scrittura del codice, sostituzione di componenti e dipendenze distribuiti).
Il framework tiene conto di 8 tipi di attacchi legati a minacce di inserimento di modifiche dannose nella fase di sviluppo del codice, assemblaggio, test e distribuzione del prodotto.
- A. Inclusione nel codice sorgente di modifiche contenenti backdoor o errori nascosti che portano a vulnerabilità.
Esempio di attacco: 'Hypocrite Commits' — tentativo di inserimento nel kernel di Linux di patch con vulnerabilità.
Metodo di protezione proposto: 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 backdoor nel repository Git del progetto PHP dopo la fuga delle password degli sviluppatori.
Metodo di protezione proposto: potenziamento della sicurezza della piattaforma di gestione del codice (nel caso di PHP, l'attacco è stato effettuato tramite un'interfaccia HTTPS poco utilizzata, che consentiva l'invio di modifiche all'accesso tramite password senza verifica della chiave SSH, e si utilizzava un MD5 poco affidabile per l'hashing delle password).
- C. Inserimento di modifiche nella fase di trasferimento del codice al sistema di assemblaggio o integrazione continua (viene assemblato codice non corrispondente a quello del repository).
Esempio di attacco: inserimento di un backdoor in Webmin attraverso modifiche all'infrastruttura di assemblaggio, che hanno portato all'utilizzo di file con codice diversi dai file nel repository.
Metodo di protezione proposto: verifica dell'integrità e identificazione della sorgente di arrivo del codice nell'assemblaggio. server.
- D. Compromissione della piattaforma di assemblaggio.
Esempio di attacco: attacco SolarWinds, durante il quale, nella fase di assemblaggio, è stata assicurata l'inserzione di un backdoor nel prodotto SolarWinds Orion.
Metodo di protezione proposto: implementazione di misure di sicurezza avanzate per la piattaforma di assemblaggio.
- E. Promozione di codice dannoso attraverso dipendenze scadenti.
Esempio di attacco: inserimento di un backdoor in una popolare libreria event-stream, tramite l'aggiunta di una dipendenza innocua che ha successivamente incluso codice dannoso in uno degli aggiornamenti di tale dipendenza (la modifica dannosa non era riflessa nel repository git, ma era presente solo nel pacchetto MNP pronto).
Metodo di protezione proposto: applicazione ricorsiva dei requisiti SLSA a tutte le dipendenze (nel caso di event-stream, il controllo avrebbe rivelato una compilazione di codice non corrispondente al contenuto del repository Git principale).
- F. Caricamento di artefatti non creati nel sistema CI/CD.
Esempio di attacco: inserimento di codice dannoso nello script CodeCov, che consentiva agli aggressori di estrarre informazioni memorizzate negli ambienti dei sistemi di integrazione continua dei clienti.
Metodo di protezione proposto: controllo della fonte e dell'integrità degli artefatti (nel caso di CodeCov, potrebbe essere stata rivelata l'incongruenza del codice dello script Bash Uploader fornito dal sito codecov.io rispetto al codice del repository di progetto).
- G. Compromissione del repository di pacchetti.
Esempio di attacco: i ricercatori sono riusciti a distribuire specchi di alcuni popolari repository di pacchetti per diffondere pacchetti dannosi attraverso di essi.
Metodo di protezione proposto: verifica che gli artefatti distribuiti siano compilati dai codici sorgente dichiarati.
- H. Introduzione in confusione dell'utente per installare il pacchetto errato.
Esempio di attacco: utilizzo di typo-squatting (NPM, RubyGems, PyPI) per pubblicare nei repository pacchetti scritti in modo simile a applicazioni popolari (ad esempio, coffe-script invece di coffee-script).
Per bloccare le minacce indicate, SLSA propone un insieme di raccomandazioni, così come strumenti per l'automazione della creazione di metadati per l'audit. SLSA generalizza le tecniche di attacco comuni e introduce il concetto di livelli di protezione. Ogni livello presenta requisiti specifici per l'infrastruttura, consentendo di garantire l'integrità degli artefatti utilizzati nello sviluppo. Maggiore è il livello SLSA supportato, maggiori sono le misure di protezione implementate e migliore è la protezione dell'infrastruttura contro attacchi comuni.
- SLSA 1 — richiede che il processo di build sia completamente automatizzato e generi metadati («provenance») su come gli artefatti sono stati raccolti, inclusi dettagli sui codici sorgente, dipendenze e sul processo di build (per GitHub Actions è stato proposto un esempio di generatore di metadati per l'audit). 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 — amplia il primo livello richiedendo l'uso di sistemi di controlli di versione e servizi di build che generano metadati autenticati. L'applicazione di SLSA 2 consente di tracciare l'origine del codice e previene modifiche non autorizzate al codice, nel caso vengano utilizzati servizi di build affidabili.
- SLSA 3 — certifica che i codici sorgente e la piattaforma di build soddisfino i requisiti degli standard, garantendo la possibilità di condurre audit del codice e assicurare l'integrità dei metadati forniti. Si prevede che gli auditor possano certificare le piattaforme per la conformità agli standard.
- SLSA 4 — il livello più elevato, che integra i livelli precedenti con i seguenti requisiti:
- Revisione obbligatoria di tutte le modifiche da parte di due sviluppatori diversi.
- Tutti i passaggi della build, codice e dipendenze devono essere completamente dichiarati, tutte le dipendenze devono essere estratte e verificate separatamente, e il processo di build deve essere eseguito senza accesso alla rete.
- Applicazione del processo di build ripetibile — la possibilità di ripetere il processo di build autonomamente e garantire che l'eseguibile sia stato costruito dai codici sorgente forniti.
Fonte: opennet.ru
