GH Actions - Cache Poisoning
Für weitere Details siehe den Originalbeitrag https://scribesecurity.com/blog/github-cache-poisoning/
Cache Poisoning
Die Git-Aktion action/cache führt einen Caching-Mechanismus im Continuous Integration (CI)-Prozess ein, der zwei kritische Phasen umfasst:
Run Action: Diese Phase beinhaltet das Suchen und Abrufen von zwischengespeicherten Daten während des CI-Laufs. Die Suche nutzt einen einzigartigen Cache-Schlüssel, was zu zwei Ergebnissen führt:
Cache-hit: Die angeforderten Daten werden im Cache gefunden und stehen somit sofort zur Verfügung.
Cache-miss: Es werden keine passenden Daten im Cache gefunden, was einen frischen Download der benötigten Dateien und Verzeichnisse erforderlich macht, ähnlich einer Erstanfrage.
Post Workflow Action: Diese Phase ist der Zwischenspeicherung von Daten nach dem CI-Workflow gewidmet. Insbesondere, wenn während der Run Action ein Cache-miss auftritt, wird der aktuelle Zustand der angegebenen Verzeichnisse mit dem bereitgestellten Schlüssel zwischengespeichert. Dieser Prozess ist automatisiert und erfordert keine explizite Aufforderung.
Sicherheitsmaßnahmen: Cache-Isolierung und Zugriffsrestriktionen
Um die Sicherheit zu gewährleisten und die Cache-Isolierung aufrechtzuerhalten, werden Zugriffsrestriktionen durchgesetzt, die eine logische Trennung zwischen verschiedenen Branches schaffen. Beispielsweise ist ein Cache, der für den Branch Feature-A (mit seiner Basis im Hauptbranch) erstellt wurde, für einen Pull-Request für den Branch Feature-B (ebenfalls basierend auf dem Hauptbranch) nicht zugänglich.
Die Cache-Aktion folgt einer spezifischen Suchreihenfolge:
Zuerst wird nach Cache-Hits im selben Branch wie der Workflow-Lauf gesucht.
Wenn dies nicht erfolgreich ist, wird die Suche auf den übergeordneten Branch und andere upstream Branches ausgeweitet.
Wichtig ist, dass der Cache-Zugriff branch-spezifisch ist und sich über alle Workflows und Läufe eines bestimmten Branches erstreckt. Darüber hinaus setzt GitHub eine schreibgeschützte Richtlinie für Cache-Einträge durch, sobald sie erstellt wurden, und verbietet jegliche Änderungen.
Reale Auswirkungen: Vom Low- zu High-Permission Workflow-Angriff
Ein illustratives CI-Szenario zeigt, wie ein Angreifer Cache Poisoning nutzen könnte, um Privilegien von einem Workflow mit niedrigen Berechtigungen auf einen mit hohen Berechtigungen zu eskalieren:
Der Unit-test Workflow, der für das Ausführen von Unit-Tests und Code-Coverage-Tools verantwortlich ist, wird angenommen, ein kompromittiertes oder anfälliges Tool zu verwenden. Dieser Workflow nutzt die action/cache Git-Aktion, wodurch der Cache für jeden Workflow zugänglich ist.
Der Release Workflow, der für das Erstellen und Veröffentlichen des Anwendungsartefakts zuständig ist, optimiert seine Abläufe durch das Caching 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
Last updated
