Github Security
Qu'est-ce que Github
(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.
Informations de base
pageBasic Github InformationReconnaissance 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.
Si vous connaissez l'utilisateur, le dépôt ou l'organisation que vous souhaitez cibler, vous pouvez utiliser des dorks Github pour trouver des informations sensibles ou rechercher des fuites d'informations sensibles sur chaque dépôt.
Dorks Github
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 à proximité d'informations sensibles, vous pouvez facilement rechercher des informations sensibles potentielles dans votre cible.
Outils (chaque outil contient sa liste de dorks) :
Fuites Github
Veuillez noter que les dorks Github sont également destinés à rechercher des fuites en utilisant les options de recherche de Github. Cette section est dédiée à ces outils qui vont télécharger chaque dépôt et rechercher des informations sensibles en leur sein (même en vérifiant une certaine profondeur de commits).
Outils (chaque outil contient sa liste de regexes) :
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 pull requests. Pour savoir si un dépôt est vulnérable, vous devez principalement lire les configurations yaml des actions Github. Plus d'informations à ce sujet ci-dessous.
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.
Permissions de base : Les membres auront la permission Aucune/Lecture/Écriture/Administration sur les dépôts de l'organisation. Il est recommandé de choisir Aucune ou Lecture.
Fork de dépôt : S'il 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 : S'il 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 aux intégrations : Avec cette option activée, 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 s'il ne l'est pas, il est préférable de le désactiver.
Je n'ai pas trouvé cette information dans la réponse des APIs, partagez-la si vous la trouvez
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 information dans la réponse des APIs, partagez-la si vous la trouvez
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 information dans la réponse des APIs, partagez-la si vous la trouvez
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 de le laisser désactivé.
Je n'ai pas trouvé cette information dans la réponse des APIs, partagez-la si vous la trouvez
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.
Notez que toutes ces configurations peuvent également être définies pour 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 autoriser l'exécution de toutes les actions.
Flux de travail des pull requests de fork des collaborateurs externes : Il est recommandé de exiger l'approbation pour tous les collaborateurs externes.
Je n'ai pas trouvé d'API avec cette information, partagez-la si vous la trouvez
Exécuter des workflows à partir des pull requests de fork : Il est fortement déconseillé d'exécuter des workflows à partir des pull requests 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 information, partagez-la si vous la trouvez
Permissions du workflow : Il est fortement recommandé de accorder uniquement des permissions de lecture sur le dépôt. Il est déconseillé de donner des permissions d'écriture et de création/approbation de pull requests pour éviter les abus du GITHUB_TOKEN donné pour l'exécution des workflows.
Intégrations
Faites-moi savoir si vous connaissez le point de terminaison de l'API pour accéder à ces informations !
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é d'autoriser uniquement celles nécessaires (après les avoir examinées).
Reconnaissance & Attaques exploitant des identifiants
Pour ce scénario, supposons que vous avez obtenu un certain accès à un compte GitHub.
Avec les identifiants de l'utilisateur
Si vous avez d'une manière ou d'une autre déjà les identifiants d'un utilisateur au sein d'une organisation, vous pouvez simplement vous connecter et vérifier quels sont les rôles d'entreprise et d'organisation que vous avez, si vous êtes un membre brut, vérifiez quels sont les permissions des membres bruts, 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 l'authentification à deux facteurs (2FA) peut être utilisée, 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.
Consultez la section ci-dessous sur les contournements de protections de branche 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 changements 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 auxquels 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 sur https://github.com/<github_username>.keys, vous pourriez 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. Toute personne ayant accès à cette clé pourra lancer des projets à partir d'un dépôt. Habituellement, sur un serveur avec différentes clés de déploiement, le fichier local ~/.ssh/config vous donnera des informations sur la clé concernée.
Clés GPG
Comme expliqué ici parfois il est nécessaire de signer les commits ou vous pourriez être découvert.
Vérifiez localement si l'utilisateur actuel a une clé avec :
Avec un jeton utilisateur
Pour une introduction sur les jetons utilisateur, consultez les informations de base.
Un jeton utilisateur peut être utilisé à la place d'un mot de passe pour Git via HTTPS, ou peut être utilisé pour s'authentifier à l'API via l'authentification de base. En fonction des privilèges qui lui sont attachés, vous pourriez être en mesure d'effectuer différentes actions.
Un jeton utilisateur ressemble à ceci : ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Avec une application Oauth
Pour une introduction sur les applications Github Oauth, 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 étendues qu'une application Oauth peut demander. Il est toujours recommandé de vérifier les étendues demandées avant de les accepter.
De plus, comme expliqué dans les informations de base, les organisations peuvent accorder/refuser l'accès aux applications tierces aux informations/dépôts/actions liés à l'organisation.
Avec une application Github
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 accorder/refuser l'accès aux applications tierces aux informations/dépôts/actions liés à l'organisation.
Compromission et Abus de l'Action Github
Il existe plusieurs techniques pour compromettre et abuser d'une Action Github, consultez-les ici :
pageAbusing Github ActionsContournement de la Protection de Branche
Exiger un certain nombre d'approbations : Si vous avez compromis plusieurs comptes, vous pourriez simplement accepter vos PR à partir d'autres comptes. Si vous avez seulement 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 Github Action à l'intérieur du dépôt, en utilisant le GITHUB_TOKEN, vous pourriez être en mesure d'approuver votre PR et obtenir une approbation de cette manière.
Notez que pour cela et pour la restriction des propriétaires de code, généralement un utilisateur ne pourra pas approuver ses propres PR, mais si vous le pouvez, vous pouvez en abuser pour accepter vos PR.
Ignorer 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é, y ajouter du code malveillant et le fusionner dans la branche protégée.
Exiger des révisions 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 l'approuve 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é, sa protection des propriétaires de code n'est pas appliquée.
Autoriser des acteurs spécifiés à contourner les exigences de pull request : Si vous êtes l'un de ces acteurs, vous pouvez contourner les protections des pull requests.
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.
Contournement des protections de push : Si un dépôt ne permet qu'à certains utilisateurs d'envoyer des push (fusionner du code) dans les branches (la protection de la branche pourrait protéger toutes les branches en spécifiant le joker
*).Si vous avez 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 la branche, vous pouvez quand même créer une nouvelle branche et à l'intérieur créer une action Github déclenchée lorsque du code est poussé. Comme la protection de la branche ne protégera pas la branche tant qu'elle n'est pas créée, ce premier push de code vers la branche exécutera l'action Github.
Contournement des Protections d'Environnements
Pour une introduction sur l'environnement Github, consultez les informations de base.
Dans le cas où un environnement peut être accédé 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 la modifiant).
Notez que vous pourriez rencontrer le cas particulier où toutes les branches sont protégées (via le joker *) et il est spécifié qui peut pousser du code dans les branches (vous pouvez le spécifier dans la protection de la branche) et que votre utilisateur n'est pas autorisé. Vous pouvez quand même exécuter une action Github personnalisée car vous pouvez créer une branche et utiliser le déclencheur de push sur celle-ci. La protection de la branche autorise le push 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.
Persistance
Générer un jeton utilisateur
Voler les jetons Github depuis les secrets
Supprimer les résultats et les branches du flux de travail
Accorder 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 secrete
Commit d'usurpation - Porte dérobée via les commits du dépôt
Sur Github, il est possible de créer une PR vers un dépôt à partir d'un fork. Même si la PR n'est pas acceptée, un identifiant de commit à l'intérieur du dépôt d'origine sera créé pour la version fork du code. Par conséquent, un attaquant pourrait choisir d'utiliser un commit spécifique d'un dépôt apparemment légitime qui n'a pas été créé par le propriétaire du dépôt.
Comme ici:
Pour plus d'informations, consultez https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd
Dernière mise à jour