mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-01 18:44:56 -07:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -24,7 +24,7 @@ Falls Sie den **Benutzer, das Repo oder die Organisation, die Sie anvisieren mö
|
||||
|
||||
### Github Dorks
|
||||
|
||||
Github ermöglicht es, **nach etwas zu suchen, indem man als Umfang einen Benutzer, ein Repo oder eine Organisation angibt**. Daher können Sie mit einer Liste von Zeichenfolgen, die in der Nähe sensibler Informationen erscheinen, leicht **nach potenziell sensiblen Informationen in Ihrem Ziel suchen**.
|
||||
Github ermöglicht es, **nach etwas zu suchen, indem man als Bereich einen Benutzer, ein Repo oder eine Organisation angibt**. Daher können Sie mit einer Liste von Zeichenfolgen, die in der Nähe sensibler Informationen erscheinen, leicht **nach potenziell sensiblen Informationen in Ihrem Ziel suchen**.
|
||||
|
||||
Tools (jedes Tool enthält seine Liste von Dorks):
|
||||
|
||||
@@ -32,9 +32,9 @@ Tools (jedes Tool enthält seine Liste von Dorks):
|
||||
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks-Liste](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Dorks-Liste](https://github.com/hisxo/gitGraber/tree/master/wordlists))
|
||||
|
||||
### Github-Leaks
|
||||
### Github Leaks
|
||||
|
||||
Bitte beachten Sie, dass die Github-Dorks auch dazu gedacht sind, nach Leaks zu suchen, indem die Suchoptionen von Github verwendet werden. Dieser Abschnitt ist den Tools gewidmet, die **jedes Repo herunterladen und nach sensiblen Informationen darin suchen** (sogar bestimmte Tiefen von Commits überprüfen).
|
||||
Bitte beachten Sie, dass die Github Dorks auch dazu gedacht sind, nach Leaks zu suchen, indem die Suchoptionen von Github verwendet werden. Dieser Abschnitt ist den Tools gewidmet, die **jedes Repo herunterladen und nach sensiblen Informationen darin suchen** (sogar bestimmte Tiefen von Commits überprüfen).
|
||||
|
||||
Tools (jedes Tool enthält seine Liste von Regex):
|
||||
|
||||
@@ -53,7 +53,7 @@ Tools (jedes Tool enthält seine Liste von Regex):
|
||||
|
||||
Es ist möglich, **Repos zu kompromittieren, indem man Pull-Requests missbraucht**. Um zu wissen, ob ein Repo anfällig ist, müssen Sie hauptsächlich die Github Actions YAML-Konfigurationen lesen. [**Weitere Informationen dazu finden Sie unten**](./#execution-from-a-external-fork).
|
||||
|
||||
### Github-Leaks in gelöschten/internen Forks
|
||||
### Github Leaks in gelöschten/internen Forks
|
||||
|
||||
Selbst wenn sie gelöscht oder intern sind, könnte es möglich sein, sensible Daten aus Forks von Github-Repositories zu erhalten. Überprüfen Sie es hier:
|
||||
|
||||
@@ -67,12 +67,12 @@ accessible-deleted-data-in-github.md
|
||||
|
||||
Es gibt einige **Standardprivilegien**, die Mitgliedern der Organisation zugewiesen werden können. Diese können von der Seite `https://github.com/organizations/<org_name>/settings/member_privileges` oder von der [**Organizations API**](https://docs.github.com/en/rest/orgs/orgs) gesteuert werden.
|
||||
|
||||
- **Basisberechtigungen**: Mitglieder haben die Berechtigung None/Read/write/Admin über die Repos der Organisation. Empfohlen ist **None** oder **Read**.
|
||||
- **Repository-Forking**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht zu erlauben**, Organisation-Repositories zu forken.
|
||||
- **Seiten erstellen**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht zu erlauben**, Seiten aus den Org-Repos zu veröffentlichen. Wenn nötig, können Sie das Erstellen öffentlicher oder privater Seiten erlauben.
|
||||
- **Basisberechtigungen**: Mitglieder haben die Berechtigung None/Read/write/Admin über die Repos der Organisation. Empfohlen wird **None** oder **Read**.
|
||||
- **Repository-Forking**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht** zu erlauben, Repositories der Organisation zu forken.
|
||||
- **Seiten erstellen**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht** zu erlauben, Seiten aus den Repos der Organisation zu veröffentlichen. Wenn notwendig, können Sie das Erstellen öffentlicher oder privater Seiten erlauben.
|
||||
- **Zugriffsanforderungen für Integrationen**: Mit dieser Aktivierung können externe Mitarbeiter den Zugriff auf GitHub oder OAuth-Apps anfordern, um auf diese Organisation und ihre Ressourcen zuzugreifen. Es ist normalerweise erforderlich, aber wenn nicht, ist es besser, es zu deaktivieren.
|
||||
- _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
|
||||
- **Änderung der Repository-Sichtbarkeit**: Wenn aktiviert, können **Mitglieder** mit **Admin**-Berechtigungen für das **Repository** die **Sichtbarkeit ändern**. Wenn deaktiviert, können nur Organisationsinhaber die Sichtbarkeit von Repositories ändern. Wenn Sie **nicht** möchten, dass Personen Dinge **öffentlich** machen, stellen Sie sicher, dass dies **deaktiviert** ist.
|
||||
- **Änderung der Repository-Sichtbarkeit**: Wenn aktiviert, können **Mitglieder** mit **Admin**-Berechtigungen für das **Repository** die **Sichtbarkeit ändern**. Wenn deaktiviert, können nur Organisationsinhaber die Sichtbarkeit von Repositories ändern. Wenn Sie nicht möchten, dass Personen Dinge **öffentlich** machen, stellen Sie sicher, dass dies **deaktiviert** ist.
|
||||
- _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
|
||||
- **Löschen und Übertragen von Repositories**: Wenn aktiviert, können Mitglieder mit **Admin**-Berechtigungen für das Repository **öffentliche und private Repositories löschen oder übertragen**.
|
||||
- _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
|
||||
@@ -105,11 +105,11 @@ _Lassen Sie es mich wissen, wenn Sie den API-Endpunkt kennen, um auf diese Infor
|
||||
|
||||
## Rekognoszierung & Angriffe unter Ausnutzung von Anmeldeinformationen
|
||||
|
||||
Für dieses Szenario nehmen wir an, dass Sie Zugang zu einem Github-Konto erhalten haben.
|
||||
Für dieses Szenario nehmen wir an, dass Sie Zugriff auf ein Github-Konto erhalten haben.
|
||||
|
||||
### Mit Benutzeranmeldeinformationen
|
||||
|
||||
Wenn Sie irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation haben, können Sie **einfach einloggen** und überprüfen, welche **Enterprise- und Organisationsrollen Sie haben**, ob Sie ein einfaches Mitglied sind, überprüfen, welche **Berechtigungen einfache Mitglieder haben**, in welchen **Gruppen** Sie sind, welche **Berechtigungen Sie haben** über welche **Repos** und **wie die Repos geschützt sind**.
|
||||
Wenn Sie irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation haben, können Sie **einfach einloggen** und überprüfen, welche **Unternehmens- und Organisationsrollen Sie haben**, wenn Sie ein einfaches Mitglied sind, überprüfen Sie, welche **Berechtigungen einfache Mitglieder haben**, in welchen **Gruppen** Sie sind, welche **Berechtigungen Sie haben** über welche **Repos** und **wie die Repos geschützt sind**.
|
||||
|
||||
Beachten Sie, dass **2FA verwendet werden kann**, sodass Sie diese Informationen nur abrufen können, wenn Sie auch **diesen Check bestehen**.
|
||||
|
||||
@@ -128,9 +128,9 @@ Mit diesem Schlüssel können Sie **Änderungen in Repositories vornehmen, in de
|
||||
# Get repo config and current user name and email
|
||||
git config --list
|
||||
```
|
||||
Wenn der Benutzer seinen Benutzernamen als seinen GitHub-Benutzernamen konfiguriert hat, können Sie auf die **öffentlichen Schlüssel, die er in seinem Konto festgelegt hat**, unter _https://github.com/\<github_username>.keys_ zugreifen. Sie könnten dies überprüfen, um zu bestätigen, dass der private Schlüssel, den Sie gefunden haben, verwendet werden kann.
|
||||
Wenn der Benutzer seinen Benutzernamen als seinen GitHub-Benutzernamen konfiguriert hat, können Sie auf die **öffentlichen Schlüssel, die er in seinem Konto festgelegt hat**, unter _https://github.com/\<github_username>.keys_ zugreifen. Sie könnten dies überprüfen, um zu bestätigen, dass der gefundene private Schlüssel verwendet werden kann.
|
||||
|
||||
**SSH-Schlüssel** können auch in Repositories als **Deploy-Schlüssel** festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann **Projekte aus einem Repository starten**. In einem Server mit verschiedenen Deploy-Schlüsseln gibt die lokale Datei **`~/.ssh/config`** Informationen darüber, welcher Schlüssel zugeordnet ist.
|
||||
**SSH-Schlüssel** können auch in Repositories als **Deploy-Schlüssel** festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann **Projekte aus einem Repository starten**. In der Regel gibt die lokale Datei **`~/.ssh/config`** auf einem Server mit verschiedenen Deploy-Schlüsseln Informationen darüber, welcher Schlüssel zugeordnet ist.
|
||||
|
||||
#### GPG-Schlüssel
|
||||
|
||||
@@ -144,7 +144,7 @@ gpg --list-secret-keys --keyid-format=long
|
||||
|
||||
Für eine Einführung über [**Benutzer-Token siehe die grundlegenden Informationen**](basic-github-information.md#personal-access-tokens).
|
||||
|
||||
Ein Benutzer-Token kann **anstatt eines Passworts** für Git über HTTPS verwendet werden oder kann verwendet werden, um sich [**über die Basis-Authentifizierung bei der API zu authentifizieren**](https://docs.github.com/v3/auth/#basic-authentication). Abhängig von den damit verbundenen Berechtigungen können Sie möglicherweise verschiedene Aktionen ausführen.
|
||||
Ein Benutzer-Token kann **anstelle eines Passworts** für Git über HTTPS verwendet werden oder kann verwendet werden, um sich [**über die Basis-Authentifizierung bei der API zu authentifizieren**](https://docs.github.com/v3/auth/#basic-authentication). Abhängig von den damit verbundenen Berechtigungen können Sie möglicherweise verschiedene Aktionen ausführen.
|
||||
|
||||
Ein Benutzer-Token sieht so aus: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
|
||||
|
||||
@@ -152,7 +152,7 @@ Ein Benutzer-Token sieht so aus: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
|
||||
|
||||
Für eine Einführung über [**Github Oauth-Anwendungen siehe die grundlegenden Informationen**](basic-github-information.md#oauth-applications).
|
||||
|
||||
Ein Angreifer könnte eine **bösartige Oauth-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich im Rahmen einer Phishing-Kampagne akzeptieren.
|
||||
Ein Angreifer könnte eine **bösartige Oauth-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.
|
||||
|
||||
Dies sind die [Scopes, die eine Oauth-Anwendung anfordern kann](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Man sollte immer die angeforderten Scopes überprüfen, bevor man sie akzeptiert.
|
||||
|
||||
@@ -162,13 +162,13 @@ Darüber hinaus können, wie in den grundlegenden Informationen erklärt, **Orga
|
||||
|
||||
Für eine Einführung über [**Github-Anwendungen siehe die grundlegenden Informationen**](basic-github-information.md#github-applications).
|
||||
|
||||
Ein Angreifer könnte eine **bösartige Github-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich im Rahmen einer Phishing-Kampagne akzeptieren.
|
||||
Ein Angreifer könnte eine **bösartige Github-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.
|
||||
|
||||
Darüber hinaus können, wie in den grundlegenden Informationen erklärt, **Organisationen den Zugriff auf Drittanbieteranwendungen** auf Informationen/Repos/Aktionen, die mit der Organisation verbunden sind, gewähren oder verweigern.
|
||||
|
||||
## Kompromittierung & Missbrauch von Github Action
|
||||
## Kompromittierung & Missbrauch von Github-Aktionen
|
||||
|
||||
Es gibt mehrere Techniken, um eine Github Action zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:
|
||||
Es gibt mehrere Techniken, um eine Github-Aktion zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:
|
||||
|
||||
{{#ref}}
|
||||
abusing-github-actions/
|
||||
@@ -176,25 +176,25 @@ abusing-github-actions/
|
||||
|
||||
## Umgehung des Branch-Schutzes
|
||||
|
||||
- **Erforderliche Anzahl von Genehmigungen**: Wenn Sie mehrere Konten kompromittiert haben, könnten Sie einfach Ihre PRs von anderen Konten akzeptieren. Wenn Sie nur das Konto haben, von dem Sie die PR erstellt haben, können Sie Ihre eigene PR nicht akzeptieren. Wenn Sie jedoch Zugriff auf eine **Github Action**-Umgebung im Repo haben, können Sie mit dem **GITHUB_TOKEN** möglicherweise Ihre PR **genehmigen** und auf diese Weise 1 Genehmigung erhalten.
|
||||
- _Hinweis für dies und für die Code-Eigentümer-Beschränkung, dass ein Benutzer normalerweise seine eigenen PRs nicht genehmigen kann, aber wenn Sie es können, können Sie es ausnutzen, um Ihre PRs zu akzeptieren._
|
||||
- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**: Wenn dies nicht festgelegt ist, können Sie legitimen Code einreichen, warten, bis jemand ihn genehmigt, und dann bösartigen Code hinzufügen und in den geschützten Branch zusammenführen.
|
||||
- **Überprüfungen von Code-Eigentümern anfordern**: Wenn dies aktiviert ist und Sie ein Code-Eigentümer sind, könnten Sie eine **Github Action erstellen, die Ihre PR erstellt und dann selbst genehmigt**.
|
||||
- Wenn eine **CODEOWNER-Datei falsch konfiguriert ist**, beschwert sich Github nicht, aber sie wird nicht verwendet. Daher, wenn sie falsch konfiguriert ist, wird **der Schutz der Code-Eigentümer nicht angewendet.**
|
||||
- **Erlauben Sie bestimmten Akteuren, die Anforderungen an Pull-Requests zu umgehen**: Wenn Sie einer dieser Akteure sind, können Sie die Pull-Request-Schutzmaßnahmen umgehen.
|
||||
- **Administratoren einbeziehen**: Wenn dies nicht festgelegt ist und Sie Administrator des Repos sind, können Sie diese Branch-Schutzmaßnahmen umgehen.
|
||||
- **Erfordere eine Anzahl von Genehmigungen**: Wenn Sie mehrere Konten kompromittiert haben, könnten Sie einfach Ihre PRs von anderen Konten akzeptieren. Wenn Sie nur das Konto haben, von dem Sie die PR erstellt haben, können Sie Ihre eigene PR nicht akzeptieren. Wenn Sie jedoch Zugriff auf eine **Github-Aktionsumgebung** im Repo haben, können Sie mit dem **GITHUB_TOKEN** möglicherweise Ihre PR **genehmigen** und auf diese Weise 1 Genehmigung erhalten.
|
||||
- _Hinweis für dies und für die Code-Eigentümer-Beschränkung, dass normalerweise ein Benutzer seine eigenen PRs nicht genehmigen kann, aber wenn Sie es können, können Sie es ausnutzen, um Ihre PRs zu akzeptieren._
|
||||
- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**: Wenn dies nicht eingestellt ist, können Sie legitimen Code einreichen, warten, bis jemand ihn genehmigt, und dann bösartigen Code hinzufügen und ihn in den geschützten Branch zusammenführen.
|
||||
- **Erfordere Überprüfungen von Code-Eigentümern**: Wenn dies aktiviert ist und Sie ein Code-Eigentümer sind, könnten Sie eine **Github-Aktion erstellen, die Ihre PR erstellt und dann selbst genehmigt**.
|
||||
- Wenn eine **CODEOWNER-Datei falsch konfiguriert ist**, beschwert sich Github nicht, aber es wird nicht verwendet. Daher, wenn sie falsch konfiguriert ist, wird **der Schutz der Code-Eigentümer nicht angewendet.**
|
||||
- **Erlaube bestimmten Akteuren, die Anforderungen an Pull-Requests zu umgehen**: Wenn Sie einer dieser Akteure sind, können Sie die Pull-Request-Schutzmaßnahmen umgehen.
|
||||
- **Administratoren einbeziehen**: Wenn dies nicht eingestellt ist und Sie Administrator des Repos sind, können Sie diese Branch-Schutzmaßnahmen umgehen.
|
||||
- **PR-Hijacking**: Sie könnten in der Lage sein, die **PR eines anderen zu ändern**, indem Sie bösartigen Code hinzufügen, die resultierende PR selbst genehmigen und alles zusammenführen.
|
||||
- **Entfernen von Branch-Schutzmaßnahmen**: Wenn Sie ein **Administrator des Repos sind, können Sie die Schutzmaßnahmen deaktivieren**, Ihre PR zusammenführen und die Schutzmaßnahmen wieder aktivieren.
|
||||
- **Umgehung von Push-Schutzmaßnahmen**: Wenn ein Repo **nur bestimmten Benutzern** erlaubt, Push (Code zusammenführen) in Branches zu senden (der Branch-Schutz könnte alle Branches schützen, indem das Wildcard `*` angegeben wird).
|
||||
- Wenn Sie **Schreibzugriff auf das Repo haben, aber nicht berechtigt sind, Code zu pushen** aufgrund des Branch-Schutzes, können Sie dennoch **einen neuen Branch erstellen** und darin eine **Github Action erstellen, die ausgelöst wird, wenn Code gepusht wird**. Da der **Branch-Schutz den Branch nicht schützt, bis er erstellt ist**, wird dieser erste Code-Push in den Branch die **Github Action ausführen**.
|
||||
- Wenn Sie **Schreibzugriff auf das Repo haben, aber nicht berechtigt sind, Code zu pushen** aufgrund des Branch-Schutzes, können Sie dennoch **einen neuen Branch erstellen** und darin eine **Github-Aktion erstellen, die ausgelöst wird, wenn Code gepusht wird**. Da der **Branch-Schutz den Branch nicht schützt, bis er erstellt ist**, wird dieser erste Code-Push in den Branch die **Github-Aktion ausführen**.
|
||||
|
||||
## Umgehung von Umgebungs-Schutzmaßnahmen
|
||||
|
||||
Für eine Einführung über [**Github-Umgebungen siehe die grundlegenden Informationen**](basic-github-information.md#git-environments).
|
||||
|
||||
Falls eine Umgebung von **allen Branches aus zugänglich ist**, ist sie **nicht geschützt** und Sie können leicht auf die Geheimnisse innerhalb der Umgebung zugreifen. Beachten Sie, dass Sie auf Repos stoßen könnten, in denen **alle Branches geschützt sind** (indem ihre Namen angegeben oder `*` verwendet wird). In diesem Szenario sollten Sie **einen Branch finden, in den Sie Code pushen können**, und Sie können die Geheimnisse exfiltrieren, indem Sie eine neue Github Action erstellen (oder eine vorhandene ändern).
|
||||
Falls eine Umgebung von **allen Branches aus zugänglich ist**, ist sie **nicht geschützt** und Sie können leicht auf die Geheimnisse innerhalb der Umgebung zugreifen. Beachten Sie, dass Sie möglicherweise Repos finden, in denen **alle Branches geschützt sind** (indem ihre Namen angegeben oder `*` verwendet wird). In diesem Szenario sollten Sie **einen Branch finden, in den Sie Code pushen können**, und Sie können die Geheimnisse exfiltrieren, indem Sie eine neue Github-Aktion erstellen (oder eine vorhandene ändern).
|
||||
|
||||
Beachten Sie, dass Sie auf den Grenzfall stoßen könnten, in dem **alle Branches geschützt sind** (über Wildcard `*`), es wird angegeben, **wer Code in die Branches pushen kann** (_das können Sie im Branch-Schutz angeben_) und **Ihr Benutzer nicht berechtigt ist**. Sie können dennoch eine benutzerdefinierte Github Action ausführen, da Sie einen Branch erstellen und den Push-Trigger über sich selbst verwenden können. Der **Branch-Schutz erlaubt den Push in einen neuen Branch, sodass die Github Action ausgelöst wird**.
|
||||
Beachten Sie, dass Sie möglicherweise den Grenzfall finden, in dem **alle Branches geschützt sind** (über Wildcard `*`), es wird angegeben, **wer Code in die Branches pushen kann** (_das können Sie im Branch-Schutz angeben_) und **Ihr Benutzer nicht berechtigt ist**. Sie können dennoch eine benutzerdefinierte Github-Aktion ausführen, da Sie einen Branch erstellen und den Push-Trigger über sich selbst verwenden können. Der **Branch-Schutz erlaubt den Push in einen neuen Branch, sodass die Github-Aktion ausgelöst wird**.
|
||||
```yaml
|
||||
push: # Run it when a push is made to a branch
|
||||
branches:
|
||||
@@ -206,8 +206,8 @@ Beachten Sie, dass **nach der Erstellung** des Branches der **Branch-Schutz auf
|
||||
|
||||
- Generieren Sie **Benutzertoken**
|
||||
- Stehlen Sie **Github-Tokens** aus **Secrets**
|
||||
- **Löschung** von Workflow-**Ergebnissen** und **Branches**
|
||||
- Gewähren Sie **mehr Berechtigungen für die gesamte Organisation**
|
||||
- **Löschen** von Workflow-**Ergebnissen** und **Branches**
|
||||
- Geben Sie **mehr Berechtigungen für die gesamte Organisation**
|
||||
- Erstellen Sie **Webhooks**, um Informationen zu exfiltrieren
|
||||
- Laden Sie **außenstehende Mitarbeiter** ein
|
||||
- **Entfernen** Sie **Webhooks**, die vom **SIEM** verwendet werden
|
||||
@@ -216,7 +216,7 @@ Beachten Sie, dass **nach der Erstellung** des Branches der **Branch-Schutz auf
|
||||
|
||||
### Imposter Commits - Hintertür über Repo-Commits
|
||||
|
||||
In Github ist es möglich, **einen PR zu einem Repo von einem Fork zu erstellen**. Selbst wenn der PR **nicht akzeptiert** wird, wird eine **Commit**-ID im ursprünglichen Repo für die Fork-Version des Codes erstellt. Daher könnte ein Angreifer **einen bestimmten Commit aus einem anscheinend legitimen Repo verwenden, das nicht vom Eigentümer des Repos erstellt wurde**.
|
||||
In Github ist es möglich, **einen PR zu einem Repo von einem Fork zu erstellen**. Selbst wenn der PR **nicht akzeptiert** wird, wird eine **Commit**-ID im ursprünglichen Repo für die Fork-Version des Codes erstellt. Daher könnte ein Angreifer **einen bestimmten Commit aus einem anscheinend legitimen Repo verwenden, der nicht vom Eigentümer des Repos erstellt wurde**.
|
||||
|
||||
Wie [**dies**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
```yaml
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Abusing Github Actions
|
||||
# Missbrauch von Github Actions
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,24 +6,24 @@
|
||||
|
||||
Auf dieser Seite finden Sie:
|
||||
|
||||
- Eine **Zusammenfassung aller Auswirkungen**, wenn es einem Angreifer gelingt, auf eine Github Action zuzugreifen
|
||||
- Eine **Zusammenfassung aller Auswirkungen**, wenn ein Angreifer Zugriff auf eine Github Action erhält
|
||||
- Verschiedene Möglichkeiten, um **Zugriff auf eine Action zu erhalten**:
|
||||
- Berechtigungen zum Erstellen der Action haben
|
||||
- Missbrauch von **Pull-Request**-bezogenen Triggern
|
||||
- Missbrauch von **anderen externen Zugriffstechniken**
|
||||
- **Pivoting** von einem bereits kompromittierten Repo
|
||||
- Schließlich ein Abschnitt über **Post-Exploitation-Techniken, um eine Action von innen zu missbrauchen** (um die genannten Auswirkungen zu verursachen)
|
||||
- Schließlich ein Abschnitt über **Post-Exploitation-Techniken, um eine Action von innen zu missbrauchen** (wegen der genannten Auswirkungen)
|
||||
|
||||
## Zusammenfassung der Auswirkungen
|
||||
|
||||
Für eine Einführung über [**Github Actions, überprüfen Sie die grundlegenden Informationen**](../basic-github-information.md#github-actions).
|
||||
Für eine Einführung zu [**Github Actions, überprüfen Sie die grundlegenden Informationen**](../basic-github-information.md#github-actions).
|
||||
|
||||
Wenn Sie **beliebigen Code in GitHub Actions** innerhalb eines **Repositories** ausführen können, könnten Sie in der Lage sein:
|
||||
|
||||
- **Geheime Daten** zu stehlen, die in die Pipeline eingebunden sind, und die **Befugnisse der Pipeline zu missbrauchen**, um unbefugten Zugriff auf externe Plattformen wie AWS und GCP zu erhalten.
|
||||
- **Geheime Daten** zu stehlen, die in die Pipeline eingebunden sind, und die **Befugnisse der Pipeline** zu missbrauchen, um unbefugten Zugriff auf externe Plattformen wie AWS und GCP zu erhalten.
|
||||
- **Deployments** und andere **Artefakte** zu kompromittieren.
|
||||
- Wenn die Pipeline Assets bereitstellt oder speichert, könnten Sie das Endprodukt ändern, was einen Supply-Chain-Angriff ermöglicht.
|
||||
- **Code in benutzerdefinierten Workern auszuführen**, um Rechenleistung zu missbrauchen und auf andere Systeme zu pivotieren.
|
||||
- **Code in benutzerdefinierten Workern auszuführen**, um Rechenleistung zu missbrauchen und zu anderen Systemen zu pivotieren.
|
||||
- **Repository-Code zu überschreiben**, abhängig von den Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind.
|
||||
|
||||
## GITHUB_TOKEN
|
||||
@@ -35,7 +35,7 @@ Dieses "**Geheimnis**" (stammend von `${{ secrets.GITHUB_TOKEN }}` und `${{ gith
|
||||
Dieses Token ist dasselbe, das eine **Github-Anwendung verwenden wird**, sodass es auf dieselben Endpunkte zugreifen kann: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
|
||||
> [!WARNING]
|
||||
> Github sollte einen [**Flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **cross-repository**-Zugriff innerhalb von GitHub ermöglicht, sodass ein Repo auf andere interne Repos mit dem `GITHUB_TOKEN` zugreifen kann.
|
||||
> Github sollte einen [**Flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **den Zugriff über Repositories hinweg** innerhalb von GitHub ermöglicht, sodass ein Repo auf andere interne Repos mit dem `GITHUB_TOKEN` zugreifen kann.
|
||||
|
||||
Sie können die möglichen **Berechtigungen** dieses Tokens hier einsehen: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
|
||||
|
||||
@@ -81,11 +81,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
|
||||
{{#endtabs }}
|
||||
|
||||
> [!CAUTION]
|
||||
> Beachten Sie, dass Sie in mehreren Fällen **Github-Benutzertokens in den Umgebungsvariablen oder in den Geheimnissen von Github Actions** finden können. Diese Tokens können Ihnen mehr Berechtigungen über das Repository und die Organisation geben.
|
||||
> Beachten Sie, dass Sie in mehreren Fällen **Github-Benutzertokens in den Umgebungsvariablen von Github Actions oder in den Secrets** finden können. Diese Tokens können Ihnen mehr Berechtigungen über das Repository und die Organisation geben.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Geheimnisse im Github Action-Ausgang auflisten</summary>
|
||||
<summary>Liste der Secrets im Github Action-Ausgang</summary>
|
||||
```yaml
|
||||
name: list_env
|
||||
on:
|
||||
@@ -151,9 +151,9 @@ Falls Mitglieder einer Organisation **neue Repos erstellen** können und Sie Git
|
||||
|
||||
### Ausführung aus einem neuen Branch
|
||||
|
||||
Wenn Sie **einen neuen Branch in einem Repository erstellen können, das bereits eine konfigurierte Github-Aktion enthält**, können Sie diese **modifizieren**, den Inhalt **hochladen** und dann **diese Aktion aus dem neuen Branch ausführen**. Auf diese Weise können Sie **Repository- und Organisationsebene Geheimnisse exfiltrieren** (aber Sie müssen wissen, wie sie genannt werden).
|
||||
Wenn Sie **einen neuen Branch in einem Repository erstellen können, das bereits eine konfigurierte Github-Aktion enthält**, können Sie diese **modifizieren**, den Inhalt **hochladen** und dann **diese Aktion aus dem neuen Branch ausführen**. Auf diese Weise können Sie **Geheimnisse auf Repository- und Organisationsebene exfiltrieren** (aber Sie müssen wissen, wie sie genannt werden).
|
||||
|
||||
Sie können die modifizierte Aktion **manuell** ausführbar machen, wenn ein **PR erstellt wird** oder wenn **einige Codes gepusht werden** (je nachdem, wie auffällig Sie sein möchten):
|
||||
Sie können die modifizierte Aktion **manuell** ausführbar machen, wenn ein **PR erstellt wird** oder wenn **einige Codes hochgeladen werden** (je nachdem, wie auffällig Sie sein möchten):
|
||||
```yaml
|
||||
on:
|
||||
workflow_dispatch: # Launch manually
|
||||
@@ -170,11 +170,11 @@ branches:
|
||||
## Forked Execution
|
||||
|
||||
> [!NOTE]
|
||||
> Es gibt verschiedene Trigger, die es einem Angreifer ermöglichen könnten, eine **Github Action eines anderen Repositories** **auszuführen**. Wenn diese auslösbaren Aktionen schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren.
|
||||
> Es gibt verschiedene Trigger, die es einem Angreifer ermöglichen könnten, eine **Github Action eines anderen Repositories** auszuführen. Wenn diese auslösbaren Aktionen schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren.
|
||||
|
||||
### `pull_request`
|
||||
|
||||
Der Workflow-Trigger **`pull_request`** wird jedes Mal den Workflow ausführen, wenn ein Pull-Request empfangen wird, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass Sie **mitarbeiten**, muss ein **Maintainer** den **Lauf** des Workflows **genehmigen**:
|
||||
Der Workflow-Trigger **`pull_request`** wird jedes Mal ausgeführt, wenn ein Pull-Request empfangen wird, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass Sie **mitarbeiten**, muss ein **Maintainer** die **Ausführung** des Workflows **genehmigen**:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -183,9 +183,9 @@ Der Workflow-Trigger **`pull_request`** wird jedes Mal den Workflow ausführen,
|
||||
>
|
||||
> **Ich habe das getestet und es funktioniert nicht**: ~~Eine andere Möglichkeit wäre, ein Konto mit dem Namen von jemandem zu erstellen, der zum Projekt beigetragen hat und dessen Konto gelöscht wurde.~~
|
||||
|
||||
Darüber hinaus **verhindert standardmäßig Schreibberechtigungen** und **Zugriff auf Geheimnisse** für das Ziel-Repository, wie in den [**Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) erwähnt:
|
||||
Darüber hinaus **verhindert standardmäßig Schreibberechtigungen** und **Zugriff auf Geheimnisse** auf das Ziel-Repository, wie in den [**Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) erwähnt:
|
||||
|
||||
> Mit Ausnahme von `GITHUB_TOKEN` werden **Geheimnisse nicht an den Runner übergeben**, wenn ein Workflow aus einem **forked** Repository ausgelöst wird. Das **`GITHUB_TOKEN` hat nur Lesezugriff** in Pull-Requests **von geforkten Repositories**.
|
||||
> Mit Ausnahme von `GITHUB_TOKEN` werden **Geheimnisse nicht an den Runner übergeben**, wenn ein Workflow von einem **forked** Repository ausgelöst wird. Das **`GITHUB_TOKEN` hat nur Lesezugriff** in Pull-Requests **von geforkten Repositories**.
|
||||
|
||||
Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Aktionen anzuhängen. Er wird jedoch nicht in der Lage sein, Geheimnisse zu stehlen oder das Repo zu überschreiben, aufgrund der genannten Einschränkungen.
|
||||
|
||||
@@ -198,10 +198,10 @@ Da der Angreifer auch den ausgeführten Code kontrolliert, könnte er beispielsw
|
||||
|
||||
Der Workflow-Trigger **`pull_request_target`** hat **Schreibberechtigungen** für das Ziel-Repository und **Zugriff auf Geheimnisse** (und fragt nicht nach Erlaubnis).
|
||||
|
||||
Beachten Sie, dass der Workflow-Trigger **`pull_request_target`** **im Basis-Kontext** und nicht im durch den PR gegebenen Kontext **ausgeführt wird** (um **nicht vertrauenswürdigen Code auszuführen**). Für weitere Informationen zu `pull_request_target` [**überprüfen Sie die Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Beachten Sie, dass der Workflow-Trigger **`pull_request_target`** **im Basis-Kontext** und nicht im durch den PR gegebenen Kontext ausgeführt wird (um **nicht vertrauenswürdigen Code auszuführen**). Für weitere Informationen zu `pull_request_target` [**überprüfen Sie die Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Darüber hinaus finden Sie weitere Informationen zu dieser spezifischen gefährlichen Verwendung in diesem [**Github-Blogbeitrag**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
|
||||
|
||||
Es könnte so aussehen, als wäre der **ausgeführte Workflow** der, der in der **Basis** definiert ist und **nicht im PR**, was es **sicher** macht, **`pull_request_target`** zu verwenden, aber es gibt **einige Fälle, in denen dies nicht der Fall ist**.
|
||||
Es könnte so aussehen, als wäre der **ausgeführte Workflow** der, der im **Basis** definiert ist und **nicht im PR**, was es **sicher** macht, **`pull_request_target`** zu verwenden, aber es gibt **einige Fälle, in denen dies nicht der Fall ist**.
|
||||
|
||||
Und dieser hat **Zugriff auf Geheimnisse**.
|
||||
|
||||
@@ -217,20 +217,20 @@ workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
Moreover, according to the docs: Der durch das `workflow_run`-Ereignis gestartete Workflow kann **auf Geheimnisse zugreifen und Token schreiben, auch wenn der vorherige Workflow nicht**.
|
||||
Darüber hinaus, laut den Dokumenten: Der durch das `workflow_run`-Ereignis gestartete Workflow kann **auf Geheimnisse zugreifen und Token schreiben, auch wenn der vorherige Workflow dies nicht konnte**.
|
||||
|
||||
Diese Art von Workflow könnte angegriffen werden, wenn sie **von einem Workflow abhängt**, der von einem externen Benutzer über **`pull_request`** oder **`pull_request_target`** **ausgelöst** werden kann. Einige anfällige Beispiele können [**in diesem Blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)** gefunden werden.** Der erste besteht darin, dass der durch **`workflow_run`** ausgelöste Workflow den Code des Angreifers herunterlädt: `${{ github.event.pull_request.head.sha }}`\
|
||||
Der zweite besteht darin, ein **Artifact** vom **nicht vertrauenswürdigen** Code an den **`workflow_run`**-Workflow zu **übergeben** und den Inhalt dieses Artifacts auf eine Weise zu verwenden, die ihn **anfällig für RCE** macht.
|
||||
Der zweite besteht darin, ein **Artifact** vom **nicht vertrauenswürdigen** Code an den **`workflow_run`**-Workflow zu **übergeben** und den Inhalt dieses Artifacts auf eine Weise zu verwenden, die **anfällig für RCE** ist.
|
||||
|
||||
### `workflow_call`
|
||||
|
||||
TODO
|
||||
|
||||
TODO: Überprüfen, ob der verwendete/heruntergeladene Code bei der Ausführung von einem pull_request der vom Ursprung oder vom geforkten PR ist
|
||||
TODO: Überprüfen, ob der verwendete/heruntergeladene Code bei der Ausführung von einem pull_request der von der Quelle oder vom geforkten PR stammt
|
||||
|
||||
## Missbrauch von geforkter Ausführung
|
||||
|
||||
Wir haben alle Möglichkeiten erwähnt, wie ein externer Angreifer einen GitHub-Workflow ausführen könnte. Schauen wir uns nun an, wie diese Ausführungen, wenn sie schlecht konfiguriert sind, missbraucht werden könnten:
|
||||
Wir haben alle Möglichkeiten erwähnt, wie ein externer Angreifer einen GitHub-Workflow zur Ausführung bringen könnte. Schauen wir uns nun an, wie diese Ausführungen, wenn sie schlecht konfiguriert sind, missbraucht werden könnten:
|
||||
|
||||
### Nicht vertrauenswürdige Checkout-Ausführung
|
||||
|
||||
@@ -276,17 +276,17 @@ Der potenziell **nicht vertrauenswürdige Code wird während `npm install` oder
|
||||
|
||||
### Kontext-Skript-Injektionen <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
|
||||
Beachten Sie, dass es bestimmte [**GitHub-Kontexte**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte vom **Benutzer** erstellt werden, der den PR erstellt. Wenn die GitHub-Aktion diese **Daten verwendet, um irgendetwas auszuführen**, könnte dies zu **willkürlicher Codeausführung** führen:
|
||||
Beachten Sie, dass es bestimmte [**GitHub-Kontexte**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte von dem **Benutzer** kontrolliert werden, der den PR erstellt. Wenn die GitHub-Aktion diese **Daten verwendet, um irgendetwas auszuführen**, könnte dies zu **willkürlicher Codeausführung** führen:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-context-script-injections.md
|
||||
{{#endref}}
|
||||
|
||||
### **GITHUB_ENV-Skript-Injektion** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
### **GITHUB_ENV Skript-Injektion** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
|
||||
Aus den Dokumenten: Sie können eine **Umgebungsvariable für alle nachfolgenden Schritte** in einem Workflow-Job verfügbar machen, indem Sie die Umgebungsvariable definieren oder aktualisieren und dies in die **`GITHUB_ENV`**-Umgebungsdatei schreiben.
|
||||
Laut den Dokumenten: Sie können eine **Umgebungsvariable für alle nachfolgenden Schritte** in einem Workflow-Job verfügbar machen, indem Sie die Umgebungsvariable definieren oder aktualisieren und dies in die **`GITHUB_ENV`**-Umgebungsdatei schreiben.
|
||||
|
||||
Wenn ein Angreifer **irgend einen Wert** in diese **env**-Variable **einschleusen** könnte, könnte er Umgebungsvariablen injizieren, die in nachfolgenden Schritten Code ausführen könnten, wie **LD_PRELOAD** oder **NODE_OPTIONS**.
|
||||
Wenn ein Angreifer **irgendeinen Wert** in diese **env**-Variable **einschleusen** könnte, könnte er Umgebungsvariablen injizieren, die in nachfolgenden Schritten Code ausführen könnten, wie **LD_PRELOAD** oder **NODE_OPTIONS**.
|
||||
|
||||
Zum Beispiel ([**dies**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) und [**dies**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stellen Sie sich einen Workflow vor, der einem hochgeladenen Artifact vertraut, um seinen Inhalt in der **`GITHUB_ENV`**-Umgebungsvariable zu speichern. Ein Angreifer könnte etwas wie dies hochladen, um es zu kompromittieren:
|
||||
|
||||
@@ -349,7 +349,7 @@ Wenn ein Konto seinen Namen ändert, könnte ein anderer Benutzer nach einiger Z
|
||||
> [!CAUTION]
|
||||
> Wenn eine Aktion ein Repo von einem nicht existierenden Konto verwendet, ist es immer noch möglich, dass ein Angreifer dieses Konto erstellen und die Aktion kompromittieren könnte.
|
||||
|
||||
Wenn andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet haben, wird ein Angreifer in der Lage sein, sie zu hijacken. Hier haben Sie eine umfassendere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
Wenn andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet haben, wird ein Angreifer in der Lage sein, sie zu hijacken. Hier haben Sie eine vollständigere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
|
||||
---
|
||||
|
||||
@@ -358,17 +358,17 @@ Wenn andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet
|
||||
> [!NOTE]
|
||||
> In diesem Abschnitt werden wir über Techniken sprechen, die es ermöglichen, **von einem Repo zu einem anderen zu pivotieren**, vorausgesetzt, wir haben eine Art von Zugriff auf das erste (siehe den vorherigen Abschnitt).
|
||||
|
||||
### Cache-Poisoning
|
||||
### Cache-Vergiftung
|
||||
|
||||
Ein Cache wird zwischen **Workflow-Ausführungen im selben Branch** aufrechterhalten. Das bedeutet, dass, wenn ein Angreifer ein **Paket** **kompromittiert**, das dann im Cache gespeichert und von einem **privilegierteren** Workflow **heruntergeladen** und ausgeführt wird, er auch diesen Workflow **kompromittieren** kann.
|
||||
Ein Cache wird zwischen **Workflow-Ausführungen im selben Branch** aufrechterhalten. Das bedeutet, dass, wenn ein Angreifer ein **Paket** kompromittiert, das dann im Cache gespeichert und von einem **privilegierteren** Workflow **heruntergeladen** und ausgeführt wird, er auch diesen Workflow **kompromittieren** kann.
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-cache-poisoning.md
|
||||
{{#endref}}
|
||||
|
||||
### Artifact-Poisoning
|
||||
### Artefaktvergiftung
|
||||
|
||||
Workflows könnten **Artefakte von anderen Workflows und sogar Repos** verwenden. Wenn es einem Angreifer gelingt, die Github Action, die ein **Artefakt hochlädt**, zu **kompromittieren**, das später von einem anderen Workflow verwendet wird, könnte er die **anderen Workflows kompromittieren**:
|
||||
Workflows könnten **Artefakte von anderen Workflows und sogar Repos** verwenden. Wenn es einem Angreifer gelingt, die Github Action zu **kompromittieren**, die ein **Artefakt hochlädt**, das später von einem anderen Workflow verwendet wird, könnte er **die anderen Workflows kompromittieren**:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-artifact-poisoning.md
|
||||
@@ -398,7 +398,7 @@ Wenn Sie Inhalte in ein Skript injizieren, ist es interessant zu wissen, wie Sie
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Geheimnisse in der Github Action-Ausgabe auflisten</summary>
|
||||
<summary>Liste der Geheimnisse in der Github Action-Ausgabe</summary>
|
||||
```yaml
|
||||
name: list_env
|
||||
on:
|
||||
@@ -470,7 +470,7 @@ Der Weg, um herauszufinden, welche **Github Actions in nicht-Github-Infrastruktu
|
||||
|
||||
**Selbst gehostete** Runner könnten Zugang zu **extra sensiblen Informationen**, zu anderen **Netzwerksystemen** (anfällige Endpunkte im Netzwerk? Metadatenservice?) haben oder, selbst wenn sie isoliert und zerstört sind, **könnten mehr als eine Aktion gleichzeitig ausgeführt werden** und die bösartige könnte die **Geheimnisse** der anderen stehlen.
|
||||
|
||||
Bei selbst gehosteten Runnern ist es auch möglich, die **Geheimnisse aus dem \_Runner.Listener**\_\*\* Prozess\*\* zu erhalten, der alle Geheimnisse der Workflows zu jedem Zeitpunkt enthält, indem man seinen Speicher ausliest:
|
||||
Bei selbst gehosteten Runnern ist es auch möglich, die **Geheimnisse aus dem \_Runner.Listener**\_\*\* Prozess\*\* zu erhalten, der alle Geheimnisse der Workflows zu jedem Zeitpunkt enthält, indem man seinen Speicher dumpet:
|
||||
```bash
|
||||
sudo apt-get install -y gdb
|
||||
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
|
||||
@@ -480,7 +480,7 @@ sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ prin
|
||||
### Github Docker Images Registry
|
||||
|
||||
Es ist möglich, Github-Aktionen zu erstellen, die **ein Docker-Image innerhalb von Github erstellen und speichern**.\
|
||||
Ein Beispiel finden Sie im folgenden ausklappbaren Bereich:
|
||||
Ein Beispiel finden Sie im folgenden erweiterbaren Abschnitt:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -517,7 +517,7 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
|
||||
|
||||
Wie Sie im vorherigen Code sehen konnten, wird das Github-Registry in **`ghcr.io`** gehostet.
|
||||
|
||||
Ein Benutzer mit Lesezugriff auf das Repo kann dann das Docker-Image mit einem persönlichen Zugriffstoken herunterladen:
|
||||
Ein Benutzer mit Lesezugriff auf das Repository kann dann das Docker-Image mit einem persönlichen Zugriffstoken herunterladen:
|
||||
```bash
|
||||
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
|
||||
docker pull ghcr.io/<org-name>/<repo_name>:<tag>
|
||||
@@ -534,9 +534,9 @@ Selbst wenn **Github** versucht, **Geheimwerte** in den Aktionsprotokollen zu **
|
||||
|
||||
## Spuren verwischen
|
||||
|
||||
(Technik von [**hier**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zunächst einmal ist jeder PR, der erstellt wird, für die Öffentlichkeit in Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub können wir standardmäßig **einen PR nicht aus dem Internet löschen**, aber es gibt einen Haken. Für GitHub-Konten, die von Github **gesperrt** sind, werden alle ihre **PRs automatisch gelöscht** und aus dem Internet entfernt. Um also Ihre Aktivitäten zu verbergen, müssen Sie entweder Ihr **GitHub-Konto sperren lassen oder Ihr Konto kennzeichnen lassen**. Dies würde **alle Ihre Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle Ihre Exploit-PRs entfernen).
|
||||
(Technik von [**hier**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zunächst einmal ist jeder PR, der erstellt wird, für die Öffentlichkeit in Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub können wir standardmäßig **einen PR nicht aus dem Internet löschen**, aber es gibt einen Haken. Für GitHub-Konten, die von Github **suspendiert** wurden, werden alle ihre **PRs automatisch gelöscht** und aus dem Internet entfernt. Um also Ihre Aktivitäten zu verbergen, müssen Sie entweder Ihr **GitHub-Konto suspendiert bekommen oder Ihr Konto als verdächtig markieren lassen**. Dies würde **alle Ihre Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle Ihre Exploit-PRs entfernen).
|
||||
|
||||
Eine Organisation in GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was Sie tun müssen, ist, „einige Dinge“ in einem Issue zu teilen, und sie werden sicherstellen, dass Ihr Konto in 12 Stunden gesperrt wird :p und da haben Sie es, Ihr Exploit ist auf GitHub unsichtbar gemacht.
|
||||
Eine Organisation in GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was Sie tun müssen, ist, „einige Dinge“ in einem Issue zu teilen, und sie werden sicherstellen, dass Ihr Konto in 12 Stunden suspendiert wird :p und da haben Sie es, Ihr Exploit ist auf GitHub unsichtbar gemacht.
|
||||
|
||||
> [!WARNING]
|
||||
> Der einzige Weg für eine Organisation herauszufinden, dass sie ins Visier genommen wurde, besteht darin, die GitHub-Protokolle von SIEM zu überprüfen, da der PR aus der GitHub-Benutzeroberfläche entfernt würde.
|
||||
|
||||
@@ -6,33 +6,33 @@ Diese Möglichkeiten, auf Daten von Github zuzugreifen, die angeblich gelöscht
|
||||
|
||||
## Zugriff auf Gelöschte Fork-Daten
|
||||
|
||||
1. Du forkt ein öffentliches Repository.
|
||||
2. Du commitest Code zu deinem Fork.
|
||||
3. Du löschst deinen Fork.
|
||||
1. Sie forken ein öffentliches Repository.
|
||||
2. Sie committen Code in Ihren Fork.
|
||||
3. Sie löschen Ihren Fork.
|
||||
|
||||
> [!CAUTION]
|
||||
> Die in dem gelöschten Fork committen Daten sind weiterhin zugänglich.
|
||||
|
||||
## Zugriff auf Gelöschte Repo-Daten
|
||||
|
||||
1. Du hast ein öffentliches Repo auf GitHub.
|
||||
2. Ein Benutzer forkt dein Repo.
|
||||
3. Du commitest Daten, nachdem sie es geforkt haben (und sie synchronisieren ihren Fork nie mit deinen Updates).
|
||||
4. Du löschst das gesamte Repo.
|
||||
1. Sie haben ein öffentliches Repo auf GitHub.
|
||||
2. Ein Benutzer forkt Ihr Repo.
|
||||
3. Sie committen Daten, nachdem sie es geforkt haben (und sie synchronisieren ihren Fork nie mit Ihren Updates).
|
||||
4. Sie löschen das gesamte Repo.
|
||||
|
||||
> [!CAUTION]
|
||||
> Selbst wenn du dein Repo gelöscht hast, sind alle Änderungen, die daran vorgenommen wurden, weiterhin über die Forks zugänglich.
|
||||
> Selbst wenn Sie Ihr Repo gelöscht haben, sind alle Änderungen, die daran vorgenommen wurden, weiterhin über die Forks zugänglich.
|
||||
|
||||
## Zugriff auf Private Repo-Daten
|
||||
|
||||
1. Du erstellst ein privates Repo, das schließlich öffentlich gemacht wird.
|
||||
2. Du erstellst eine private, interne Version dieses Repos (durch Forking) und commitest zusätzlichen Code für Funktionen, die du nicht öffentlich machen möchtest.
|
||||
3. Du machst dein „Upstream“-Repository öffentlich und hältst deinen Fork privat.
|
||||
1. Sie erstellen ein privates Repo, das schließlich öffentlich gemacht wird.
|
||||
2. Sie erstellen eine private, interne Version dieses Repos (durch Forking) und committen zusätzlichen Code für Funktionen, die Sie nicht öffentlich machen möchten.
|
||||
3. Sie machen Ihr „Upstream“-Repository öffentlich und halten Ihren Fork privat.
|
||||
|
||||
> [!CAUTION]
|
||||
> Es ist möglich, auf alle Daten zuzugreifen, die in den internen Fork gepusht wurden, in der Zeit zwischen der Erstellung des internen Forks und der Veröffentlichung der öffentlichen Version.
|
||||
|
||||
## Wie man Commits von gelöschten/verborgenen Forks entdeckt
|
||||
## So entdecken Sie Commits von gelöschten/verborgenen Forks
|
||||
|
||||
Der gleiche Blogbeitrag schlägt 2 Optionen vor:
|
||||
|
||||
|
||||
@@ -16,19 +16,19 @@ Und schließlich können **Repositories spezielle Schutzmechanismen** haben.
|
||||
|
||||
### Unternehmensrollen
|
||||
|
||||
- **Unternehmensinhaber**: Personen mit dieser Rolle können **Administratoren verwalten, Organisationen innerhalb des Unternehmens verwalten, Unternehmenseinstellungen verwalten, Richtlinien über Organisationen durchsetzen**. Sie **können jedoch nicht auf die Einstellungen oder Inhalte der Organisation zugreifen**, es sei denn, sie werden zum Organisationsinhaber ernannt oder erhalten direkten Zugriff auf ein von der Organisation besessenes Repository.
|
||||
- **Unternehmensmitglieder**: Mitglieder von Organisationen, die von Ihrem Unternehmen besessen werden, sind ebenfalls **automatisch Mitglieder des Unternehmens**.
|
||||
- **Unternehmensinhaber**: Personen mit dieser Rolle können **Administratoren verwalten, Organisationen innerhalb des Unternehmens verwalten, Unternehmenseinstellungen verwalten, Richtlinien über Organisationen hinweg durchsetzen**. Sie **können jedoch nicht auf die Einstellungen oder Inhalte der Organisation zugreifen**, es sei denn, sie werden zu einem Organisationsinhaber ernannt oder erhalten direkten Zugriff auf ein von der Organisation besessenes Repository.
|
||||
- **Unternehmensmitglieder**: Mitglieder von Organisationen, die Ihrem Unternehmen gehören, sind ebenfalls **automatisch Mitglieder des Unternehmens**.
|
||||
|
||||
### Organisationsrollen
|
||||
|
||||
In einer Organisation können Benutzer verschiedene Rollen haben:
|
||||
|
||||
- **Organisationsinhaber**: Organisationsinhaber haben **vollständigen administrativen Zugriff auf Ihre Organisation**. Diese Rolle sollte begrenzt sein, jedoch auf nicht weniger als zwei Personen in Ihrer Organisation.
|
||||
- **Organisationsinhaber**: Organisationsinhaber haben **vollständigen administrativen Zugriff auf Ihre Organisation**. Diese Rolle sollte begrenzt sein, jedoch nicht auf weniger als zwei Personen in Ihrer Organisation.
|
||||
- **Organisationsmitglieder**: Die **Standard**-Nicht-Administrationsrolle für **Personen in einer Organisation** ist das Organisationsmitglied. Standardmäßig haben Organisationsmitglieder **eine Reihe von Berechtigungen**.
|
||||
- **Abrechnungsmanager**: Abrechnungsmanager sind Benutzer, die **die Abrechnungseinstellungen für Ihre Organisation verwalten** können, wie z. B. Zahlungsinformationen.
|
||||
- **Sicherheitsmanager**: Es ist eine Rolle, die Organisationsinhaber einem Team in einer Organisation zuweisen können. Wenn sie angewendet wird, gibt sie jedem Mitglied des Teams Berechtigungen, um **Sicherheitswarnungen und -einstellungen in Ihrer Organisation zu verwalten sowie Lesezugriff auf alle Repositories** in der Organisation zu haben.
|
||||
- Wenn Ihre Organisation ein Sicherheitsteam hat, können Sie die Rolle des Sicherheitsmanagers verwenden, um den Mitgliedern des Teams den minimalen Zugriff zu gewähren, den sie für die Organisation benötigen.
|
||||
- **Github-App-Manager**: Um zusätzlichen Benutzern zu ermöglichen, **GitHub-Apps zu verwalten, die von einer Organisation besessen werden**, kann ein Eigentümer ihnen Berechtigungen als GitHub-App-Manager gewähren.
|
||||
- **Github App-Manager**: Um zusätzlichen Benutzern zu ermöglichen, **GitHub-Apps zu verwalten, die einer Organisation gehören**, kann ein Inhaber ihnen Berechtigungen als GitHub App-Manager gewähren.
|
||||
- **Externe Mitarbeiter**: Ein externer Mitarbeiter ist eine Person, die **Zugriff auf eines oder mehrere Repositories der Organisation hat, aber nicht ausdrücklich Mitglied** der Organisation ist.
|
||||
|
||||
Sie können **die Berechtigungen** dieser Rollen in dieser Tabelle vergleichen: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
|
||||
@@ -37,9 +37,9 @@ Sie können **die Berechtigungen** dieser Rollen in dieser Tabelle vergleichen:
|
||||
|
||||
In _https://github.com/organizations/\<org_name>/settings/member_privileges_ können Sie die **Berechtigungen sehen, die Benutzer nur durch ihre Mitgliedschaft in der Organisation haben**.
|
||||
|
||||
Die hier konfigurierten Einstellungen geben die folgenden Berechtigungen der Mitglieder der Organisation an:
|
||||
Die hier konfigurierten Einstellungen geben die folgenden Berechtigungen für Mitglieder der Organisation an:
|
||||
|
||||
- Administrator, Autor, Leser oder keine Berechtigung für alle Repositories der Organisation sein.
|
||||
- Admin, Autor, Leser oder keine Berechtigung für alle Repos der Organisation.
|
||||
- Ob Mitglieder private, interne oder öffentliche Repositories erstellen können.
|
||||
- Ob das Forken von Repositories möglich ist.
|
||||
- Ob externe Mitarbeiter eingeladen werden können.
|
||||
@@ -54,12 +54,12 @@ Standardmäßig werden Repository-Rollen erstellt:
|
||||
- **Lesen**: Empfohlen für **Nicht-Code-Beitragsleistende**, die Ihr Projekt ansehen oder diskutieren möchten.
|
||||
- **Triage**: Empfohlen für **Beitragsleistende, die Probleme und Pull-Requests proaktiv verwalten müssen**, ohne Schreibzugriff zu haben.
|
||||
- **Schreiben**: Empfohlen für Beitragsleistende, die **aktiv zu Ihrem Projekt beitragen**.
|
||||
- **Wartung**: Empfohlen für **Projektmanager, die das Repository verwalten müssen**, ohne Zugriff auf sensible oder destruktive Aktionen zu haben.
|
||||
- **Verwalten**: Empfohlen für **Projektmanager, die das Repository verwalten müssen**, ohne Zugriff auf sensible oder destruktive Aktionen zu haben.
|
||||
- **Admin**: Empfohlen für Personen, die **vollständigen Zugriff auf das Projekt** benötigen, einschließlich sensibler und destruktiver Aktionen wie das Verwalten von Sicherheit oder das Löschen eines Repositories.
|
||||
|
||||
Sie können **die Berechtigungen** jeder Rolle in dieser Tabelle vergleichen [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||||
Sie können **die Berechtigungen** jeder Rolle in dieser Tabelle vergleichen: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||||
|
||||
Sie können auch **Ihre eigenen Rollen erstellen** in _https://github.com/organizations/\<org_name>/settings/roles_
|
||||
Sie können auch **Ihre eigenen Rollen erstellen** in _https://github.com/organizations/\<org_name>/settings/roles_.
|
||||
|
||||
### Teams
|
||||
|
||||
@@ -69,7 +69,7 @@ Sie können **die in einer Organisation erstellten Teams auflisten** in _https:/
|
||||
|
||||
Die Benutzer einer Organisation können in _https://github.com/orgs/\<org_name>/people_ **aufgelistet** werden.
|
||||
|
||||
In den Informationen jedes Benutzers können Sie die **Teams sehen, in denen der Benutzer Mitglied ist**, und die **Repos, auf die der Benutzer Zugriff hat**.
|
||||
In den Informationen zu jedem Benutzer können Sie die **Teams sehen, in denen der Benutzer Mitglied ist**, und die **Repos, auf die der Benutzer Zugriff hat**.
|
||||
|
||||
## Github-Authentifizierung
|
||||
|
||||
@@ -81,7 +81,7 @@ Durch den Zugriff auf **github.com** können Sie sich mit Ihrem **Benutzernamen
|
||||
|
||||
### **SSH-Schlüssel**
|
||||
|
||||
Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die es dem zugehörigen **privaten Schlüssel ermöglichen, Aktionen in Ihrem Namen auszuführen.** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die es dem zugehörigen **privaten Schlüssel ermöglichen, Aktionen in Ihrem Namen auszuführen**. [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
|
||||
#### **GPG-Schlüssel**
|
||||
|
||||
@@ -93,19 +93,19 @@ Sie können persönliche Zugriffstoken generieren, um **einer Anwendung Zugriff
|
||||
|
||||
### Oauth-Anwendungen
|
||||
|
||||
Oauth-Anwendungen können Sie um Berechtigungen **bitten, um auf Teile Ihrer Github-Informationen zuzugreifen oder Sie zu impersonifizieren**, um einige Aktionen auszuführen. Ein häufiges Beispiel für diese Funktionalität ist die **Login mit Github-Schaltfläche**, die Sie möglicherweise auf einigen Plattformen finden.
|
||||
Oauth-Anwendungen können Sie um Berechtigungen **bitten, um auf Teile Ihrer Github-Informationen zuzugreifen oder Sie zu impersonifizieren**, um einige Aktionen auszuführen. Ein häufiges Beispiel für diese Funktionalität ist die **Anmeldung mit Github-Schaltfläche**, die Sie möglicherweise auf einigen Plattformen finden.
|
||||
|
||||
- Sie können **Ihre eigenen Oauth-Anwendungen** in [https://github.com/settings/developers](https://github.com/settings/developers) erstellen.
|
||||
- Sie können Ihre eigenen **Oauth-Anwendungen** in [https://github.com/settings/developers](https://github.com/settings/developers) **erstellen**.
|
||||
- Sie können alle **Oauth-Anwendungen sehen, die Zugriff auf Ihr Konto haben** in [https://github.com/settings/applications](https://github.com/settings/applications).
|
||||
- Sie können die **Scopes sehen, die Oauth-Apps anfordern können** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps).
|
||||
- Sie können den Zugriff von Drittanwendungen auf Anwendungen in einer **Organisation** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ sehen.
|
||||
- Sie können den Zugriff von Drittanwendungen in einer **Organisation** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ sehen.
|
||||
|
||||
Einige **Sicherheitsempfehlungen**:
|
||||
|
||||
- Eine **OAuth-App** sollte immer **als authentifizierter GitHub-Benutzer über das gesamte GitHub** hinweg agieren (zum Beispiel, wenn Benutzerbenachrichtigungen bereitgestellt werden) und nur Zugriff auf die angegebenen Scopes haben.
|
||||
- Eine OAuth-App kann als Identitätsanbieter verwendet werden, indem ein "Login mit GitHub" für den authentifizierten Benutzer aktiviert wird.
|
||||
- **Bauen Sie keine OAuth-App**, wenn Sie möchten, dass Ihre Anwendung auf ein **einzelnes Repository** zugreift. Mit dem `repo` OAuth-Scope können OAuth-Apps **auf \_allen**\_\*\* Repositories des authentifizierten Benutzers zugreifen\*\*.
|
||||
- **Bauen Sie keine OAuth-App**, um als Anwendung für Ihr **Team oder Unternehmen** zu agieren. OAuth-Apps authentifizieren sich als **einzelner Benutzer**, sodass, wenn eine Person eine OAuth-App für ein Unternehmen erstellt, und dann das Unternehmen verlässt, niemand sonst Zugriff darauf hat.
|
||||
- Eine **OAuth-App** sollte immer **als der authentifizierte GitHub-Benutzer über das gesamte GitHub hinweg agieren** (zum Beispiel, wenn Benutzerbenachrichtigungen bereitgestellt werden) und nur Zugriff auf die angegebenen Scopes haben.
|
||||
- Eine OAuth-App kann als Identitätsanbieter verwendet werden, indem eine "Anmeldung mit GitHub" für den authentifizierten Benutzer aktiviert wird.
|
||||
- **Bauen Sie keine** **OAuth-App**, wenn Sie möchten, dass Ihre Anwendung auf ein **einzelnes Repository** zugreift. Mit dem `repo` OAuth-Scope können OAuth-Apps **auf _allen_**\*\* Repositories des authentifizierten Benutzers zugreifen\*\*.
|
||||
- **Bauen Sie keine** OAuth-App, um als Anwendung für Ihr **Team oder Unternehmen** zu agieren. OAuth-Apps authentifizieren sich als **einzelner Benutzer**, sodass, wenn eine Person eine OAuth-App für ein Unternehmen erstellt, und dann das Unternehmen verlässt, niemand sonst Zugriff darauf hat.
|
||||
- **Mehr** dazu [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
|
||||
|
||||
### Github-Anwendungen
|
||||
@@ -113,7 +113,7 @@ Einige **Sicherheitsempfehlungen**:
|
||||
Github-Anwendungen können um Berechtigungen bitten, um **auf Ihre Github-Informationen zuzugreifen oder Sie zu impersonifizieren**, um spezifische Aktionen über spezifische Ressourcen auszuführen. In Github-Apps müssen Sie die Repositories angeben, auf die die App Zugriff haben wird.
|
||||
|
||||
- Um eine GitHub-App zu installieren, müssen Sie **Organisationsinhaber oder über Administratorberechtigungen** in einem Repository verfügen.
|
||||
- Die GitHub-App sollte **mit einem persönlichen Konto oder einer Organisation** verbunden sein.
|
||||
- Die GitHub-App sollte **mit einem persönlichen Konto oder einer Organisation verbunden sein**.
|
||||
- Sie können Ihre eigene Github-Anwendung in [https://github.com/settings/apps](https://github.com/settings/apps) erstellen.
|
||||
- Sie können alle **Github-Anwendungen sehen, die Zugriff auf Ihr Konto haben** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations).
|
||||
- Dies sind die **API-Endpunkte für Github-Anwendungen** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Je nach den Berechtigungen der App kann sie auf einige von ihnen zugreifen.
|
||||
@@ -122,12 +122,12 @@ Github-Anwendungen können um Berechtigungen bitten, um **auf Ihre Github-Inform
|
||||
Einige Sicherheitsempfehlungen:
|
||||
|
||||
- Eine GitHub-App sollte **unabhängig von einem Benutzer handeln** (es sei denn, die App verwendet ein [User-to-Server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) Token). Um die Sicherheit von User-to-Server-Zugriffstoken zu erhöhen, können Sie Zugriffstoken verwenden, die nach 8 Stunden ablaufen, und ein Refresh-Token, das gegen ein neues Zugriffstoken eingetauscht werden kann. Weitere Informationen finden Sie unter "[Aktualisieren von User-to-Server-Zugriffstoken](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Stellen Sie sicher, dass die GitHub-App mit **bestimmten Repositories** integriert ist.
|
||||
- Die GitHub-App sollte **mit einem persönlichen Konto oder einer Organisation** verbunden sein.
|
||||
- Stellen Sie sicher, dass die GitHub-App mit **spezifischen Repositories** integriert ist.
|
||||
- Die GitHub-App sollte **mit einem persönlichen Konto oder einer Organisation verbunden sein**.
|
||||
- Erwarten Sie nicht, dass die GitHub-App alles weiß und tut, was ein Benutzer kann.
|
||||
- **Verwenden Sie keine GitHub-App, wenn Sie nur einen "Login mit GitHub"-Dienst benötigen**. Aber eine GitHub-App kann einen [Benutzeridentifikationsfluss](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) verwenden, um Benutzer einzuloggen _und_ andere Dinge zu tun.
|
||||
- **Verwenden Sie keine GitHub-App, wenn Sie nur einen "Login mit GitHub"-Dienst benötigen**. Aber eine GitHub-App kann einen [Benutzeridentifikationsfluss](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) verwenden, um Benutzer anzumelden _und_ andere Dinge zu tun.
|
||||
- Bauen Sie keine GitHub-App, wenn Sie _nur_ als GitHub-Benutzer agieren und alles tun möchten, was dieser Benutzer tun kann.
|
||||
- Wenn Sie Ihre App mit GitHub Actions verwenden und Workflow-Dateien ändern möchten, müssen Sie sich im Namen des Benutzers mit einem OAuth-Token authentifizieren, das den `workflow`-Scope enthält. Der Benutzer muss über Administrator- oder Schreibberechtigungen für das Repository verfügen, das die Workflow-Datei enthält. Weitere Informationen finden Sie unter "[Verstehen von Scopes für OAuth-Apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- Wenn Sie Ihre App mit GitHub Actions verwenden und Workflow-Dateien ändern möchten, müssen Sie sich im Namen des Benutzers mit einem OAuth-Token authentifizieren, das den `workflow`-Scope enthält. Der Benutzer muss über Administrator- oder Schreibberechtigungen für das Repository verfügen, das die Workflow-Datei enthält. Weitere Informationen finden Sie unter "[Verstehen der Scopes für OAuth-Apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- **Mehr** dazu [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
|
||||
|
||||
### Github Actions
|
||||
@@ -144,7 +144,7 @@ In _https://github.com/organizations/\<org_name>/settings/actions_ ist es mögli
|
||||
|
||||
Es ist möglich, die Verwendung von Github-Aktionen vollständig zu verbieten, **alle Github-Aktionen zuzulassen** oder nur bestimmte Aktionen zuzulassen.
|
||||
|
||||
Es ist auch möglich zu konfigurieren, **wer die Genehmigung benötigt, um eine Github-Aktion auszuführen**, und die **Berechtigungen des GITHUB_TOKEN** einer Github-Aktion, wenn sie ausgeführt wird.
|
||||
Es ist auch möglich zu konfigurieren, **wer die Genehmigung benötigt, um eine Github-Aktion auszuführen** und die **Berechtigungen des GITHUB_TOKEN** einer Github-Aktion, wenn sie ausgeführt wird.
|
||||
|
||||
### Git-Geheimnisse
|
||||
|
||||
@@ -168,77 +168,77 @@ run: |
|
||||
example-command "$SUPER_SECRET"
|
||||
```
|
||||
> [!WARNING]
|
||||
> Secrets **können nur von den Github Actions** zugegriffen werden, die sie deklariert haben.
|
||||
> Geheimnisse **können nur von den Github Actions** abgerufen werden, die sie deklariert haben.
|
||||
|
||||
> Sobald sie im Repo oder in den Organisationen konfiguriert sind, **werden die Nutzer von Github nicht mehr darauf zugreifen können**, sie können sie nur **ändern**.
|
||||
> Sobald sie im Repo oder in den Organisationen konfiguriert sind, **werden die Benutzer von Github nicht mehr darauf zugreifen können**, sie können sie nur **ändern**.
|
||||
|
||||
Daher ist der **einzige Weg, Github-Secrets zu stehlen, Zugriff auf die Maschine zu haben, die die Github Action ausführt** (in diesem Szenario können Sie nur auf die für die Action deklarierten Secrets zugreifen).
|
||||
Daher ist der **einzige Weg, Github-Geheimnisse zu stehlen, Zugriff auf die Maschine zu haben, die die Github Action ausführt** (in diesem Szenario können Sie nur auf die für die Action deklarierten Geheimnisse zugreifen).
|
||||
|
||||
### Git-Umgebungen
|
||||
|
||||
Github ermöglicht es, **Umgebungen** zu erstellen, in denen Sie **Secrets** speichern können. Dann können Sie der Github Action Zugriff auf die Secrets innerhalb der Umgebung gewähren, indem Sie etwas wie Folgendes verwenden:
|
||||
Github ermöglicht es, **Umgebungen** zu erstellen, in denen Sie **Geheimnisse** speichern können. Dann können Sie der Github Action Zugriff auf die Geheimnisse innerhalb der Umgebung gewähren, indem Sie etwas wie Folgendes verwenden:
|
||||
```yaml
|
||||
jobs:
|
||||
deployment:
|
||||
runs-on: ubuntu-latest
|
||||
environment: env_name
|
||||
```
|
||||
You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
|
||||
It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
|
||||
Sie können eine Umgebung so konfigurieren, dass sie **von allen Branches** (Standard), **nur von geschützten** Branches oder **bestimmten** Branches, die darauf zugreifen können, **zugänglich** ist.\
|
||||
Es kann auch eine **Anzahl erforderlicher Überprüfungen** festgelegt werden, bevor eine **Aktion** unter Verwendung einer **Umgebung** **ausgeführt** wird, oder es kann einige **Zeit** gewartet werden, bevor die Bereitstellungen fortgesetzt werden.
|
||||
|
||||
### Git Action Runner
|
||||
|
||||
A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
|
||||
Eine Github-Aktion kann **innerhalb der Github-Umgebung ausgeführt** oder in einer **drittanbieter Infrastruktur**, die vom Benutzer konfiguriert wurde, ausgeführt werden.
|
||||
|
||||
Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
|
||||
Mehrere Organisationen erlauben es, Github-Aktionen in einer **drittanbieter Infrastruktur** auszuführen, da dies in der Regel **günstiger** ist.
|
||||
|
||||
You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
|
||||
Sie können die **selbst gehosteten Runner** einer Organisation unter _https://github.com/organizations/\<org_name>/settings/actions/runners_ auflisten.
|
||||
|
||||
The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.
|
||||
Der Weg, um herauszufinden, welche **Github-Aktionen in nicht-Github-Infrastrukturen ausgeführt werden**, besteht darin, nach `runs-on: self-hosted` in der Github-Aktionskonfigurations-yaml zu suchen.
|
||||
|
||||
It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.
|
||||
Es ist **nicht möglich, eine Github-Aktion einer Organisation innerhalb einer selbst gehosteten Box** einer anderen Organisation auszuführen, da **ein einzigartiges Token für den Runner generiert wird**, wenn er konfiguriert wird, um zu wissen, zu welcher Organisation der Runner gehört.
|
||||
|
||||
If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with.
|
||||
Wenn der benutzerdefinierte **Github Runner auf einer Maschine innerhalb von AWS oder GCP** konfiguriert ist, könnte die Aktion **Zugriff auf den Metadaten-Endpunkt haben** und **das Token des Dienstkontos stehlen**, mit dem die Maschine betrieben wird.
|
||||
|
||||
### Git Action Compromise
|
||||
### Git Action Kompromittierung
|
||||
|
||||
If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed.
|
||||
Wenn alle Aktionen (oder eine bösartige Aktion) erlaubt sind, könnte ein Benutzer eine **Github-Aktion** verwenden, die **bösartig** ist und den **Container** kompromittiert, in dem sie ausgeführt wird.
|
||||
|
||||
> [!CAUTION]
|
||||
> A **malicious Github Action** run could be **abused** by the attacker to:
|
||||
> Eine **bösartige Github-Aktion** könnte vom Angreifer **missbraucht** werden, um:
|
||||
>
|
||||
> - **Steal all the secrets** the Action has access to
|
||||
> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
|
||||
> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
|
||||
> - **Alle Geheimnisse zu stehlen**, auf die die Aktion Zugriff hat
|
||||
> - **Laterale Bewegungen** durchzuführen, wenn die Aktion in einer **drittanbieter Infrastruktur** ausgeführt wird, wo das SA-Token, das zum Ausführen der Maschine verwendet wird, abgerufen werden kann (wahrscheinlich über den Metadatenservice)
|
||||
> - **Das Token** zu **missbrauchen**, das vom **Workflow** verwendet wird, um **den Code des Repos zu stehlen**, in dem die Aktion ausgeführt wird, oder **sogar zu modifizieren**.
|
||||
|
||||
## Branch Protections
|
||||
## Branch-Schutz
|
||||
|
||||
Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
|
||||
Branch-Schutzmaßnahmen sind so konzipiert, dass sie **nicht die vollständige Kontrolle über ein Repository** an die Benutzer geben. Das Ziel ist es, **mehrere Schutzmethoden zu implementieren, bevor man in einem bestimmten Branch Code schreiben kann**.
|
||||
|
||||
The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
|
||||
Die **Branch-Schutzmaßnahmen eines Repositories** finden Sie unter _https://github.com/\<orgname>/\<reponame>/settings/branches_.
|
||||
|
||||
> [!NOTE]
|
||||
> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
|
||||
> Es ist **nicht möglich, einen Branch-Schutz auf Organisationsebene festzulegen**. Daher müssen alle in jedem Repo deklariert werden.
|
||||
|
||||
Different protections can be applied to a branch (like to master):
|
||||
Verschiedene Schutzmaßnahmen können auf einen Branch (wie auf master) angewendet werden:
|
||||
|
||||
- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
|
||||
- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
|
||||
- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
|
||||
- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
|
||||
- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
|
||||
- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
|
||||
- **Require status checks to pass before merging.** Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
|
||||
- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
|
||||
- **Require signed commits**. The commits need to be signed.
|
||||
- **Require linear history.** Prevent merge commits from being pushed to matching branches.
|
||||
- **Include administrators**. If this isn't set, admins can bypass the restrictions.
|
||||
- **Restrict who can push to matching branches**. Restrict who can send a PR.
|
||||
- Sie können **eine PR vor dem Mergen verlangen** (so dass Sie Code nicht direkt über den Branch mergen können). Wenn dies ausgewählt ist, können verschiedene andere Schutzmaßnahmen in Kraft treten:
|
||||
- **Eine Anzahl von Genehmigungen verlangen**. Es ist sehr üblich, 1 oder 2 weitere Personen zu verlangen, die Ihre PR genehmigen, damit ein einzelner Benutzer nicht in der Lage ist, Code direkt zu mergen.
|
||||
- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**. Andernfalls könnte ein Benutzer legitimen Code genehmigen und dann bösartigen Code hinzufügen und mergen.
|
||||
- **Überprüfungen von Code-Eigentümern verlangen**. Mindestens 1 Code-Eigentümer des Repos muss die PR genehmigen (so dass "zufällige" Benutzer dies nicht genehmigen können).
|
||||
- **Einschränken, wer Pull-Request-Überprüfungen zurückweisen kann.** Sie können Personen oder Teams angeben, die berechtigt sind, Pull-Request-Überprüfungen zurückzuweisen.
|
||||
- **Bestimmten Akteuren erlauben, die Anforderungen an Pull-Requests zu umgehen**. Diese Benutzer können vorherige Einschränkungen umgehen.
|
||||
- **Statusprüfungen verlangen, die vor dem Mergen bestehen müssen.** Einige Prüfungen müssen bestehen, bevor der Commit gemergt werden kann (wie eine Github-Aktion, die überprüft, dass es kein Klartextgeheimnis gibt).
|
||||
- **Gespräche vor dem Mergen lösen.** Alle Kommentare zum Code müssen gelöst werden, bevor die PR gemergt werden kann.
|
||||
- **Signierte Commits verlangen**. Die Commits müssen signiert sein.
|
||||
- **Lineare Historie verlangen.** Verhindern, dass Merge-Commits in übereinstimmende Branches gepusht werden.
|
||||
- **Administratoren einbeziehen**. Wenn dies nicht festgelegt ist, können Administratoren die Einschränkungen umgehen.
|
||||
- **Einschränken, wer in übereinstimmende Branches pushen kann**. Einschränken, wer einen PR senden kann.
|
||||
|
||||
> [!NOTE]
|
||||
> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
|
||||
> Wie Sie sehen können, selbst wenn Sie es geschafft haben, einige Anmeldeinformationen eines Benutzers zu erhalten, **könnten Repos geschützt sein, sodass Sie beispielsweise keinen Code in master pushen können, um die CI/CD-Pipeline zu kompromittieren**.
|
||||
|
||||
## References
|
||||
## Referenzen
|
||||
|
||||
- [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
|
||||
- [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
|
||||
|
||||
Reference in New Issue
Block a user