Google ha presentato il framework SLSA (Supply-chain Levels for Software Artifacts), che riassume l'esperienza esistente nella protezione dell'infrastruttura di sviluppo dagli attacchi effettuati durante la scrittura del codice, il testing, la compilazione e la distribuzione del prodotto.
I processi di sviluppo stanno diventando sempre più complessi e dipendenti da strumenti di terze parti, creando condizioni favorevoli per attacchi che mirano non solo a identificare ed sfruttare vulnerabilità nel prodotto finale, ma anche a compromettere il processo di sviluppo stesso (gli attacchi alla ‘supply chain’ sono tipicamente rivolti a introdurre modifiche dannose durante la scrittura del codice, sostituendo componenti e dipendenze distribuite).
Il framework considera 8 tipi di attacchi legati alle minacce di inserimento di modifiche dannose nelle fasi di sviluppo del codice, compilazione, testing e distribuzione del prodotto.
- A. Includere nel codice sorgente modifiche contenenti backdoor o bug nascosti che portano a vulnerabilità.
Esempio di attacco: 'Hypocrite Commits' — tentativa di inserimento nel kernel 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: iniezione di commit malevoli con backdoor nel repository Git di un progetto PHP dopo la fuga di password degli sviluppatori.
Metodo di protezione proposto: aumento della sicurezza della piattaforma di gestione del codice (nel caso di PHP, l'attacco è stato effettuato tramite un'interfaccia HTTPS poco utilizzata, che consentiva di inviare modifiche durante l'accesso con password senza verifica della chiave SSH, pur utilizzando un algoritmo di hash MD5 inaffidabile per le password).
- C. Modifiche al momento della trasferimento del codice nel sistema di build o integrazione continua (viene compilato codice non corrispondente a quello del repository).
Esempio di attacco: iniezione di un backdoor in Webmin tramite modifiche all'infrastruttura di build, che hanno portato all'uso di file con codice diverso da quelli del repository.
Metodo di protezione proposto: verifica dell'integrità e identificazione della fonte del codice in arrivo nel sistema di build. server.
- D. Compromissione della piattaforma di build.
Esempio di attacco: l'attacco SolarWinds, durante il quale è stato garantito l'inserimento di un backdoor nel prodotto SolarWinds Orion durante la fase di costruzione.
Metodo di protezione proposto: implementazione di misure di sicurezza avanzate per la piattaforma di costruzione.
- E. Promozione di codice dannoso tramite dipendenze di bassa qualità.
Esempio di attacco: inserimento di un backdoor in una libreria popolare chiamata event-stream, tramite l'aggiunta di una dipendenza innocua, che a sua volta includeva codice dannoso in uno degli aggiornamenti di quella dipendenza (la modifica malevola non era riflessa nel repository git, ma era presente solo nel pacchetto MNP finale).
Metodo di protezione proposto: applicazione ricorsiva dei requisiti SLSA a tutte le dipendenze (nel caso di event-stream, il controllo avrebbe rivelato la costruzione di codice non conforme al contenuto del principale repository Git).
- F. Caricamento di artefatti non creati nel sistema CI/CD.
Esempio di attacco: aggiunta 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 suggerito: monitoraggio delle origini e dell'integrità degli artefatti (nel caso di CodeCov, è stato possibile scoprire che lo script Bash Uploader fornito dal sito codecov.io non corrisponde al codice nel repository del progetto).
- G. Compromissione del repository dei pacchetti.
Esempio di attacco: i ricercatori sono riusciti a distribuire specchi di alcuni repository di pacchetti popolari al fine di diffondere pacchetti dannosi attraverso di essi.
Metodo di protezione suggerito: verifica che gli artefatti distribuiti siano raccolti dai rispettivi codici sorgente dichiarati.
- H. Introduzione alla confusione dell'utente per l'installazione di un pacchetto errato.
Esempio di attacco: uso del typo-squatting (NPM, RubyGems, PyPI) per pubblicare nei repository pacchetti simili per scrittura a popolari applicazioni (ad esempio, coffe-script al posto di coffee-script).
Per bloccare le minacce evidenziate, SLSA offre un insieme di raccomandazioni e strumenti per l'automazione della creazione di metadati per la revisione. SLSA riassume le tipologie di attacco e introduce il concetto di livelli di protezione. Ogni livello richiede specifici requisiti infrastrutturali, che garantiscono l'integrità degli artefatti utilizzati nello sviluppo. Maggiore è il livello SLSA supportato, più sono i mezzi di protezione implementati e migliore è la protezione dell'infrastruttura contro gli attacchi comuni.
- SLSA 1 — richiede che il processo di compilazione sia completamente automatizzato e generi metadati («provenance») su come gli artefatti sono stati assemblati, inclusi dettagli sul codice sorgente, sulle dipendenze e sul processo di compilazione (per GitHub Actions è stato proposto un esempio di generatore di metadati per la revisione). SLSA 1 non include elementi di protezione contro le modifiche dannose, ma identifica semplicemente il codice e fornisce metadati per la gestione delle vulnerabilità e l'analisi dei rischi.
- SLSA 2 — espande il primo livello richiedendo l'uso di sistemi di controllo 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, nel caso venga utilizzato un servizio di build affidabile.
- SLSA 3 — conferma che il codice sorgente e la piattaforma di build soddisfano i requisiti di standard che garantiscono la possibilità di audit del codice e la integrità dei metadati forniti. Si presume che gli auditor possano certificare le piattaforme per la conformità agli standard richiesti.
- SLSA 4 — il livello più alto, che integra i livelli precedenti con i seguenti requisiti:
- Revisione obbligatoria di tutte le modifiche da parte di due sviluppatori diversi.
- Tutti i passaggi di build, il codice e le 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.
- L'applicazione del processo di build ripetibile offre la possibilità di ripetere il processo di costruzione autonomamente e di verificare che il file eseguibile sia stato compilato dai sorgenti forniti.
Fonte: opennet.ru
