Il ricercatore di sicurezza Tomer Peled, di Akamai Security Research, ha identificato CVE-2024-9042: una vulnerabilità di esecuzione remota che concede privilegi SYSTEM su ogni nodo Windows di un cluster Kubernetes. La falla, divulgata responsabilmente il 28 giugno 2024, sfrutta la feature beta Log Query ed è attivabile con una semplice richiesta GET, senza necessità di inviare manifest YAML o compromettere il piano di controllo. La scoperta riapre interrogativi sulla validazione degli input utente nel codice Windows-specifico di Kubernetes, un percorso già battuto dallo stesso ricercatore con CVE-2023-3676.
- CVE-2024-9042 consente RCE con privilegi SYSTEM su tutti i nodi Windows di un cluster Kubernetes tramite command injection nel parametro "pattern" della feature beta Log Query.
- L'exploit richiede una sola richiesta GET autenticata all'API del nodo target: la fonte fornisce un proof-of-concept curl che esegue codice arbitrario senza interazione con il kube-apiserver.
- La root cause risiede nella costruzione dinamica di comandi PowerShell: l'input "pattern" viene inserito senza sanitizzazione nella clausola
Where-Object -Property Message -Match, mentre solo il nome del servizio subisce validazione regex. - Le versioni affette precedono la 1.32.1 e richiedono che il cluster abbia optato per l'uso delle beta features; l'ambiente testato con condizioni più affidabili combina Calico come CNI e NSSM per la gestione del servizio Windows.
Come funziona l'injection nel Log Query di Kubernetes
La feature Log Query, introdotta come beta in Kubernetes, consente di interrogare i log dei servizi sui nodi Windows attraverso l'API del kubelet. Secondo l'analisi di Akamai, il componente kubelet costruisce dinamicamente un comando PowerShell per filtrare le voci di log: l'utente fornisce due parametri, "query" per il nome del servizio e "pattern" per il criterio di ricerca.
La validazione, però, è asimmetrica. Il nome del servizio viene controllato con un'espressione regolare. Il parametro "pattern" subisce solo un controllo di lunghezza: l'input utente viene concatenato direttamente nella stringa Where-Object -Property Message -Match senza alcuna trasformazione in string literal. Questo permette di rompere la sintassi PowerShell con un apostrofo opportunamente posizionato e iniettare comandi arbitrari.
Il percorso vulnerabile non è però universale. Secondo la fonte, l'exploit richiede che il servizio target scriva i propri log tramite ETW (Event Tracing for Windows), non attraverso klog. Il ricercatore ha individuato in Calico con NSSM una configurazione che soddisfa questa condizione: NSSM gestisce autonomamente l'output di log, bypassando i meccanismi di Kubernetes e garantendo la scrittura diretta su ETW. Questo rende l'ambiente di test particolarmente favorevole, sebbene la fonte non escluda che altri setup Windows possano presentare prerequisiti diversi.
Dal report curl a SYSTEM: la dimostrazione di Akamai
La fonte fornisce esplicitamente il proof-of-concept: una richiesta curl all'endpoint proxy del nodo target, con il parametro pattern costruito per eseguire un processo arbitrario. La risposta del server contiene l'output del comando iniettato, confermando l'esecuzione con i privilegi del servizio kubelet — SYSTEM su Windows.
La differenza rispetto a vettori precedenti è sostanziale. CVE-2023-3676, scoperta dallo stesso Tomer Peled nel 2023, richiedeva l'invio di un manifest YAML malformato al kube-apiserver. CVE-2024-9042 elimina questo passaggio: l'attaccante interagisce direttamente con il nodo, riducendo la superficie di rilevamento e il controllo del piano di controllo. Per un operatore che monitora il traffico verso il kube-apiserver, questa richiesta GET al proxy del nodo può apparire come traffico legittimo di gestione.
"The vulnerability allows remote code execution (RCE) with SYSTEM privileges on all Windows endpoints within a Kubernetes cluster" — Akamai Security Research
Perché è importante
Il dossier non specifica il numero di cluster potenzialmente affetti, né documenta exploit in-the-wild. La fonte non indica misure correttive oltre l'aggiornamento alla versione 1.32.1, e non dettaglia se configurazioni Windows diverse da Calico/NSSM presentino condizioni ETW analoghe.
La rilevanza della scoperta va però oltre il singolo CVE. È il secondo caso in due anni in cui lo stesso ricercatore individua un pattern sistemico: componenti Windows-specifici di Kubernetes che inseriscono input utente in comandi PowerShell senza adeguata sanitizzazione. La recidività solleva questioni sulla revisione del codice relativo alla piattaforma Windows nel progetto, un'area tradizionalmente meno scrutinata rispetto al path Linux.
I cluster ibridi Windows/Linux sono diffusi in ambienti enterprise, specialmente in workload legacy che migrano verso container e orchestrazione cloud. La combinazione di nodi Windows con beta features abilitate — tipica in fasi di adozione di nuove capacità di logging — allarga la finestra di esposizione rispetto a installazioni conservative. La semplicità del vettore GET, inoltre, abbassa la barriera tecnica per l'exploitation rispetto a attacchi che richiedono comprensione del modello di oggetti di Kubernetes.
La fonte non chiarisce se il fix introduca anche controlli aggiuntivi su altri parametri del Log Query o se la mitigazione sia circoscritta al solo "pattern". Il dossier non documenta inoltre la data esatta di rilascio della versione 1.32.1, limitandosi a indicare le build precedenti come affette.
La correzione e il contesto della disclosure
Kubernetes ha adottato una mitigazione specifica: l'introduzione della variabile d'ambiente kubelet_pattern, che tratta l'input come string literal prima del passaggio al comando PowerShell. Questo approccio, documentato dalla fonte, elimina la possibilità di injection sintattica senza alterare la logica di filtraggio dei log.
La timeline di disclosure è parzialmente nota: il 28 giugno 2024 il ricercatore ha inoltrato la segnalazione al team di sicurezza di Kubernetes; il 18 luglio 2024 ha ricevuto risposta, ma il testo fornito tronca il contenuto a "Kubernetes t". La fonte non completa questo dato.
Il testing è stato condotto sia su deployment on-premise sia su Azure Kubernetes Service, indicando che la vulnerabilità non è condizionata da una specifica distribuzione cloud ma dal sottosistema Windows e dalle scelte di configurazione del cluster.
Domande frequenti
I nodi Linux sono coinvolti?
No. La fonte specifica esplicitamente che la vulnerabilità interessa esclusivamente i nodi Windows del cluster, in quanto il percorso vulnerabile utilizza PowerShell per l'interrogazione dei log.
È necessario abilitare qualcosa per essere a rischio?
Sì. La feature Log Query è in beta e richiede l'opt-in attraverso il feature-gate. Le installazioni default che non hanno abilitato le beta features non espongono il percorso vulnerabile.
Il fix è sufficiente a proteggere anche altre componenti simili?
Il dossier non fornisce elementi per valutare se la stessa modalità di costruzione dinamica dei comandi PowerShell esista in altre funzionalità Windows di Kubernetes. La fonte si limita a documentare il caso del Log Query.
Le informazioni sono basate sull advisory citata e aggiornate al momento della pubblicazione.
Fonti
- https://www.akamai.com/blog/security-research/kubernetes-log-query-rce-windows
- https://www.akamai.com/blog
- https://www.akamai.com/blog/security-research
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.