mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-29 06:03:26 -08:00
Translated ['src/pentesting-cloud/azure-security/az-services/az-cosmosDB
This commit is contained in:
Translator
@@ -19,7 +19,7 @@ Lernen & üben Sie GCP Hacking: <img src="../../../.gitbook/assets/image (2) (1)
|
||||
|
||||
**Azure Cosmos DB** ist eine vollständig **verwaltete NoSQL-, relationale und Vektordatenbank**, die Reaktionszeiten im einstelligen Millisekundenbereich, automatische Skalierbarkeit und SLA-gestützte Verfügbarkeit mit Unternehmenssicherheit bietet. Es ermöglicht eine schnellere Anwendungsentwicklung durch schlüsselfertige, mehrregionale Datenverteilung, Open-Source-APIs, SDKs für beliebte Sprachen und KI-Datenbankfunktionen wie integrierte Vektorsupport und nahtlose Azure KI-Integration.
|
||||
|
||||
Azure Cosmos DB bietet mehrere Datenbank-APIs, um reale Daten mit Dokumenten, relationalen, Schlüssel-Wert-, Graph- und Spaltenfamilien-Datenmodellen zu modellieren, wobei diese APIs NoSQL, MongoDB, PostgreSQL, Cassandra, Gremlin und Table sind.
|
||||
Azure Cosmos DB bietet mehrere Datenbank-APIs, um reale Daten mit Dokumenten, relationalen, Schlüssel-Wert-, Graph- und Spaltenfamilien-Datenmodellen zu modellieren. Diese APIs sind NoSQL, MongoDB, PostgreSQL, Cassandra, Gremlin und Table.
|
||||
|
||||
Ein wichtiger Aspekt von CosmosDB ist das Azure Cosmos-Konto. **Azure Cosmos-Konto** fungiert als Einstiegspunkt zu den Datenbanken. Das Konto bestimmt wichtige Einstellungen wie globale Verteilung, Konsistenzstufen und die spezifische API, die verwendet werden soll, wie z.B. NoSQL. Über das Konto können Sie die globale Replikation konfigurieren, um sicherzustellen, dass Daten in mehreren Regionen für einen latenzarmen Zugriff verfügbar sind. Darüber hinaus können Sie eine Konsistenzstufe wählen, die zwischen Leistung und Datenakkuratheit balanciert, mit Optionen von starker bis eventualer Konsistenz.
|
||||
|
||||
@@ -36,7 +36,7 @@ https://<Account-Name>.documents.azure.com:443/
|
||||
Innerhalb eines Kontos können Sie eine oder mehrere Datenbanken erstellen, die als logische Gruppierungen von Containern dienen. Eine Datenbank fungiert als Grenze für das Ressourcenmanagement und die Benutzerberechtigungen. Datenbanken können entweder die bereitgestellte Durchsatzrate über ihre Container teilen oder dedizierten Durchsatz für einzelne Container zuweisen.
|
||||
|
||||
#### Container
|
||||
Die zentrale Einheit der Datenspeicherung ist der Container, der JSON-Dokumente enthält und automatisch für effiziente Abfragen indiziert wird. Container sind elastisch skalierbar und über Partitionen verteilt, die durch einen benutzerdefinierten Partitionierungsschlüssel bestimmt werden. Der Partitionierungsschlüssel ist entscheidend für die Gewährleistung optimaler Leistung und gleichmäßiger Datenverteilung. Zum Beispiel könnte ein Container Kundendaten speichern, wobei "customerId" als Partitionierungsschlüssel dient.
|
||||
Die zentrale Einheit der Datenspeicherung ist der Container, der JSON-Dokumente enthält und automatisch für effizientes Abfragen indiziert wird. Container sind elastisch skalierbar und über Partitionen verteilt, die durch einen benutzerdefinierten Partitionierungsschlüssel bestimmt werden. Der Partitionierungsschlüssel ist entscheidend für die Gewährleistung optimaler Leistung und gleichmäßiger Datenverteilung. Zum Beispiel könnte ein Container Kundendaten speichern, wobei "customerId" als Partitionierungsschlüssel dient.
|
||||
|
||||
#### Aufzählung
|
||||
|
||||
@@ -131,7 +131,7 @@ Get-AzCosmosDBSqlUserDefinedFunction -ResourceGroupName "<ResourceGroupName>" -A
|
||||
|
||||
#### Verbindung
|
||||
|
||||
Um die azure-cosmosDB (pip install azure-cosmos) zu verbinden, wird die Bibliothek benötigt. Darüber hinaus sind der Endpunkt und der Schlüssel entscheidende Komponenten, um die Verbindung herzustellen.
|
||||
Um die azure-cosmosDB (pip install azure-cosmos) Bibliothek zu verbinden, sind der Endpunkt und der Schlüssel entscheidende Komponenten, um die Verbindung herzustellen.
|
||||
{% code overflow="wrap" %}
|
||||
```python
|
||||
from azure.cosmos import CosmosClient, PartitionKey
|
||||
@@ -203,7 +203,7 @@ print("Document inserted.")
|
||||
{% endcode %}
|
||||
|
||||
### MongoDB
|
||||
Die MongoDB NoSQL-API ist eine dokumentenbasierte API, die JSON-ähnliches BSON (Binary JSON) als Datenformat verwendet. Sie bietet eine Abfragesprache mit Aggregationsfähigkeiten, was sie geeignet macht für die Arbeit mit strukturierten, semi-strukturierten und unstrukturierten Daten. Der Endpunkt des Dienstes folgt typischerweise diesem Format:
|
||||
Die MongoDB NoSQL-API ist eine dokumentenbasierte API, die BSON (Binary JSON) im JSON-ähnlichen Format als Datenformat verwendet. Sie bietet eine Abfragesprache mit Aggregationsfähigkeiten, was sie geeignet macht für die Arbeit mit strukturierten, semi-strukturierten und unstrukturierten Daten. Der Endpunkt des Dienstes folgt typischerweise diesem Format:
|
||||
|
||||
{% code overflow="wrap" %}
|
||||
```bash
|
||||
@@ -291,7 +291,7 @@ Get-AzCosmosDBMongoDBRoleDefinition -AccountName <account-name> -ResourceGroupNa
|
||||
|
||||
#### Verbindung
|
||||
|
||||
Hier das Passwort, das Sie mit den Schlüsseln oder mit der im Privesc-Abschnitt beschriebenen Methode finden können.
|
||||
Hier können Sie das Passwort mit den Schlüsseln oder mit der im Privesc-Abschnitt beschriebenen Methode finden.
|
||||
{% code overflow="wrap" %}
|
||||
```python
|
||||
from pymongo import MongoClient
|
||||
|
||||
@@ -1,37 +0,0 @@
|
||||
# Az - VMs Unath
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Virtuelle Maschinen
|
||||
|
||||
Für weitere Informationen zu Azure Virtual Machines siehe:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/vms/
|
||||
{{#endref}}
|
||||
|
||||
### Ausgesetzter verwundbarer Dienst
|
||||
|
||||
Ein Netzwerkdienst, der anfällig für einige RCE ist.
|
||||
|
||||
### Öffentliche Galerie-Bilder
|
||||
|
||||
Ein öffentliches Bild könnte Geheimnisse enthalten:
|
||||
```bash
|
||||
# List all community galleries
|
||||
az sig list-community --output table
|
||||
|
||||
# Search by publisherUri
|
||||
az sig list-community --output json --query "[?communityMetadata.publisherUri=='https://3nets.io']"
|
||||
```
|
||||
### Öffentliche Erweiterungen
|
||||
|
||||
Das wäre zwar seltsam, aber nicht unmöglich. Ein großes Unternehmen könnte eine Erweiterung mit sensiblen Daten darin bereitstellen:
|
||||
```bash
|
||||
# It takes some mins to run
|
||||
az vm extension image list --output table
|
||||
|
||||
# Get extensions by publisher
|
||||
az vm extension image list --publisher "Site24x7" --output table
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -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, **andere Benutzer/Gruppen/SAs zu impersonifizieren**, die bessere Berechtigungen innerhalb des Kubernetes-Clusters oder zu externen Clouds haben
|
||||
- In der Lage sein, **Pods zu erstellen/zu patchen/auszuführen**, wo 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 SAs-Token als Secrets gespeichert sind
|
||||
- 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
|
||||
- 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, **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
|
||||
- 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 ü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.
|
||||
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.
|
||||
```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 Eskalation von Berechtigungen darstellt.
|
||||
1. **`create`:** Gewährt die Möglichkeit, jede Cluster-Ressource zu erstellen, was ein Risiko für die Privilegieneskalation 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
|
||||
@@ -47,9 +47,9 @@ rules:
|
||||
resources: ["*"]
|
||||
verbs: ["create", "list", "get"]
|
||||
```
|
||||
### Pod Create - Steal Token
|
||||
### Pod erstellen - Token stehlen
|
||||
|
||||
Ein Angreifer mit den Berechtigungen zum Erstellen eines Pods könnte ein privilegiertes Service-Konto in den Pod anhängen und das Token stehlen, um das Service-Konto zu impersonieren. Dadurch werden die Berechtigungen effektiv erhöht.
|
||||
Ein Angreifer mit den Berechtigungen zum Erstellen eines Pods könnte ein privilegiertes Service-Konto in den Pod anhängen und das Token stehlen, um das Service-Konto zu impersonifizieren. Dadurch werden die Berechtigungen effektiv erhöht.
|
||||
|
||||
Beispiel eines Pods, der das Token des `bootstrap-signer` Service-Kontos stehlen und es an den Angreifer senden wird:
|
||||
```yaml
|
||||
@@ -78,7 +78,7 @@ 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 die Cloud-Berechtigungen der Knoten zu stehlen und besseren Zugang zu Netzwerken zu erhalten
|
||||
- **Deaktivieren des hostNetwork**-Namespaces, der Zugriff ermöglicht, um 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
|
||||
@@ -151,7 +151,7 @@ pod-escape-privileges.md
|
||||
|
||||
### **Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs und Cronjobs erstellen/patchen**
|
||||
|
||||
Es ist möglich, diese Berechtigungen auszunutzen, um einen **neuen Pod** zu **erstellen** und Berechtigungen wie im vorherigen Beispiel zu erlangen.
|
||||
Es ist möglich, diese Berechtigungen auszunutzen, um **einen neuen Pod zu erstellen** und Berechtigungen wie im vorherigen Beispiel zu erlangen.
|
||||
|
||||
Die folgende YAML **erstellt ein Daemonset und exfiltriert das Token des SA** innerhalb des Pods:
|
||||
```yaml
|
||||
@@ -193,20 +193,20 @@ 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 den Knoten (miss)zu verwenden:
|
||||
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:
|
||||
```bash
|
||||
kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
|
||||
```
|
||||
### port-forward
|
||||
|
||||
Diese Berechtigung erlaubt es, **einen lokalen Port an einen Port im angegebenen Pod weiterzuleiten**. Dies soll es ermöglichen, Anwendungen, die innerhalb eines Pods 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 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:
|
||||
```
|
||||
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 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.\
|
||||
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.\
|
||||
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:
|
||||
@@ -235,11 +235,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 erneut einhängen:
|
||||
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:
|
||||
```bash
|
||||
mount -o rw,remount /hostlogs/
|
||||
```
|
||||
#### Bypassing hostPath readOnly protection <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
#### Umgehung 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
|
||||
@@ -383,15 +383,7 @@ Beachten Sie, dass, wenn Sie in einem bestimmten Namespace Secrets erstellen und
|
||||
|
||||
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).
|
||||
|
||||
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, können Sie **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:
|
||||
Das Token wird aus einem begrenzten 27-Zeichen-Satz (`bcdfghjklmnpqrstvwxz2456789`) generiert,
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -424,10 +416,10 @@ verbs:
|
||||
```
|
||||
Also, mit dem genehmigten neuen Node CSR kannst du die speziellen 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 zu eskalieren, indem Geheimnisse gestohlen werden.\
|
||||
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.**
|
||||
|
||||
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):
|
||||
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):
|
||||
```bash
|
||||
"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
|
||||
```
|
||||
@@ -481,7 +473,7 @@ groups:
|
||||
|
||||
### 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 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 die 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.\
|
||||
@@ -511,7 +503,7 @@ Für ein [`mutatingwebhookconfigurations` Beispiel überprüfen Sie diesen Absch
|
||||
|
||||
### Eskalieren
|
||||
|
||||
Wie Sie im nächsten Abschnitt lesen können: [**Integrierte Prävention von privilegierter 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`** über **`roles`** oder **`clusterroles`**.\
|
||||
Dann kann er neue Rollen, Clusterrollen mit besseren Berechtigungen als die, die er hat, aktualisieren/erstellen.
|
||||
|
||||
### Nodes-Proxy
|
||||
@@ -541,7 +533,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)).
|
||||
|
||||
### Knoten- und Pod-Status
|
||||
### Status von Knoten und Pods
|
||||
|
||||
Principals mit **`update`** oder **`patch`** Berechtigungen über `nodes/status` oder `pods/status` könnten Labels modifizieren, um die durchgesetzten Planungsbeschränkungen zu beeinflussen.
|
||||
|
||||
@@ -549,19 +541,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-Autorisierer 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-Authorizer inaktiv ist.
|
||||
|
||||
Die Regel besagt, dass ein **Benutzer nur eine Rolle 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.
|
||||
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 ClusterRoles erhöhen, auch ohne die Berechtigungen selbst zu besitzen.
|
||||
> 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.
|
||||
|
||||
### **Get & Patch RoleBindings/ClusterRoleBindings**
|
||||
|
||||
> [!CAUTION]
|
||||
> **Offensichtlich hat diese Technik früher funktioniert, aber laut meinen Tests funktioniert sie aus demselben 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, 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.**
|
||||
|
||||
Das Privileg, Rolebindings zu erstellen, ermöglicht es einem Benutzer, **Rollen an ein Dienstkonto zu binden**. Dieses Privileg kann potenziell zu einer Privilegieneskalation führen, da es **dem Benutzer erlaubt, Administratorberechtigungen an ein kompromittiertes Dienstkonto zu binden.**
|
||||
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.**
|
||||
|
||||
## Andere Angriffe
|
||||
|
||||
@@ -659,7 +651,7 @@ Value: "rewanthtammana/malicious-image",
|
||||
```
|
||||
Der obige Snippet ersetzt das erste Container-Image in jedem Pod mit `rewanthtammana/malicious-image`.
|
||||
|
||||
## OPA Gatekeeper Bypass
|
||||
## OPA Gatekeeper umgehen
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md
|
||||
@@ -672,7 +664,7 @@ Der obige Snippet ersetzt das erste Container-Image in jedem Pod mit `rewanthtam
|
||||
- **Pods und Service Accounts**: Standardmäßig montieren Pods ein Service Account Token. Um die Sicherheit zu erhöhen, erlaubt Kubernetes die Deaktivierung dieser Automount-Funktion.
|
||||
- **Anwendung**: Setzen Sie `automountServiceAccountToken: false` in der Konfiguration von Service Accounts oder Pods ab Kubernetes-Version 1.6.
|
||||
|
||||
### **Restriktive Benutzerzuweisung in RoleBindings/ClusterRoleBindings**
|
||||
### **Einschränkende Benutzerzuweisung in RoleBindings/ClusterRoleBindings**
|
||||
|
||||
- **Selektive Einbeziehung**: Stellen Sie sicher, dass nur notwendige Benutzer in RoleBindings oder ClusterRoleBindings einbezogen werden. Überprüfen Sie regelmäßig und entfernen Sie irrelevante Benutzer, um eine strenge Sicherheit aufrechtzuerhalten.
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ Entnommen aus der Kubernetes [Dokumentation](https://kubernetes.io/docs/tasks/co
|
||||
|
||||
_„Wenn Sie ein Pod erstellen, wird ihm automatisch das_ standardmäßige _Service-Konto im selben Namespace zugewiesen, wenn Sie kein Service-Konto angeben.“_
|
||||
|
||||
**ServiceAccount** ist ein von Kubernetes verwaltetes Objekt, das verwendet wird, um eine Identität für Prozesse bereitzustellen, die in einem Pod ausgeführt werden.\
|
||||
**ServiceAccount** ist ein von Kubernetes verwaltetes Objekt, das verwendet wird, um Prozessen, die in einem Pod ausgeführt werden, eine Identität zuzuweisen.\
|
||||
Jedes Service-Konto hat ein zugehöriges Geheimnis, und dieses Geheimnis enthält ein Bearer-Token. Dies ist ein JSON Web Token (JWT), eine Methode zur sicheren Darstellung von Ansprüchen zwischen zwei Parteien.
|
||||
|
||||
In der Regel befindet sich **eines** der Verzeichnisse:
|
||||
@@ -27,10 +27,10 @@ In der Regel befindet sich **eines** der Verzeichnisse:
|
||||
- `/var/run/secrets/kubernetes.io/serviceaccount`
|
||||
- `/secrets/kubernetes.io/serviceaccount`
|
||||
|
||||
enthält die Dateien:
|
||||
enthalten die Dateien:
|
||||
|
||||
- **ca.crt**: Es ist das CA-Zertifikat zur Überprüfung der Kubernetes-Kommunikation
|
||||
- **namespace**: Es gibt den aktuellen Namespace an
|
||||
- **namespace**: Es zeigt den aktuellen Namespace an
|
||||
- **token**: Es enthält das **Service-Token** des aktuellen Pods.
|
||||
|
||||
Jetzt, da Sie das Token haben, können Sie den API-Server innerhalb der Umgebungsvariable **`KUBECONFIG`** finden. Für weitere Informationen führen Sie `(env | set) | grep -i "kuber|kube`**`"`** aus.
|
||||
@@ -53,7 +53,7 @@ _**Hot Pods sind**_ Pods, die ein privilegiertes Service-Konto-Token enthalten.
|
||||
|
||||
Wenn Sie nicht wissen, was **RBAC** ist, **lesen Sie diesen Abschnitt**.
|
||||
|
||||
## GUI-Anwendungen
|
||||
## GUI Applications
|
||||
|
||||
- **k9s**: Eine GUI, die einen Kubernetes-Cluster über das Terminal auflistet. Überprüfen Sie die Befehle in [https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/). Schreiben Sie `:namespace` und wählen Sie alle aus, um dann Ressourcen in allen Namespaces zu suchen.
|
||||
- **k8slens**: Es bietet einige kostenlose Testtage: [https://k8slens.dev/](https://k8slens.dev/)
|
||||
@@ -119,9 +119,9 @@ Standardmäßig kommuniziert der APISERVER mit dem `https://`-Schema.
|
||||
```bash
|
||||
alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-verify=true [--all-namespaces]' # Use --all-namespaces to always search in all namespaces
|
||||
```
|
||||
> Wenn kein `https://` in der URL vorhanden ist, kann es zu einem Fehler wie Bad Request kommen.
|
||||
> Wenn kein `https://` in der URL vorhanden ist, kann es zu einem Fehler wie "Bad Request" kommen.
|
||||
|
||||
Sie können ein [**offizielles kubectl Cheatsheet hier finden**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). Das Ziel der folgenden Abschnitte ist es, in geordneter Weise verschiedene Optionen zur Enumeration und zum Verständnis des neuen K8s, auf das Sie Zugriff erhalten haben, darzustellen.
|
||||
Sie finden ein [**offizielles kubectl Cheatsheet hier**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). Das Ziel der folgenden Abschnitte ist es, in geordneter Weise verschiedene Optionen zur Enumeration und zum Verständnis des neuen K8s, auf das Sie Zugriff erhalten haben, zu präsentieren.
|
||||
|
||||
Um die HTTP-Anfrage zu finden, die `kubectl` sendet, können Sie den Parameter `-v=8` verwenden.
|
||||
|
||||
@@ -229,7 +229,7 @@ kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clu
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Holen Sie sich Namespaces
|
||||
### Namespaces abrufen
|
||||
|
||||
Kubernetes unterstützt **mehrere virtuelle Cluster**, die von demselben physischen Cluster unterstützt werden. Diese virtuellen Cluster werden **Namespaces** genannt.
|
||||
|
||||
@@ -270,9 +270,9 @@ Wenn Sie Geheimnisse lesen können, können Sie die folgenden Zeilen verwenden,
|
||||
```bash
|
||||
for token in `k describe secrets -n kube-system | grep "token:" | cut -d " " -f 7`; do echo $token; k --token $token auth can-i --list; echo; done
|
||||
```
|
||||
### Servicekonten abrufen
|
||||
### Holen Sie sich Dienstkonten
|
||||
|
||||
Wie zu Beginn dieser Seite besprochen **wird einem Pod normalerweise ein Servicekonto zugewiesen**. Daher kann das Auflisten der Servicekonten, ihrer Berechtigungen und wo sie ausgeführt werden, einem Benutzer ermöglichen, Privilegien zu eskalieren.
|
||||
Wie zu Beginn dieser Seite besprochen **wird einem Pod normalerweise ein Dienstkonto zugewiesen, wenn es ausgeführt wird**. Daher kann das Auflisten der Dienstkonten, ihrer Berechtigungen und wo sie ausgeführt werden, einem Benutzer ermöglichen, Privilegien zu eskalieren.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -288,9 +288,9 @@ kurl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Holen Sie sich Bereitstellungen
|
||||
### Deployments abrufen
|
||||
|
||||
Die Bereitstellungen geben die **Komponenten** an, die **ausgeführt** werden müssen.
|
||||
Die Deployments geben die **Komponenten** an, die **ausgeführt** werden müssen.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -309,7 +309,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/
|
||||
|
||||
### Pods abrufen
|
||||
|
||||
Die Pods sind die tatsächlichen **Container**, die **ausgeführt** werden.
|
||||
Die Pods sind die eigentlichen **Container**, die **ausgeführt** werden.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -401,7 +401,7 @@ kurl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs
|
||||
|
||||
### Konfigurationsmappe abrufen
|
||||
|
||||
configMap enthält immer viele Informationen und Konfigurationsdateien, die an Apps bereitgestellt werden, die in Kubernetes ausgeführt werden. Normalerweise finden Sie viele Passwörter, Geheimnisse und Tokens, die zur Verbindung und Validierung mit anderen internen/externen Diensten verwendet werden.
|
||||
configMap enthält immer viele Informationen und Konfigurationsdateien, die an Apps bereitgestellt werden, die in Kubernetes ausgeführt werden. Normalerweise finden Sie viele Passwörter, Geheimnisse und Tokens, die zum Verbinden und Validieren mit anderen internen/externen Diensten verwendet werden.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -417,7 +417,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/${NAMESPACE}/configmaps
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Netzwerk-Richtlinien / Cilium Netzwerk-Richtlinien
|
||||
### Netzwerk-Richtlinien abrufen / Cilium Netzwerk-Richtlinien
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Erster Tab" }}
|
||||
@@ -637,7 +637,7 @@ curl --path-as-is -i -s -k -X $'POST' \
|
||||
--data-binary $'{\"apiVersion\":\"rbac.authorization.k8s.io/v1\",\"kind\":\"Role\",\"metadata\":{\"name\":\"secrets-manager-role\",\"namespace\":\"default\"},\"rules\":[{\"apiGroups\":[\"\"],\"resources\":[\"secrets\"],\"verbs\":[\"get\",\"create\"]}]}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/apis/rbac.authorization.k8s.io/v1/namespaces/$NAMESPACE/roles?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
|
||||
```
|
||||
### Löschen einer Rolle
|
||||
### Rolle löschen
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
|
||||
Reference in New Issue
Block a user