DevSecOps è quella pratica che integra i test di sicurezza in ogni fase del processo di sviluppo del software. In un panorama complesso come quello odierno, i test di sicurezza sono ormai imprescindibili. A rafforzare questa affermazione, minacce e vulnerabilità recenti, come quella scoperta nella libreria xz, ci fanno riflettere su quanto sia esposta la nostra Supply Chain.
Quali sono, però, le minacce a cui siamo esposti, quando consideriamo la Supply Chain? Vediamoli insieme, per poter comprendere insieme a cosa siamo esposti quotidianamente. E se vuoi approfondire, il 15 maggio, durante la mia Masterclass, vedremo anche quali azioni mettere in campo per cercare di mitigare queste minacce.
Che cosa si intende per “Supply chain”
Nello sviluppo del software, per Supply Chain si intendono tutti i processi e componenti che contribuiscono alla realizzazione dell’applicazione software finale. Non si tratta di un movimento fisico di merci, ma piuttosto del flusso di informazioni, codice, librerie e strumenti:
- Codice: il cuore del software, costituito dal codice ad hoc scritto per soddisfare i requisiti di business;
- Dipendenze: tutti i componenti esterni come librerie, plugin, codice open-source di cui il nostro software necessita per funzionare;
- Strumenti: si tratta degli strumenti e dei processi utilizzati per automatizzare la compilazione, il testing, il deployment e il monitoraggio del software. Include tutti gli strumenti per gestire il progetto, far comunicare le persone all’interno del team e via dicendo;
- Persone: sviluppatori, ingegneri, tester e altri professionisti che lavorano insieme per progettare, scrivere e manutenere il software, sono per forza di cose parte della supply chain;
- Documentazione: informazioni. Una documentazione chiara e coincisa permette a chiunque sia coinvolto nello sviluppo di comprendere il codice, i processi e l’utilizzo di dipendenze.
In questo scenario, avere un elevato numero di strumenti allarga la base di attacco che andremo ad esporre. Conseguentemente, i punti deboli del nostro processo di sviluppo sono numerosi.
Minacce alla Supply chain
Come accennato inizialmente, conoscere le possibili minacce a cui andiamo incontro ci aiuta ad intraprendere le giuste azioni per mitigare e prevenire degli attacchi. Una classificazione e descrizione standard di queste minacce è offerta da Supply-chain Levels for Software Artifacts, conosciuto SLSA (leggi “salsa”). SLSA è un framework di sicurezza collaborativo, guidato da un comitato direttivo che vendor neutral (la lista include Cloud Native Computing Foundation, The Linux Foundation, Google, Intel), impegnato a migliorare l’ecosistema di sicurezza per chiunque, e parte anche della Open Source Security Foundation.
SLSA è un insieme di linee guida relative alla sicurezza della supply chain e adottabili in via incrementale. Include delle definizioni, delle checklist, procedure e molti suggerimenti per migliorare complessivamente la sicurezza del nostro software. Queste linee guida definiscono le minacce alla supply chain raggruppandole in tre aree. Inoltre, le linee guida indicano le minacce tramite delle lettere, dalla A alla H, come mostrato in figura.
Le tre aree sono:
- Minacce ai sorgenti, dove troviamo minacce relative al codice sorgente;
- Minacce alla fase di Build, dove i problemi possono trovarsi nei tool e nel processo creazione del pacchetto;
- Minacce alle Dipendenze, dove troviamo problemi all’interno delle nostre dipendenze.
Andiamo ora nel dettaglio di ognuna di queste arree.
Minacce ai sorgenti
Nell’area dedicata alle minacce ai sorgenti troviamo tutte quelle situazioni in cui il codice è, in qualche modo, compromesso:
- A – Invio di codice non autorizzato: questa casistica può capitare, ad esempio, quando si invia del codice bypassando la revisione del codice. Per “bypassando” si intende qualsiasi tecnica assicuri che il codice malevolo passi la fase di revisione. Un esempio: ottenere le credenziali del revisore e usarle per autenticarsi nel sistema e approvare le modifiche non autorizzate;
- B – Il repository del codice è compromesso: questo è il caso in cui è il sistema usato per tener traccia delle modifiche al codice ad essere compromesso. Possiamo trovare dettagli di un incidente noto di questo tipo a questo link. In questo caso, l’attaccante ha compromesso il server git di PHP, ottenendo la possibilità di modificare arbitrariamente il codice sorgente;
- C – Build effettuata usando codice modificato dopo la revisione. Un attaccante potrebbe ottenere questo risultato, ad esempio, dopo aver compromesso il repository, rendendo ogni mitigazione della minaccia A inutile.
Minacce alla fase di Build
Dopo le minacce al codice sorgente, è il turno delle minacce alla fase di build e di deploy. É bene tenere a mente che, in questa fase, un attaccante potrebbe comunque aver già compromesso il codice.
- E – Compromissione del processo di Build: questo può succedere quando l’intera piattaforma dove viene effettuata la Build è compromessa. É da notare che questa situazione potrebbe essere slegata dalla piattaforma in sé. In una passata esperienza lavorativa, ho scoperto che un attaccante aveva compromesso una piattaforma di blogging. La compromissione era avvenuta riuscendo ad accedere precedentemente ad una piattaforma di e-learning che aveva una vulnerabilità. Entrambe le piattaforme erano sullo stesso web server e l’attaccante aveva compromesso degli eseguibili di sistema. Ogni chiamata a quegli eseguibili, che normalmente sarebbero stati innocui, risultava in un data leak;
- F – Upload di un pacchetto modificato: l’attaccante, dopo aver ottenuto accesso al sistema su cui vengono salvati i pacchetti, carica una versione malevola di un pacchetto. Questo attacco è rivolto direttamente al pacchetto finale, con modalità simili al caso in cui si invia del codice malevolo e lo si approva. Nuovamente, è abbastanza frequente che la causa principale di questa minaccia siano delle credenziali trapelate, per errore o meno;
- G – Compromissione del registro di pacchetti: in maniera simile a quanto accade per la minaccia E, in questa casistica l’attacco compromette la piattaforma del registro di pacchetti. Nel 2008, un team di ricercatori dell’Università dell’Arizona riuscì ad attivare dei mirror per diversi registri di pacchetti molto conosciuti. Il team ottenne che gli utilizzatori di quei registri iniziarono a scaricare pacchetti dai mirror. Un attaccante avrebbe potuto utilizzare questo approccio per distribuire pacchetti malevoli;
- H – Utilizzo di un pacchetto compromesso: arrivati in questa fase, del codice o un pacchetto malevoli sono pronti ad essere utilizzati, e quando questo accade, l’attacco è praticamente in corso. Un caso d’uso è l’attacco Browserify typosquatting. L’attaccante aveva creato un pacchetto che, oltre a simulare il comportamento del pacchetto originario, si chiamava in maniera molto simile. Situazioni del genere sono molto difficili da individuare senza una pratica di mitigazione adeguata.
Minacce alle Dipendenze
Infine, e non certo per importanza, ci sono le dipendenze:
- D – Compromissione delle dipendenze: Quando una delle minacce precedenti non è affrontata correttamente e il pacchetto malevolo viene utilizzato, questo potrebbe essere una dipendenza per un altro sistema. Quello che si ottiene è un attacco al sistema che utilizza la dipendenza, passando per la compromissione di un componente che si pensava sicuro. Siamo nel caso specifico di xz: l’attaccante ha utilizzato la minaccia A per iniettare del codice malevolo. Il codice poteva attivare un pacchetto malevolo, iniettato usando la minaccia F. Quando il pacchetto compromesso è stato rilasciato, sarebbe potuto essere utilizzato da chiunque come dipendenza.
Minacce aggiuntive identificate da Google
In aggiunta alle minacce che SLSA elenca come possibili quando si parla di vulnerabilità della Supply chain, Google considera anche vettori di attacco addizionali, che io personalmente considero piuttosto frequenti e molto importanti:
- 1 – Scrittura di codice non sicuro: quante volte? Se penso a quando ho iniziato a scrivere codice, ricordo tante volte in cui ho scritto codice poco sicuro, anche se non intenzionalmente. La formazione in questi casi è molto importante, ma possiamo implementare anche sistemi che eseguano dei controlli per noi;
- 2 – Compromissione del processo di rilascio: in maniera simile alla minaccia E, ma questa volta è l’intero sistema di rilascio ad essere compromesso. Ad esempio, un sistema compromesso potrebbe iniettare un sidecar container all’interno dei nostri pod;
- 3 – Rilascio di software compromesso o non conforme: come per la minaccia H, questo è il passo finale, quando l’attacco ha effetto dopo aver compromesso il processo di rilascio;
- 4 – Vulnerabilità e configurazioni errate in software in esecuzione: in alcuni casi, sono le configurazioni ad essere malevole o vulnerabili, e possono essere utilizzate come vettore d’attacco. Un esempio su tutti? Beh, quante volte impostiamo l’utente ad uno non-root all’interno dei nostri Dockerfiles? Dovremmo, ed è a tutti gli effetti una delle best practices più importanti.
Prossimi passi: mitigazioni
Abbiamo visto quali sono le minacce a cui siamo esposti quando parliamo di Supply chain (praticamente sempre). Ancora, abbiamo visto alcuni esempi di scenari reali in cui queste minacce si sono trasformate in attacchi. E ora? Come possiamo affrontare queste minacce e mitigarle?
SLSA offre una serie di casi d’uso, principi e suggerimenti su come applicare delle mitigazioni per ognuna di queste minacce. In dei prossimi articoli approfondirò questi aspetti, fornendo anche delle implementazioni di riferimento per Google Cloud Platform.