Github Security
Last updated
Last updated
Apprenez et pratiquez le Hacking AWS :HackTricks Formation AWS Red Team Expert (ARTE) Apprenez et pratiquez le Hacking GCP : HackTricks Formation GCP Red Team Expert (GRTE)
(De ici) À 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.
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 des github dorks pour trouver des informations sensibles ou rechercher des fuites d'informations sensibles dans chaque dépôt.
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) :
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 des commits).
Outils (chaque outil contient sa liste de regex) :
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 !
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.
Même si supprimé ou interne, il pourrait être possible d'obtenir des données sensibles à partir de forks de dépôts github. Vérifiez ici :
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.
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 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 à 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é.
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.
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.
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 jetons 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.
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).
Pour ce scénario, nous allons supposer que vous avez obtenu un accès à un compte github.
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 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 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 au cas où cela serait utile.
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 certains 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 :
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 des 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é.
Comme expliqué ici, 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 :
Pour une introduction sur les jetons utilisateur, consultez les informations de base.
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. 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
Pour une introduction sur les applications Oauth de Github, consultez les informations de base.
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. 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.
Pour une introduction sur les applications Github, consultez les informations de base.
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.
Il existe plusieurs techniques pour compromettre et abuser d'une action Github, consultez-les ici :
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 obtenir 1 approbation de cette manière.
Note 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 configuré, 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 configuré 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.
Pour une introduction sur l'environnement Github, consultez les informations de base.
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 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.
Générer un jeton utilisateur
Voler des jetons 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 une action Github avec une porte dérobée
Trouver une action Github vulnérable à l'injection de commandes via la modification de la valeur secrète
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 celui-ci:
Pour plus d'informations, consultez https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-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)
