GCP - Containers, GKE & Composer Enum
Container
In GCP-Containern finden Sie die meisten containerbasierten Dienste, die GCP anbietet. Hier erfahren Sie, wie Sie die häufigsten Dienste aufzählen können:
Privilege Escalation
Auf der folgenden Seite können Sie nachschauen, wie Sie Container-Berechtigungen missbrauchen, um Privilegien zu eskalieren:
pageGCP - Container PrivescKnotenpools
Dies sind die Gruppe von Maschinen (Knoten), die die Kubernetes-Cluster bilden.
Composer
Dies ist die verwaltete Version von Airflow in GCP.
Privilege Escalation
Auf der folgenden Seite können Sie überprüfen, wie Sie Composer-Berechtigungen missbrauchen, um Privilegien zu eskalieren:
pageGCP - Composer PrivescKubernetes
Für Informationen darüber, was Kubernetes ist, besuchen Sie diese Seite:
pageKubernetes PentestingZunächst können Sie überprüfen, ob in Ihrem Projekt Kubernetes-Cluster vorhanden sind.
Wenn Sie einen Cluster haben, kann gcloud
automatisch Ihre ~/.kube/config
-Datei konfigurieren. Diese Datei wird verwendet, um Sie zu authentifizieren, wenn Sie kubectl, die native CLI zur Interaktion mit K8s-Clustern, verwenden. Versuchen Sie diesen Befehl.
Dann schauen Sie sich die Datei ~/.kube/config
an, um die generierten Anmeldeinformationen zu sehen. Diese Datei wird verwendet, um Zugriffstoken automatisch zu aktualisieren, basierend auf der gleichen Identität, die Ihre aktive gcloud
-Sitzung verwendet. Dies erfordert natürlich die korrekten Berechtigungen.
Sobald dies eingerichtet ist, können Sie den folgenden Befehl ausprobieren, um die Clusterkonfiguration zu erhalten.
Sie können mehr über gcloud
für Container hier nachlesen.
Dies ist ein einfaches Skript zur Auflistung von Kubernetes in GCP: https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum
TLS-Bootstrap-Privileg-Eskalation
Ursprünglich ermöglichte diese Privileg-Eskalationstechnik es, innerhalb des GKE-Clusters Privilegien zu eskalieren, was einem Angreifer effektiv erlaubte, ihn vollständig zu kompromittieren.
Dies liegt daran, dass GKE TLS-Bootstrap-Anmeldeinformationen in den Metadaten bereitstellt, die von jedem zugänglich sind, der einfach ein Pod kompromittiert.
Die verwendete Technik wird in den folgenden Beiträgen erläutert:
Und dieses Tool wurde erstellt, um den Prozess zu automatisieren: https://github.com/4ARMED/kubeletmein
Allerdings missbrauchte die Technik die Tatsache, dass es mit den Metadaten-Anmeldeinformationen möglich war, einen CSR (Certificate Signing Request) für einen neuen Knoten zu generieren, der automatisch genehmigt wurde. In meinem Test habe ich festgestellt, dass diese Anfragen nicht mehr automatisch genehmigt werden, daher bin ich mir nicht sicher, ob diese Technik noch gültig ist.
Geheimnisse im Kubelet-API
In diesem Beitrag wurde entdeckt, dass eine Kubelet-API-Adresse von innerhalb eines Pods in GKE zugänglich ist und Details zu den ausgeführten Pods liefert:
Auch wenn die API keine Änderung von Ressourcen zulässt, könnte es möglich sein, sensible Informationen in der Antwort zu finden. Der Endpunkt /pods wurde mithilfe von Kiterunner gefunden.
Last updated