Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains

2025-12-22 15:16:35 -08:00 · 2025-01-11 19:17:43 +00:00
parent 6960947800
commit 4d97898638
44 changed files with 1924 additions and 351 deletions
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
@@ -7,10 +7,10 @@
 Dans cette page, vous trouverez :

 - Un **résumé de tous les impacts** d'un attaquant parvenant à accéder à une Github Action
- Différentes manières d'**accéder à une action** :
+- Différentes manières de **accéder à une action** :
 - Avoir des **permissions** pour créer l'action
 - Abuser des déclencheurs liés aux **pull requests**
- Abuser d'autres techniques d'**accès externe**
+- Abuser d'autres techniques d'accès **externe**
 - **Pivoting** à partir d'un dépôt déjà compromis
 - Enfin, une section sur les **techniques de post-exploitation pour abuser d'une action de l'intérieur** (causant les impacts mentionnés)

@@ -20,7 +20,7 @@ Pour une introduction sur [**Github Actions, consultez les informations de base*

 Si vous pouvez **exécuter du code arbitraire dans GitHub Actions** au sein d'un **dépôt**, vous pourriez être en mesure de :

- **Voler des secrets** montés dans le pipeline et **abuser des privilèges du pipeline** pour obtenir un accès non autorisé à des plateformes externes, telles qu'AWS et GCP.
+- **Voler des secrets** montés dans le pipeline et **abuser des privilèges du pipeline** pour obtenir un accès non autorisé à des plateformes externes, telles que AWS et GCP.
 - **Compromettre des déploiements** et d'autres **artéfacts**.
 - Si le pipeline déploie ou stocke des actifs, vous pourriez altérer le produit final, permettant une attaque de la chaîne d'approvisionnement.
 - **Exécuter du code dans des workers personnalisés** pour abuser de la puissance de calcul et pivoter vers d'autres systèmes.
@@ -35,7 +35,7 @@ Ce "**secret**" (provenant de `${{ secrets.GITHUB_TOKEN }}` et `${{ github.token
 Ce token est le même qu'une **application Github utilisera**, donc il peut accéder aux mêmes points de terminaison : [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 devrait publier un [**flux**](https://github.com/github/roadmap/issues/74) qui **permet un accès inter-dépôts** au sein de GitHub, afin qu'un dépôt puisse accéder à d'autres dépôts internes en utilisant le `GITHUB_TOKEN`.
+> Github devrait publier un [**flux**](https://github.com/github/roadmap/issues/74) qui **permet l'accès inter-dépôts** au sein de GitHub, afin qu'un dépôt puisse accéder à d'autres dépôts internes en utilisant le `GITHUB_TOKEN`.

 Vous pouvez voir les **permissions** possibles de ce token ici : [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)

@@ -141,19 +141,19 @@ Il est possible de vérifier les permissions accordées à un Github Token dans
 ## Exécution Autorisée

 > [!NOTE]
-> Ce serait le moyen le plus simple de compromettre les actions Github, car ce cas suppose que vous avez accès à **créer un nouveau dépôt dans l'organisation**, ou avoir **des privilèges d'écriture sur un dépôt**.
+> Ce serait le moyen le plus simple de compromettre les actions Github, car ce cas suppose que vous avez accès à **créer un nouveau dépôt dans l'organisation**, ou que vous avez **des privilèges d'écriture sur un dépôt**.
 >
-> Si vous êtes dans ce scénario, vous pouvez simplement vérifier les [techniques de Post Exploitation](./#post-exploitation-techniques-from-inside-an-action).
+> Si vous êtes dans ce scénario, vous pouvez simplement vérifier les [techniques de Post Exploitation](#post-exploitation-techniques-from-inside-an-action).

-### Exécution à partir de la Création de Dépôt
+### Exécution depuis la Création de Dépôt

-Dans le cas où des membres d'une organisation peuvent **créer de nouveaux dépôts** et que vous pouvez exécuter des actions github, vous pouvez **créer un nouveau dépôt et voler les secrets définis au niveau de l'organisation**.
+Dans le cas où les membres d'une organisation peuvent **créer de nouveaux dépôts** et que vous pouvez exécuter des actions github, vous pouvez **créer un nouveau dépôt et voler les secrets définis au niveau de l'organisation**.

-### Exécution à partir d'une Nouvelle Branche
+### Exécution depuis une Nouvelle Branche

 Si vous pouvez **créer une nouvelle branche dans un dépôt qui contient déjà une Action Github** configurée, vous pouvez **la modifier**, **télécharger** le contenu, puis **exécuter cette action depuis la nouvelle branche**. De cette manière, vous pouvez **exfiltrer les secrets au niveau du dépôt et de l'organisation** (mais vous devez savoir comment ils sont appelés).

-Vous pouvez rendre l'action modifiée exécutable **manuellement,** lorsqu'un **PR est créé** ou lorsque **du code est poussé** (selon le niveau de bruit que vous souhaitez faire) :
+Vous pouvez rendre l'action modifiée exécutable **manuellement,** lorsqu'un **PR est créé** ou lorsque **du code est poussé** (selon le niveau de discrétion que vous souhaitez avoir) :
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -179,7 +179,7 @@ Le déclencheur de workflow **`pull_request`** exécutera le workflow chaque foi
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>

 > [!NOTE]
-> Comme la **limitation par défaut** est pour les **contributeurs de première fois**, vous pourriez contribuer en **corrigeant un bug/typo valide** et ensuite envoyer **d'autres PRs pour abuser de vos nouveaux privilèges `pull_request`**.
+> Comme la **limitation par défaut** est pour les contributeurs **de première fois**, vous pourriez contribuer **en corrigeant un bug/typo valide** et ensuite envoyer **d'autres PRs pour abuser de vos nouveaux privilèges `pull_request`**.
 >
 > **J'ai testé cela et ça ne fonctionne pas** : ~~Une autre option serait de créer un compte avec le nom de quelqu'un qui a contribué au projet et a supprimé son compte.~~

@@ -196,7 +196,7 @@ Comme l'attaquant contrôle également le code exécuté, même s'il n'y a pas d

 ### **`pull_request_target`**

-Le déclencheur de workflow **`pull_request_target`** a **des permissions d'écriture** sur le dépôt cible et **accès aux secrets** (et ne demande pas de permission).
+Le déclencheur de workflow **`pull_request_target`** a **la permission d'écriture** sur le dépôt cible et **l'accès aux secrets** (et ne demande pas de permission).

 Notez que le déclencheur de workflow **`pull_request_target`** **s'exécute dans le contexte de base** et non dans celui donné par la PR (pour **ne pas exécuter de code non fiable**). Pour plus d'infos sur `pull_request_target`, [**consultez les docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
 De plus, pour plus d'infos sur cet usage dangereux spécifique, consultez ce [**post de blog github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
@@ -209,7 +209,7 @@ Et celui-ci aura **accès aux secrets**.

 Le déclencheur [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permet d'exécuter un workflow à partir d'un autre lorsqu'il est `complété`, `demandé` ou `en cours`.

-Dans cet exemple, un workflow est configuré pour s'exécuter après que le workflow séparé "Exécuter des tests" soit complété :
+Dans cet exemple, un workflow est configuré pour s'exécuter après la fin du workflow séparé "Exécuter des tests" :
 ```yaml
 on:
 workflow_run:
@@ -217,10 +217,10 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-De plus, selon la documentation : Le flux de travail démarré par l'événement `workflow_run` est capable d'**accéder aux secrets et d'écrire des tokens, même si le flux de travail précédent ne l'était pas**.
+De plus, selon la documentation : Le workflow démarré par l'événement `workflow_run` est capable d'**accéder aux secrets et d'écrire des tokens, même si le workflow précédent ne l'était pas**.

-Ce type de flux de travail pourrait être attaqué s'il **dépend** d'un **flux de travail** qui peut être **déclenché** par un utilisateur externe via **`pull_request`** ou **`pull_request_target`**. Quelques exemples vulnérables peuvent être [**trouvés dans ce blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Le premier consiste à ce que le flux de travail déclenché par **`workflow_run`** télécharge le code des attaquants : `${{ github.event.pull_request.head.sha }}`\
-Le second consiste à **passer** un **artifact** du code **non fiable** au flux de travail **`workflow_run`** et à utiliser le contenu de cet artifact d'une manière qui le rend **vulnérable à RCE**.
+Ce type de workflow pourrait être attaqué s'il **dépend** d'un **workflow** qui peut être **déclenché** par un utilisateur externe via **`pull_request`** ou **`pull_request_target`**. Quelques exemples vulnérables peuvent être [**trouvés dans ce blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Le premier consiste à ce que le workflow déclenché par **`workflow_run`** télécharge le code des attaquants : `${{ github.event.pull_request.head.sha }}`\
+Le second consiste à **passer** un **artifact** du code **non fiable** au workflow **`workflow_run`** et à utiliser le contenu de cet artifact d'une manière qui le rend **vulnérable à RCE**.

 ### `workflow_call`

@@ -230,18 +230,18 @@ TODO : Vérifiez si, lorsqu'il est exécuté à partir d'un pull_request, le cod

 ## Abus de l'exécution forkée

-Nous avons mentionné toutes les façons dont un attaquant externe pourrait réussir à faire exécuter un flux de travail github, maintenant examinons comment ces exécutions, si mal configurées, pourraient être abusées :
+Nous avons mentionné toutes les façons dont un attaquant externe pourrait réussir à faire exécuter un workflow github, maintenant examinons comment ces exécutions, si mal configurées, pourraient être abusées :

 ### Exécution de checkout non fiable

-Dans le cas de **`pull_request`,** le flux de travail va être exécuté dans le **contexte de la PR** (il exécutera donc le **code malveillant de la PR**), mais quelqu'un doit **l'autoriser d'abord** et il s'exécutera avec certaines [limitations](./#pull_request).
+Dans le cas de **`pull_request`,** le workflow sera exécuté dans le **contexte de la PR** (il exécutera donc le **code malveillant de la PR**), mais quelqu'un doit d'abord **l'autoriser** et il s'exécutera avec certaines [limitations](#pull_request).

-Dans le cas d'un flux de travail utilisant **`pull_request_target` ou `workflow_run`** qui dépend d'un flux de travail pouvant être déclenché à partir de **`pull_request_target` ou `pull_request`**, le code du dépôt original sera exécuté, donc l'**attaquant ne peut pas contrôler le code exécuté**.
+Dans le cas d'un workflow utilisant **`pull_request_target` ou `workflow_run`** qui dépend d'un workflow pouvant être déclenché à partir de **`pull_request_target` ou `pull_request`**, le code du dépôt d'origine sera exécuté, donc l'**attaquant ne peut pas contrôler le code exécuté**.

 > [!CAUTION]
 > Cependant, si l'**action** a un **checkout explicite de la PR** qui **récupère le code de la PR** (et non de la base), elle utilisera le code contrôlé par les attaquants. Par exemple (voir la ligne 12 où le code de la PR est téléchargé) :

-<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Fournie uniquement à titre d'exemple.
+<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
 pull_request_target

@@ -266,7 +266,7 @@ arg1: ${{ secrets.supersecret }}
 - uses: fakerepo/comment-on-pr@v1
 with:
 message: |
-Merci !
+Thank you!
 </code></pre>

 Le code potentiellement **non fiable est exécuté pendant `npm install` ou `npm build`** car les scripts de construction et les **packages référencés sont contrôlés par l'auteur de la PR**.
@@ -284,11 +284,11 @@ gh-actions-context-script-injections.md

 ### **Injection de script GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>

-D'après la documentation : Vous pouvez rendre une **variable d'environnement disponible pour toutes les étapes suivantes** dans un job de flux de travail en définissant ou en mettant à jour la variable d'environnement et en l'écrivant dans le fichier d'environnement **`GITHUB_ENV`**.
+D'après la documentation : Vous pouvez rendre une **variable d'environnement disponible pour toutes les étapes suivantes** dans un job de workflow en définissant ou en mettant à jour la variable d'environnement et en l'écrivant dans le fichier d'environnement **`GITHUB_ENV`**.

 Si un attaquant pouvait **injecter n'importe quelle valeur** dans cette variable **env**, il pourrait injecter des variables d'environnement qui pourraient exécuter du code dans les étapes suivantes telles que **LD_PRELOAD** ou **NODE_OPTIONS**.

-Par exemple ([**ceci**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) et [**ceci**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imaginez un flux de travail qui fait confiance à un artifact téléchargé pour stocker son contenu dans la variable d'environnement **`GITHUB_ENV`**. Un attaquant pourrait télécharger quelque chose comme ceci pour le compromettre :
+Par exemple ([**ceci**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) et [**ceci**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imaginez un workflow qui fait confiance à un artifact téléchargé pour stocker son contenu dans la variable d'environnement **`GITHUB_ENV`**. Un attaquant pourrait télécharger quelque chose comme ceci pour le compromettre :

 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>

@@ -296,11 +296,11 @@ Par exemple ([**ceci**](https://www.legitsecurity.com/blog/github-privilege-esca

 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)

-Comme mentionné dans [**cet article de blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), cette action Github permet d'accéder à des artifacts provenant de différents flux de travail et même de dépôts.
+Comme mentionné dans [**cet article de blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), cette action Github permet d'accéder à des artifacts provenant de différents workflows et même de dépôts.

-Le problème est que si le paramètre **`path`** n'est pas défini, l'artifact est extrait dans le répertoire actuel et peut écraser des fichiers qui pourraient être utilisés ou même exécutés plus tard dans le flux de travail. Par conséquent, si l'artifact est vulnérable, un attaquant pourrait en abuser pour compromettre d'autres flux de travail faisant confiance à l'artifact.
+Le problème est que si le paramètre **`path`** n'est pas défini, l'artifact est extrait dans le répertoire courant et peut écraser des fichiers qui pourraient être utilisés ou même exécutés plus tard dans le workflow. Par conséquent, si l'artifact est vulnérable, un attaquant pourrait en abuser pour compromettre d'autres workflows faisant confiance à l'artifact.

-Exemple de flux de travail vulnérable :
+Exemple de workflow vulnérable :
 ```yaml
 on:
 workflow_run:
@@ -349,7 +349,7 @@ Si un compte change de nom, un autre utilisateur pourrait enregistrer un compte
 > [!CAUTION]
 > Donc, si une action utilise un dépôt d'un compte inexistant, il est toujours possible qu'un attaquant puisse créer ce compte et compromettre l'action.

-Si d'autres dépôts utilisaient **des dépendances de ces dépôts d'utilisateur**, un attaquant pourra les détourner. Voici une explication plus complète : [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+Si d'autres dépôts utilisaient **des dépendances de ces dépôts utilisateurs**, un attaquant pourra les détourner. Voici une explication plus complète : [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)

 ---

@@ -368,7 +368,7 @@ gh-actions-cache-poisoning.md

 ### Poisoning d'Artifact

-Les workflows pourraient utiliser **des artifacts d'autres workflows et même de dépôts**, si un attaquant parvient à **compromettre** l'Action Github qui **télécharge un artifact** qui est ensuite utilisé par un autre workflow, il pourrait **compromettre les autres workflows** :
+Les workflows pourraient utiliser **des artifacts d'autres workflows et même dépôts**, si un attaquant parvient à **compromettre** l'Action Github qui **télécharge un artifact** qui est ensuite utilisé par un autre workflow, il pourrait **compromettre les autres workflows** :

 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -448,7 +448,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>

- Si le secret est utilisé **directement dans une expression**, le script shell généré est stocké **sur disque** et est accessible.
+- Si le secret est utilisé **directement dans une expression**, le script shell généré est stocké **sur le disque** et est accessible.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
@@ -464,7 +464,7 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```

-### Abus de runners auto-hébergés
+### Abus des runners auto-hébergés

 La façon de trouver quelles **Github Actions sont exécutées dans une infrastructure non-Github** est de rechercher **`runs-on: self-hosted`** dans la configuration yaml de l'Action Github.

@@ -480,11 +480,11 @@ Vérifiez [**ce post pour plus d'informations**](https://karimrahal.com/2023/01/
 ### Registre d'images Docker Github

 Il est possible de créer des actions Github qui **construiront et stockeront une image Docker à l'intérieur de Github**.\
-Un exemple peut être trouvé dans le suivant extensible :
+Un exemple peut être trouvé dans l'expansible suivant :

 <details>

-<summary>Github Action Build &#x26; Push Docker Image</summary>
+<summary>Github Action Build & Push Docker Image</summary>
 ```yaml
 [...]

@@ -522,28 +522,28 @@ Un utilisateur ayant des permissions de lecture sur le dépôt pourra alors tél
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Ensuite, l'utilisateur pourrait rechercher des **secrets exposés dans les couches d'image Docker :**
+Ensuite, l'utilisateur pourrait rechercher des **secrets divulgués dans les couches d'image Docker :**

 {{#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}}

-### Informations sensibles dans les journaux des actions Github
+### Informations sensibles dans les journaux de Github Actions

-Même si **Github** essaie de **détecter les valeurs secrètes** dans les journaux des actions et **d'éviter de les afficher**, **d'autres données sensibles** qui pourraient avoir été générées lors de l'exécution de l'action ne seront pas cachées. Par exemple, un JWT signé avec une valeur secrète ne sera pas caché à moins qu'il ne soit [spécifiquement configuré](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Même si **Github** essaie de **détecter les valeurs secrètes** dans les journaux d'actions et **d'éviter de les afficher**, **d'autres données sensibles** qui pourraient avoir été générées lors de l'exécution de l'action ne seront pas cachées. Par exemple, un JWT signé avec une valeur secrète ne sera pas caché à moins qu'il ne soit [spécifiquement configuré](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).

 ## Couvrir vos traces

-(Technique de [**ici**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Tout d'abord, toute PR soumise est clairement visible au public sur Github et au compte GitHub cible. Dans GitHub par défaut, nous **ne pouvons pas supprimer une PR d'internet**, mais il y a un twist. Pour les comptes Github qui sont **suspendus** par Github, toutes leurs **PRs sont automatiquement supprimées** et retirées d'internet. Donc, pour cacher votre activité, vous devez soit faire **suspendre votre compte GitHub ou faire flaguer votre compte**. Cela **cacherait toutes vos activités** sur GitHub d'internet (en gros, supprimer toutes vos PR d'exploitation)
+(Technique de [**ici**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Tout d'abord, toute PR soumise est clairement visible au public sur Github et au compte GitHub cible. Sur GitHub, par défaut, nous **ne pouvons pas supprimer une PR d'internet**, mais il y a un twist. Pour les comptes Github qui sont **suspendus** par Github, toutes leurs **PRs sont automatiquement supprimées** et retirées d'internet. Donc, pour cacher votre activité, vous devez soit faire **suspendre votre compte GitHub, soit faire flaguer votre compte**. Cela **cacherait toutes vos activités** sur GitHub d'internet (en gros, retirer toutes vos PR d'exploitation)

 Une organisation sur GitHub est très proactive dans le signalement des comptes à GitHub. Tout ce que vous avez à faire est de partager "certaines choses" dans un problème et ils s'assureront que votre compte est suspendu dans les 12 heures :p et voilà, vous avez rendu votre exploitation invisible sur github.

 > [!WARNING]
-> La seule façon pour une organisation de comprendre qu'elle a été ciblée est de vérifier les journaux GitHub depuis SIEM car depuis l'interface utilisateur de GitHub, la PR serait supprimée.
+> La seule façon pour une organisation de comprendre qu'elle a été ciblée est de vérifier les journaux GitHub depuis SIEM, car depuis l'interface utilisateur de GitHub, la PR serait supprimée.

 ## Outils

-Les outils suivants sont utiles pour trouver des workflows d'actions Github et même en trouver des vulnérables :
+Les outils suivants sont utiles pour trouver des workflows Github Action et même en trouver des vulnérables :

 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)