Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Basic Github Information

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

Structure de base

La structure de base de l'environnement github d'une grande entreprise consiste à posséder une entreprise qui détient plusieurs organisations et chacune d'elles peut contenir plusieurs dépôts et plusieurs équipes. Les petites entreprises peuvent simplement posséder une organisation et aucune entreprise.

Du point de vue de l'utilisateur, un utilisateur peut être membre de différentes entreprises et organisations. Au sein de celles-ci, l'utilisateur peut avoir différents rôles au niveau de l'entreprise, de l'organisation et du dépôt.

De plus, un utilisateur peut faire partie de différentes équipes avec différents rôles au niveau de l'entreprise, de l'organisation ou du dépôt.

Et enfin, les dépôts peuvent avoir des mécanismes de protection spéciaux.

Privilèges

Rôles au niveau de l'entreprise

  • Propriétaire de l'entreprise : Les personnes ayant ce rôle peuvent gérer les administrateurs, gérer les organisations au sein de l'entreprise, gérer les paramètres de l'entreprise, appliquer des politiques à travers les organisations. Cependant, ils ne peuvent pas accéder aux paramètres ou au contenu de l'organisation à moins qu'ils ne soient nommés propriétaire de l'organisation ou qu'ils aient un accès direct à un dépôt appartenant à l'organisation.

  • Membres de l'entreprise : Les membres des organisations détenues par votre entreprise sont également automatiquement membres de l'entreprise.

Rôles au sein de l'organisation

Au sein d'une organisation, les utilisateurs peuvent avoir différents rôles :

  • Propriétaires de l'organisation : Les propriétaires de l'organisation ont un accès administratif complet à votre organisation. Ce rôle devrait être limité, mais pas à moins de deux personnes, dans votre organisation.

  • Membres de l'organisation : Le rôle par défaut, non administratif pour les personnes dans une organisation est celui de membre de l'organisation. Par défaut, les membres de l'organisation ont un certain nombre de permissions.

  • Gestionnaires de facturation : Les gestionnaires de facturation sont des utilisateurs qui peuvent gérer les paramètres de facturation de votre organisation, tels que les informations de paiement.

  • Gestionnaires de sécurité : C'est un rôle que les propriétaires de l'organisation peuvent attribuer à n'importe quelle équipe au sein d'une organisation. Lorsqu'il est appliqué, il donne à chaque membre de l'équipe les permissions de gérer les alertes de sécurité et les paramètres à travers votre organisation, ainsi que des permissions de lecture pour tous les dépôts de l'organisation.

  • Si votre organisation dispose d'une équipe de sécurité, vous pouvez utiliser le rôle de gestionnaire de sécurité pour donner aux membres de l'équipe le moins d'accès nécessaire à l'organisation.

  • Gestionnaires d'applications Github : Pour permettre à des utilisateurs supplémentaires de gérer les applications Github détenues par une organisation, un propriétaire peut leur accorder des permissions de gestionnaire d'applications Github.

  • Collaborateurs extérieurs : Un collaborateur extérieur est une personne qui a accès à un ou plusieurs dépôts de l'organisation mais qui n'est pas explicitement membre de l'organisation.

Vous pouvez comparer les permissions de ces rôles dans ce tableau : https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Privilèges des membres

Dans https://github.com/organizations/<org_name>/settings/member_privileges vous pouvez voir les permissions que les utilisateurs auront simplement en faisant partie de l'organisation.

Les paramètres configurés ici indiqueront les permissions suivantes des membres de l'organisation :

  • Être administrateur, rédacteur, lecteur ou sans permission sur tous les dépôts de l'organisation.

  • Si les membres peuvent créer des dépôts privés, internes ou publics.

  • Si la création de forks de dépôts est possible.

  • Si c'est possible d'inviter des collaborateurs extérieurs.

  • Si des sites publics ou privés peuvent être publiés.

  • Les permissions que les administrateurs ont sur les dépôts.

  • Si les membres peuvent créer de nouvelles équipes.

Rôles de dépôt

Par défaut, les rôles de dépôt sont créés :

  • Lecture : Recommandé pour les contributeurs non-codeurs qui souhaitent voir ou discuter de votre projet.

  • Triage : Recommandé pour les contributeurs qui doivent gérer proactivement les problèmes et les pull requests sans accès en écriture.

  • Écriture : Recommandé pour les contributeurs qui poussent activement sur votre projet.

  • Maintenance : Recommandé pour les gestionnaires de projet qui doivent gérer le dépôt sans accès aux actions sensibles ou destructrices.

  • Admin : Recommandé pour les personnes qui ont besoin d'un accès complet au projet, y compris les actions sensibles et destructrices comme la gestion de la sécurité ou la suppression d'un dépôt.

Vous pouvez comparer les permissions de chaque rôle dans ce tableau https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

Vous pouvez également créer vos propres rôles dans https://github.com/organizations/<org_name>/settings/roles

Équipes

Vous pouvez lister les équipes créées dans une organisation dans https://github.com/orgs/<org_name>/teams. Notez que pour voir les équipes qui sont enfants d'autres équipes, vous devez accéder à chaque équipe parente.

Utilisateurs

Les utilisateurs d'une organisation peuvent être listés dans https://github.com/orgs/<org_name>/people.

Dans les informations de chaque utilisateur, vous pouvez voir les équipes dont l'utilisateur est membre, et les dépôts auxquels l'utilisateur a accès.

Authentification Github

Github propose différentes manières de s'authentifier à votre compte et d'effectuer des actions en votre nom.

Accès Web

En accédant à github.com, vous pouvez vous connecter en utilisant votre nom d'utilisateur et mot de passe (et potentiellement une 2FA).

Clés SSH

Vous pouvez configurer votre compte avec une ou plusieurs clés publiques permettant à la clé privée correspondante d'effectuer des actions en votre nom. https://github.com/settings/keys

Clés GPG

Vous ne pouvez pas usurper l'identité de l'utilisateur avec ces clés, mais si vous ne les utilisez pas, il est possible que vous soyez découvert pour avoir envoyé des commits sans signature. En savoir plus sur le mode vigilant ici.

Jetons d'accès personnel

Vous pouvez générer un jeton d'accès personnel pour donner à une application l'accès à votre compte. Lors de la création d'un jeton d'accès personnel, l'utilisateur doit spécifier les permissions que le jeton aura. https://github.com/settings/tokens

Applications Oauth

Les applications Oauth peuvent vous demander des permissions pour accéder à une partie de vos informations github ou pour vous usurper afin d'effectuer certaines actions. Un exemple courant de cette fonctionnalité est le bouton de connexion avec github que vous pouvez trouver sur certaines plateformes.

Quelques recommandations de sécurité :

  • Une application OAuth doit toujours agir en tant qu'utilisateur authentifié de GitHub sur l'ensemble de GitHub (par exemple, lors de la fourniture de notifications à l'utilisateur) et avec un accès uniquement aux scopes spécifiés.

  • Une application OAuth peut être utilisée comme fournisseur d'identité en activant un "Login with GitHub" pour l'utilisateur authentifié.

  • Ne créez pas une application OAuth si vous souhaitez que votre application agisse sur un seul dépôt. Avec le scope repo, les applications OAuth peuvent agir sur _tous_** les dépôts de l'utilisateur authentifié**.

  • Ne créez pas une application OAuth pour agir en tant qu'application pour votre équipe ou entreprise. Les applications OAuth s'authentifient en tant que seul utilisateur, donc si une personne crée une application OAuth pour qu'une entreprise l'utilise, et qu'ensuite elle quitte l'entreprise, personne d'autre n'aura accès à celle-ci.

  • Plus d'informations ici.

Applications Github

Les applications Github peuvent demander des permissions pour accéder à vos informations github ou vous usurper afin d'effectuer des actions spécifiques sur des ressources spécifiques. Dans les applications Github, vous devez spécifier les dépôts auxquels l'application aura accès.

  • Pour installer une application GitHub, vous devez être un propriétaire d'organisation ou avoir des permissions d'administrateur dans un dépôt.

  • L'application GitHub doit se connecter à un compte personnel ou à une organisation.

  • Vous pouvez créer votre propre application Github sur https://github.com/settings/apps

  • Vous pouvez voir toutes les applications Github qui ont accès à votre compte sur https://github.com/settings/apps/authorizations

  • Voici les points de terminaison de l'API pour les applications Github https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Selon les permissions de l'application, elle pourra accéder à certains d'entre eux

  • Vous pouvez voir les applications installées dans une organisation sur https://github.com/organizations/<org_name>/settings/installations

Quelques recommandations de sécurité :

  • Une application GitHub doit prendre des actions indépendamment d'un utilisateur (à moins que l'application n'utilise un jeton user-to-server). Pour sécuriser davantage les jetons d'accès user-to-server, vous pouvez utiliser des jetons d'accès qui expireront après 8 heures, et un jeton de rafraîchissement qui peut être échangé contre un nouveau jeton d'accès. Pour plus d'informations, voir "Rafraîchir les jetons d'accès user-to-server."

  • Assurez-vous que l'application GitHub s'intègre avec des dépôts spécifiques.

  • L'application GitHub doit se connecter à un compte personnel ou à une organisation.

  • Ne vous attendez pas à ce que l'application GitHub sache et fasse tout ce qu'un utilisateur peut faire.

  • N'utilisez pas une application GitHub si vous avez juste besoin d'un service "Login with GitHub". Mais une application GitHub peut utiliser un flux d'identification d'utilisateur pour connecter les utilisateurs et faire d'autres choses.

  • Ne créez pas une application GitHub si vous voulez uniquement agir en tant qu'utilisateur GitHub et faire tout ce que l'utilisateur peut faire.

  • Si vous utilisez votre application avec GitHub Actions et souhaitez modifier des fichiers de workflow, vous devez vous authentifier au nom de l'utilisateur avec un jeton OAuth qui inclut le scope workflow. L'utilisateur doit avoir des permissions d'administrateur ou d'écriture sur le dépôt qui contient le fichier de workflow. Pour plus d'informations, voir "Comprendre les scopes pour les applications OAuth."

  • Plus d'informations ici.

Actions Github

Ceci n'est pas une méthode d'authentification sur github, mais une Action Github malveillante pourrait obtenir un accès non autorisé à github et selon les privilèges accordés à l'Action, plusieurs attaques différentes pourraient être réalisées. Voir ci-dessous pour plus d'informations.

Actions Git

Les actions Git permettent d'automatiser l'exécution de code lorsqu'un événement se produit. Habituellement, le code exécuté est d'une certaine manière lié au code du dépôt (peut-être construire un conteneur Docker ou vérifier que la PR ne contient pas de secrets).

Configuration

Dans https://github.com/organizations/<org_name>/settings/actions il est possible de vérifier la configuration des actions github pour l'organisation.

Il est possible d'interdire complètement l'utilisation des actions github, d'autoriser toutes les actions github, ou de n'autoriser que certaines actions.

Il est également possible de configurer qui a besoin d'une approbation pour exécuter une Action Github et les permissions du GITHUB_TOKEN d'une Action Github lorsqu'elle est exécutée.

Git Secrets

Les Actions Github ont généralement besoin de certains secrets pour interagir avec github ou des applications tierces. Pour éviter de les mettre en clair dans le dépôt, github permet de les mettre en tant que Secrets.

Ces secrets peuvent être configurés pour le dépôt ou pour toute l'organisation. Ensuite, pour que l'Action puisse accéder au secret, vous devez le déclarer comme suit :

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret: ${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret: ${{ secrets.SuperSecret }}

Exemple d'utilisation de Bash

steps:
- shell: bash
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Les secrets ne peuvent être accédés que depuis les Actions Github qui les ont déclarés.

Une fois configurés dans le dépôt ou les organisations, les utilisateurs de github ne pourront plus y accéder, ils pourront seulement les modifier.

Par conséquent, la seule manière de voler les secrets github est de pouvoir accéder à la machine qui exécute l'Action Github (dans ce scénario, vous aurez accès uniquement aux secrets déclarés pour l'Action).

Environnements Git

Github permet de créer des environnements où vous pouvez sauvegarder des secrets. Ensuite, vous pouvez donner à l'action github l'accès aux secrets à l'intérieur de l'environnement avec quelque chose comme :

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name
Vous pouvez configurer un environnement pour être **accessible** par **toutes les branches** (par défaut), **uniquement les branches protégées** ou **spécifier** quelles branches peuvent y accéder.
Il peut également définir un **nombre d'avis requis** avant **d'exécuter** une **action** en utilisant un **environnement** ou **attendre** un certain **temps** avant de permettre la poursuite des déploiements.

### Git Action Runner

Une Github Action peut être **exécutée à l'intérieur de l'environnement github** ou peut être exécutée sur une **infrastructure tierce** configurée par l'utilisateur.

Plusieurs organisations permettront d'exécuter des Github Actions sur une **infrastructure tierce** car cela est généralement **moins cher**.

Vous pouvez **lister les runners auto-hébergés** d'une organisation sur _https://github.com/organizations/\<org\_name>/settings/actions/runners_

La manière de trouver quelles **Github Actions sont exécutées sur une infrastructure non-github** est de rechercher `runs-on: self-hosted` dans le yaml de configuration de l'action Github.

Il est **impossible d'exécuter une Github Action d'une organisation à l'intérieur d'une boîte auto-hébergée** d'une autre organisation car **un jeton unique est généré pour le Runner** lors de sa configuration pour savoir à quelle organisation le runner appartient.

Si le **Github Runner personnalisé est configuré sur une machine à l'intérieur d'AWS ou GCP** par exemple, l'Action **pourrait avoir accès au point de terminaison des métadonnées** et **voler le jeton du compte de service** avec lequel la machine fonctionne.

### Compromission de Git Action

Si toutes les actions (ou une action malveillante) sont autorisées, un utilisateur pourrait utiliser une **Github action** qui est **malveillante** et qui va **compromettre** le **conteneur** où elle est exécutée.

<div data-gb-custom-block data-tag="hint" data-style='danger'>

Une exécution de **Github Action malveillante** pourrait être **abusée** par l'attaquant pour :

* **Vol tous les secrets** auxquels l'Action a accès
* **Se déplacer latéralement** si l'Action est exécutée à l'intérieur d'une **infrastructure tierce** où le jeton SA utilisé pour faire fonctionner la machine peut être accédé (probablement via le service de métadonnées)
* **Abuser du jeton** utilisé par le **workflow** pour **voler le code du dépôt** où l'Action est exécutée ou **même le modifier**.

</div>

## Protections des Branches

Les protections de branches sont conçues pour **ne pas donner un contrôle complet d'un dépôt** aux utilisateurs. L'objectif est de **mettre plusieurs méthodes de protection avant de pouvoir écrire du code à l'intérieur d'une branche**.

Les **protections de branches d'un dépôt** peuvent être trouvées sur _https://github.com/\<orgname>/\<reponame>/settings/branches_

<div data-gb-custom-block data-tag="hint" data-style='info'>

Il est **impossible de définir une protection de branche au niveau de l'organisation**. Donc, elles doivent toutes être déclarées sur chaque dépôt.

</div>

Différentes protections peuvent être appliquées à une branche (comme à master) :

* Vous pouvez **exiger une PR avant de fusionner** (donc vous ne pouvez pas fusionner directement le code sur la branche). Si cela est sélectionné, différentes autres protections peuvent être en place :
* **Exiger un certain nombre d'approbations**. Il est très courant d'exiger que 1 ou 2 personnes supplémentaires approuvent votre PR afin qu'un seul utilisateur ne soit pas capable de fusionner directement le code.
* **Rejeter les approbations lorsque de nouveaux commits sont poussés**. Sinon, un utilisateur peut approuver un code légitime puis ajouter du code malveillant et le fusionner.
* **Exiger des avis de Propriétaires de Code**. Au moins 1 propriétaire de code du dépôt doit approuver la PR (donc des utilisateurs "aléatoires" ne peuvent pas l'approuver)
* **Restreindre qui peut rejeter les avis de pull request**. Vous pouvez spécifier des personnes ou des équipes autorisées à rejeter les avis de pull request.
* **Permettre à des acteurs spécifiés de contourner les exigences de pull request**. Ces utilisateurs pourront contourner les restrictions précédentes.
* **Exiger que les contrôles d'état réussissent avant de fusionner**. Certains contrôles doivent réussir avant de pouvoir fusionner le commit (comme une action github vérifiant qu'il n'y a pas de secret en clair).
* **Exiger la résolution des conversations avant de fusionner**. Tous les commentaires sur le code doivent être résolus avant que la PR puisse être fusionnée.
* **Exiger des commits signés**. Les commits doivent être signés.
* **Exiger un historique linéaire**. Empêcher les commits de fusion d'être poussés sur les branches correspondantes.
* **Inclure les administrateurs**. Si cela n'est pas défini, les administrateurs peuvent contourner les restrictions.
* **Restreindre qui peut pousser vers les branches correspondantes**. Restreindre qui peut envoyer une PR.

<div data-gb-custom-block data-tag="hint" data-style='info'>

Comme vous pouvez le voir, même si vous avez réussi à obtenir certaines informations d'identification d'un utilisateur, **les dépôts pourraient être protégés vous empêchant de pousser du code sur master** par exemple pour compromettre le pipeline CI/CD.

</div>

## Références

* [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
* [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
* [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
* [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
* [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)

<details>

<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Autres moyens de soutenir HackTricks :

* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF** Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github.

</details>
PrécédentGh Actions - Context Script InjectionsSuivantGitea Security

Dernière mise à jour