Nonostante non faccia spesso notizia, se non ogni tanto tra i suoi affezionati utenti, Kubernetes continua a costituire un elemento fondamentale e molto diffuso dell’universo IT. Ciò significa che, quando si scopre una vulnerabilità che lo riguarda, dovrebbe scattare un’allerta consapevole in tutti coloro che ci hanno a che fare o che ne possono subire l’impatto.
Chissà se accadrà almeno stavolta: i ricercatori di Akamai hanno infatti proprio alcuni giorni fa scoperto e “denunciato” una grave falla di sicurezza nel sistema.
Assegnata a CVE-2023-3676 con un punteggio CVSS di 8,8, questa nuova vulnerabilità sembrerebbe permettere a un attaccante di prendere il controllo di un intero cluster Kubernetes. E ha per giunta una bassa barriera all’ingresso, dal punto di vista tecnico. Richiedendo privilegi ridotti, infatti, per sfruttarla serve solo l’accesso a un nodo: questo elemento ne amplifica la gravità. L’unica consolazione è la sua portata, limitata ai soli nodi Windows, oggi non molto diffusi.
Dal YAML il controllo dei nodi
Al momento la nuova vulnerabilità risulta sfruttabile su installazioni predefinite di Kubernetes ed è stata testata sia su distribuzioni on-premise che su Azure Kubernetes Service. Per approfittarne, aggirando la verifica di chi è autorizzato a funzionare come root, il criminale deve applicare un file YAML (YAML Ain’t Markup Language) dannoso al cluster. Si tratta di un linguaggio di serializzazione dei dati molto importante in Kubernetes perché impiegato praticamente per tutto, dalla configurazione dell’interfaccia di rete dei container alla gestione dei pod, fino al management dei segreti.
Quando un aggressore ottiene privilegi “apply”, ovvero i privilegi necessari per interagire con l’API di Kubernetes, diventa autorizzato a iniettare codice che verrà eseguito su tutti gli endpoint Windows con privilegi SYSTEM all’interno di un cluster Kubernetes.
Nello specifico, quando viene creato un pod, l’utente ha la possibilità di creare una directory condivisa tra il pod e l’host, sfruttando la funzione volumi (includendo il parametro volume proprio nel file YAML del pod). È proprio questo il passaggio con cui un criminale riesce a raggiungere il codice vulnerabile, eseguire qualsiasi comando con privilegi SYSTEM da nodi remoti e ottenere il controllo su tutti i nodi Windows del cluster.
Strumenti di mitigazione. Anche open source
La scoperta di CVE-2023-3676 ha portato all’identificazione di altre due vulnerabilità che condividono la stessa causa principale. La prima (CVE-2023-3893) riguarda l’escalation di privilegi nel contesto del proxy Container Storage Interface (CSI) e consente a un utente malintenzionato di ottenere l’accesso amministrativo. L’altra (CVE-2023-3955) nasce dalla mancanza di sanitizzazione dell’input dell’utente e consente di analizzare una stringa di percorso appositamente predisposta come parametro di comando PowerShell, portando all’esecuzione del comando.
Due altre note di attenzione da gestire, mentre spuntano best practice e strumenti di mitigazione per affrontare la principale new entry, la vulnerabilità CVE-2023-3676. Per proteggersi efficacemente è necessario sempre scegliere quello più adatto al proprio ambiente.
In generale viene consigliato di disabilitare l’uso di Volume.Subpath per mettere il cluster al sicuro da questa vulnerabilità, ma così si finisce con il disabilitare un meccanismo importante per i cluster in produzione. Per questo, è essenziale esplorare delle alternative.
Una potrebbe essere Open Policy Agent (OPA), un agente open source che consente di ricevere dati sul traffico in entrata e in uscita dai nodi e di intraprendere azioni basate su policy in base ai dati ricevuti, per esempio delle regole che blocchino l’implementazione di determinati file YAML.
Un’altra opzione è quella di segmentare le operazioni degli utenti in base alla loro identità. Si può parlare quindi di controllo dell’accesso basato sui ruoli (RBAC – Role Based Access Control): ogni utente può creare pod solo nel proprio spazio dei nomi o può visualizzare solo le informazioni relative agli spazi dei nomi consentiti. È un tentativo di limitare il numero di utenti che possono eseguire azioni su un cluster e concentrare l’attenzione su quelli che hanno i privilegi rilevanti per lo sfruttamento.
