# Sécurité Github

{{#include ../../banners/hacktricks-training.md}}

## Qu'est-ce que Github

(De [ici](https://kinsta.com/knowledgebase/what-is-github/)) À un niveau élevé, **GitHub est un site web et un service basé sur le cloud qui aide les développeurs à stocker et gérer leur code, ainsi qu'à suivre et contrôler les modifications apportées à leur code**.

### Informations de base

{{#ref}}
basic-github-information.md
{{#endref}}

## Reconnaissance externe

Les dépôts Github peuvent être configurés comme publics, privés et internes.

- **Privé** signifie que **seules** les personnes de l'**organisation** pourront y accéder.
- **Interne** signifie que **seules** les personnes de l'**entreprise** (une entreprise peut avoir plusieurs organisations) pourront y accéder.
- **Public** signifie que **tout internet** pourra y accéder.

Dans le cas où vous connaissez le **utilisateur, le dépôt ou l'organisation que vous souhaitez cibler**, vous pouvez utiliser **github dorks** pour trouver des informations sensibles ou rechercher des **fuites d'informations sensibles** **dans chaque dépôt**.

### Github Dorks

Github permet de **rechercher quelque chose en spécifiant comme portée un utilisateur, un dépôt ou une organisation**. Par conséquent, avec une liste de chaînes qui vont apparaître près d'informations sensibles, vous pouvez facilement **rechercher des informations sensibles potentielles dans votre cible**.

Outils (chaque outil contient sa liste de dorks) :

- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Liste de Dorks](https://github.com/obheda12/GitDorker/tree/master/Dorks))
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Liste de Dorks](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Liste de Dorks](https://github.com/hisxo/gitGraber/tree/master/wordlists))

### Fuites Github

Veuillez noter que les github dorks sont également destinés à rechercher des fuites en utilisant les options de recherche github. Cette section est dédiée à ces outils qui vont **télécharger chaque dépôt et rechercher des informations sensibles dans ceux-ci** (même en vérifiant une certaine profondeur de commits).

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)

> [!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).

### 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 :

{{#ref}}
accessible-deleted-data-in-github.md
{{#endref}}

## Renforcement de l'organisation

### 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).

- **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.
- _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.
- _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_
- **D'autres choses peuvent être configurées** sur cette page, mais les précédentes sont celles qui sont les plus liées à la sécurité.

### Paramètres des Actions

Plusieurs paramètres liés à la sécurité peuvent être configurés pour les actions depuis la page `https://github.com/organizations/<org_name>/settings/actions`.

> [!NOTE]
> Notez que toutes ces configurations peuvent également être définies sur chaque dépôt indépendamment.

- **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.
- _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_
- **Permissions des workflows** : Il est fortement recommandé de **donner uniquement des permissions de lecture sur le dépôt**. Il est déconseillé de donner des permissions d'écriture et de création/d'approbation de demandes de tirage pour éviter l'abus du GITHUB_TOKEN donné aux workflows en cours d'exécution.
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)

### Intégrations

_Faites-moi savoir si vous connaissez le point de terminaison de l'API pour accéder à cette info !_

- **Politique d'accès aux applications tierces** : Il est recommandé de restreindre l'accès à chaque application et de n'autoriser que celles nécessaires (après les avoir examinées).
- **Applications GitHub installées** : Il est recommandé de n'autoriser que celles nécessaires (après les avoir examinées).

## Reconnaissance & Attaques abusant des identifiants

Pour ce scénario, nous allons supposer que vous avez obtenu un accès à un compte github.

### Avec les identifiants 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**.

> [!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.

### Avec la clé SSH de l'utilisateur

Github permet aux **utilisateurs** de définir des **clés SSH** qui seront utilisées comme **méthode d'authentification pour déployer du code** en leur nom (aucune 2FA n'est appliquée).

Avec cette clé, vous pouvez effectuer **des modifications dans les dépôts où l'utilisateur a des privilèges**, cependant vous ne pouvez pas l'utiliser pour accéder à l'API github pour énumérer l'environnement. Cependant, vous pouvez **énumérer les paramètres locaux** pour obtenir des informations sur les dépôts et l'utilisateur auquel vous avez accès :
```bash
# Go to the the repository folder
# Get repo config and current user name and email
git config --list
```
Si l'utilisateur a configuré son nom d'utilisateur comme son nom d'utilisateur github, vous pouvez accéder aux **clés publiques qu'il a définies** dans son compte à _https://github.com/\<github_username>.keys_, vous pouvez vérifier cela pour confirmer que la clé privée que vous avez trouvée peut être utilisée.

Les **clés SSH** peuvent également être définies dans les dépôts en tant que **clés de déploiement**. Quiconque ayant accès à cette clé pourra **lancer des projets à partir d'un dépôt**. En général, sur un serveur avec différentes clés de déploiement, le fichier local **`~/.ssh/config`** vous donnera des informations sur la clé à laquelle il est lié.

#### 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.

Vérifiez localement si l'utilisateur actuel a une clé avec :
```shell
gpg --list-secret-keys --keyid-format=long
```
### Avec le jeton utilisateur

Pour une introduction sur [**les jetons utilisateur, 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 jeton utilisateur ressemble à ceci : `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`

### Avec l'application Oauth

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.

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

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.

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

Il existe plusieurs techniques pour compromettre et abuser d'une action Github, consultez-les ici :

{{#ref}}
abusing-github-actions/
{{#endref}}

## 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._
- **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.**
- **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**.

## Contournement des protections des environnements

Pour une introduction sur [**l'environnement Github, 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).

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:
- current_branch_name #Use '**' to run when a push is made to any branch
```
Notez que **après la création** de la branche, la **protection de la branche s'appliquera à la nouvelle branche** et vous ne pourrez pas la modifier, mais à ce moment-là, vous aurez déjà extrait les secrets.

## Persistance

- Générer **un token utilisateur**
- Voler **des tokens github** à partir des **secrets**
- **Suppression** des **résultats** de workflow et des **branches**
- Donner **plus de permissions à toute l'organisation**
- Créer des **webhooks** pour exfiltrer des informations
- Inviter **des collaborateurs externes**
- **Supprimer** les **webhooks** utilisés par le **SIEM**
- 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

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**.

Comme [**ceci**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
```yaml
name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
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)

{{#include ../../banners/hacktricks-training.md}}
