Dove sono tutte le violazioni dei container?

In che modo gli autori delle minacce attaccheranno e utilizzeranno i container? Questa è una domanda a cui penso costantemente. Lavoro in questo settore da più di due decenni ormai e sento che dovrei avere una risposta. Ma non lo faccio.

Invece, ho molte idee diverse, nessuna delle quali riesco a individuare come corretta. Parte di questa indecisione è dovuta a tutto il tempo che ho trascorso ad apprendere la sicurezza nel mondo “legacy”. I contenitori non hanno realmente un analogo. Certo, le macchine virtuali (VM) vengono spesso confuse con i contenitori, ma non sono mai state in grado di scalare come contenitori. Inoltre vengono utilizzati per scopi completamente diversi rispetto ai contenitori. Ci è voluto un po’ per adattare il mio pensiero e capire dove effettivamente i contenitori si inseriscono nella superficie di attacco.

Gli esempi pubblici di attacchi contro ambienti containerizzati sono molto limitati. Le violazioni sono quasi sempre correlate al cryptomining, che sono attacchi gravi, ma il risponditore di incidenti che è in me le trova deludenti. Un altro punto in comune è che sono principalmente il risultato di una configurazione errata, sia che si tratti di Kubernetes o di un account cloud. La combinazione delle motivazioni e delle tattiche finora non è stata molto stimolante.

La vecchia via

Le vulnerabilità legate all’esecuzione di codice in modalità remota (RCE) rappresentano da molto tempo la principale preoccupazione nella sicurezza informatica. Lo sono ancora, ma come si applica questo modo di pensare ai contenitori? È facile passare immediatamente all’RCE come minaccia principale, ma non sembra essere il modo giusto di affrontare i container. Per prima cosa, i contenitori hanno spesso vita breve – Il 44% dei container vive meno di cinque minuti – quindi un intruso dovrebbe essere veloce.

Questo approccio presuppone inoltre che il contenitore sia esposto a Internet. Sicuramente alcuni container sono impostati in questo modo, ma spesso sono molto semplici e utilizzano tecnologie ben collaudate, come NGINX. Potrebbero esserci zero giorni di scadenza per queste applicazioni, ma sarebbero estremamente preziose e difficili da trovare. La mia esperienza mi ha mostrato che molti contenitori vengono utilizzati internamente e non si connettono direttamente a Internet. In questo caso lo scenario RCE diventa molto più difficile. Dovrei menzionare log4j, sebbene questo tipo di vulnerabilità abbiano il potenziale per essere sfruttate da remoto anche se il sistema vulnerabile non è al limite.

Il nuovo modo

Se l’RCE non è la minaccia più grande per i container, allora cos’è? I container sono addirittura sul radar degli autori di minacce? Sì, i container e la loro infrastruttura di supporto sono troppo importanti per essere ignorati. Il software di orchestrazione dei container ha consentito di scalare i carichi di lavoro containerizzati fino a raggiungere numeri inimmaginabili. Anche la tendenza all'utilizzo è in aumento, quindi puoi essere sicuro che saranno un obiettivo. Semplicemente non possono essere pensati come server a cui si accede tramite le vulnerabilità RCE.

Invece, in realtà è vero il contrario. Invece di attaccare i container dall'esterno verso l'interno, devono essere attaccati dall'interno verso l'esterno. Questo è essenzialmente ciò che fanno gli attacchi alla catena di approvvigionamento. La supply chain è un vettore di attacco estremamente efficace contro i container quando inizi a capire come sono costruiti. Un contenitore inizia con un file di definizione, ad esempio Dockerfile, che definisce tutto ciò che sarà nel contenitore durante l'esecuzione. Viene trasformato in un'immagine una volta creata e quell'immagine è ciò che può essere trasformato in un carico di lavoro innumerevoli volte. Se qualcosa in quel file di definizione viene compromesso, ogni singolo carico di lavoro in esecuzione viene compromesso.

I contenitori sono spesso, ma non sempre, creati appositamente con un'applicazione che fa qualcosa ed esce. Queste applicazioni possono essere quasi qualsiasi cosa: la cosa importante da capire è quanto viene creato utilizzando librerie, closed source o open source, scritte da altre persone. GitHub ha milioni di progetti e non è l'unico repository di codice disponibile. Come abbiamo visto con SolarWinds, il closed source è vulnerabile anche agli attacchi alla catena di fornitura.

Un attacco alla catena di fornitura è un ottimo modo per gli autori delle minacce di entrare nell’ambiente container di un bersaglio. Possono anche lasciare che sia l’infrastruttura del cliente a ridimensionare l’attacco per loro se la compromissione passa inosservata. Questo tipo di scenario si sta già realizzando, come abbiamo visto con il Violazione del codecov. Ma è difficile da rilevare per quanto tutto questo sia nuovo e per quanto il nostro pensiero sia ancora radicato nei problemi del passato.

Una via giusta

Come per la risoluzione della maggior parte dei problemi, la visibilità è solitamente un ottimo punto di partenza. È difficile aggiustare ciò che non puoi vedere. Per proteggere i tuoi contenitori devi avere visibilità sui contenitori stessi, nonché sull'intera pipeline che li costruisce. La gestione delle vulnerabilità è un tipo di visibilità che deve essere integrata nella pipeline di compilazione. Includerei anche altri strumenti di analisi statica, come quelli che cercano anche segreti trapelati. Poiché non è possibile prevedere come si presenterà un attacco alla catena di fornitura, il monitoraggio del runtime diventa fondamentale in modo da sapere esattamente cosa stanno facendo i tuoi contenitori.