mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-20 00:20:44 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains
This commit is contained in:
Translator
@@ -16,19 +16,19 @@ Auf dieser Seite finden Sie:
|
||||
|
||||
## Zusammenfassung der Auswirkungen
|
||||
|
||||
Für eine Einführung zu [**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 **Berechtigungen 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 zu anderen Systemen zu pivotieren.
|
||||
- **Repository-Code zu überschreiben**, abhängig von den Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind.
|
||||
- **Code in benutzerdefinierten Workern ausführen**, um Rechenleistung zu missbrauchen und zu anderen Systemen zu pivotieren.
|
||||
- **Repository-Code überschreiben**, abhängig von den Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind.
|
||||
|
||||
## GITHUB_TOKEN
|
||||
|
||||
Dieses "**Geheimnis**" (stammend von `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`) wird gegeben, wenn der Administrator diese Option aktiviert:
|
||||
Dieses "**Geheimnis**" (stammend von `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`) wird vergeben, wenn der Administrator diese Option aktiviert:
|
||||
|
||||
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -67,7 +67,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
|
||||
-d '{"event":"APPROVE"}'
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#tab name="PR erstellen" }}
|
||||
{{#tab name="Create PR" }}
|
||||
```bash
|
||||
# Create a PR
|
||||
curl -X POST \
|
||||
@@ -85,7 +85,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Liste der Secrets im Github Action-Ausgang</summary>
|
||||
<summary>Liste der Secrets im Github Action-Ausgabe</summary>
|
||||
```yaml
|
||||
name: list_env
|
||||
on:
|
||||
@@ -143,7 +143,7 @@ Es ist möglich, die Berechtigungen, die einem Github-Token in den Repositories
|
||||
> [!NOTE]
|
||||
> Dies wäre der einfachste Weg, Github-Aktionen zu kompromittieren, da dieser Fall voraussetzt, dass Sie **ein neues Repo in der Organisation erstellen** können oder **Schreibrechte über ein Repository** haben.
|
||||
>
|
||||
> Wenn Sie sich in diesem Szenario befinden, können Sie einfach die [Post Exploitation-Techniken](./#post-exploitation-techniques-from-inside-an-action) überprüfen.
|
||||
> Wenn Sie sich in diesem Szenario befinden, können Sie einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) überprüfen.
|
||||
|
||||
### Ausführung aus der Repo-Erstellung
|
||||
|
||||
@@ -153,7 +153,7 @@ Falls Mitglieder einer Organisation **neue Repos erstellen** können und Sie Git
|
||||
|
||||
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 hochgeladen 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 gepusht werden** (je nachdem, wie auffällig Sie sein möchten):
|
||||
```yaml
|
||||
on:
|
||||
workflow_dispatch: # Launch manually
|
||||
@@ -174,7 +174,7 @@ branches:
|
||||
|
||||
### `pull_request`
|
||||
|
||||
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**:
|
||||
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**:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -190,7 +190,7 @@ Darüber hinaus **verhindert standardmäßig Schreibberechtigungen** und **Zugri
|
||||
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.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Ja, wenn der Angreifer im PR die Github Action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem Ursprungsrepo!**
|
||||
> **Ja, wenn der Angreifer im PR die Github Action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem ursprünglichen Repo!**
|
||||
|
||||
Da der Angreifer auch den ausgeführten Code kontrolliert, könnte er beispielsweise **bösartige Artefakte hochladen**, selbst wenn es keine Geheimnisse oder Schreibberechtigungen für das `GITHUB_TOKEN` gibt.
|
||||
|
||||
@@ -198,7 +198,7 @@ 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 untrusted 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 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**.
|
||||
@@ -217,31 +217,31 @@ workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
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**.
|
||||
Außerdem, laut den Dokumenten: Der durch das `workflow_run`-Ereignis gestartete Workflow kann **Geheimnisse und Token schreiben, selbst wenn der vorherige Workflow nicht**.
|
||||
|
||||
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 **anfällig für RCE** ist.
|
||||
Dieser Art von 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. 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 **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 von der Quelle oder vom geforkten PR stammt
|
||||
TODO: Überprüfen, ob der verwendete/heruntergeladene Code, wenn er von einem pull_request ausgeführt wird, der aus dem Ursprung oder vom geforkten PR stammt.
|
||||
|
||||
## Missbrauch von geforkter Ausführung
|
||||
|
||||
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:
|
||||
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:
|
||||
|
||||
### Nicht vertrauenswürdige Checkout-Ausführung
|
||||
|
||||
Im Fall von **`pull_request`** wird der Workflow im **Kontext des PR** ausgeführt (er wird also den **bösartigen PR-Code** ausführen), aber jemand muss ihn **zuerst autorisieren**, und er wird mit einigen [Einschränkungen](./#pull_request) ausgeführt.
|
||||
Im Fall von **`pull_request`** wird der Workflow im **Kontext des PR** ausgeführt (er wird also den **bösartigen PR-Code** ausführen), aber jemand muss ihn **zuerst autorisieren**, und er wird mit einigen [Einschränkungen](#pull_request) ausgeführt.
|
||||
|
||||
Im Fall eines Workflows, der **`pull_request_target` oder `workflow_run`** verwendet und von einem Workflow abhängt, der von **`pull_request_target` oder `pull_request`** ausgelöst werden kann, wird der Code aus dem ursprünglichen Repo ausgeführt, sodass der **Angreifer den ausgeführten Code nicht kontrollieren kann**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Wenn die **Aktion** jedoch einen **expliziten PR-Checkout** hat, der **den Code vom PR** (und nicht von der Basis) **holt**, wird der vom Angreifer kontrollierte Code verwendet. Zum Beispiel (siehe Zeile 12, wo der PR-Code heruntergeladen wird):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># UNSICHER. Nur als Beispiel angegeben.
|
||||
<pre class="language-yaml"><code class="lang-yaml"># UNSICHER. Nur als Beispiel bereitgestellt.
|
||||
on:
|
||||
pull_request_target
|
||||
|
||||
@@ -269,14 +269,14 @@ message: |
|
||||
Danke!
|
||||
</code></pre>
|
||||
|
||||
Der potenziell **nicht vertrauenswürdige Code wird während `npm install` oder `npm build`** ausgeführt, da die Build-Skripte und die referenzierten **Pakete vom Autor des PR** kontrolliert werden.
|
||||
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 PR** kontrolliert werden.
|
||||
|
||||
> [!WARNING]
|
||||
> Ein GitHub-Dork, um nach anfälligen Aktionen zu suchen, ist: `event.pull_request pull_request_target extension:yml`, jedoch gibt es verschiedene Möglichkeiten, die Jobs sicher auszuführen, selbst wenn die Aktion unsicher konfiguriert ist (wie die Verwendung von Bedingungen darüber, wer der Akteur ist, der den PR generiert).
|
||||
|
||||
### 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 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:
|
||||
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:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-context-script-injections.md
|
||||
@@ -298,7 +298,7 @@ Zum Beispiel ([**dies**](https://www.legitsecurity.com/blog/github-privilege-esc
|
||||
|
||||
Wie in [**diesem Blogbeitrag**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) erwähnt, ermöglicht diese GitHub-Aktion den Zugriff auf Artefakte aus verschiedenen Workflows und sogar Repositories.
|
||||
|
||||
Das Problem ist, dass, wenn der **`path`**-Parameter nicht gesetzt ist, das Artifact im aktuellen Verzeichnis extrahiert wird und Dateien überschreiben kann, die später im Workflow verwendet oder sogar ausgeführt werden könnten. Daher könnte ein Angreifer dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artifact vertrauen.
|
||||
Das Problem ist, dass, wenn der **`path`**-Parameter nicht gesetzt ist, das Artifact im aktuellen Verzeichnis extrahiert wird und Dateien überschreiben kann, die später im Workflow verwendet oder sogar ausgeführt werden könnten. Daher könnte ein Angreifer, wenn das Artifact anfällig ist, dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artifact vertrauen.
|
||||
|
||||
Beispiel eines anfälligen Workflows:
|
||||
```yaml
|
||||
@@ -347,9 +347,9 @@ path: ./script.py
|
||||
Wenn ein Konto seinen Namen ändert, könnte ein anderer Benutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein Repository **weniger als 100 Sterne vor der Namensänderung hatte**, erlaubt Github dem neu registrierten Benutzer mit demselben Namen, ein **Repository mit demselben Namen** wie das gelöschte zu erstellen.
|
||||
|
||||
> [!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 eine Aktion also 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 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/)
|
||||
Wenn andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet haben, wird ein Angreifer in der Lage sein, sie zu übernehmen. 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/)
|
||||
|
||||
---
|
||||
|
||||
@@ -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-Vergiftung
|
||||
### Cache-Poisoning
|
||||
|
||||
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}}
|
||||
|
||||
### Artefaktvergiftung
|
||||
### Artifact-Poisoning
|
||||
|
||||
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**:
|
||||
Workflows könnten **Artefakte von anderen Workflows und sogar Repos** verwenden. Wenn es einem Angreifer gelingt, die Github Action, die ein **Artefakt hochlädt**, das später von einem anderen Workflow verwendet wird, zu **kompromittieren**, könnte er **die anderen Workflows kompromittieren**:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-artifact-poisoning.md
|
||||
@@ -464,13 +464,13 @@ with:
|
||||
key: ${{ secrets.PUBLISH_KEY }}
|
||||
```
|
||||
|
||||
### Missbrauch von selbst gehosteten Runnern
|
||||
### Missbrauch von selbstgehosteten Runnern
|
||||
|
||||
Der Weg, um herauszufinden, welche **Github Actions in nicht-Github-Infrastrukturen ausgeführt werden**, besteht darin, nach **`runs-on: self-hosted`** in der Github Action-Konfigurations-YAML zu suchen.
|
||||
Der Weg, um herauszufinden, welche **Github Actions in nicht-Github-Infrastrukturen** ausgeführt werden, besteht darin, nach **`runs-on: self-hosted`** in der Github Action-Konfigurations-YAML zu suchen.
|
||||
|
||||
**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.
|
||||
**Selbstgehostete** 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 dumpet:
|
||||
Bei selbstgehosteten 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 }')"
|
||||
@@ -484,7 +484,7 @@ Ein Beispiel finden Sie im folgenden erweiterbaren Abschnitt:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Github Action Build & Push Docker Image</summary>
|
||||
<summary>Github Action Build & Push Docker Image</summary>
|
||||
```yaml
|
||||
[...]
|
||||
|
||||
@@ -525,7 +525,7 @@ docker pull ghcr.io/<org-name>/<repo_name>:<tag>
|
||||
Dann könnte der Benutzer nach **geleakten Geheimnissen in den Docker-Image-Schichten suchen:**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### Sensible Informationen in Github Actions-Protokollen
|
||||
@@ -534,7 +534,7 @@ 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 **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).
|
||||
(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 aus dem Internet nicht 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 suspendiert wird :p und da haben Sie es, Ihr Exploit ist auf GitHub unsichtbar gemacht.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user