Attacchi CMDi (Command injection) in Kubernetes Log Query Attacchi CMDi (Command injection) in Kubernetes Log Query

Editoriale e commenti aggiuntivi di Tricia Howard

Kubernetes e i container, in generale, sono diventati una forza predominante nel settore della sicurezza e, in quanto tale, un punto di interesse per i ricercatori in tutto il mondo (noi inclusi). Il percorso della nostra ricerca, inizialmente, ci ha condotto alla vulnerabilità CVE-2023-3676, una vulnerabilità CMDi (Command injection) che può essere sfruttata applicando un file YAML dannoso YAML sul cluster. Questa ricerca ha portato all’individuazione di molti altri problemi nel codice sorgente di Kubernetes che consentono di assumere il controllo completo del cluster.

Non abbiamo trovato solo queste vulnerabilità, ma sono emersi anche risultati importanti nel progetto collaterale git-sync, che abbiamo presentato in occasione del Red Team Village al DEF CON 32 e, durante la preparazione della conferenza, ci siamo imbattuti nell’argomento di questo blog: un’altra opportunità per gli attacchi CMDi (Command injection), la funzione beta di Kubernetes per il suo principale strumento di registrazione denominato Log Query.

Log Query consente agli utenti di effettuare query ai computer remoti sullo stato dei loro sistemi utilizzando il comando CLI o cURL. Ad esempio, è possibile digitare il seguente comando per effettuare una query sullo stato del servizio kubelet in un nodo remoto:

Quando abbiamo visto il comando riportato nell’esempio qui sopra, ci è venuta in mente la nostra ricerca precedente: la query inviata al computer remoto viene verificata?

Nella Figura 1, viene riportato un esempio del codice sorgente per Log Query, in cui abbiamo individuato la creazione di vari comandi PowerShell.

Dopo aver provato molti metodi CMDi, alla fine abbiamo scoperto che il problema non era costituito dal payload in sé. Per sfruttare questa vulnerabilità, abbiamo bisogno di specificare un servizio che registra il suo stato in modo nativo in ETW (Event Tracing for Windows) e non nel sistema standard klog perché il controllo delle vulnerabilità avviene solo durante la registrazione in ETW.

Un ambiente Kubernetes con Calico (una comune interfaccia di rete open source per Kubernetes) consente di sfruttare questa vulnerabilità in modo affidabile tramite NSSM (Non-Sucking Service Manager).

• In una configurazione Calico, NSSM esiste, solitamente, per controllare lo stato dei servizi di Kubernetes. In altri ambienti/configurazioni, lo stato dei servizi viene gestito in altri modi.

• Kubernetes non gestisce gli output della registrazione di NSSM, pertanto garantisce che i registri vengano scritti direttamente in ETW e non tramite klog.

È semplice stabilire se la vostra azienda è vulnerabile. Notate la parte “os=windows”. Se non sono presenti nodi di Windows, il comando non avrà alcun effetto a indicare che la vostra azienda non è vulnerabile.

Poiché si tratta di una funzione beta, è necessario configurare il cluster anche per utilizzare lo stesso sistema.

Per verificare se la funzione è attivata o meno, gli amministratori possono esaminare il parametro di avvio “feature-gate” per “kubelet.” Ulteriori informazioni sono disponibili sul sito di Kubernetes.

Per mitigare questa vulnerabilità, Kubernetes ha deciso di utilizzare una variabile di ambiente denominata “kubelet_pattern” prima di passare il valore allo stesso comando di PowerShell.

In tal modo, l’input dell’utente verrà considerato come una stringa letterale anziché un’espressione secondaria da dover valutare.

Per aiutare a mitigare questa vulnerabilità, gli amministratori possono utilizzare il modulo per il controllo degli accessi basato sui ruoli (RBAC) per verificare gli utenti che accedono a Log Query e, persino, per disattivare completamente gli accessi. Il metodo RBAC segmenta le operazioni degli utenti in base alla loro identità. Ad esempio, ogni utente può creare i pod solo nel proprio spazio dei nomi o solo visualizzare le informazioni per gli spazi dei nomi consentiti. In tal modo, viene ridotto il rischio di RCE, non solo in fase di esecuzione, ma anche durante il rilevamento, pertanto un comportamento anomalo degli utenti è, spesso, il segno indicativo di un’attività criminale. 

Tenete presente che questa vulnerabilità non riguarda solo i nodi di Windows. Se il vostro cluster di Kubernetes non contiene nodi di Windows, non siete interessati da questa specifica vulnerabilità. Tuttavia, consigliamo comunque di tenere le patch il più possibile aggiornate per evitare di incorrere in altre vulnerabilità sconosciute. 

Poiché il problema risiede nel codice sorgente, questa minaccia rimarrà attiva e lo sfruttamento della vulnerabilità è destinato a crescere. Ecco perché consigliamo vivamente di applicare la patch al cluster anche se non contiene nodi di Windows.

In questo blog, abbiamo mostrato come un criminale con privilegi di query può eseguire comandi su un nodo di Windows contenuto in un cluster. È possibile sfruttare questa vulnerabilità mediante un semplice comando cURL senza dover inviare un file YAML. Questo metodo, tuttavia, nasconde un rischio enorme perché, in tal caso, lo sfruttamento della vulnerabilità è più difficile da mitigare e rilevare. Questi problemi di sanificazione di Kubernetes non sono esclusivi di Log Query, come abbiamo detto in precedenza.

Il personale del supporto deve verificare la presenza di eventuali comportamenti insoliti nella propria organizzazione. Riteniamo che questo vettore di attacco possa portare ad un controllo completo del cluster, pertanto è importante per noi aumentare la consapevolezza e aiutare gli amministratori della sicurezza a conoscere il potenziale pericolo.

L'Akamai Security Intelligence Group continuerà a ricercare minacce come queste e a segnalarle per i clienti dell'azienda e per la più vasta comunità della sicurezza. Per aggiornamenti in tempo reale sulle nostre ricerche, potete seguirci su X (in precedenza Twitter).

Desideriamo ringraziare il team di Kubernetes per la risposta rapida e la trattazione efficace.