Erkenntnisse aus der Zero-Day-Schwachstelle in Argo CD (CVE-2022-24348)

Am 30. Januar 2022 wurde das Argo-CD-Team von Forschenden bei Apiiro über eine entdeckte Schwachstelle in der beliebten Continuous-Delivery-Plattform informiert, durch die Angreifer vertrauliche Informationen aus Deployments stehlen könnten. Dem Argo-CD-Team gelang es, schnell Fehlerbehebungen für alle drei derzeit unterstützten Versionen zu entwickeln und sie innerhalb von 48 Stunden für die Nutzer bereitzustellen. In seinem Blogartikel zur CVE führt Dan Garfield, Mitgründer von CodeFresh und Maintainer des Argo-Projekts, die schnelle Reaktion darauf zurück, dass das Projekt in den vergangenen 18 Monaten die Sicherheit auf der gesamten Plattform in den Fokus gerückt hatte.

In diesem Artikel sprechen wir über die Schwachstelle und die weiterreichenden Auswirkungen auf den Schutz vor der Art von Supply-Chain-Angriff, die durch diese Schwachstelle hätte ermöglicht werden können.

Was ist die Argo-CD-Schwachstelle?

Im Kern handelt es sich bei CVE-2022-24348 um eine Directory-Traversal-Schwachstelle, über die Angreifer mithilfe eines bösartig präparierten Helm-Charts auf Daten anderer Anwendungen zugreifen können. Dies kann zu einer Rechteausweitung und einer umfassenderen Kompromittierung des Kubernetes-Clusters führen, auf dem Argo CD ausgeführt wird.

Woher wissen wir, ob wir betroffen sind?

Wenn Sie Argo CD in den Versionen 0.5.0 bis 2.1.12, 2.2.7 oder 2.3.1 einsetzen, sind Sie betroffen und sollten umgehend auf die aktuellen Versionen aktualisieren. Am 24. März 2022 waren dies:

• 2.3.2

• 2.2.8

• 2.1.14

Wie groß ist das Risiko?

Dies ist ein weiteres Beispiel für Angriffsvektoren auf der ständig wachsenden Liste von Supply-Chain-Angriffen. Dabei versuchen Angreifer, Software bereits während ihrer Entwicklung zu infiltrieren, statt nach der Veröffentlichung die Eingangstür zu stürmen. Zu den jüngsten Beispielen zählen Angriffe auf CodeCov, den iOS App Store und, am bekanntesten, SolarWinds. Bei diesem jüngsten Vorfall könnte ein Angreifer ein bösartiges Helm-Chart erstellen, das die Schwachstelle ausnutzt und ihm so Zugriff auf vertrauliche Daten anderer Anwendungen im Argo-CD-Reposerver verschafft.

Eine Beschreibung der Funktionsweise dieser Schwachstelle finden Sie in der ursprünglichen CVE-Meldung. Wir wiederholen hier nicht alle Details. Kurz gesagt: Durch ein Helm-Chart mit einer URI, die einen bestimmten, vorhersehbaren absoluten Dateipfad enthält, könnte ein Angreifer vertrauliche Dateisystemdaten aus diesem Pfad im Argo-Reposerver exfiltrieren – darunter auch Daten aus den Bereichen anderer Anwendungen und Nutzer.

Wie lässt sich das Problem beheben?

Wenn Sie hier nach einer Lösung für CVE-2022-24348 in Ihren Clustern suchen, ist es ganz einfach: Lesen Sie nicht weiter und aktualisieren Sie Ihre Argo-CD-Deployments sofort! Lesen Sie anschließend weiter, um mehr über die größeren Zusammenhänge zu erfahren.

Erledigt? Gut! Sprechen wir nun über die größeren Herausforderungen rund um die Software-Supply-Chain-Sicherheit.

Maßnahmen gegen Supply-Chain-Angriffe

Wie können wir uns vor der nächsten Zero-Day-Schwachstelle dieser Art schützen? Da diese Schwachstelle spezifisch für die Argo-CD-Anwendung ist, gibt es keine einfache oder allgemeingültige Antwort. Es gibt jedoch einige Maßnahmen auf übergeordneter Ebene, mit denen Sie verhindern können, dass bösartig präparierte Dateien – wie in diesem Fall das Helm-Chart – überhaupt erst in Ihre Systeme gelangen:

1. Kleine, leicht überprüfbare Commits anstreben

Bei der agilen Vorgehensweise mit kleinen, iterativen Änderungen geht es nicht nur um saubere Entwicklungspraktiken. Sie erleichtert auch das Erkennen unsicherer oder fragwürdiger Änderungen, wenn diese eingereicht werden. Wir behaupten nicht, dass jemand in Ihrer Organisation fragwürdigen Code von StackOverflow kopieren und einfügen würde. Bei einem Code-Review wäre es jedoch wesentlich einfacher, ihn zu entdecken, wenn er nicht in einem Commit mit tausend Zeilen verborgen wäre.

2. Behandeln Sie alle SDLC-Systeme wie Produktionssysteme

Viele von uns behandeln ihre Build-Server – insbesondere selbst gebaute – zu locker. Sie wissen schon: der Jenkins-, GitLab- oder RunDeck-Server auf dem zusätzlichen Desktop im Netzwerkschrank, mit dem allgemein bekannten Admin-Passwort und ein paar Hundert Plugins, die mit den Zugangsdaten eines beliebigen Entwicklers externe Dienste anbinden? Genau der! (Wir wollen diese Projekte nicht herausgreifen: Jedes schlecht verwaltete Tool ist für Angreifer ein leichtes Ziel.)

In der Vergangenheit wurden Build- und Deployment-Server als Systeme mit niedriger Priorität behandelt und nicht besonders gut gegen Angriffe abgesichert. Die Angriffe auf SolarWinds und CodeCov zeigen beispielsweise, dass diese Systeme genauso ernst genommen werden müssen wie die Produktionsserver, auf denen die Daten Ihrer Nutzer liegen.

• Verwenden Sie keine gemeinsam genutzten Zugangsdaten.

• Verwenden Sie keine maßgeschneiderten Plugins, Aktionen oder Module, die nicht überprüft wurden.

• Sorgen Sie stets dafür, dass eine geeignete, zentralisierte RBAC-Zugriffskontrolle verwendet wird, um den Zugriff angemessen zu beschränken.

3. Kennen Sie Ihre Supply-Chain

Es ist entscheidend, die Herkunft der Artefakte zu kennen, die Ihre Systeme erstellen, und zu wissen, was darin enthalten ist. Die Umsetzung einer sicheren Supply Chain ist ein Thema, über das sich ganze Bücher füllen ließen. Tatsächlich gibt es ganze Konferenzen, die sich ausschließlich damit befassen! Hier sind einige wichtige Bereiche, auf die Sie achten sollten:

• Vertrauen Sie nicht blind auf Container-Images, Betriebssystempakete, Codebibliotheken – oder auch Helm-Charts –, die aus Quellen außerhalb Ihrer Kontrolle stammen. Private, verwaltete Repositories mit überprüften und signierten Artefakten sind entscheidend, damit Sie den Abhängigkeiten in Ihren Anwendungen vertrauen können. Ein gängiges Muster, das sich in diesem Szenario bewährt hat, ist ein „Quarantäne“-Repository. Teams können dort neu erworbene Artefakte zur Prüfung durch die Sicherheitsteams und für Funktionstests importieren. Anschließend können sie in ein Repository übernommen werden, auf das Entwickler und Build-Systeme allgemein zugreifen können. Diese Prüfung muss natürlich mit dem Bedürfnis des Teams nach schnellem Arbeiten in Einklang gebracht werden. Der Prozess sollte daher an den geschäftlichen Kontext angepasst und durch Leitplanken abgesichert werden. Selbstverständlich sollten Teams diese Artefakte auf Schwachstellen prüfen. Das gilt nach Möglichkeit auch für IaC-Konfigurationsdateien. Regelmäßige erneute Scans sind ebenfalls wichtig, falls neue Schwachstellen entdeckt werden. Snyk hilft Ihnen dabei, Schwachstellen und Fehlkonfigurationen zu finden und zu beheben.

• Erstellen Sie für Ihre Anwendungen eine Software-Stückliste (Software Bill of Materials, SBoM). Dieser Bereich entwickelt sich rasant und erhält dank der Vorgaben einer US-Präsidialverordnung von 2021 erfreulicherweise viel Aufmerksamkeit.

• Ein weiteres interessantes Thema sind signierte Git-Commits, mit denen Sie Codeänderungen von nicht verifizierten externen Parteien erkennen könnten. Um ehrlich zu sein, habe ich bisher nicht erlebt, dass diese Methode weit verbreitet ist. Außerdem ist sie nicht das Allheilmittel, als das sie erscheinen mag. Dan Lorenc, ein Experte auf diesem Gebiet, erläutert in seinem Blogbeitrag vom Juli 2021 die Vor- und Nachteile sehr gut: Sollten Sie Git-Commits signieren?.

Alles dreht sich um DevSecOps

Die hier beschriebenen Tools und Praktiken führen alle zu einer wichtigen Erkenntnis: Um unsere Supply Chains zu schützen, muss das gesamte Team mitwirken – von der Entwicklung über SRE bis hin zu allen dazwischen. Je mehr wir Entwickler mit Tools und Prozessen unterstützen und befähigen, statt sie lediglich einzuschränken oder zu kontrollieren, desto erfolgreicher schützen wir unsere Anwendungen. Durch die Integration von Tools wie Snyk in den SDLC können Entwickler Sicherheitslücken in ihrer Arbeit leicht finden, bevor sie überhaupt ein Release veröffentlichen! Genau darum geht es bei Shift Left und DevSecOps. Dabei muss ich an Dans Aussage zum Sicherheitsfokus des Argo-CD-Teams denken. Ich weiß zwar nicht aus erster Hand, wie das Team arbeitet, doch die schnelle Reaktion und die transparente Diskussion über diese Schwachstelle haben sich offensichtlich direkt darauf ausgewirkt, wie schnell das Problem behoben wurde.

In unserem Bericht zum Status der Cloud-Native-Anwendungssicherheit 2021 haben wir festgestellt, dass Unternehmen, die Tests in ihrem SDLC umfassend automatisieren, mit doppelt so hoher Wahrscheinlichkeit Sicherheitstests durchführen. Mehr als 72 % dieser Unternehmen gaben an, Schwachstellen im Durchschnitt innerhalb einer Woche zu beheben; bei 36 % lag der Durchschnitt sogar bei einem Tag oder weniger! Den Dokumentationen des Argo-Projekts zufolge setzt das Team diese Praktiken eindeutig um. Die schnelle Behebung dieses Problems ist ein Beleg dafür.

Weiterführende Informationen

Hier finden Sie weitere Ressourcen zu den besprochenen Themen:

• Erfahren Sie mehr über Directory-Traversal-Schwachstellen

• Schützen Sie Ihre moderne Software-Supply-Chain

• Mit Snyk bösartige Pakete und Supply-Chain-Angriffe verhindern

• SnykCon 2021: Supply-Chain-Sicherheit, die Zukunft der Cybersicherheit, Automatisierung als Wegbereiter und mehr