Ein einziger GitHub-Workflow-Token öffnete die Tür zur Software-Lieferkette

Ein einziger GitHub-Workflow-Token scheiterte in der Rotation und öffnete die Tür. Dies ist die zentrale Schlussfolgerung des Vorfalls in Grafana Labs nach der jüngsten Welle von schädlichen Paketen veröffentlicht in npm, die die Lieferkette des Entwickler-Ökosystems betroffen. Laut der öffentlichen Untersuchung des Unternehmens hat ein robustes Modul eines engagierten Pakets für TanStack in seinen Pipelines Geheimnisse ausgefiltert und Angreifern erlaubt, auf private Repositories zuzugreifen, wenn ein Token nicht rechtzeitig widerrufen wurde.

Der Vorfall zeigt grausam, dass die Angriffsfläche nicht nur in der Produktion, sondern in den Werkzeugen, mit denen wir Software bauen und veröffentlichen: kontinuierliche Integration und Paketmanager. Wenn ein Fluss von CI verbraucht eine schädliche Abhängigkeit, diese Abhängigkeit läuft mit den Privilegien des Läufers und kann filtern, was es in der Umgebung findet, einschließlich Token, die Nebenbewegungen zu anderen Vermögenswerten der Organisation ermöglichen.

Die von Grafana bestätigten Konsequenzen kombinieren Code Diebstahl und Exfiltration von operativen Informationen, aber für jetzt gibt es keine Hinweise auf Kundendaten Engagement in der Produktion. Das Unternehmen behauptet, dass es keine Rettung gezahlt hat, dass das Code-Repository nicht geändert wurde und dass die heruntergeladenen Informationen professionelle Namen und E-Mails enthalten, die in Geschäftsbeziehungen verwendet wurden; aber das Ereignis reduziert das Vertrauen in die Lieferkette und Kräfte, um die CI / CD-Kontrollen zu überprüfen.

Dieser Fall wiederholt ein jüngstes Muster in Supply Chain Angriffen: Open Source Paket Engagement (in diesem Fall Pakete mit TanStack), Ausführung in Entwicklungs- oder CI-Umgebungen und Exfiltration von Anmeldeinformationen, die auf interne Infrastruktur. Mitigation erfordert sofortige technische Maßnahmen und organisatorische Veränderungen, wie Software und ihre Geheimnisse verwaltet werden.

Für technische Ausrüstungen und Sicherheitsbeamte sind dringende Maßnahmen klar: den Umfang aller von Pipelines verwendeten Token und Anmeldeinformationen zu rotieren und einzuschränken, forensisch zu prüfen, auf welche Repositorien und Artefakte zugegriffen oder heruntergeladen wurden, und Kontrollen hinzuzufügen, so dass ein einzelnes, begangenes Geheimnis keine Bewegungen auf andere kritische Ressourcen erlaubt. GitHubs Dokumentation zur Action-Härtung und gute Praxis für Geheimnisse ist ein guter Ausgangspunkt für die Umsetzung konkreter Minderungen: https: / / docs.github.com / en / Aktionen / Security-guides / Security-hardening-for-github-actions und https: / / docs.github.com / en / Aktionen / Sicherheits-Leitungen / Verwendung-verschlüsselte-secrets-in-Workflows.

Über die reaktive Reaktion hinaus sollten Organisationen Kontrollen einschließen, die die Wahrscheinlichkeit und Wirkung dieser Art von Intrusionen verringern: Tokens-Bereiche minimieren, schnelle und kurzlebige Anmeldeinformationen verwenden, Segment-Läufer-Zugriff (z.B. selbstgehostete Läufer isoliert pro Projekt), die Verwendung von Token in Workflows beschränken, die sie nicht benötigen und Genehmigungsrichtlinien für externe Einheiten in CI anwenden.

In der Schicht der Abhängigkeiten und der Entwicklung ist es unerlässlich, eine gründliche Verteidigung anzuwenden: Set-Versionen und Hashes von Paketen (Verpackungs- oder Integritätsverifikationen), verwenden automatische Einheitsabtastung mit Frühwarnungen, verwenden Sie Sperrrichtlinien für unbekannte Pakete oder neue Autoren und betrachten Sie die Verifizierung von Lieferketten wie Paketsignaturen und SLSA. Es hilft auch, ein aktualisiertes Inventar (SBOM) zu halten, das es einfacher macht zu identifizieren, welche Pipelines verbraucht, welche Buchhandlungen in jedem Gebäude.

Aus der Sicht der Erkennung ist es zweckmäßig, die Telemetrie für die Exfiltration von Läufern und Warnungen auf anormale Verhaltensweisen in GitHub zu implementieren (Massen-Downloads von Repositorien, Erstellung von Gabeln oder Klonen, die von nicht regulären Akteuren wiederholt werden). Regelmäßige Genehmigungen in GitHub-Organisationen und die Umsetzung von funktionsbasierten Zugangsrichtlinien sind Maßnahmen, die den ausbeutbaren Bereich durch einen engagierten Token reduzieren.

Für die Open Source Community gibt es auch eine kollektive Lektion: Projekte und Betreuer sollten Nutzer über Abhängigkeitsrisiken informieren, mit Datensätzen für schnellere Reaktionen zusammenarbeiten, wenn schädliche Pakete auftreten und Sicherheitsinitiativen unterstützen, die es ihnen erlauben, verdächtige Pakete zu verfälschen, bevor sie massiv automatisierte Pipelines erreichen.

Grafana hat ihre Aktualisierungen und den Stand der Forschung auf ihrem Blog veröffentlicht, wo sie die getroffenen Maßnahmen und den bisher bekannten Umfang detailliert erläutert: https: / / grafana.com / blog / grafana-labs-security-updatate-latest-on-tanstack-npm-supply-chain-ransomware-incident /. Diejenigen, die Plattformen und Pipelines verwalten, sollten diese Berichte überprüfen, um Verpflichtungsindikatoren zu extrahieren und zu überprüfen, ob ihre Umgebung ähnliche Vektoren teilt.

Kurz gesagt, der Vorfall ist ein Aufruf, die Kontrolle über CI-Geheimnisse zu stärken, die Lieferkette als strategische Priorität zu behandeln und kombinierte Lösungen anzuwenden: bessere Zugangspolitik, tiefgehende Verteidigung gegenüber Abhängigkeiten und proaktive Erkennung, so dass ein einziger verlorener Token nicht mehr eine Hintertür für kritische Vermögenswerte sein wird.