Continuous-Integration- und -Development-Pipelines (CI/CD) sind laut NCC-Forschern die gefährlichste potenzielle Angriffsfläche der Software-Lieferkette, so die NCC-Forscher.
Die Präsentation von NCCs Iain Smart und Viktor Gazdag auf der Black-Hat-Sicherheitskonferenz in der vergangenen Woche trug den Titel „RCE-as-a-Service: Lessons Learned from 5 Years of Real-World CI/CD Pipeline Compromise“ und stützt sich auf frühere Arbeiten der NCC-Forscher zu kompromittierten CI/CD-Pipelines.
Eine CI/CD-Pipeline ist grundsätzlich eine Remote-Code-Ausführung (RCE), und unabhängig von der Unternehmensgröße gibt es zahlreiche Wege, sie zu kompromittieren.
Da Unternehmen ihren Pipelines zu sehr vertrauen, ist die Kompromittierung dieser Kanäle für Hacker meist ein guter Weg, da sie wahrscheinlich unbefugten Zugriff auf kritische Daten erlangen und sogar ihre Rechte erweitern könnten, um weitere Angriffe durchzuführen.
Siehe die besten Tools für das Management von Risiken durch Drittanbieter (TPRM).
CI/CD-Ansätze schaffen Risiken
CI steht für „Continuous Integration“ und CD für „Continuous Delivery“. Die Kombination beider Verfahren ermöglicht die Automatisierung und Überwachung der Entwicklung über den gesamten Lebenszyklus hinweg.
Continuous Integration bedeutet, dass Entwickler Prozesse bei Codeänderungen automatisieren können. Typischerweise werden Skripte ausgeführt, sobald eine Änderung in bestimmte Branches des Projekts integriert wird, um den Code zu testen, zu erstellen und bereitzustellen.
Ziel ist es, den für die Bereitstellung neuen Codes in allen Umgebungen erforderlichen Aufwand zu reduzieren, was nicht nur Entwickler, sondern auch Geschäftsteams betrifft. Da eine optimierte Bereitstellung Teil der Twelve-Factor-App, einer Reihe von Prinzipien für moderne SaaS-Anwendungen, ist, sollen Ansätze wie CI/CD den Prozess weniger riskant machen.
Der Jenkins-Open-Source-Automatisierungsserver beispielsweise ist eine der beliebtesten Lösungen auf dem Markt. Viele Unternehmen, darunter auch große Konzerne, nutzen ihn für ihre DevOps-Prozesse. Bei ihren Tests konnten die Forscher Jenkins-Umgebungen auf verschiedene Weise kompromittieren, indem sie Fehlkonfigurationen in S3-Buckets oder in der Umgebung selbst ausnutzten.
Tatsächlich nutzen Unternehmen Drittanbieterlösungen wie Jenkins, um ihre Prozesse zu beschleunigen, doch zu großzügige Konfigurationen führen letztlich zur Rechteausweitung.
Lesen Sie auch: So kompromittieren Hacker die Software-Lieferkette
Drittanbieterlösungen machen CI/CD-Pipelines verwundbar
Die Forscher fanden Angriffspfade in beliebten Plattformen mit erweiterten CI/CD-Funktionen, etwa GitLab. Sie nutzten sensible Funktionen in GitLab Runners aus, um ihre Rechte auszuweiten und Geheimnisse abzugreifen.
Erneut ermöglichen zu großzügige Konfigurationen jedem Benutzer mit dem Recht, Code zu committen, den Zugriff auf Passwörter und Geheimnisse, etwa wenn die Daten unverschlüsselt in Umgebungsvariablen gespeichert werden.
Die Forscher nutzten außerdem privilegierte Prozesse und Container aus, die beispielsweise in Docker und Kubernetes als Root ausgeführt werden, während einige Lösungen rootless Builds unterstützen.
Diese Angriffe mögen ziemlich klassisch wirken, und eine robuste Konfiguration würde solche Rechteausweitungen verhindern. In der Realität wenden viele Unternehmen jedoch schlechte Praktiken an und stellen Bequemlichkeit über Sicherheit. Manche Teams wissen möglicherweise nicht einmal, dass es zusätzliche Sicherheitseinstellungen gibt, oder halten sie für unvereinbar mit ihren Zeitvorgaben.
Die Forscher berichteten über interessante Ergebnisse in ihren 10 Szenarien. Das letzte bestand darin, vorzugeben, „den Laptop eines Entwicklers kompromittiert zu haben“. Nachdem sie mehrere Exploits miteinander verkettet hatten, gelangten sie auf den Jenkins-Masterknoten und lasen alle Variablen aus. Dadurch erhielten sie letztlich vollständigen Zugriff auf die Produktionsumgebung, da die Bereitstellungspipeline mit zu vielen Berechtigungen ausgestattet war.
Lesen Sie auch: Neue Open-Source-Sicherheitsinitiative gegen Angriffe auf die Lieferkette
So sichern Sie Ihre CI/CD-Pipeline
CI/CD-Pipelines sind kritische Umgebungen, die Hacker bei der kleinsten Gelegenheit angreifen werden. Aufgrund ihrer Komplexität und des Zeitaufwands für eine korrekte Konfiguration erteilen viele Teams Drittanbietertools, die eigentlich nicht so viele Rechte benötigen sollten, vollständige Berechtigungen.
Hier sind einige praktische Sicherheitsmaßnahmen:
- Der Ansatz der geringsten Rechte (überall in der Kette) ist hier der richtige Weg. Weisen Sie Personen und Drittanbietertools nur die unbedingt erforderlichen Rechte zu. Die Konfiguration dauert zwar länger und kann sogar einige Fehler in Tests und an anderen Stellen auslösen, aber der Aufwand lohnt sich.
- Aktivieren Sie, wann immer möglich, die Zwei-Faktor- (2FA) und Multi-Faktor-Authentifizierung (MFA), insbesondere für Administratorkonten.
- Verwenden Sie unter keinen Umständen Umgebungsvariablen für Zugangsdaten – oder verschlüsseln Sie diese zumindest.
- Ermitteln Sie die schwächsten Punkte in Ihren Pipelines, die zusätzliche Sicherheitsmaßnahmen erfordern.
- Implementieren Sie Sicherheitsprüfungen, insbesondere für Commits.
- Legen Sie eine strenge Richtlinie für Anbieter fest. Continuous Deployment bringt Code in die Produktionsumgebung, den Ihre Teams nicht selbst verwalten – dadurch werden Angriffe auf die Lieferkette für Hacker attraktiv.
Die Einrichtungsphase ist von entscheidender Bedeutung. Seien Sie in den ersten Phasen Ihrer Projekte besonders wachsam, da Sie normalerweise zu diesem Zeitpunkt fehlkonfigurierte Instanzen finden, die zu einer Rechteausweitung führen können.
Das Prinzip der geringsten Rechte, auch Zero-Trust-Prinzipien, spielt in der Arbeit von Smart und Gazdag eine zentrale Rolle. Sie empfehlen außerdem zusätzliche Kontrollen wie Netzwerksegmentierung und Patch-Management.
Weitere Lektüre: