Wie wir während eines Client-Pentests eine vollständige Exploit-Chain aufgedeckt haben

In der heutigen Cloud-getriebenen Welt bewegen sich Unternehmen schneller denn je und deployen Software über komplexe Systeme hinweg, um Nutzer*Innen in großem Maßstab zu bedienen. Tools wie Kubernetes und GitOps-Plattformen (z. B. ArgoCD, Helm und GoCD) automatisieren und optimieren diese Abläufe. Doch hinter dieser Geschwindigkeit und Effizienz kann sich ein ernstes Risiko verstecken: Security-Miskonfigurationen, die still und leise Angreifer*Innen einen Zugang ermöglichen.

Dieser Blogpost ist der erste Teil einer Serie, die die Erkenntnisse aus einem realen Security-Audit für einen unserer Kunden beleuchtet. In der gesamten Serie zeigen wir, wie ein*e Angreifer*In mit begrenztem Zugang eine cloud-native Deployment-Pipeline von Kubernetes über GitOps-Tools hinweg durchdringen und letztlich die Kontrolle über kritische Infrastruktur und sensible Daten erlangen könnte.

Die sicherheitsrelevanten Herausforderungen moderner DevOps

Moderne DevOps-Umgebungen stützen sich stark auf Kubernetes für Orchestrierung und GitOps-Tools zur Verwaltung von Deployments und Konfigurationen. Diese Tools sind leistungsfähig und ermöglichen schnelle Release-Zyklen, automatisierte Rollouts und einfache Wiederherstellung bei Fehlern.

Gleichzeitig bringen sie jedoch neue Risiken mit sich:

• Eine einzige Miskonfiguration kann zu Privilege-Escalation führen
• Überprivilegierte Tokens können unbeabsichtigten Zugriff auf Cloud-Ressourcen gewähren
• Wiederverwendete Passwörter über Services hinweg ermöglichen einfache laterale Bewegung

GitOps-Tools wie ArgoCD, Helm und GoCD interagieren oft direkt mit Cloud-APIs, Source-Control-Systemen und Kubernetes-Clustern. Wenn diese Tools nicht angemessen gehärtet sind, werden sie zu High-Value Targets für Angreifer*Innen.

Ein Walkthrough der Attack Chain

Initialer Zugriff über Kubernetes RBAC

Unsere Untersuchung begann mit eingeschränkten Credentials innerhalb eines Kubernetes-Clusters. Der Benutzer hatte eine “Edit”-Rolle innerhalb eines einzelnen Namespace. Was zunächst geringes Risiko vermuten lässt, erlaubte uns jedoch das Deployment eines Pods mit erhöhten Privilegien.

Über diesen Pod führten wir einen Namespace Escape durch, der uns Einblick in andere Namespaces, Secrets und Workloads im Cluster verschaffte. Dies zeigt einen häufigen Fehler: übermäßig permissive Rollen in Kubernetes-Umgebungen.

In Teil zwei der Serie erfährst du, wie wir eine scheinbar harmlose Kubernetes-RBAC-Rolle genutzt haben, um Privilegien zu eskalieren und schließlich den gesamten Cluster zu kompromittieren.

ArgoCD-Exploitation und laterale Bewegung

Von unserer nun erhöhten Position aus entdeckten wir ArgoCD im Umfeld. Aufgrund mangelhafter Secret-Management-Praktiken konnten wir das ArgoCD Admin-Passwort aus einer gemounteten Konfigurationsdatei innerhalb eines Containers extrahieren.

Nach erfolgreicher Authentifizierung nutzten wir die repo-server-Konfiguration von ArgoCD, um AWS-Tokens aus Deployments zu extrahieren. Diese Tokens hatten volle Berechtigungen zum Management von EC2-Instanzen – ein massiver Verstoß gegen das Least-Privilege-Prinzip.

Alle Details zu den ArgoCD-Miskonfigurationen, die uns Zugriff auf Cloud-Infrastruktur ermöglichten und uns tiefer ins System gelangen ließen, erfährst du in Teil drei der Serie.

GoCD-Miskonfiguration und Leak eines sensiblen Tokens

Die Untersuchung ging weiter, als wir Zugang zu GoCD testeten. Die wiederverwendeten Admin-Credentials aus ArgoCD funktionierten auch hier. Ein klarer Hinweis auf schlechte Passwort-Hygiene.

Als Pipeline Operator fanden wir zudem eine Argument Injection in einer Pipeline-Definition. Diese Schwachstelle ermöglichte uns das Ausführen beliebiger Kommandos auf den zugrunde liegenden Agenten. Darüber extrahierten wir ein GitHub-Token aus einer Environment-Variable, das uns Read/Write-Zugriff auf sensible private Repositories gewährte.

Wie wir GoCD nutzten, um beliebige Befehle auszuführen und kritische Entwickler-Credentials zu exfiltrieren, erfährst du im finalen Teil der Serie.

Warum DevOps eingebauten Kubernetes-Schutz benötigt

Diese Exploit-Chain zeigt, wie kleine Versäumnisse zu einer vollständigen Kompromittierung der Infrastruktur führen können. Ausgehend von begrenztem Kubernetes-Zugriff kann ein Angreifer:

• Privilegien durch Pod-Miskonfigurationen eskalieren
• Sich über Tools wie ArgoCD und GoCD lateral bewegen
• Cloud-Provider-Credentials und Source Code exfiltrieren

Solche Angriffe sind besonders gefährlich in Umgebungen, die Continuous Delivery mit Cloud-native Infrastruktur kombinieren. Wenn Secrets, Berechtigungen und Credentials nicht strikt kontrolliert werden, entsteht ein vernetztes Risiko-Ökosystem, das sich leicht ausnutzen lässt.

Daher muss Sicherheit in jede Phase des DevOps-Lifecycles eingebettet sein. Dazu zählen regelmäßige Konfigurationsprüfungen, konsequente Least-Privilege-Umsetzung und die Behandlung jedes einzelnen Tools als potenziellen Entry Point.

Organisationen profitieren besonders von einer Kombination aus offensiven und defensiven Maßnahmen:

Penetration Tests decken Schwachstellen aus Angreiferperspektive auf, während Secure-by-Design-Prinzipien sicherstellen, dass Systeme von Grund auf mit Sicherheitsmechanismen ausgestattet sind. Gemeinsam bilden sie einen Feedback-Loop, der Risiken nachhaltig reduziert.

Die Lücken in der Kubernetes Security schließen

Kubernetes und GitOps-Tools bieten enorme Power und Agilität, öffnen aber auch neue Angriffsflächen, die traditionelle Security-Teams oft übersehen. Diese Untersuchung zeigt, wie Angreifer eine Reihe kleiner Schwachstellen zu einer mächtigen Exploit-Chain kombinieren können, um Cloud-Infrastruktur zu übernehmen.

Durch das Lernen aus realen Szenarien wie diesem können Unternehmen potenzielle Lücken schließen, bevor sie ausgenutzt werden.