Una recente scoperta ha portato alla luce potenziali problemi di sicurezza nei cluster Kubernetes che utilizzano strumenti di monitoraggio. Sì, proprio così: se nel tuo cluster è presente un sistema di monitoraggio, questa storia potrebbe riguardarti da vicino.

Il ricercatore di sicurezza Graham Helton ha pubblicato un’analisi dettagliata in cui mostra come sia possibile eseguire codice arbitrario su qualsiasi pod utilizzando un semplice service account con permessi di sola lettura. Parliamo di un exploit relativamente semplice da riprodurre senza accessi privilegiati e che potrebbe compromettere un intero cluster.

Secondo Helton, nella pratica quotidiana molti amministratori Kubernetes concedono ai service account l’accesso alla risorsa nodes/proxy. Questo permesso è spesso necessario per raccogliere metriche, log dei container e informazioni di stato ed è quindi richiesto da numerosi strumenti di monitoraggio molto diffusi, come i classici Prometheus o lo Stack Elastic.

Il problema è che questo accesso, apparentemente innocuo, apre la porta a scenari molto più pericolosi. Il punto centrale della questione è il comportamento dell’endpoint nodes/proxy quando viene utilizzato tramite WebSocket.

nodes/proxy GET allows command execution when using a connection protocol such as WebSockets. This is due to the Kubelet making authorization decisions based on the initial WebSocket handshake’s request without verifying CREATE permissions are present for the Kubelet’s /exec endpoint requiring different permissions depending solely on the connection protocol.

La GET a nodes/proxy consente l’esecuzione di comandi quando si utilizza un protocollo di connessione come WebSocket. Ciò è dovuto al fatto che il Kubelet prende decisioni di autorizzazione basandosi sulla richiesta iniziale di handshake WebSocket senza verificare la presenza dei permessi CREATE per l’endpoint /exec di Kubelet, che richiede permessi diversi a seconda del protocollo di connessione.

Come spiega Helton, chiunque disponga di un service account con accesso GET a nodes/proxy e riesca a raggiungere il Kubelet sulla porta 10250 può accedere all’endpoint /exec ed eseguire comandi arbitrari sui pod, compresi i pod di sistema privilegiati.

E non è finita qui: queste azioni non vengono registrate dalla Kubernetes Audit Policy, perché i comandi eseguiti tramite una connessione diretta alle API del Kubelet non vengono loggati. Di fatto, un attacco può avvenire senza lasciare tracce evidenti.

Helton ha analizzato numerosi Helm Chart e ha identificato 69 chart potenzialmente impattati. Tra i più noti troviamo:

• prometheus-community/prometheus
• grafana/promtail
• datadog/datadog
• elastic/elastic-agent
• cilium/cilium
• opentelemetry-helm/opentelemetry-kube-stack
• trivy-operator/trivy-operator
• newrelic/newrelic-infrastructure
• wiz-sec/sensor

L’autore ha rilasciato anche una PoC funzionante per dimostrare l’attacco. È sufficiente utilizzare uno strumento in grado di gestire WebSocket, come websocat per lanciare l’exploit:

websocat --insecure \
  --header "Authorization: Bearer $TOKEN" \
  --protocol v4.channel.k8s.io \
  "wss://$NODE_IP:10250/exec/default/nginx/nginx?output=1&error=1&command=id"

Questa richiesta avrà come risultato una RCE, ovvero:

uid=0(root) gid=0(root) groups=0(root)

Una vera e propria remote code execution all’interno del pod.

Secondo Helton, un attaccante potrebbe sfruttare questa vulnerabilità rubando token di service account da altri pod ed eseguire codice nei pod del control plane per prendere il controllo dell’intero cluster.

Riguardo a questa presunta vulnerabilità, la posizione ufficiale del team di sicurezza di Kubernetes è chiara:

Following further review with SIG-Auth and SIG-Node, we are confirming our decision that this behavior is working as intended and will not be receiving a CVE. While we agree that nodes/proxy presents a risk, a patch to restrict this specific path would require changing authorization in both the kubelet (to special-case the /exec path) and the kube-apiserver

A seguito di un’ulteriore revisione con SIG-Auth e SIG-Node, confermiamo la nostra decisione secondo cui questo comportamento funziona come previsto e non riceverà un CVE. Pur concordando sul fatto che i nodi/proxy presentano un rischio, una patch per limitare questo percorso specifico richiederebbe la modifica dell’autorizzazione sia nel kubelet (per trattare il percorso /exec come caso speciale) che nel kube-apiserver.

La risposta è quindi “working as intended” ovvero nessuna vulnerabilità né tanto meno una CVE.

La soluzione che viene proposta per evitare la code execution sui pod è quella di usare le KEP-2862, ovvero la Fine-grained Kubelet API authorization che però è ancora in beta e secondo Graham non è una risoluzione effettiva del problema.

In attesa che KEP-2862 diventi stabile e venga adottato su larga scala, è opportuno adottare una serie di contromisure pratiche:

• Audit immediato delle policy RBAC che concedono accesso a nodes/proxy. Eliminate tutto quello che non è necessario
• Implementare delle NetworkPolicy per limitare l’accesso alla porta 10250
• Adottare tecnologie di isolamento dei workload per evitare movimenti laterali e ulteriori exploit

Buone patch!