Sicherheitsvorfall in der CircleCI-Supply-Chain: Rotieren Sie Ihre Secrets

Am 4. Januar meldete CircleCI, ein Tool zur Einrichtung automatisierter CI/CD-Pipelines, einen Sicherheitsvorfall in seinem Produkt und veröffentlichte dazu eine Mitteilung.

Hintergrund zum CircleCI-Vorfall

Am 27. Dezember erhielt der Security Engineer Daniel Hückmann dank eines von ihm platzierten AWS CanaryTokens eine E-Mail-Benachrichtigung über einen möglichen Eindringversuch in sein CircleCI-Konto. Der Köder in Form eines AWS-Schlüssels wurde wahrscheinlich vom Angreifer ausgelöst. Solche Köder, auch Honeytokens genannt, können in Systemen platziert werden, um Eindringversuche zu untersuchen und zu erkennen. Werden sie von einem Angreifer aktiviert, warnen sie Sie vor möglichen Sicherheitsverletzungen.

Am 4. Januar 2022 empfahl CircleCI seinen Kunden als Reaktion auf einen Sicherheitsvorfall, ihre Secrets zu rotieren:

Der vollständigen Offenlegung halber: Snyk ist sowohl Partner als auch Kunde von CircleCI.

Empfehlungen von CircleCI für Nutzer

CircleCI hat allen Nutzern empfohlen, alle auf der Plattform gespeicherten Secrets umgehend zu rotieren – unabhängig davon, ob sie in Projektumgebungsvariablen oder in Contexts hinterlegt sind. Außerdem empfiehlt CircleCI, interne Logs auf unbefugte Zugriffe zwischen dem 21. Dezember 2020 und dem 4. Januar 2023 sowie auf Zugriffe nach Abschluss der Secret-Rotation zu überprüfen. CircleCI hat persönliche API-Tokens und Projekt-API-Tokens ungültig gemacht und alle OAuth-Tokens von GitHub und Bitbucket rotiert.

Wenn Sie in der Softwareentwicklung oder in Infrastrukturumgebungen arbeiten, sollten Sie wissen, dass das Rotieren von Secrets schwierig sein und CI/CD-Workflows beeinträchtigen kann. Sie können Folgendes tun:

• Erstellen Sie eine Bestandsaufnahme der Umgebungsvariablen, die in all Ihren Projekten und Pipelines verwendet werden, einschließlich der Variablen auf Context- und Projektebene.

• Löschen Sie Ihre Secrets nicht aus CircleCI, sondern entziehen Sie sie, damit potenzielle Angreifer nicht darauf zugreifen können.

• Rotieren Sie unbedingt die Umgebungsvariablen und SSH-Schlüssel.

Die Auswirkungen der unkontrollierten Verteilung von Secrets auf die Software-Supply-Chain

Die Speicherung von Secrets wie Passwörtern und API-Schlüsseln an mehreren Orten wird als „Secret Sprawl“ bezeichnet und erschwert deren effektive Verwaltung und Absicherung. Das kann sowohl innerhalb eines Unternehmens als auch in der Software-Supply-Chain vorkommen. Wenn Secrets über verschiedene Speicherorte verstreut sind, lassen sie sich nur schwer nachverfolgen und aktualisieren, was das Risiko unbefugter Zugriffe erhöht. Ein weiteres Problem sind langfristig gültige Berechtigungen, auch statische Secrets genannt, die nicht regelmäßig rotiert werden.

Plattformen für das Secrets-Management können Secrets zwar effektiv speichern und verschlüsseln, doch statische Secrets sind weiterhin anfällig. Sie können offengelegt werden, wenn sie im Klartext im Quellcode einer Anwendung enthalten, in Anwendungslogs aufgezeichnet oder in Konfigurationsdateien gespeichert sind. Je häufiger ein Secret verwendet wird, desto höher ist das Risiko, dass es kompromittiert wird. Außerdem können statische Secrets dauerhafte Berechtigungen für mehrere Systeme gewähren und Hackern so fortlaufenden Zugriff auf Ihre Infrastruktur ermöglichen.

Die Verwendung statischer Zugangsdaten, die gemeinsam genutzt und weit verbreitet eingesetzt werden, kann verschiedene Probleme mit sich bringen. Dazu zählen eine unklare Zuständigkeit, veraltete Zugangsdaten, die nach der Außerbetriebnahme von Diensten nicht entfernt wurden, fehlende regelmäßige Rotationsprozesse, eine fehlende Ablauf- oder Gültigkeitsdauer sowie der unnötige Einsatz statischer Zugangsdaten, obwohl sicherere Zugriffskontrollen wie kurzlebige, dynamisch erstellte Tokens verfügbar sind.

Bei einem Supply-Chain-Angriff dringt ein Hacker in die Lieferkette eines Unternehmens ein, um Zugriff auf dessen Systeme oder Daten zu erhalten. Das kann besonders gefährlich sein, weil der Hacker dadurch Sicherheitsmaßnahmen umgehen und auf vertrauliche Informationen zugreifen kann. Angreifer versuchen oft, den Quellcode oder Build-Prozesse zu kompromittieren, böswillige Aktivitäten auszuführen oder weitere Sicherheitsverletzungen entlang der Supply-Chain zu ermöglichen.

Unternehmen sollten die Risiken durch die unkontrollierte Verteilung von Secrets erkennen und Maßnahmen ergreifen, um Supply-Chain-Angriffe zu verhindern. Softwareprodukte bestehen häufig aus verschiedenen Komponenten, die von unterschiedlichen Anbietern stammen und in verschiedenen Repositories gespeichert sind. Wenn Hacker Zugriff erhalten, können sie Malware einschleusen und die Unterkomponente signieren, sodass ihr im Verlauf der Supply-Chain vertraut wird.

Um diese Probleme zu beheben, können Unternehmen eine Secrets-Management-Lösung mit einem verschlüsselten Vault einsetzen, um Zugangsdaten und Schlüssel zu schützen. Diese Lösung sollte Entwicklern außerdem optimierte Workflows bieten, über die sie bei Bedarf auf Secrets zugreifen können – geregelt durch vom Security-Team genehmigte Richtlinien. Zum weiteren Schutz von Schlüsseln und Zugangsdaten sollte die Lösung Secrets einfach rotieren können.

Dynamische Secrets sind Zugangsdaten, die bei Bedarf generiert werden und für einen begrenzten Zeitraum vorübergehenden Zugriff auf eine Ressource mit einem begrenzten Berechtigungssatz gewähren. Sie werden nicht gespeichert und sind daher weniger anfällig für Angriffe. Selbst wenn ein dynamisches Secret kompromittiert wird, ist es wertlos, bevor ein Cyberkrimineller es verwenden kann. Dynamische Secrets werden häufig zusammen mit Zero Standing Privileges (ZSP) eingesetzt. Dabei erhalten Clients privilegierten Zugriff auf eine Ressource, aber nur mit den Mindestberechtigungen, die für eine bestimmte Aufgabe erforderlich sind, und nur für die kürzestmögliche Zeit. Dieser Ansatz senkt das Risiko unbefugter Zugriffe und stellt sicher, dass Berechtigungen nur bei Bedarf gewährt werden.

So rotieren Sie Secrets

Beim Rotieren von Secrets wird ein bestehendes Secret – etwa ein Passwort, ein API-Schlüssel oder ein SSH-Schlüssel – durch ein neues ersetzt, um das Risiko einer Kompromittierung zu senken. Je nach verwendetem System kann dies manuell oder automatisch erfolgen.

Für das Rotieren von Secrets gibt es verschiedene Strategien:

• Regelmäßige Intervalle: Sie können einen Zeitplan für die regelmäßige Rotation von Secrets festlegen. So lässt sich das Risiko einer Kompromittierung verringern, denn Angreifern steht nur ein begrenztes Zeitfenster zur Verfügung, um ein Secret auszunutzen.

• Bei Bedarf: Sie können Secrets auch rotieren, sobald Sie vermuten, dass eines kompromittiert wurde, oder wenn Sie das Kompromittierungsrisiko vorsorglich senken möchten.

• Automatisierung: Mit Tools und Skripten können Sie die Rotation von Secrets automatisieren. So stellen Sie sicher, dass Secrets konsistent und zeitnah rotiert werden.

Beim Rotieren von Secrets ist es wichtig, das neue Secret angemessen zu schützen und korrekt zu implementieren und zu konfigurieren. Außerdem müssen Sie alle relevanten Parteien, etwa Systemadministratoren und Nutzer, über die Änderung informieren.

Die Strategie für das Secrets-Management neu überdenken

Auch wenn wir früher vielleicht davon ausgegangen sind, dass unsere Secrets sicher sind, haben frühere Fälle kompromittierter Plattformen Unternehmen dazu veranlasst, ihre Strategien zur Speicherung von Secrets neu zu bewerten und die sicherste Methode zu ermitteln. Wichtig ist dabei: Sobald Secrets verwendet und in einem Repository committet wurden, sind sie keine Secrets mehr. Wie lassen sich Secrets also am besten verwalten? Sollten sie gar nicht verwendet oder nur einmal genutzt und anschließend widerrufen werden?

Dieser Beitrag wird aktualisiert, sobald neue Informationen vorliegen.