Fuites de secrets : un pas vers la véritésaster

Donner les clés de votre maison à des criminels n’est certainement pas la meilleure idée. Mais c’est ce qui se produit souvent dans la plupart des organisations développant des logiciels modernes.

Dans ce premier article sur les fuites de secrets, nous analyserons pourquoi cela se produit si souvent, quelles en sont les conséquences et quelles actions prendre pour prévenir ou atténuer le problème et gérer les incidents de fuite de secrets.

OH MON DIEU! J'ai poussé mes clés d'accès au cloud vers un dépôt public

Secrets codés en dur dans le code source ou les fichiers de configuration des outils DevOps peuvent finir entre de mauvaises mains. Si le secret est commitplacé dans un référentiel de sources publiques, vous êtes certainement condamné. Mais même les référentiels privés ne sont pas sûrs, car des secrets sont également divulgués via les fichiers binaires des applications, les journaux ou le code source volé.

Rétrospectivement, c'est inquiétant combien de fois un simple oubli a conduit à une grave faille de sécurité. Il suffit de chercher sur Google "Fuites de clés AWS","Fuites du jeton d'accès GitHub", et ainsi de suite. Ne considérez pas ces exemples comme des recommandations cachées pour tel ou tel fournisseur. Utilise le tien !

Par exemple, le (in)célèbre Attaque Codecov d'avril 2021 a été possible car l'image Codecov Docker contenait des informations d'identification git qui permettaient à un attaquant d'accéder aux référentiels git privés de Codecov et d'ajouter une seule ligne dans le script de téléchargement bash de Codecov pour les variables d'environnement de collection et les URL du référentiel git.

Rappelez-vous qu’une partie de la richesse des attaques réside dans les secrets permettant d’accéder à des systèmes supplémentaires, et que de nombreuses attaques investissent massivement dans l’exfiltration d’informations d’identification, de clés cryptographiques et de jetons. 

Le problème est que les secrets codés en dur sont monnaie courante. En mars 2022, le Lapsus$ APT fuite de 189 Go du code source de Samsung et d'autres fichiers sensibles. L'analyse a révélé qu'il contenait des 6,600 XNUMX secrets codés en dur: 90% pour les systèmes internes, mais 10% pour les services et outils externes comme GitHub, AWS ou Google. Ces secrets comprenaient des clés API AWS/Twilio/Google, des chaînes de connexion à la base de données et d'autres informations sensibles. Il s'agit de l'état de l'art dans la plupart des bases de code.

Les fuites de secrets constituent le moyen le plus simple d’attaquer la chaîne d’approvisionnement

Les dépendances aux packages sont actuellement la cible la plus fréquente, bien qu'elle ne soit pas l'unique cible des attaques sur la chaîne d'approvisionnement. Les méchants pourraient créer un nouveau package qui finirait par être installé dans le logiciel des victimes (en utilisant le typosquattage et d'autres techniques), mais ils tentent généralement d'infecter un package existant soit en ajoutant des modifications au code source dans les référentiels de logiciels (SCM) comme GitHub, GitLab ou BitBucket, ou en ajoutant des versions malveillantes aux registres publics comme NPM, PyPI, RubyGems, Maven Central.

Mais l'injection de code malveillant ou d'une dépendance malveillante cachée dans un graphe de dépendances complexe nécessite login informations d'identification telles que nom d'utilisateur/mot de passe, jetons ou clés d'accès (appelons-les « »clés" pour faire court), pour le référentiel source cible ou le registre public, respectivement. 

Les méchants obtiennent parfois les clés via ingénierie socialeL’ attaque contre le event-stream Le package NPM populaire fournit un bon exemple. Mais à la recherche d'une fuite login les informations d’identification ou les clés d’accès constituent la technique d’attaque la plus fréquente pour les attaques de la chaîne d’approvisionnement logicielle.

Les référentiels sources et les registres de packages sont deux systèmes essentiels dans la construction de logiciels pipeline. Mais il existe de nombreux outils dans DevOps : CI/CD Systèmes, outils de tests, automatisation de la configuration et du provisionnement, ou encore déploiement et publication. Tous ces outils peuvent être détournés pour injecter du code malveillant dans les logiciels. La fuite de clés valides pour ces outils mène directement à la misère et à l'angoisse. Imaginez la fuite de clés d'accès root avec un contrôle total sur vos ressources de cloud public…

Les recommandations habituelles

Nous n'annonçons rien de nouveau ici, vous le savez tous. Mais agissez ! N'oubliez pas que des robots analysent régulièrement l'ensemble du public. SCM Dépôts. Quelques recommandations, sans ordre particulier.

• Si vous avez une responsabilité dans la gestion de la sécurité informatique, définir comment les secrets doivent être traités dans la politique de sécurité. Mais les politiques ne sont efficaces que si elles sont appliquées : assurez-vous qu'une directive sur la gestion des secrets est appliquée dans votre organisation, y compris non seulement par vos équipes DevOps mais également par vos fournisseurs de logiciels, et que le plan de réponse aux incidents de votre organisation contient des dispositions pour les incidents de fuite de secrets.
• Mettre en œuvre et appliquer authentification multi-facteurs (MFA, 2FA ou quel que soit l’acronyme). Et pas de compromis en matière de sécurité : une clé de sécurité USB vaut les quelques dollars qu'elle coûte. Vous devez pousser n'importe laquelle de vos milliers d'informations d'identification (facile), puis vous enivrer et laisser vos clés dans un bar avec quelque chose qui vous relie (les chances sont juste un peu plus petites, surtout si vous êtes abstinent).
• Utilisez un gestionnaire de mots de passe avec un mot de passe fort et non enregistré. Pour gérer les secrets dans l'utilisation des systèmes Coffres secrets. CI/CD systèmes, fournisseurs de cloud, SCMs et d'autres outils DevOps fournissent ce service, mais vous pouvez opter pour une solution Secret Vault générique.
• Préférez de courte durée jetons aux clés d’accès de longue durée. Ils sont plus faciles à révoquer et exposent une fenêtre plus limitée au mal.
• Limiter la réutilisation des identifiants: les attaquants réutiliseront les informations d'identification récoltées pour une cible dans d'autres systèmes, un autre argument pour l'utilisation d'un gestionnaire de mots de passe. Les gestionnaires de mots de passe et les coffres-forts secrets devraient faire de la réutilisation des informations d’identification une chose du passé.
• Limiter et surveiller l’utilisation de admin mots de passe. Ils sont suffisamment puissants pour mériter un suivi spécial.
• Mettre en œuvre le hachage et cryptage forts. Retour aux clés USB (cryptographiques), aux procédures strictes de transmission des informations d'identification avec les partenaires et collègues, etc.
• Utiliser un scanner de secrets, par exemple exécuté dans un pre-commit crochet pour éviter les fuites dans les systèmes de contrôle de version, comme barrière de sécurité. Avant la chose est important ici. Alternativement, utilisez des analyses post-hoc pour détecter les secrets divulgués, par exemple comme vérification avant pull request fusionne. Remarque : Notre plateforme Xygeni comprend un scanner de secrets permettant les deux modes de fonctionnement. 
• L'alternative manuelle consistant à utiliser revues de code rechercher des secrets codés en dur entraîne des coûts plus élevés et fonctionne aprèscommit (mais j'espère au moins avant que le secret ne soit accessible aux étrangers). Mais les examens peuvent détecter des secrets non conventionnels qui pourraient échapper aux scanners de secrets.       
• Éviter accidentellement committing fichiers communs avec des secrets pour le contrôle de version avec approprié exclure les modèles (comme le modèle `gitignore`), en prenant en compte des fichiers comme .env, .npmrc, .pypirc, fichiers temporaires… Une couche supplémentaire dans l’oignon de sécurité en effet.
• Et le dernier de cette longue liste : laissez les fournisseurs de cloud effectuer des analyses pour détecter les fuites de leurs clés, lorsqu'elles sont disponibles. Au moins, ceci Mai vous informer de la fuite quand elle s'est produite, mais la sécurité est un must pour les fournisseurs de cloud. Ce post-hoc L'analyse secrète n'est pas très transparente quant à l'endroit et à la fréquence d'exécution de l'analyse, et nécessite souvent une configuration explicite, mais elle constitue certainement la dernière ressource lorsque tout le reste échoue.

OH MON DIEU! J'ai poussé mes clés d'accès au cloud vers un dépôt public, prenez le n°2

Cela pourrait arriver aux meilleurs d’entre nous. Retrousser vos manches !

Renouveler / révoquer / désactiver immédiatement le secret divulgué ! Si le compte dispose d’une MFA décente, le risque est beaucoup plus faible. Cela pourrait être plus difficile, par exemple, avec les clés privées des sites Web (vous devez émettre un nouveau certificat pour une nouvelle clé privée et révoquer celle existante), mais les outils modernes disposent d'un moyen rapide de renouveler les informations d'identification ou de révoquer les jetons. 

Suivez les étapes recommandées par le fournisseur lorsqu'elles sont disponibles, comme AWS dans cet exemple.

Identifiez la cause de la fuite. Savoir comment cela s’est produit est essentiel pour les activités de divulgation, d’analyse, de confinement et de enseignements tirés.

Signalez ensuite la fuite aux parties concernées, en expliquant les mesures que vous prenez pour colmater la fuite et réduire les dégâts. Il n’y a aucun moyen de réparer les dégâts causés, ce qui a été divulgué est une fuite. Soyez transparent et informez les autres afin qu’ils puissent agir. 

Commencez ensuite par le forensicsL’ fenêtre d'exposition est le temps entre la fuite et le moment où le secret n'était pas valide. Soyez prêt à lire les journaux et à suivre les activités inhabituelles avec le compte concerné pendant cette fenêtre. Supprimez les comptes et les clés générés à l'aide du compte concerné. Rappelez-vous que si le compte concerné dispose de privilèges d'administrateur, la correction est beaucoup plus complexe. 

Réécriture (contrôle de version) de l'historique est complexe. Même les États totalitaires tentent cela en vain (jeu de mots). Et probablement sans importance : les pirates ou les robots des pensions publiques pourraient avoir cloné le dépôt ou avoir déjà extrait l'or, en particulier si la fenêtre d'exposition est suffisamment grande. 

Si vous êtes aventureux et que vous voulez voir par vous-même combien de temps il faut aux robots pour détecter une fuite de secret, des fils de déclenchement comme Jetons Canaries laissez-vous expérimenter. N'oubliez pas que les robots mettent sur liste noire les valeurs par défaut canarytokens.org domaine…

Pour en savoir plusKovacs, E. “Des milliers de clés secrètes trouvées dans une fuite de code source Samsung« . Semaine de la sécurité, mars 2022. Dyjak, A. «Il y a quelques jours, j'ai mené une petite expérience WRT Secrets commitenvoyé aux référentiels git publics…« . Fil de discussion, novembre 2020.Rzepa, P. "Fuite des clés d'accès AWS dans le référentiel GitHub et quelques améliorations dans Amazon Reaction« . Moyen, novembre 2020.