Informations de base GitHub

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Structure de base

La structure de base de l’environnement GitHub d’une grande company est de posséder un enterprise qui possède several organizations et chacune d’elles peut contenir several repositories et several teams. Les entreprises plus petites peuvent simplement own one organization and no enterprises.

Du point de vue d’un utilisateur, un user peut être member de different enterprises and organizations. Au sein de celles-ci, l’utilisateur peut avoir different enterprise, organization and repository roles.

De plus, un utilisateur peut faire part of different teams avec différents rôles au niveau enterprise, organization ou repository.

Et enfin, repositories may have special protection mechanisms.

Privilèges

Enterprise Roles

  • Enterprise owner : Les personnes ayant ce rôle peuvent manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations. Cependant, elles cannot access organization settings or content sauf si elles sont nommées owner d’une organisation ou reçoivent un accès direct à un repository appartenant à l’organisation.
  • Enterprise members : Les membres des organizations détenues par votre enterprise sont automatically members of the enterprise.

Organization Roles

Dans une organisation, les utilisateurs peuvent avoir différents rôles :

  • Organization owners : Les organization owners ont complete administrative access to your organization. Ce rôle doit être limité, mais à pas moins de deux personnes dans votre organisation.
  • Organization members : Le rôle default, non-administratif pour les people in an organization est organization member. Par défaut, les organization members have a number of permissions.
  • Billing managers : Les billing managers sont des utilisateurs qui peuvent manage the billing settings for your organization, comme les informations de paiement.
  • Security Managers : C’est un rôle que les organization owners peuvent assigner à n’importe quelle équipe dans une organisation. Lorsqu’il est appliqué, il donne à chaque membre de l’équipe les permissions pour manage security alerts and settings across your organization, as well as read permissions for all repositories dans l’organisation.
  • Si votre organisation dispose d’une équipe de sécurité, vous pouvez utiliser le rôle security manager pour donner aux membres de l’équipe le minimum d’accès nécessaire à l’organisation.
  • Github App managers : Pour permettre à des utilisateurs supplémentaires de manage GitHub Apps owned by an organization, un owner peut leur accorder des permissions de GitHub App manager.
  • Outside collaborators : Un outside collaborator est une personne qui a access to one or more organization repositories but is not explicitly a member de l’organisation.

Vous pouvez compare the 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

Members Privileges

Dans https://github.com/organizations/<org_name>/settings/member_privileges vous pouvez voir les permissions users will have just for being part of the organisation.

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

  • Être admin, writer, reader ou n’avoir aucune permission sur tous les repos de l’organisation.
  • Si les membres peuvent créer des repositories private, internal ou public.
  • Si le forking des repositories est possible.
  • Si l’invitation d’outside collaborators est possible.
  • Si des sites public ou private peuvent être publiés.
  • Les permissions que les admins ont sur les repositories.
  • Si les membres peuvent créer de nouvelles teams.

Repository Roles

Par défaut les repository roles sont créés :

  • Read : Recommandé pour les non-code contributors qui veulent voir ou discuter votre projet.
  • Triage : Recommandé pour les contributors who need to proactively manage issues and pull requests sans accès en écriture.
  • Write : Recommandé pour les contributors qui actively push to your project.
  • Maintain : Recommandé pour les project managers who need to manage the repository sans accès à des actions sensibles ou destructrices.
  • Admin : Recommandé pour les personnes qui ont full access to the project, y compris les actions sensibles et destructrices comme gérer la sécurité ou supprimer un repository.

Vous pouvez compare the 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 aussi create your own roles dans https://github.com/organizations/<org_name>/settings/roles

Teams

Vous pouvez list the teams created in an organization dans https://github.com/orgs/<org_name>/teams. Notez que pour voir les teams qui sont enfants d’autres teams, vous devez accéder à chaque parent team.

Users

Les users d’une organisation peuvent être listed dans https://github.com/orgs/<org_name>/people.

Dans les informations de chaque user, vous pouvez voir les teams the user is member of, et les repos the user has access to.

Github Authentication

GitHub propose différentes façons de s’authentifier sur votre compte et d’effectuer des actions en votre nom.

Web Access

En accédant à github.com vous pouvez vous connecter en utilisant votre username and password (et potentiellement un 2FA).

SSH Keys

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

GPG Keys

Vous cannot impersonate the user with these keys mais si vous ne les utilisez pas il peut être possible que vous get discover for sending commits without a signature. En savoir plus sur le vigilant mode ici.

Personal Access Tokens

Vous pouvez générer des personal access token pour donner à une application l’accès à votre compte. Lors de la création d’un personal access token, l’user doit specify les permissions que le token aura. https://github.com/settings/tokens

Oauth Applications

Les Oauth applications peuvent vous demander des permissions to access part of your github information or to impersonate you pour effectuer certaines actions. Un exemple courant de cette fonctionnalité est le bouton login with github que vous pouvez trouver sur certaines plateformes.

Quelques recommandations de sécurité :

  • Une OAuth App devrait toujours act as the authenticated GitHub user across all of GitHub (par exemple, pour fournir des notifications utilisateur) et n’avoir accès qu’aux scopes spécifiés.
  • Une OAuth App peut être utilisée comme fournisseur d’identité en activant un “Login with GitHub” pour l’utilisateur authentifié.
  • Don’t construire une OAuth App si vous voulez que votre application agisse sur un single repository. Avec le scope repo, les OAuth Apps peuvent act on _all_** of the authenticated user’s repositorie**s.
  • Don’t construire une OAuth App pour agir en tant qu’application pour votre team or company. Les OAuth Apps s’authentifient en tant que single user, donc si une personne crée une OAuth App pour que la société l’utilise, et qu’elle quitte la société, personne d’autre n’y aura accès.
  • More ici : https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps.

Github Applications

Les Github applications peuvent demander des permissions pour access your github information or impersonate you afin d’effectuer des actions spécifiques sur des ressources spécifiques. Dans les Github Apps, vous devez spécifier les repositories auxquels l’app aura accès.

Quelques recommandations de sécurité :

  • Un GitHub App devrait take actions independent of a user (sauf si l’app utilise un user-to-server token). Pour sécuriser davantage les access tokens user-to-server, vous pouvez utiliser des access tokens qui expirent après 8 heures, et un refresh token qui peut être échangé contre un nouvel access token. Pour plus d’informations, voir “Refreshing user-to-server access tokens”.
  • Assurez-vous que le GitHub App s’intègre avec specific repositories.
  • Le GitHub App devrait connect to a personal account or an organisation.
  • N’attendez pas du GitHub App qu’il sache et fasse tout ce qu’un user peut faire.
  • Don’t use a GitHub App if you just need a “Login with GitHub” service. Mais un GitHub App peut utiliser un user identification flow pour connecter les users and faire d’autres choses.
  • Ne créez pas un GitHub App si vous souhaitez only agir en tant qu’utilisateur GitHub et faire tout ce que cet utilisateur peut faire.
  • Si vous utilisez votre app avec GitHub Actions et que vous souhaitez modifier des fichiers de workflow, vous devez vous authentifier au nom de l’utilisateur avec un OAuth token qui inclut le scope workflow. L’utilisateur doit avoir la permission admin ou write sur le repository contenant le fichier workflow. Pour plus d’informations, voir “Understanding scopes for OAuth apps”.
  • More ici : https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps.

Github Actions

Ce n’est pas une méthode d’authentification dans github, mais une action malveillante via GitHub Action pourrait obtenir un unauthorised access to github et, depending des privileges donnés à l’Action, plusieurs different attacks pourraient être menées. Voir ci-dessous pour plus d’informations.

Git Actions

Git actions permettent d’automatiser l’exécution de code when an event happen. Habituellement le code exécuté est somehow related to the code of the repository (par exemple construire un container docker ou vérifier que le PR ne contient pas de secrets).

Configuration

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

Il est possible d’interdire complètement l’utilisation des github actions, allow all github actions, ou n’autoriser que certaines actions.

Il est aussi possible de configurer who needs approval to run a Github Action et les permissions of the GITHUB_TOKEN d’une Github Action lors de son exécution.

Git Secrets

Les Github Action ont généralement besoin de secrets pour interagir avec GitHub ou des applications tierces. Pour éviter de les mettre en clair dans le repo, GitHub permet de les stocker comme Secrets.

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

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 utilisant Bash 

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

Warning

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

Une fois configurés dans le repo ou dans les organizations, users of github ne pourront plus y accéder, ils pourront seulement les modifier.

Par conséquent, la seule façon de voler des secrets github est d’accéder à la machine qui exécute la Github Action (dans ce scénario vous ne pourrez accéder qu’aux secrets déclarés pour l’Action).

Git Environments

Github permet de créer des environments où vous pouvez stocker des secrets. Ensuite, vous pouvez donner à la github action l’accès aux secrets contenus dans l’environment avec quelque chose comme :

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

Vous pouvez configurer un environnement pour qu’il soit accessible par toutes les branches (par défaut), seulement les branches protégées ou spécifier quelles branches peuvent y accéder.
De plus, les protections d’environnement incluent :

  • Examinateurs requis : bloquent les jobs ciblant l’environnement jusqu’à approbation. Activez Prevent self-review pour appliquer un véritable principe des quatre‑yeux sur l’approbation elle‑même.
  • Branches et tags de déploiement : restreindre quelles branches/tags peuvent déployer vers l’environnement. Préférez sélectionner des branches/tags spécifiques et assurez‑vous que ces branches sont protégées. Remarque : l’option “Protected branches only” s’applique aux protections classiques de branches et peut ne pas se comporter comme prévu si vous utilisez des rulesets.
  • Temporisateur d’attente : retarder les déploiements pendant une période configurable.

Il est également possible de définir un nombre d’approbations requis avant d’exécuter une action utilisant un environment ou d’attendre un certain temps avant d’autoriser 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 dans une infrastructure tierce configurée par l’utilisateur.

Plusieurs organisations autorisent l’exécution des Github Actions dans une infrastructure tierce car cela a tendance à être moins cher.

Vous pouvez lister les runners self-hosted d’une organisation sur https://github.com/organizations/<org_name>/settings/actions/runners

La façon de trouver quelles Github Actions sont exécutées dans une infrastructure non‑github est de rechercher runs-on: self-hosted dans le YAML de configuration de la Github Action.

Il n’est pas possible d’exécuter une Github Action d’une organisation à l’intérieur d’une machine self-hosted d’une autre organisation parce qu’un token unique est généré pour le Runner lors de sa configuration pour indiquer à quelle organisation il appartient.

Si le Github Runner personnalisé est configuré sur une machine dans AWS ou GCP par exemple, l’Action pourrait avoir accès à l’endpoint metadata et voler le token du service account avec lequel la machine s’exécute.

Git Action Compromise

Si toutes les actions (ou une action malveillante) sont autorisées, un utilisateur pourrait utiliser une Github Action malveillante qui compromettrait le container où elle est exécutée.

Caution

Un run de Github Action malveillant pourrait être abusé par un attaquant pour :

  • Voler tous les secrets auxquels l’Action a accès
  • Se déplacer latéralement si l’Action est exécutée dans une infrastructure tierce où le token SA utilisé pour exécuter la machine est accessible (probablement via le service metadata)
  • Abuser du token utilisé par le workflow pour voler le code du repo où l’Action est exécutée ou même le modifier.

Branch Protections

Les branch protections sont conçues pour ne pas donner le contrôle complet d’un repository aux utilisateurs. L’objectif est de mettre en place plusieurs méthodes de protection avant de pouvoir écrire du code dans une branche.

Les branch protections d’un repository se trouvent sur https://github.com/<orgname>/<reponame>/settings/branches

Note

Il n’est pas possible de définir une branch protection au niveau de l’organisation. Elles doivent donc toutes être déclarées sur chaque repo.

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

  • Vous pouvez exiger une PR avant de merger (ainsi vous ne pouvez pas fusionner du code directement dans la branche). Si ceci est sélectionné, d’autres protections peuvent être en place :
  • Exiger un nombre d’approbations. Il est très courant d’exiger 1 ou 2 personnes supplémentaires pour approuver votre PR afin qu’un seul utilisateur ne puisse pas merger du code directement.
  • Annuler les approbations quand de nouveaux commits sont poussés. Sinon, un utilisateur peut approuver du code légitime puis ajouter du code malveillant et merger.
  • Exiger l’approbation du push revue le plus récent. Garantit que tout nouveau commit après une approbation (y compris les pushes par d’autres collaborateurs) déclenche une nouvelle revue afin qu’un attaquant ne puisse pas pousser des modifications post‑approbation et merger.
  • Exiger des revues des Code Owners. Au moins 1 code owner du repo doit approuver la PR (ainsi des utilisateurs “aléatoires” ne peuvent pas approuver).
  • Restreindre qui peut annuler les revues de pull request. Vous pouvez spécifier des personnes ou équipes autorisées à annuler les revues.
  • Autoriser certains acteurs à contourner les exigences de pull request. Ces utilisateurs pourront bypasser les restrictions précédentes.
  • Exiger que des checks de statut passent avant de merger. Certains checks doivent réussir avant de pouvoir merger le commit (comme une GitHub App rapportant des résultats SAST). Astuce : liez les checks requis à une GitHub App spécifique ; sinon n’importe quelle app pourrait usurper le check via la Checks API, et beaucoup de bots acceptent des directives de skip (ex. “@bot-name skip”).
  • Exiger la résolution des conversations avant de merger. Tous les commentaires sur le code doivent être résolus avant que la PR puisse être mergée.
  • Exiger des commits signés. Les commits doivent être signés.
  • Exiger un historique linéaire. Empêche les merge commits d’être poussés vers les branches correspondantes.
  • Inclure les administrateurs. Si cela n’est pas activé, les admins peuvent contourner les restrictions.
  • Restreindre qui peut pusher sur les branches correspondantes. Restreindre qui peut envoyer une PR.

Note

Comme vous pouvez le voir, même si vous parvenez à obtenir les identifiants d’un utilisateur, les repos peuvent être protégés et vous empêcher de pousser du code sur master par exemple pour compromettre le pipeline CI/CD.

Tag Protections

Les tags (comme latest, stable) sont mutables par défaut. Pour appliquer un flux à quatre‑yeux sur les mises à jour de tags, protégez les tags et chaînez les protections via les environments et les branches :

  1. Sur la règle de protection des tags, activez Require deployments to succeed et exigez un déploiement réussi vers un environment protégé (ex. prod).
  2. Dans l’environnement cible, restreignez Deployment branches and tags à la branche de release (ex. main) et configurez éventuellement Required reviewers avec Prevent self-review.
  3. Sur la branche de release, configurez les protections de branche pour Require a pull request, définissez approvals ≥ 1, et activez à la fois Dismiss approvals when new commits are pushed et Require approval of the most recent reviewable push.

Cette chaîne empêche un seul collaborateur de retagger ou de forcer la publication de releases en modifiant le YAML du workflow, puisque les gates de déploiement sont appliqués en dehors des workflows.

References

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks