CI/CD Pipeline

6 Wege, Ihren Code zu schützen

20.07.2021
Von 
Ax Sharma ist ein Security- und Technologieexperte und schreibt für die US-Schwesterpublikation CSO Online.
Schwachstellen in CI/CD Pipelines sind für Cyberkriminelle ein gefundenes Fressen. So bleibt Ihre Continuous Integration and Delivery Pipeline sicher.
Hält Ihre (CI/CD-)Pipeline dem nächsten Angriff stand?
Hält Ihre (CI/CD-)Pipeline dem nächsten Angriff stand?
Foto: shinobi - shutterstock.com

Cyberangriffe, die Schwachstellen in Continuous Integration/Continuous Delivery (CI/CD)-Pipelines und Entwickler-Tools ausnutzen, unterstreichen, dass die Sicherheit von Entwicklungsinfrastrukturen erhöht werden muss. Insbesondere der Codecov-Supply-Chain-Angriff sollte allen Unternehmen eine Warnung sein, geheime Informationen niemals in CI/CD-Umgebungsvariablen abzuspeichern - egal, wie sicher die Umgebung erscheinen mag.

Den Codecov-Angreifern gelang es, einen Bash Uploader einzuschleusen, der von Tausenden von Entwicklern genutzt wird, um Anmeldedaten, Schlüssel und API-Token aus Kundenumgebungen abzugreifen. Die Eindringlinge blieben über zwei Monate hinweg unentdeckt und konnten Medienberichten zufolge hunderte eingeschränkte Kundennetzwerke kompromittieren. Angriffe auf Automatisierungs-Tools wie Jenkins, GitHub Actions oder Cloud-native Containerumgebungen haben Unternehmen darüber hinaus veranlasst, effektive Schutzmaßnahmen für diese Tools zu erforschen und einzusetzen. Die folgenden Best Practices, helfen Ihnen, Ihre CI/CD-Pipelines abzusichern.

1. Keine Geheimnisse in CI/CD

Der Codecov-Supply-Chain-Angriff war so erfolgreich, weil die von den Angreifern exfiltrierten Umgebungsvariablen hart kodierte, geheime Informationen enthielten, darunter Passwörter, Token und Schlüssel. Diese Anmeldeinformationen verschafften den Angreifern auch Zugriff auf die privaten GitHub-Repositories von Unternehmen. Das hatte eine weitere Exfiltration vertraulicher Daten zur Folge.

Mehrere Codecov-Kunden, darunter HashiCorp, Twilio, Rapid7 und Monday.com klärten umfassend über die Auswirkungen des Supply-Chain-Angriffs auf. Der bedeutendste Vorfall in diesem Zusammenhang spielte sich jedoch beim japanischen E-Commerce-Riesen Mercari ab: Mehr als 27.000 Datensätze, die über die Finanzen von Kunden, Händlern, Geschäftspartnern, Mitarbeitern, Auftragsnehmern und verschiedenen Entitäten Auskunft geben, wurden nach der Codecov-Attacke von externen Akteuren veröffentlicht.

Dabei wurde insbesondere die Frage aufgeworfen, warum persönliche Daten wie Finanzinformationen von Kunden in privaten GitHub-Repositories gespeichert wurden. Ähnliche Bedenken wurden in Bezug auf den in der CI/CD-Umgebung gespeicherten, privaten GPG-Schlüssel von HashiCorp laut. Dabei handelt es sich um den geheimen Schlüssel, mit dem HashiCorp veröffentlichte Software-Releases signiert und verifiziert. Ein Angreifer hätte diesen Schlüssel missbrauchen können, um eine bösartige Software zu signieren.

Unternehmen müssen überdenken, welche Informationen in CI/CD-Tools, Umgebungsvariablen und privaten GitHub-Repositories gespeichert werden können. Wenn eine Anwendung einen Berechtigungsnachweis oder einen Token verlangt, empfiehlt es sich, Berechtigungsnachweise für ein Konto oder eine Ressource mit den niedrigsten Privilegien einzurichten. So wird der Schaden begrenzt, selbst wenn die Informationen kompromittiert werden.

2. Planung überprüfen

CI/CD-Automatisierungs-Tools wie GitHub Actions ermöglichen es Entwicklern, geplante Aufgaben für ihre Code Repositories einzurichten, etwa um eingehende Pull Requests automatisch zu prüfen und zu verarbeiten. Was aber, wenn der Benutzer, der die Pull-Anfrage für ein Open-Source-Projekt stellt, maliziöse Absichten hat?

Im April 2021 wurde GitHub Actions von Angreifern missbraucht, die automatisierte Pull Requests an Hunderte von Repositories stellten. Ihr Ziel: über die Infrastruktur von GitHub Kryptowährung zu schürfen. Dieser groß angelegte Angriff erfolgte, nachdem der "Fehler" bei GitHub Actions bereits Anfang Februar gemeldet worden war. Solche Pull-Anfragen können missbraucht werden, um über die Server von GitHub Kryptowährung zu schürfen oder bösartigen Code auszuführen. Agieren Projektverantwortliche fahrlässig und führen diese Pull Requests zusammen, führen sie Schadcode in ihr Repository und die breitere Softwarelieferkette ein. Im Mai berichtete GitLab über ähnliche Kryptomining-Angriffe auf seiner Plattform.

Da CI/CD Tools wie GitHub Actions und GitLab, wichtige Aufgaben erleichtern, beziehungsweise automatisieren sollen, wird Gatekeeping zur Herausforderung: Was einmal als Funktion gedacht war, wird nach dem Missbrauch durch Cyberkriminelle schnell zur Sicherheitslücke. GitHub kündigte kürzlich neue Funktionen an, um dem Missbrauch seiner Actions-Plattform durch Kryptomining-Angreifer vorzubeugen: "Pull Requests von erstmalig Mitwirkenden erfordern eine manuelle Genehmigung durch einen Repository-Mitarbeiter mit Schreibrechten, bevor irgendwelche Actions-Workflows ausgeführt werden. Wenn ein Erstbeitragsleistender eine Pull-Anfrage öffnet, wird er eine Nachricht sehen, dass ein Betreuer seinen Actions-Workflow genehmigen muss, bevor er ausgeführt wird", erklärt GitHub-Produktmanager Chris Patterson in einem Blogbeitrag.

Führende CI/CD-Lösungen und DevOps-Plattformen können dem Beispiel von GitHub folgen und Sicherheitsprüfungen integrieren, um den Missbrauch ihrer Infrastruktur zu verhindern.

3. Container härten

Es geht nichts über die Einhaltung von Standard-Best-Practices. Dazu gehört beispielsweise, Ihre Produktionscontainer richtig zu konfigurieren, gegen gängige Angriffsvektoren zu härten und Ihre Pipeline-Konfiguration abzusichern.

Gerade einfache Fehlkonfigurationen sind für menschliche Mitarbeiter manchmal besonders schwer zu erkennen. Im Anschluss stellt sich die Frage, ob Ihre Docker-basierten Umgebungen Sicherheitslücken aufweisen. Es ist deshalb hilfreich, regelmäßig ein Sicherheits-Audit Ihrer Container durchzuführen und die Images und Dateien auf Sicherheitsprobleme zu scannen. Dabei ist es ratsam, in zuverlässige Cloud-native Container-Sicherheitslösungen zu investieren, die einen Großteil dieser Aufgaben automatisieren können. Schließlich werden jedes Jahr unzählige Schwachstellen gemeldet - es ist nahezu unmöglich, (manuell) den Überblick zu behalten. Immer mehr Unternehmen setzen zudem Kubernetes-Frameworks und Docker-Container für die Bereitstellung von Applikationen ein. Container-Sicherheitslösungen mit integrierten Web Application Firewalls können verdächtigen Netzwerkverkehr frühzeitig erkennen und blockieren, was größere Kompromittierungen verhindern kann, selbst wenn die Angreifer in der Lage sind, in einen Container einzudringen.

4. Deep Code Scanning integrieren

Der Einsatz von Werkzeugen, um Qualitätsprobleme, Sicherheitslücken und andere Fehlern im Programmcode wie Speicherlecks oder Race Conditions automatisch aufzuspüren, ist eine effektive Strategie, um Ihre CI/CD-Pipeline von Anfang an zu sichern. Dabei ist es wichtig zu wissen, dass es nicht immer Cyberangriffe sind, die es zu verhindern gilt. Scheinbar harmlose Bugs können ebenfalls große Auswirkungen haben, wie der Ausfall des globalen Content-Delivery-Netzwerks Fastly gezeigt hat.

Lösungen wie der Code-Scanner von GitHub lassen sich nahtlos in bestehende Code-Workflows integrieren und bieten grundlegende Schutzmaßnahmen, ohne Kosten zu verursachen. Letztendlich sollte es das Ziel jeder Organisation sein, ihre Entwickler dabei zu unterstützen, bestmögliche Arbeit zu leisten und gleichzeitig Bugs oder Sicherheitslücken in den Anwendungen so weit wie möglich zu verhindern.

Dieser Prozess muss mit minimaler Reibung zwischen Entwicklungs- und Sicherheitsteams ablaufen. Benachrichtigungen in Echtzeit, die die Entwickler während der Programmierarbeit auf mögliche Versehen aufmerksam machen, können dabei nicht nur den CI/CD Workflow absichern, sondern auch allen Beteiligten Zeit sparen.

5. Frühzeitig patchen

Im März 2021 setzten Angreifer ein Kryptomining-Botnet namens "z0Miner" ein, um auf anfälligen Jenkins- und ElasticSearch-Servern die Kryptowährung Monero zu schürfen. Um ihre kriminellen Machenschaften zu initiieren, nutzten die Angreifer Remote Code Execution in den mit dem Internet verbundenen Servern und versuchten so die Automatisierungsinfrastruktur zu infizieren und zu übernehmen.

Wie bereits im letzten Jahr bekannt wurde, könnten Jenkins-Server von Angreifern auch dazu genutzt werden, einen DDoS-Angriff zu starten. Das resultierte aus einer UDP-Amplification-Reflection-DDoS-Schwachstelle. Um Automatisierungswerkzeuge und Pipelines gegen solche schwerwiegenden Schwachstellen abzusichern und die Sicherheit Ihrer CI/CD-Infrastruktur gewährleisten zu können, ist zeitnahes Patching unerlässlich.

6. Update-Integrität prüfen

Neueste Updates und Patches einzuspielen, ist ein guter Ratschlag, aber woher wissen Sie, dass das Update nicht manipuliert wurde? Der seit Jahrzehnten das Mantra von Sicherheitsexperten bereichernde Ratschlag, einfach unerbittlich "auf die neueste Version zu aktualisieren", wurde spätestens nach dem Supply-Chain-Angriff auf SolarWinds in Frage gestellt. Bei diesem Lieferketten-Angriff ermöglichten bösartige Updates der Software Orion es den Angreifern, Schadcode an über 18.000 Kunden "auszuspielen".

Im Fall des Codecov-Supply-Chain-Angriffs führte eine einfache Integritätsprüfung dazu, dass die bereits zwei Monate andauernde Kompromittierung aufgedeckt wurde. Ein Kunde bemerkte eine Diskrepanz zwischen der Prüfsumme (Hash) des Bash-Uploaders, der auf dem Server gehostet wurde, und der legitimen Prüfsumme, die im GitHub-Repository von Codecov aufgeführt war.

Es ist also allgemein eine schlechte Idee, Produkt-Updates blindlings anzuwenden. Stattdessen sollten Sie im Rahmen eines Defense-in-Depth-Ansatzes die Integrität aller Updates, Patches und Downloads überprüfen, um das Risiko eines Supply-Chain-Angriffs auszuschließen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.