Kubernetes Enumeration
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Se hai accesso compromesso a una macchina, l'utente potrebbe avere accesso a qualche piattaforma Kubernetes. Il token si trova solitamente in un file indicato dalla variabile d'ambiente KUBECONFIG
o all'interno di ~/.kube
.
In questa cartella potresti trovare file di configurazione con token e configurazioni per connettersi al server API. In questa cartella puoi anche trovare una cartella di cache con informazioni precedentemente recuperate.
Se hai compromesso un pod all'interno di un ambiente kubernetes, ci sono altri luoghi dove puoi trovare token e informazioni sull'attuale ambiente K8:
Prima di continuare, se non sai cosa sia un servizio in Kubernetes, ti consiglio di seguire questo link e leggere almeno le informazioni sull'architettura di Kubernetes.
Preso dalla documentazione di Kubernetes:
“Quando crei un pod, se non specifichi un service account, viene automaticamente assegnato il service account predefinito nello stesso namespace.”
ServiceAccount è un oggetto gestito da Kubernetes e utilizzato per fornire un'identità per i processi che vengono eseguiti in un pod. Ogni service account ha un segreto ad esso correlato e questo segreto contiene un bearer token. Questo è un JSON Web Token (JWT), un metodo per rappresentare in modo sicuro le affermazioni tra due parti.
Di solito uno delle directory:
/run/secrets/kubernetes.io/serviceaccount
/var/run/secrets/kubernetes.io/serviceaccount
/secrets/kubernetes.io/serviceaccount
contiene i file:
ca.crt: È il certificato ca per controllare le comunicazioni kubernetes
namespace: Indica l'attuale namespace
token: Contiene il token di servizio dell'attuale pod.
Ora che hai il token, puoi trovare il server API all'interno della variabile d'ambiente KUBECONFIG
. Per ulteriori informazioni esegui (env | set) | grep -i "kuber|kube
"
Il token del service account è firmato dalla chiave presente nel file sa.key e convalidato da sa.pub.
Posizione predefinita su Kubernetes:
/etc/kubernetes/pki
Posizione predefinita su Minikube:
/var/lib/localkube/certs
Hot pods sono pods che contengono un token di service account privilegiato. Un token di service account privilegiato è un token che ha il permesso di eseguire compiti privilegiati come elencare segreti, creare pod, ecc.
Se non sai cosa sia RBAC, leggi questa sezione.
k9s: Un'interfaccia grafica che enumera un cluster kubernetes dal terminale. Controlla i comandi in https://k9scli.io/topics/commands/. Scrivi :namespace
e seleziona tutto per poi cercare risorse in tutti i namespace.
k8slens: Offre alcuni giorni di prova gratuita: https://k8slens.dev/
Per enumerare un ambiente K8 hai bisogno di un paio di queste:
Un token di autenticazione valido. Nella sezione precedente abbiamo visto dove cercare un token utente e un token di service account.
L'indirizzo (https://host:port) dell'API Kubernetes. Questo può essere solitamente trovato nelle variabili d'ambiente e/o nel file di configurazione kube.
Opzionale: Il ca.crt per verificare il server API. Questo può essere trovato negli stessi luoghi in cui può essere trovato il token. Questo è utile per verificare il certificato del server API, ma utilizzando --insecure-skip-tls-verify
con kubectl
o -k
con curl
non avrai bisogno di questo.
Con questi dettagli puoi enumerare kubernetes. Se l'API per qualche motivo è accessibile attraverso l'Internet, puoi semplicemente scaricare quelle informazioni e enumerare la piattaforma dal tuo host.
Tuttavia, di solito il server API è all'interno di una rete interna, quindi dovrai creare un tunnel attraverso la macchina compromessa per accedervi dalla tua macchina, oppure puoi caricare il kubectl binario, o usare curl/wget/anything
per eseguire richieste HTTP raw al server API.
list
and get
verbsCon i permessi get
puoi accedere alle informazioni di asset specifici (opzione describe
in kubectl
) API:
Se hai il permesso list
, ti è consentito eseguire richieste API per elencare un tipo di risorsa (get
opzione in kubectl
):
Se hai il permesso watch
, ti è consentito eseguire richieste API per monitorare le risorse:
Aprono una connessione streaming che ti restituisce il manifesto completo di un Deployment ogni volta che cambia (o quando ne viene creato uno nuovo).
I seguenti comandi kubectl
indicano solo come elencare gli oggetti. Se vuoi accedere ai dati, devi usare describe
invece di get
Dall'interno di un pod puoi usare diverse variabili d'ambiente:
Per impostazione predefinita, il pod può accedere al kube-api server nel nome di dominio kubernetes.default.svc
e puoi vedere la rete kube in /etc/resolv.config
poiché qui troverai l'indirizzo del server DNS di kubernetes (il ".1" della stessa gamma è l'endpoint kube-api).
Avendo il token e l'indirizzo del server API, puoi utilizzare kubectl o curl per accedervi come indicato qui:
Per impostazione predefinita, l'APISERVER comunica con lo schema https://
se non c'è
https://
nell'URL, potresti ricevere un errore come Bad Request.
Puoi trovare un foglio di riferimento ufficiale di kubectl qui. L'obiettivo delle sezioni seguenti è presentare in modo ordinato diverse opzioni per enumerare e comprendere il nuovo K8s a cui hai ottenuto accesso.
Per trovare la richiesta HTTP che kubectl
invia, puoi usare il parametro -v=8
Se sei riuscito a rubare le credenziali di alcuni utenti, puoi configurarle localmente utilizzando qualcosa come:
Con queste informazioni saprai tutti i servizi che puoi elencare
Un altro modo per controllare i tuoi privilegi è utilizzare lo strumento: https://github.com/corneliusweig/rakkess****
Puoi saperne di più su Kubernetes RBAC in:
Kubernetes Role-Based Access Control(RBAC)Una volta che sai quali privilegi hai, controlla la seguente pagina per capire se puoi abusarne per escalare i privilegi:
Abusing Roles/ClusterRoles in KubernetesKubernetes supporta più cluster virtuali supportati dallo stesso cluster fisico. Questi cluster virtuali sono chiamati namespace.
Se puoi leggere i segreti, puoi usare le seguenti righe per ottenere i privilegi relativi a ciascun token:
Come discusso all'inizio di questa pagina quando un pod viene eseguito, di solito viene assegnato un account di servizio. Pertanto, elencare gli account di servizio, le loro autorizzazioni e dove vengono eseguiti potrebbe consentire a un utente di elevare i privilegi.
I deployments specificano i componenti che devono essere eseguiti.
I Pods sono i contenitori effettivi che verranno eseguiti.
I servizi di Kubernetes vengono utilizzati per esporre un servizio su una porta e un IP specifici (che agiranno come bilanciatore di carico per i pod che offrono effettivamente il servizio). È interessante sapere dove puoi trovare altri servizi da provare ad attaccare.
Ottieni tutti i nodi configurati all'interno del cluster.
DaeamonSets consente di garantire che un pod specifico sia in esecuzione in tutti i nodi del cluster (o in quelli selezionati). Se elimini il DaemonSet, i pod gestiti da esso verranno rimossi.
I cron job consentono di pianificare, utilizzando una sintassi simile a crontab, il lancio di un pod che eseguirà alcune azioni.
configMap contiene sempre molte informazioni e file di configurazione che forniscono alle app che girano in Kubernetes. Di solito puoi trovare molte password, segreti e token utilizzati per connettersi e convalidare altri servizi interni/esterni.
Se sei in grado di creare nuovi pod, potresti essere in grado di uscire da essi verso il nodo. Per farlo, devi creare un nuovo pod utilizzando un file yaml, passare al pod creato e poi chroot nel sistema del nodo. Puoi utilizzare pod già esistenti come riferimento per il file yaml poiché mostrano immagini e percorsi esistenti.
se hai bisogno di creare un pod su un nodo specifico, puoi usare il seguente comando per ottenere le etichette sul nodo
k get nodes --show-labels
Comunemente, kubernetes.io/hostname e node-role.kubernetes.io/master sono tutte buone etichette per la selezione.
Poi crei il tuo file attack.yaml
Dopo di che crei il pod
Ora puoi passare al pod creato come segue
E infine ti chroot nel sistema del nodo
Informazioni ottenute da: Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1 Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)