Deceptive Tags und Impostor Commits: der neue Angriffsvektor in der Software-Versorgungskette

In einem neuen Beispiel, wie die Software-Versorgungskette ein attraktiver Vektor für die Angreifer bleibt, wurde die Überprüfung der beliebten Aktion von GitHub erkannt. Aktionen-cool / Probleme-Hilfe, wo schädliche Schauspieler zog alle Tags im Projektarchiv, um sie auf eine impostor die nicht Teil der legitimen Projektgeschichte ist. Das Ergebnis: Jeder Workflow, der die Aktion mit dem Label oder mit der Version anstelle eines zuverlässigen Commit SHA bezeichnet, könnte im nächsten Lauf bösartigen Code im GitHub Actions Läufer herunterladen und ausführen.

Die Impostor-Kommissionstechnik nutzt ein weniger bekanntes Eigentum der Tags: Im Gegensatz zu einem unwiderruflichen SHA kann ein Label von jedem, der das Repository oder eine Schadgabel steuert, wieder vergeben werden. In diesem Fall lädt der injizierte Code die Laufzeit Bun herunter, versucht den Runner zu lesen. Worker-Prozessspeicher, um Anmeldeinformationen in der CI / CD-Umgebung zu extrahieren und die Daten an einen vom Angreifer gesteuerten Server ("t.m-kosche [.] com") zu senden. Nach der ersten Analyse beeinflusste die gleiche Taktik ein anderes verwandtes Repository, Aktionen-Kühlen / Wartung-Einzel-Kommentar, und die Exfiltrationsinfrastruktur verbindet diesen Vorfall mit einer vorherigen Welle, die npm-Pakete im @ antv-Ökosystem angriff, was auf eine mögliche koordinierte Operation an mehreren Fronten hindeutet.

Die Auswirkungen von Open Source Organisationen und Projekten sind klar und tief: Es wurde gezeigt, dass CI / CD-Integrationen ein direkter Vektor für die Extraktion von Geheimnissen werden können. GitHub Tokens, Cloud-Anmeldeinformationen, API-Schlüssel und andere Geheimnisse, die in automatisierten Workflows verwendet werden, können gelesen und ausgefiltert werden, wenn ein Schauspieler es schafft, beliebigen Code auf dem Lauf auszuführen. Darüber hinaus erhöht die Leichtigkeit, das Engagement zu verbreiten - Tags zu ändern, die viele Aktionen standardmäßig verwenden - den Umfang des potenziellen Schadens.

Die Verteidigung gegen solche Angriffe sollte unmittelbare technische Veränderungen und umfassendere Strategien zur Software-Governance kombinieren. So schnell wie möglich, alle Workflows mit Drittaktien überprüfen und jegliche nicht konsolidierte Referenz (z.B. "v1" oder ein Label) durch ein bekanntes und geprüftes Engagement ersetzen SHA. GitHub bietet Empfehlungen und Anleitungen zum Härten von GitHub-Aktionen, die gute Praktiken wie Pinning zu SHAs erklären, Workflow-Bewilligungen begrenzen und Geheimnisse schützen; diese Richtlinien sind in der offiziellen Dokumentation der Aktionen verfügbar: https: / / docs.github.com / en / Aktionen / Security-guides / Security-hardening-for-github-actions.

Rotation von Anmeldeinformationen und Eindämmung sind unverzichtbare Schritte, sobald eine mögliche Belichtung erkannt wird. Wenn ein potenziell gefährdetes Repository oder Workflow seit der Veröffentlichung der Impostorkommission abgelaufen ist, nehmen Engagement und drehen Sie Token und Schlüssel, die von diesen Workflows verwendet werden ist die umsichtige Maßnahme. Parallel sollte der Austrittsverkehr zu verdächtigen Domänen in DNS-Auflösung und in internen Netzwerk-Firewalls blockiert werden, um zu verhindern, dass Daten während der Untersuchung weiter kommen.

Auf strategischer Ebene stärkt dieser Vorfall die Notwendigkeit, robustere Supply-Chain-Integrity-Praktiken wie das Modell SLSA (Supply-Chain Levels for Software artifacts) anzunehmen, das Kontrollen vorschlägt, um die Herkunft und Unmutbarkeit der Artefakte zu gewährleisten: https: / / slsa.dev /. Darüber hinaus implementieren föderierte Authentifizierung ohne eingebettete Geheimnisse (z.B. OIDC für Cloud-Lieferanten), Ausführung Läufer mit weniger Privilegien und Zeit, und strenge Überprüfungs- und Genehmigungsrichtlinien für die Aufnahme von Drittaktionen, reduziert den Expositionsbereich.

Für Teams, die Open Source-Projekte oder CI-Infrastruktur in Unternehmen verwalten, ist es auch angebracht, die Verwendung von Tags und Gabeln, die Zugang zu veröffentlichen Versionen haben, zu überprüfen und Pipelines zu fördern, die keine Geheimnisse für Drittaktionen aussetzen. Lieferkette und Ruf-Scan-Tools für Pakete und Aktionen, sowie anormale Verhaltensmonitore in Läufern - zum Beispiel, ungewöhnliche Downloads von Binaries wie Bun oder Outbound Traffic Peaks zu neuen Domänen - helfen, Früherkennungen zu erkennen.

Schließlich ist die betriebliche Lehre, dass die Sicherheit der Lieferkette sowohl technische Kontrollen als auch eine organisatorische Kultur erfordert, die sich mit den Geheimnissen und Abhängigkeiten von Dritten und Elementen kritischer Risiken befasst. Wenn Ihre Organisation betroffene Workflows durchführt, handeln Sie bereits: identifizieren Sie Referenzen auf Aktionen-cool und andere Aktionen Dritter, ersetzen Sie Etiketten durch verifizierte SHAs, widerrufen und erneuern Sie freigegebene Anmeldeinformationen und verschärfen Sie die Berechtigungen Ihrer Pipeline. Prävention und schnelle Reaktion sind der Unterschied zwischen einer überschaubaren Unterbrechung und einer hohen Aufprallfiltration.