GKE Container Escape Hack: Wie funktioniert das?
Der Container-Escape-Hack in GKE umfasst drei Hauptschritte:
- Eine Command-Injection-Schwachstelle in der anfälligen Webanwendung ausnutzen, DVWA. Dadurch kann der Angreifer Befehle im Kontext der Webanwendung ausführen, die auf einem Kubernetes-Pod im GKE-Cluster ausgeführt wird.
- Verwenden Sie Techniken zum Sammeln von Informationen, um festzustellen, ob das Dienstkonto berechtigt ist, privilegierte Pods auf dem Cluster bereitzustellen.
- Stellen Sie einen privilegierten Pod auf dem Knoten bereit, sodass Sie ein Container-Escape-Verfahren durchführen und Ihre Rechte erweitern können, um eine Root-Shell auf dem Knoten zu erhalten.
Anhand von Codebeispielen und schrittweisen Anleitungen erfahren Sie, wie Sie einen unsicher konfigurierten und daher anfälligen Google Kubernetes-Cluster ausnutzen, Ihr GCP-Projekt scannen und die Sicherheit Ihres GKE-Clusters bewerten. Diese praktische Erfahrung wird Ihr Verständnis für unsichere Kubernetes-Konfigurationen verbessern und Ihnen das Wissen und die Tools vermitteln, die Sie zum Schutz Ihrer eigenen Infrastruktur benötigen.
Lassen Sie uns in das GKE-Hacking eintauchen und herausfinden, wie Sie Ihre Cluster vor potenziellen Angriffen schützen können.
Voraussetzungen
Bevor Sie beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
- Ein Google Cloud Platform-Konto
- Die gcloud CLI auf Ihrem Computer installiert
- Terraform auf Ihrem Computer installiert
- kubectl auf dem Host installiert, von dem aus Sie ausführen
Terraform
Einen GKE-Cluster einrichten und hacken
Um Ihren Cluster und Ihre Anwendung auf GKE einzurichten, folgen Sie den schrittweisen Anweisungen in der README ZU GKE LAB. Dieser Leitfaden führt Sie auch durch den Prozess des Hackens der anfälligen Webanwendung und der Eskalation Ihrer Zugriffsrechte Wurzel
Zugriff auf den Clusterknoten.
Schützen Sie Ihren GKE-Cluster mit cnspec
Nutzen Sie die kostenlose Open-Source-CLI von Mondoo, cnspec, um Sicherheitslücken zu identifizieren, die zu potenziellen Sicherheitslücken führen könnten. Folgen Sie den Schritten zur Installation von cnspec und scannen Sie Ihren GKE-Cluster nach Sicherheitslücken, um eine sicherere Umgebung zu gewährleisten.
Überprüfen der Cluster-Einstellungen aus der Sicht der Google Cloud Platform (GCP)
1. Stellen Sie mithilfe der cnspec-Shell eine Verbindung zum GCP-Projekt her:
cnspec shell gcp project <project-name>
2. Rufen Sie die Einstellungen des GKE-Clusters (oder aller Ihrer Cluster im Projekt) ab:
gcp.project.gke.clusters {*}
3. Holen Sie sich grundlegende Informationen zu den Knotenpools im GKE-Cluster:
gcp.project.gke.clusters.map(nodePools{*})
4. Sehen Sie sich die Einstellungen der Knotenpools im GKE-Cluster an:
gcp.project.gke.clusters.map(nodePools{config{*}})
5. Rufen Sie den Namen des Dienstkontos ab, in dem die Knotenpools im GKE-Cluster ausgeführt werden:
gcp.project.gke.clusters { name nodePools{name config{serviceAccount{name}}}}
6. Rufen Sie die GCP-Berechtigungen des Dienstkontos ab, auf dem der Cluster ausgeführt wird.
Hinweis: Stellen Sie sicher, dass Sie dieses Format für den Dienstkontonamen in der folgenden Abfrage verwenden:
serviceAccount:name@project.iam.gserviceaccount.com
Der Name sollte der Zeichenfolge ähneln lunalectric-xxxx-node
. Für Projektname
, ersetzen Sie den Namen Ihres Google-Projekts.
Anfrage:
gcp.project.iamPolicy.where(_.members.any(_ == "serviceAccount:lunalectric-xxxx-node@project-name.iam.gserviceaccount.com")) {*}
Diese Ausgabe zeigt die Berechtigungen, die dem Dienstkonto zugeordnet sind, das den Knotenpool in Ihrem Testcluster ausführt. Wie Sie sehen, hat das Dienstkonto zusätzlich zu den drei Rollen, die für den Betrieb eines Clusters erforderlich sind, auch Zugriff auf die Rolle roles/iam.serviceaccountUser
. Dies ist einer der Gründe, warum es möglich ist, einen neuen Pod bereitzustellen, der Rechte auf das Root-Konto des Knotens überträgt.

Die Anwesenheit der roles/iam.serviceaccountUser
Die Rolle ist ein Schlüsselfaktor für die Rechteerweiterung, die erforderlich ist, um eine Root-Shell auf dem Knoten zu erhalten.
Überprüfen Sie Ihre Cluster-Einstellungen aus der Kubernetes-Perspektive
Wenn Sie mit Ihrem Kubernetes-Cluster verbunden sind über kubectl
(wie beschrieben in der LESEN SIE MICH Anweisungen), können Sie sich mit einer Verbindung zur Kubernetes-Cluster-API verbinden cnspec
Schale:
cnspec shell k8s
Suchen Sie im Cluster nach Pod-Sicherheitsrichtlinien und Pod-Sicherheitsstandards
Prüfen Sie, ob eine Pod-Sicherheitsrichtlinie (der Cluster in unserem Beispiel verwendet Version 1.23.16-gke.1400) an die gebunden ist Standard
Namespace, der die möglichen Funktionen einschränkt, die eine Pod-Bereitstellung haben kann:
k8s.clusterrolebindings.where( _.subjects.any(_['namespace'] == "default"))
Da an das keine Cluster-Rollenbindung angehängt ist Standard
Namespace, es gibt keine Pod-Sicherheitsrichtlinie, die den Einsatz privilegierter Pods in diesem Namespace einschränken könnte.
Sicherheitsstandards für Pods sind die neue Methode, Ihren Namespace vor der Bereitstellung privilegierter Pods zu schützen. Die Pod-Sicherheitsstandards werden die Pod-Sicherheitsrichtlinien in Kubernetes Version 1.25 ersetzen.
Sie können nach Beschriftungen suchen in der Standard
Namespace, der die fraglichen Bereitstellungen ablehnen würde. Diese Abfrage prüft, ob Standard
Der Namespace wird mit dem gesichert beschränkt
politik:
k8s.namespaces.where(name == "default") {manifest["metadata"]["labels"] {_["pod-security.kubernetes.io/enforce"] == "restricted"}}
Das Ergebnis dieser Abfrage ist falsch
, was darauf hindeutet, dass keiner der Mechanismen vorhanden ist, die den Privilegieneskalations-Hack verhindern würden, bei dem die Bereitstellung eines privilegierten Pods verwendet wird, um Root-Zugriff auf den Knoten zu erlangen.
Find and fix the security risks that pose the biggest threat to your business.
Nutzen Sie Mondoo für ein verbessertes GKE-Sicherheitsmanagement
Obwohl benutzerdefiniert prüft und Politik Mondoo mag Sicherheitsbegeisterte ansprechen, aber Mondoo möchte Ihnen die Arbeit erleichtern, indem es eine Reihe von Vorteilen bietet:
- CIS-zertifizierte Richtlinien für alle großen Cloud-Anbieter
- CIS-zertifizierte Richtlinien für alle wichtigen Linux-Distributionen und Windows-Builds
- Die maßgeschneiderten Best-Practice-Richtlinien von Mondoo
- Eine benutzerfreundliche, browserbasierte Oberfläche zur Nachverfolgung der Härtungsmaßnahmen in Ihrer gesamten Infrastruktur
- Zahlreiche Funktionen zur Stärkung der Sicherheitslage Ihres Unternehmens
Scannen Sie Ihren GKE-Cluster
Nachdem Sie Ihr Mondoo-Konto eingerichtet haben, geben Sie diesen Befehl in Ihre Shell ein, um Ihr GCP-Projekt zu scannen:
cnspec scan gcp project <your-project-name>
Zunächst wird dadurch kein Scannen ausgelöst, das auf einer Richtlinie basiert. Sie müssen eine Richtlinie aktivieren, auf der der Scan basieren soll:
1. Folgen Sie dem Link zu Ihrem Bereich in der Mondoo-Konsole, der ungefähr so aussieht:
See more scan results and asset relationships on the Mondoo Console: https://console.mondoo.com/space/fleet/1KnZA3cAE1GHRTzU3s64Dw4QWERAu?spaceId=spicy-fisher-123456

2. Wählen Sie das Richtlinien Tab.

3. Wählen Sie EINE RICHTLINIE HINZUFÜGEN und tippe Google Kubernetes
in das Suchfeld. Aktiviere das CIS-Benchmark für Google Kubernetes Engine (GKE) — Stufe 1 indem Sie das Aktivierungssymbol (ein Balkendiagramm) auswählen.

Nachdem Sie die Richtlinie aktiviert haben, kehren Sie zu Ihrer Shell zurück und scannen Sie Ihr Projekt:
cnspec scan gcp project <your-project-name>
Tipp: Wenn Sie das verwenden -o voll
Option, Sie können die Details aller fehlgeschlagenen Prüfungen direkt in der Shell sehen.
cnspec scan gcp project <your-project-name> -o full
Die folgende Ausgabe zeigt eine der fehlgeschlagenen Prüfungen und verweist auf das Dienstkonto, auf das der GKE-Hack angewiesen ist, um erfolgreich zu sein.
✕ Fail: F 5 Ensure GKE clusters are not running using the Compute Engine default service account
Query:
gcp.project.gke.clusters.map(
nodePools {
config.serviceAccount {
serviceAccountsNodepools = 'serviceAccount:' + email
gcp.project.iamPolicy.where(
_.role != "roles/logging.logWriter" &&
_.role != "roles/monitoring.metricWriter" &&
_.role != "roles/monitoring.viewer"
).map(members).none(
_ == serviceAccountsNodepools
) serviceAccountsNodepools
} name
}
)
Result:
gcp.project.gke.clusters.map: [
0: [
0: {
config.serviceAccount: {
serviceAccountsNodepools: "serviceAccount:lunalectric-xxxx-node@project-name.iam.gserviceaccount.com"
[].none(): false
}
name: "lunalectric-pool"
}
]
]
Kehren Sie nun, wenn die Richtlinie aktiviert ist, zur Mondoo-Konsole zurück, um die Ergebnisse aller Prüfungen in dieser Richtlinie zu sehen. Von dort aus können Sie die Umgebung weiter erkunden.

Weitere nützliche Befehle zur Überprüfung Ihrer GKE-Infrastruktur
Kubernetes-Manifeste scannen
Sie können Kubernetes-Manifeste nach potenziellen Sicherheitslücken durchsuchen, bevor Sie sie in Ihren Clustern bereitstellen:
cnspec scan k8s --path ../assets/escape-to-node.yaml
Hier sind die Ergebnisse eines Scans des Pod-Manifests, der zur Übernahme des Knotens geführt hat:

Scannen Sie den GKE-Cluster
cnspec scan k8s scan
Weitere Exploits und Plattformen zum Erkunden
Erweitere dein Kubernetes-Hacking-Abenteuer mit Mondoo, indem du unsere Provider Labs ausprobierst:
- Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes-Dienste (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- Minikube
Folgen Sie dem Tutorial in der README-Datei jedes Labors, um ein einzigartiges Hacking-Erlebnis mit verschiedenen Cloud-Anbietern zu erhalten.
Stärken Sie Ihre Sicherheitslage mit den Kubernetes Container Escape Labs von Mondoo
Mit den Kubernetes Container Escape Labs von Mondoo können Sie lernen, wie Sie Ihre GKE-Cluster vor potenziellen Sicherheitslücken schützen können. Indem Sie die Perspektive des Angreifers verstehen und die leistungsstarken Tools von Mondoo verwenden, können Sie Ihre Infrastruktur effektiv vor ähnlichen Angriffen schützen. Vergessen Sie nicht, andere Exploits und Plattformen mit Mondoo zu erkunden, um Ihr Wissen und Ihre Erfahrung zu erweitern. Viel Spaß beim Hacken!