Mozilla essaie de protéger ses référentiels sur GitHub contre les modifications malveillantes. Comme le récent incident Gentoo l'a montré, de telles attaques sont réelles.


Mozilla a initialement utilisé GitHub comme hébergement de sauvegarde. Comme Gentoo, les référentiels d'origine ont été stockés sur leur propre infrastructure. Bien que la plupart du code Firefox soit toujours distribué avec sa propre infrastructure, de nombreux projets n'existent que sur GitHub. Certains ne sont que des expériences, tandis que d'autres sont utilisés en production (par exemple, les comptes Firefox ). Ces référentiels «sensibles» doivent être protégés contre les modifications malveillantes, sans compliquer les commits pour les personnes normales.

Les étapes réelles sont décrites ici contre la distribution (ou le déploiement) de code à partir d'un référentiel compromis. Nous partageons l'expérience et certains outils d' audit. Une telle protection n'interfère presque pas avec les flux de travail normaux dans GitHub.

Nous considérons ici le risque de pirater un compte GitHub à travers les mécanismes uniques de ce site. Comme le cas Gentoo et d'autres incidents l'ont montré, en cas de piratage, tout le code auquel l'utilisateur a accès est compromis.

L'essence du problème

GitHub est un excellent écosystème avec de nombreuses extensions ou «applications» pour simplifier des workflows spécifiques. Les applications reçoivent l'autorisation de l'utilisateur d'effectuer des actions en son nom. Ils peuvent demander des autorisations, y compris la modification ou l'ajout de comptes supplémentaires. GitHub affiche clairement ces demandes: l'utilisateur doit les approuver via l'interface web, mais tout le monde n'est pas au courant des conséquences. Beaucoup ne comprennent pas que l'autorisation d'accéder à un référentiel personnel donne le même accès à n'importe quel référentiel sur GitHub au nom de l'utilisateur.

Les autorisations excessives mettent en danger les référentiels avec des informations confidentielles, tandis que l'administrateur du référentiel ne voit rien. La meilleure chose qu'il puisse faire est de remarquer un commit malveillant après coup. Ni GitHub ni Git ne peuvent être configurés pour empêcher ou marquer ce type de commit malveillant. Surveillance externe uniquement.

Implémentation

Les recommandations suivantes sont tirées de notre système de sécurité , seules les fonctionnalités spécifiques de Mozilla ont été supprimées pour cet article. Dans la mesure du possible, nous empruntons les meilleures pratiques d'Internet, utilisons les fonctions de GitHub et essayons de ne pas trop compliquer la vie des développeurs.

Recommandations aux organisations

• 2FA obligatoire pour tous les employés.
• Pour tous ou au moins les utilisateurs avec des autorisations plus élevées:
  
  • Fournissez un contact (e-mail, messagerie instantanée) à l'organisation ou à l'administrateur (GitHub vous permet de masquer les informations de contact pour la confidentialité).
  • Assurez-vous d'informer l'organisation ou l'administrateur de la compromission possible de votre compte (par exemple, en cas de vol d'un ordinateur portable).

Lignes directrices pour les référentiels

• Les référentiels importants ne doivent être hébergés que dans une organisation qui suit les recommandations ci-dessus.
• Définissez et configurez les branches de production:
  
  • Ban forcé de pousser.
  • Autorisation de valider uniquement pour un petit nombre d'utilisateurs.
  • Appliquez également ces restrictions aux administrateurs et propriétaires.
  • Signez toutes les validations avec des clés GPG précédemment connues.

Recommandations de workflow

• Les déploiements, versions et autres événements dignes d'un audit doivent être notés avec une balise signée avec une clé GPG précédemment connue.
• Tous les déploiements et versions doivent être émis uniquement après un audit de toutes les validations et balises signées pour les clés correctes.

La mise en œuvre de ces mesures de protection entraîne certains coûts, notamment en lien avec la signature des engagements. Nous avons développé des outils pour l'audit des configurations et prévoyons de publier des outils pour l'audit des commits. Tous sont dans notre référentiel .



Voici un exemple d'audit. Tout d'abord, nous obtenons une copie locale des données pour l'organisation octo_org , puis un rapport est compilé pour chaque référentiel:

 $ ./get_branch_protections.py octo_org 2018-07-06 13:52:40,584 INFO: Running as ms_octo_cat 2018-07-06 13:52:40,854 INFO: Gathering branch protection data. (calls remaining 4992). 2018-07-06 13:52:41,117 INFO: Starting on org octo_org. (calls remaining 4992). 2018-07-06 13:52:59,116 INFO: Finished gathering branch protection data (calls remaining 4947). 

Maintenant, avec des données mises en cache localement, vous pouvez générer des rapports. Par exemple, un rapport montre la conformité avec les recommandations ci-dessus:

 $ ./report_branch_status.py --header octo_org.db.json name,protected,restricted,enforcement,signed,team_used octo_org/react-starter,True,False,False,False,False octo_org/node-starter,False,False,False,False,False 

Comme vous pouvez le voir, seul octo_org/react-starter comprenait une protection contre les poussées forcées sur la branche de production. Le résultat est au format CSV à insérer facilement dans une feuille de calcul.

Comment pouvez-vous aider

Nous mettons toujours en œuvre ces recommandations et apprenons en cours de route. Si vous pensez que nos recommandations de sécurité de référentiel vous conviennent, contribuez à simplifier la mise en œuvre. Partagez votre expérience sur la page des conseils ou ouvrez un ticket dans le référentiel GitHub-Audit .