gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-29 22:20:33 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains

Browse Source
This commit is contained in:
Translator
2025-01-11 18:51:46 +00:00
parent c312e61a71
commit fa893cca64
44 changed files with 1974 additions and 401 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
View File

@@ -13,13 +13,13 @@
Um zu versuchen, aus den Pods zu entkommen, müssen Sie möglicherweise zuerst **Berechtigungen eskalieren**, einige Techniken dafür:
{{#ref}}
https://book.hacktricks.xyz/linux-hardening/privilege-escalation
https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html
{{#endref}}
Sie können diese **Docker-Ausbrüche überprüfen, um zu versuchen, aus einem Pod zu entkommen, den Sie kompromittiert haben:**
{{#ref}}
https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-breakout
https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/index.html
{{#endref}}
### Missbrauch von Kubernetes-Berechtigungen
@@ -30,7 +30,7 @@ Wie im Abschnitt über **Kubernetes-Enumeration** erklärt:
kubernetes-enumeration.md
{{#endref}}
In der Regel werden die Pods mit einem **Service-Account-Token** innerhalb von ihnen ausgeführt. Dieser Service-Account kann einige **Berechtigungen haben**, die Sie **missbrauchen** könnten, um zu anderen Pods zu **wechseln** oder sogar zu den Knoten, die im Cluster konfiguriert sind, zu **entkommen**. Überprüfen Sie, wie in:
In der Regel werden die Pods mit einem **Service-Account-Token** innerhalb von ihnen ausgeführt. Dieser Service-Account kann einige **Berechtigungen haben**, die Sie **ausnutzen** können, um zu anderen Pods zu **wechseln** oder sogar zu den Knoten, die im Cluster konfiguriert sind, zu **entkommen**. Überprüfen Sie, wie in:
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
@@ -42,7 +42,7 @@ Wenn der Pod in einer **Cloud-Umgebung** ausgeführt wird, könnten Sie in der L
## Suche nach anfälligen Netzwerkdiensten
Da Sie sich in der Kubernetes-Umgebung befinden, sollten Sie, wenn Sie die Berechtigungen nicht durch den Missbrauch der aktuellen Pod-Berechtigungen eskalieren können und nicht aus dem Container entkommen können, **potenziell anfällige Dienste suchen.**
Da Sie sich in der Kubernetes-Umgebung befinden, sollten Sie, wenn Sie die Berechtigungen der aktuellen Pods nicht ausnutzen und nicht aus dem Container entkommen können, **nach potenziell anfälligen Diensten suchen.**
### Dienste
@@ -73,7 +73,7 @@ nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
}
nmap-kube-discover
```
Überprüfen Sie die folgende Seite, um zu erfahren, wie Sie **Kubernetes-spezifische Dienste angreifen** können, um **andere Pods/die gesamte Umgebung zu kompromittieren**:
Überprüfen Sie die folgende Seite, um zu erfahren, wie Sie **Kubernetes-spezifische Dienste** **angreifen** können, um **andere Pods/die gesamte Umgebung zu kompromittieren**:
{{#ref}}
pentesting-kubernetes-services/
@@ -94,7 +94,7 @@ kubernetes-network-attacks.md
## Node DoS
Es gibt keine Spezifikation von Ressourcen in den Kubernetes-Manifests und **keine angewendeten Limit**-Bereiche für die Container. Als Angreifer können wir **alle Ressourcen verbrauchen, in denen der Pod/Deployment läuft**, und andere Ressourcen aushungern und einen DoS für die Umgebung verursachen.
Es gibt keine Spezifikation von Ressourcen in den Kubernetes-Manifests und **keine angewendeten Limit**-Bereiche für die Container. Als Angreifer können wir **alle Ressourcen verbrauchen, in denen der Pod/Deployment läuft** und andere Ressourcen aushungern und einen DoS für die Umgebung verursachen.
Dies kann mit einem Tool wie [**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng) durchgeführt werden:
```
@@ -106,10 +106,10 @@ kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxx
```
## Node Post-Exploitation
Wenn Sie es geschafft haben, **aus dem Container zu entkommen**, gibt es einige interessante Dinge, die Sie im Knoten finden werden:
Wenn Sie es geschafft haben, **aus dem Container zu entkommen**, gibt es einige interessante Dinge, die Sie im Node finden werden:
- Der **Container Runtime** Prozess (Docker)
- Weitere **Pods/Container**, die im Knoten laufen und die Sie wie diesen missbrauchen können (mehr Tokens)
- Weitere **Pods/Container**, die im Node laufen und die Sie wie diesen missbrauchen können (mehr Tokens)
- Das gesamte **Dateisystem** und das **Betriebssystem** im Allgemeinen
- Der **Kube-Proxy** Dienst, der lauscht
- Der **Kubelet** Dienst, der lauscht. Überprüfen Sie die Konfigurationsdateien:
@@ -119,7 +119,7 @@ Wenn Sie es geschafft haben, **aus dem Container zu entkommen**, gibt es einige
- `/var/lib/kubelet/config.yaml`
- `/var/lib/kubelet/kubeadm-flags.env`
- `/etc/kubernetes/kubelet-kubeconfig`
- Weitere **kubernetes gemeinsame Dateien**:
- Weitere **kubernetes gängige Dateien**:
- `$HOME/.kube/config` - **Benutzerkonfiguration**
- `/etc/kubernetes/kubelet.conf` - **Reguläre Konfiguration**
- `/etc/kubernetes/bootstrap-kubelet.conf` - **Bootstrap-Konfiguration**
@@ -154,14 +154,14 @@ echo ""
fi
done
```
Das Skript [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) wird automatisch **die Tokens anderer Pods abrufen und überprüfen, ob sie die Berechtigung** haben, nach der Sie suchen (anstatt dass Sie 1 nach dem anderen suchen):
Das Skript [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) wird automatisch **die Tokens anderer Pods abrufen und überprüfen, ob sie die Berechtigung** haben, nach der Sie suchen (anstatt dass Sie 1 für 1 suchen):
```bash
./can-they.sh -i "--list -n default"
./can-they.sh -i "list secrets -n kube-system"// Some code
```
### Privileged DaemonSets
Ein DaemonSet ist ein **pod**, der in **allen Knoten des Clusters** **ausgeführt** wird. Daher, wenn ein DaemonSet mit einem **privilegierten Dienstkonto** konfiguriert ist, wirst du in **ALLEN Knoten** das **Token** dieses **privilegierten Dienstkontos** finden, das du ausnutzen könntest.
Ein DaemonSet ist ein **pod**, der in **allen Knoten des Clusters** **ausgeführt** wird. Daher, wenn ein DaemonSet mit einem **privilegierten Dienstkonto** konfiguriert ist, wirst du in **ALLEN Knoten** das **Token** dieses **privilegierten Dienstkontos** finden, das du missbrauchen könntest.
Der Exploit ist derselbe wie im vorherigen Abschnitt, aber du bist jetzt nicht auf Glück angewiesen.
@@ -175,7 +175,7 @@ kubernetes-pivoting-to-clouds.md
### Steal etcd
Wenn du den [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node) des Knotens angeben kannst, der den Container ausführen wird, erhalte eine Shell innerhalb eines Control-Plane-Knotens und hole die **etcd-Datenbank**:
Wenn du den [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node) des Knotens angeben kannst, der den Container ausführen wird, erhalte eine Shell in einem Control-Plane-Knoten und hole die **etcd-Datenbank**:
```
kubectl get nodes
NAME STATUS ROLES AGE VERSION
@@ -186,15 +186,15 @@ control-plane-Knoten haben die **Rolle Master** und in **cloud-managed Clustern
#### Geheimnisse aus etcd lesen 1
Wenn Sie Ihren Pod auf einem control-plane-Knoten mit dem `nodeName`-Selektor in der Pod-Spezifikation ausführen können, haben Sie möglicherweise einfachen Zugriff auf die `etcd`-Datenbank, die alle Konfigurationen für den Cluster enthält, einschließlich aller Geheimnisse.
Wenn Sie Ihren Pod auf einem Control-Plane-Knoten mit dem `nodeName`-Selektor in der Pod-Spezifikation ausführen können, haben Sie möglicherweise einfachen Zugriff auf die `etcd`-Datenbank, die alle Konfigurationen für den Cluster, einschließlich aller Geheimnisse, enthält.
Unten finden Sie eine schnelle und einfache Möglichkeit, Geheimnisse aus `etcd` zu extrahieren, wenn es auf dem control-plane-Knoten läuft, auf dem Sie sich befinden. Wenn Sie eine elegantere Lösung wünschen, die einen Pod mit dem `etcd`-Client-Utility `etcdctl` startet und die Anmeldeinformationen des control-plane-Knotens verwendet, um sich mit etcd zu verbinden, wo auch immer es läuft, schauen Sie sich [dieses Beispiel-Manifest](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) von @mauilion an.
Unten finden Sie eine schnelle und schmutzige Möglichkeit, Geheimnisse aus `etcd` zu extrahieren, wenn es auf dem Control-Plane-Knoten läuft, auf dem Sie sich befinden. Wenn Sie eine elegantere Lösung wünschen, die einen Pod mit dem `etcd`-Client-Utility `etcdctl` startet und die Anmeldeinformationen des Control-Plane-Knotens verwendet, um sich mit etcd zu verbinden, wo auch immer es läuft, schauen Sie sich [dieses Beispiel-Manifest](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) von @mauilion an.
**Überprüfen Sie, ob `etcd` auf dem control-plane-Knoten läuft und wo sich die Datenbank befindet (Dies ist in einem `kubeadm`-erstellten Cluster)**
**Überprüfen Sie, ob `etcd` auf dem Control-Plane-Knoten läuft und wo sich die Datenbank befindet (Dies ist in einem `kubeadm`-erstellten Cluster)**
```
root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir
```
Bitte geben Sie den zu übersetzenden Text an.
Please provide the text you would like me to translate.
```bash
data-dir=/var/lib/etcd
```
@@ -206,11 +206,11 @@ strings /var/lib/etcd/member/snap/db | less
```bash
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done
```
**Dasselbe Kommando, aber einige Greps, um nur das Standard-Token im kube-system-Namespace zurückzugeben**
**Der gleiche Befehl, aber einige Greps, um nur das Standard-Token im kube-system-Namespace zurückzugeben**
```bash
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default
```
Bitte geben Sie den zu übersetzenden Text an.
Please provide the text you would like me to translate.
```
1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]
```
@@ -222,12 +222,12 @@ Bitte geben Sie den zu übersetzenden Text an.
```bash
mkdir -p restore ; etcdutl snapshot restore etcd-loot-backup.db \ --data-dir ./restore
```
4. Start **`etcd`** auf deinem lokalen Rechner und lasse es den gestohlenen Snapshot verwenden:
4. Start **`etcd`** auf Ihrem lokalen Rechner und lassen Sie es den gestohlenen Snapshot verwenden:
```bash
etcd \ --data-dir=./restore \ --initial-cluster=state=existing \ --snapshot='./etcd-loot-backup.db'
```
5. Liste alle Geheimnisse auf:
5. Liste alle Geheimnisse:
```bash
etcdctl get "" --prefix --keys-only | grep secret
```
@@ -235,13 +235,13 @@ etcdctl get "" --prefix --keys-only | grep secret
```bash
etcdctl get /registry/secrets/default/my-secret
```
### Statische/Mirrored Pods Persistenz
### Statische/Gespiegelte Pods Persistenz
_Statische Pods_ werden direkt vom kubelet-Daemon auf einem bestimmten Knoten verwaltet, ohne dass der API-Server sie beobachtet. Im Gegensatz zu Pods, die vom Control Plane verwaltet werden (zum Beispiel ein Deployment); stattdessen **überwacht der kubelet jeden statischen Pod** (und startet ihn neu, wenn er fehlschlägt).
_Statische Pods_ werden direkt vom kubelet-Daemon auf einem bestimmten Knoten verwaltet, ohne dass der API-Server sie beobachtet. Im Gegensatz zu Pods, die vom Control Plane verwaltet werden (zum Beispiel ein Deployment); stattdessen **beobachtet der kubelet jeden statischen Pod** (und startet ihn neu, wenn er fehlschlägt).
Daher sind statische Pods immer **an einen Kubelet** auf einem bestimmten Knoten gebunden.
Der **kubelet versucht automatisch, einen Mirror-Pod auf dem Kubernetes-API-Server** für jeden statischen Pod zu erstellen. Das bedeutet, dass die Pods, die auf einem Knoten ausgeführt werden, auf dem API-Server sichtbar sind, aber von dort aus nicht gesteuert werden können. Die Pod-Namen werden mit dem Hostnamen des Knotens und einem vorangestellten Bindestrich versehen.
Der **kubelet versucht automatisch, einen Spiegel-Pod auf dem Kubernetes API-Server** für jeden statischen Pod zu erstellen. Das bedeutet, dass die Pods, die auf einem Knoten ausgeführt werden, auf dem API-Server sichtbar sind, aber von dort aus nicht gesteuert werden können. Die Pod-Namen werden mit dem Hostnamen des Knotens und einem vorangestellten Bindestrich versehen.
> [!CAUTION]
> Die **`spec` eines statischen Pods kann nicht auf andere API-Objekte** verweisen (z. B. ServiceAccount, ConfigMap, Secret usw.). Daher **kannst du dieses Verhalten nicht ausnutzen, um einen Pod mit einem beliebigen ServiceAccount** im aktuellen Knoten zu starten, um den Cluster zu kompromittieren. Aber du könntest dies nutzen, um Pods in verschiedenen Namespaces auszuführen (falls das aus irgendeinem Grund nützlich ist).
@@ -250,7 +250,7 @@ Wenn du dich im Knotenhost befindest, kannst du ihn dazu bringen, einen **statis
Um einen statischen Pod zu erstellen, sind die [**Dokumente eine große Hilfe**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/). Du benötigst im Grunde 2 Dinge:
- Konfiguriere den Parameter **`--pod-manifest-path=/etc/kubernetes/manifests`** im **kubelet-Dienst** oder in der **kubelet-Konfiguration** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) und starte den Dienst neu
- Konfiguriere den Parameter **`--pod-manifest-path=/etc/kubernetes/manifests`** im **kubelet-Dienst** oder in der **kubelet-Konfiguration** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) und starte den Dienst neu
- Erstelle die Definition in der **Pod-Definition** in **`/etc/kubernetes/manifests`**
**Eine andere, stealthy Methode wäre:**
@@ -286,7 +286,7 @@ type: Directory
### Pods löschen + nicht planbare Knoten
Wenn ein Angreifer **einen Knoten kompromittiert hat** und er **Pods von anderen Knoten löschen** und **andere Knoten daran hindern kann, Pods auszuführen**, werden die Pods im kompromittierten Knoten neu gestartet und er wird in der Lage sein, die **Tokens**, die darin ausgeführt werden, zu **stehlen**.\
Für [**weitere Informationen folgen Sie diesen Links**](abusing-roles-clusterroles-in-kubernetes/#delete-pods-+-unschedulable-nodes).
Für [**weitere Informationen folgen Sie diesen Links**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes).
## Automatische Werkzeuge