Integration

Hacken Sie GKE-Cluster mit den Kubernetes Container Escape Labs von Mondoo

In diesem praktischen Tutorial erfahren Sie, wie leicht eine Sicherheitslücke zu einer Sicherheitslücke werden kann, indem Sie mit den Kubernetes Container Escape Labs von Mondoo in die Welt der Kubernetes-Ausnutzung eintauchen. Sie erfahren, wie Sie mithilfe von Terraform einen Google Kubernetes Engine (GKE) -Cluster einrichten, eine absichtlich anfällige Webanwendung (DVWA) bereitstellen und einige Fehlkonfigurationen ausnutzen, um das Root-Konto eines Kubernetes-Knotens zu übernehmen. Wenn Sie die Perspektive des Angreifers verstehen und praktische Erfahrungen sammeln, sind Sie besser gerüstet, um Ihre eigene Infrastruktur zu sichern und potenzielle Sicherheitslücken zu verhindern.

GKE Container Escape Hack: Wie funktioniert das?

Der Container-Escape-Hack in GKE umfasst drei Hauptschritte:

  1. 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.
  2. Verwenden Sie Techniken zum Sammeln von Informationen, um festzustellen, ob das Dienstkonto berechtigt ist, privilegierte Pods auf dem Cluster bereitzustellen.
  3. 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:

  1. Ein Google Cloud Platform-Konto
  2. Die gcloud CLI auf Ihrem Computer installiert
  3. Terraform auf Ihrem Computer installiert
  4. 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.

poliyc_08

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

policy

2. Wählen Sie das Richtlinien Tab.

policy_02

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.

policy_05

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.

policy_07

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:

policy_06

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:

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!

Manuel Weber

Manuel, Sicherheitsingenieur bei Mondoo, ist begeistert davon, Wege zu finden, Computersysteme sicherer zu machen. Bevor er zu Mondoo kam, arbeitete er als Pentester und überprüfte eine Vielzahl von Computersystemen (Webanwendungen, mobile Apps, ICS und andere) auf Sicherheitslücken und Fehlkonfigurationen. In seiner Freizeit hebt Manuel schwere Dinge, unternimmt mehrtägige Wanderungen und kocht gerne.

You might also like

Vergleiche
Mondoo gegen Tenable — Zehn Möglichkeiten, Tenable-Alternativen zu vergleichen
Sanierung
Wie wir unser Risiko in weniger als drei Stunden um 54% reduziert haben
Sanierung
Branchenweit erste Priorisierung von Problembehebungen unter Berücksichtigung der Auswirkungen und des Aufwands