GH Actions - Cache Poisoning

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn Sie Ihr Unternehmen in HackTricks beworben sehen möchten oder HackTricks als PDF herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!

• Holen Sie sich das offizielle PEASS & HackTricks-Merchandise

• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.

• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositories einreichen.

Für weitere Details lesen Sie den Originalbeitrag https://scribesecurity.com/blog/github-cache-poisoning/

Cache-Vergiftung

Die Git-Aktion action/cache führt einen Caching-Mechanismus im Continuous Integration (CI)-Prozess ein, der zwei wichtige Phasen umfasst:

1. Ausführungsaktion: In dieser Phase wird nach und das zwischengespeicherte Daten während des CI-Laufs abgerufen. Die Suche verwendet einen eindeutigen Cache-Schlüssel und führt zu zwei Ergebnissen:

• Cache-Treffer: Die angeforderten Daten werden im Cache gefunden und daher sofort abgerufen.

• Cache-Miss: Es werden keine übereinstimmenden Daten im Cache gefunden, was einen frischen Download der erforderlichen Dateien und Verzeichnisse zur Folge hat, ähnlich wie bei einer Erstanforderung.

2. Nach Workflow-Aktion: Diese Phase ist der Zwischenspeicherung von Daten nach dem CI-Workflow gewidmet. Speziell, wenn ein Cache-Miss während der Ausführungsaktion auftritt, wird der aktuelle Zustand der angegebenen Verzeichnisse unter Verwendung des bereitgestellten Schlüssels zwischengespeichert. Dieser Prozess erfolgt automatisch und erfordert keine explizite Aufforderung.

Sicherheitsmaßnahmen: Cache-Isolierung und Zugriffsbeschränkungen

Um die Sicherheit zu gewährleisten und die Cache-Isolierung sicherzustellen, werden Zugriffsbeschränkungen durchgesetzt, die eine logische Trennung zwischen verschiedenen Branches schaffen. Beispielsweise ist ein für den Branch Feature-A erstellter Cache (mit seinem Ursprung im Hauptbranch) für ein Pull-Request für den Branch Feature-B (ebenfalls basierend auf dem Hauptbranch) nicht zugänglich.

Die Cache-Aktion folgt einer spezifischen Suchreihenfolge:

• Zuerst werden Cache-Treffer im selben Branch wie der Workflow-Lauf gesucht.

• Bei Misserfolg wird die Suche auf den übergeordneten Branch und andere übergeordnete Branches ausgeweitet.

Wichtig ist, dass der Cache-Zugriff branchenbezogen ist und sich auf alle Workflows und Läufe eines bestimmten Branches erstreckt. Darüber hinaus erzwingt GitHub eine Richtlinie nur für den Lesezugriff auf Cache-Einträge, sobald sie erstellt wurden, was Änderungen verbietet.

Realweltliche Auswirkung: Von einem Workflow mit niedrigen Berechtigungen zu einem Angriff auf einen Workflow mit hohen Berechtigungen

Ein veranschaulichendes CI-Szenario zeigt, wie ein Angreifer Cache-Vergiftung nutzen könnte, um Berechtigungen von einem Workflow mit niedrigen Berechtigungen auf einen mit hohen Berechtigungen zu eskalieren:

• Der Unit-Test-Workflow, der für das Ausführen von Unittests und Codeabdeckungstools verantwortlich ist, verwendet ein kompromittiertes oder verwundbares Tool. Dieser Workflow verwendet die Git-Aktion action/cache, wodurch der Cache für jeden Workflow zugänglich wird.

• Der Release-Workflow, der mit dem Erstellen und Veröffentlichen des Anwendungsartefakts beauftragt ist, optimiert seine Operationen durch Zwischenspeichern von Golang-Abhängigkeiten.

In diesem Szenario führt der Unit-Test-Workflow einen bösartigen Cache-Eintrag ein, indem er eine legitime Golang-Logging-Bibliothek (`go