Basic Github Information
Last updated
Last updated
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)
La structure de base de l'environnement github d'une grande entreprise est de posséder une entreprise qui possède 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 pas d'entreprises.
Du point de vue d'un 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 d'entreprise, d'organisation et de dépôt.
De plus, un utilisateur peut être membre de différentes équipes avec différents rôles d'entreprise, d'organisation ou de dépôt.
Et enfin, les dépôts peuvent avoir des mécanismes de protection spéciaux.
Propriétaire d'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, elles ne peuvent pas accéder aux paramètres ou au contenu de l'organisation à moins qu'elles ne soient désignées comme propriétaires d'organisation ou qu'on leur donne un accès direct à un dépôt appartenant à l'organisation.
Membres d'entreprise : Les membres des organisations appartenant à votre entreprise sont également automatiquement membres de l'entreprise.
Dans une organisation, les utilisateurs peuvent avoir différents rôles :
Propriétaires d'organisation : Les propriétaires d'organisation ont un accès administratif complet à votre organisation. Ce rôle doit être limité, mais à pas moins de deux personnes, dans votre organisation.
Membres d'organisation : Le rôle par défaut, non administratif pour les personnes dans une organisation est le 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 d'organisation peuvent attribuer à n'importe quelle équipe dans une organisation. Lorsqu'il est appliqué, il donne à chaque membre de l'équipe des permissions pour gérer les alertes de sécurité et les paramètres dans votre organisation, ainsi que des permissions de lecture pour tous les dépôts de l'organisation.
Si votre organisation a une équipe de sécurité, vous pouvez utiliser le rôle de gestionnaire de sécurité pour donner aux membres de l'équipe le minimum d'accès dont ils ont besoin à l'organisation.
Gestionnaires d'applications Github : Pour permettre à des utilisateurs supplémentaires de gérer les applications GitHub appartenant à une organisation, un propriétaire peut leur accorder des permissions de gestionnaire d'applications GitHub.
Collaborateurs externes : Un collaborateur externe est une personne qui a accès à un ou plusieurs dépôts de l'organisation mais 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
Dans https://github.com/organizations/<org_name>/settings/member_privileges vous pouvez voir les permissions que les utilisateurs auront juste pour faire 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 le fork des dépôts est possible.
S'il est possible d'inviter des collaborateurs externes.
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.
Par défaut, les rôles de dépôt sont créés :
Lecture : Recommandé pour les contributeurs non-code qui souhaitent voir ou discuter de votre projet.
Triage : Recommandé pour les contributeurs qui doivent gérer proactivement les problèmes et les demandes de tirage sans accès en écriture.
Écriture : Recommandé pour les contributeurs qui poussent activement vers votre projet.
Maintenir : Recommandé pour les chefs de projet qui doivent gérer le dépôt sans accès à des actions sensibles ou destructrices.
Administrateur : Recommandé pour les personnes qui ont besoin d'un accès complet au projet, y compris des 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
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 des enfants d'autres équipes, vous devez accéder à chaque équipe parente.
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.
Github offre différentes manières de s'authentifier à votre compte et d'effectuer des actions en votre nom.
En accédant à github.com, vous pouvez vous connecter en utilisant votre nom d'utilisateur et mot de passe (et un 2FA potentiellement).
Vous pouvez configurer votre compte avec une ou plusieurs clés publiques permettant à la clé privée associée d'effectuer des actions en votre nom. https://github.com/settings/keys
Vous ne pouvez pas usurper l'identité de l'utilisateur avec ces clés, mais si vous ne l'utilisez pas, il pourrait être possible que vous soyez découvert pour avoir envoyé des commits sans signature. En savoir plus sur le mode vigilant ici.
Vous pouvez générer un jeton d'accès personnel pour donner à une application 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
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 pourriez trouver sur certaines plateformes.
Vous pouvez créer vos propres applications Oauth dans https://github.com/settings/developers
Vous pouvez voir toutes les applications Oauth qui ont accès à votre compte dans https://github.com/settings/applications
Vous pouvez voir les scopes que les applications Oauth peuvent demander dans https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Vous pouvez voir l'accès des applications tierces dans une organisation dans https://github.com/organizations/<org_name>/settings/oauth_application_policy
Quelques recommandations de sécurité :
Une application OAuth doit toujours agir en tant qu'utilisateur GitHub authentifié sur tout GitHub (par exemple, lors de la fourniture de notifications utilisateur) et avec 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 construisez pas une application OAuth si vous souhaitez que votre application agisse sur un dépôt unique. Avec le scope repo, les applications OAuth peuvent agir sur tous les dépôts de l'utilisateur authentifié.
Ne construisez pas une application OAuth pour agir comme une application pour votre équipe ou entreprise. Les applications OAuth s'authentifient en tant qu'utilisateur unique, donc si une personne crée une application OAuth pour une entreprise à utiliser, et qu'elle quitte ensuite l'entreprise, personne d'autre n'y aura accès.
Plus ici ici.
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 dans https://github.com/settings/apps
Vous pouvez voir toutes les applications Github qui ont accès à votre compte dans https://github.com/settings/apps/authorizations
Voici les points de terminaison API pour les applications Github https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. En fonction des permissions de l'application, elle pourra accéder à certains d'entre eux.
Vous pouvez voir les applications installées dans une organisation dans 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 utilisateur-à-serveur). Pour garder les jetons d'accès utilisateur-à-serveur plus sécurisés, 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 utilisateur-à-serveur."
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.
Ne pas utiliser une application GitHub si vous avez juste besoin d'un service "Login with GitHub". Mais une application GitHub peut utiliser un flux d'identification utilisateur pour connecter les utilisateurs et faire d'autres choses.
Ne construisez pas une application GitHub si vous voulez seulement agir en tant qu'utilisateur GitHub et faire tout ce que cet 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 contenant le fichier de workflow. Pour plus d'informations, voir "Comprendre les scopes pour les applications OAuth."
Plus ici ici.
Ce n'est pas un moyen de s'authentifier dans 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.
Les actions Git permettent d'automatiser l'exécution de code lorsqu'un événement se produit. En général, 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).
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 simplement d'autoriser certaines actions.
Il est également possible de configurer qui a besoin d'approbation pour exécuter une Action Github et les permissions du GITHUB_TOKEN d'une Action Github lorsqu'elle est exécutée.
Les Actions Github ont généralement besoin d'un certain type de secrets pour interagir avec github ou des applications tierces. Pour éviter de les mettre en texte 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 :
Les secrets ne peuvent être accessibles que depuis les Github Actions 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 ne pourront que les modifier.
Par conséquent, la seule façon de voler les secrets github est de pouvoir accéder à la machine qui exécute l'Action Github (dans ce scénario, vous ne pourrez accéder qu'aux secrets déclarés pour l'Action).
Github permet de créer des environnements où vous pouvez enregistrer des secrets. Ensuite, vous pouvez donner à l'action github l'accès aux secrets à l'intérieur de l'environnement avec quelque chose comme :
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'examens requis avant d'exécuter une action utilisant un environnement ou attendre un certain temps avant de permettre aux déploiements de se poursuivre.
Une action Github peut être exécutée dans l'environnement github ou peut être exécutée dans une infrastructure tierce configurée par l'utilisateur.
Plusieurs organisations permettront d'exécuter des actions Github dans une infrastructure tierce car cela a tendance à être moins cher.
Vous pouvez lister les runners auto-hébergés d'une organisation à https://github.com/organizations/<org_name>/settings/actions/runners
La façon de trouver quelles actions Github sont exécutées dans une infrastructure non-github est de rechercher runs-on: self-hosted dans la configuration yaml de l'action Github.
Il est impossible d'exécuter une action Github 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 de 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.
Si toutes les actions (ou une action malveillante) sont autorisées, un utilisateur pourrait utiliser une action Github qui est malveillante et qui compromettra le conteneur où elle est exécutée.
Une action Github malveillante exécutée pourrait être abusée par l'attaquant pour :
Voler 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 exécuter la machine peut être accessible (probablement via le service de métadonnées)
Abuser du jeton utilisé par le workflow pour voler le code du repo où l'action est exécutée ou même le modifier.
Les protections des branches sont conçues pour ne pas donner un contrôle complet d'un dépôt aux utilisateurs. L'objectif est de mettre en place plusieurs méthodes de protection avant de pouvoir écrire du code dans une certaine branche.
Les protections des branches d'un dépôt peuvent être trouvées à https://github.com/<orgname>/<reponame>/settings/branches
Il est impossible de définir une protection de branche au niveau de l'organisation. Donc, toutes doivent être déclarées sur chaque dépôt.
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 du code sur la branche). Si cela est sélectionné, d'autres protections peuvent être en place :
Exiger un nombre d'approbations. Il est très courant d'exiger que 1 ou 2 autres personnes approuvent votre PR afin qu'un seul utilisateur ne puisse pas fusionner directement du code.
Rejeter les approbations lorsque de nouveaux commits sont poussés. Sinon, un utilisateur peut approuver du code légitime et ensuite l'utilisateur pourrait ajouter du code malveillant et le fusionner.
Exiger des examens de la part des propriétaires de code. Au moins 1 propriétaire de code du dépôt doit approuver la PR (de sorte que des utilisateurs "aléatoires" ne puissent pas l'approuver)
Restreindre qui peut rejeter les examens des demandes de tirage. Vous pouvez spécifier des personnes ou des équipes autorisées à rejeter les examens des demandes de tirage.
Autoriser des acteurs spécifiés à contourner les exigences des demandes de tirage. Ces utilisateurs pourront contourner les restrictions précédentes.
Exiger que les vérifications de statut réussissent avant de fusionner. Certaines vérifications 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 une histoire linéaire. Empêcher les commits de fusion d'être poussés vers des branches correspondantes.
Inclure les administrateurs. Si cela n'est pas défini, les administrateurs peuvent contourner les restrictions.
Restreindre qui peut pousser vers des branches correspondantes. Restreindre qui peut envoyer une PR.
Comme vous pouvez le voir, même si vous parvenez à obtenir des identifiants d'un utilisateur, les dépôts peuvent être protégés vous empêchant de pousser du code sur master par exemple pour compromettre le pipeline CI/CD.
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)
