Protégez vos identifiants dans vos projets open source

Au début du mois, un chercheur nommé ChALkeR a partagé ses recherches sur les identifiants divulgués dans des packages npm. Ses conclusions montrent que des identifiants, comme des jetons npm et GitHub ou des mots de passe, sont souvent inclus dans des packages npm publiés ou des dépôts GitHub. En fait, 13 des 15 principaux packages npm dépendent de packages ayant divulgué des identifiants, exposant ainsi leurs utilisateurs.

L’article de ChALKeR est intéressant et constitue la première analyse des identifiants divulgués propre à npm dont j’aie connaissance, mais le problème n’est pas nouveau. La recherche GitHub permettait déjà de trouver des clés privées il y a près de trois ans (révélant, selon certaines sources, des clés de l’équipe Chrome), et Google peut exposer toutes sortes d’informations privées. À mesure que le code devient plus facile à découvrir, ce type d’erreur est plus facile à repérer, ce qui est une raison de plus d’agir.

Pour respecter les bonnes pratiques de sécurité, téléchargez le mémo de Snyk présentant 10 bonnes pratiques de sécurité pour npm. Vous y découvrirez comment adopter des pratiques d’utilisation sécurisée de npm, utiles aux développeurs Node.js et JavaScript.

Pourquoi vous préoccuper des identifiants divulgués ?

Une fuite d’identifiants revient à exposer des secrets donnant accès à différents comptes.

Les identifiants qui fuient le plus souvent sont les mots de passe, les clés API et les clés privées SSH. Ces clés peuvent suffire à un outil automatisé, qu’il vous appartienne ou qu’il soit utilisé par un attaquant, pour effectuer une action, comme publier une nouvelle version d’un package ou supprimer du code. Les actions autorisées varient selon la clé et le système.

Si vous utilisez des packages open source, les identifiants qui doivent le plus vous inquiéter sont ceux qui permettent de publier du nouveau code, comme un jeton npm ou une clé de déploiement GitHub. Un attaquant qui y a accès peut facilement publier une nouvelle version « correctrice » contenant du code malveillant, que vous installerez souvent sans le savoir.

Si vous hébergez votre projet open source quelque part, veillez également à ne pas divulguer d’informations sur vos systèmes d’exécution. Cela ne concerne pas seulement npm : vous pourriez exposer vos clés AWS, vos clés privées SSH ou les mots de passe de différents systèmes. N’importe laquelle de ces clés peut donner aux attaquants accès à votre système, qu’ils pourront exploiter pour voler votre propriété intellectuelle et les données de vos utilisateurs, ou simplement profiter gratuitement de vos ressources de calcul (et vous laisser la facture).

Que faire en tant que développeur open source ?

Au-delà de rester conscient des risques, adoptez quelques bonnes pratiques dans votre workflow et mettez en place plusieurs niveaux de défense pour éviter les erreurs. Voici quelques mesures à envisager :

Évitez les commandes génériques git add *

Les jokers peuvent facilement inclure des fichiers locaux que vous ne souhaitez pas partager. C’est particulièrement important lorsque vous ajoutez des sous-dossiers entiers (par ex. git add dirname), car les fichiers masqués (dot) seront également inclus.

Au lieu d’utiliser des jokers, indiquez le nom de chaque fichier à valider, ou utilisez git add -p pour examiner chaque modification que vous ajoutez.

Indiquez les fichiers sensibles dans .gitignore et .npmignore

Git et npm prennent tous deux en charge un fichier local qui répertorie les exclusions des packages et des commits. Vous pouvez vous en servir pour éviter d’inclure accidentellement des fichiers sensibles. Si vous ne précisez pas les exclusions, npm ignore quand même certains fichiers, mais Git les inclut tous. Quelles que soient les exclusions par défaut, aucun de ces outils ne connaît votre application aussi bien que vous : il est donc préférable de modifier vous-même ces fichiers.

Voici quelques exemples de fichiers auxquels prêter attention :

• Fichiers de configuration CI (par ex. .travis.yml, circle.yml)

• Dockerfile et docker-compose.yml

• Fichiers de sortie de compilation (par ex. gypi)

• Scripts de déploiement personnalisés (par ex. tout fichier dans /deploy/ ou /scripts/).

ChALKeR présente quelques autres exemples dans son article. Vous pouvez également vous inspirer des fichiers .gitignore d’exemple de GitHub.

Notez que les règles d’exclusion par défaut plus étendues de npm n’ont été introduites qu’avec npm@2.14.1 : veillez donc à utiliser cette version ou une version ultérieure.

Chiffrez vos jetons ou utilisez des variables d’environnement pour publier depuis une CI

Si vous publiez sur npm via votre CI, celle-ci doit avoir accès à votre jeton npm. Il est facile de l’ajouter par inadvertance aux fichiers de configuration de la CI et de l’exposer.

Dans la mesure du possible, stockez plutôt ce jeton dans une variable d’environnement : il ne sera pas enregistré dans le contrôle de version et sa valeur sera masquée dans la sortie (au moins sur Travis et Circle). Si vous devez absolument inclure une clé dans votre contrôle de version (par exemple, si vous voulez renvoyer du contenu dans GitHub), veillez à bien la chiffrer.

git-secrets : un hook Git qui empêche de valider des identifiants

Michael Dowling, des AWS Labs, a récemment publié un outil pratique appelé git-secrets. Cet outil s’exécute lors de git commit et interrompt le commit s’il contient des modèles correspondant à des identifiants. Cette protection axée sur le contenu est une bonne mesure de sécurité complémentaire à la protection par nom de fichier mentionnée précédemment.

Il est important de noter que vous devez détecter ces éléments avant de valider vos modifications (ou plutôt, avant de les pousser), comme le fait cet outil. Pour les projets open source, effectuer des tests dans le cadre de la CI ou du processus de pull request ne suffit pas : il est déjà trop tard, les identifiants ont fuité.

Révoquez les identifiants divulgués

Enfin, si vous découvrez que vous avez déjà divulgué une clé ou un mot de passe, veillez à révoquer rapidement les jetons concernés.

Supprimer le jeton de la dernière version ou branche ne suffit pas. Même si vous effacez les références de l’historique, des copies de votre clé continueront d’exister, même après leur suppression de GitHub et npm : Internet n’oublie jamais. Pensez également à vérifier si quelqu’un a utilisé la clé entre-temps pour publier du code malveillant ou accéder à vos systèmes.

Que faire en tant qu’utilisateur de packages open source ?

En tant qu’utilisateur de packages open source, vous ne pouvez pas faire grand-chose. En utilisant un package, vous lui accordez explicitement votre confiance et faites implicitement confiance à ses dépendances. Les failles de sécurité de ces dépendances peuvent compromettre vos propres systèmes, qu’il s’agisse d’identifiants divulgués ou de vulnérabilités (vous pouvez utiliser Snyk pour corriger ces dernières). Selon ChALKeR, les identifiants qu’il a découverts ont depuis été révoqués par GitHub et npm, respectivement. Des identifiants révoqués ne présentent plus de risque de sécurité, à condition qu’ils n’aient pas été exploités entre-temps.

Cela dit, si vous souhaitez prendre les devants, vous pouvez auditer vos dépendances et vérifier si elles partagent des informations qui, selon vous, ne devraient pas l’être. Quelques commandes bash peuvent vous aider à repérer les fichiers cachés pertinents dans vos dépendances. Vous pourrez ensuite déterminer s’ils contiennent des informations privées.

Voici une commande bash pour Mac/Linux qui vous aidera à démarrer. Elle repère certains de ces fichiers, supprime les doublons et les affiche avec leur nom de fichier :

find . \( -name '*.gypi' -o -name '.npmrc' -o -name '.travis.yml' \) | xargs md5 -r | sort | awk '{print $2" "$1}' | uniq -f1 | sort | awk '{print "echo "$1";cat "$1}'

En résumé

Développer en open source, c’est formidable, mais tout n’a pas vocation à être partagé. La divulgation d’identifiants met en danger vos utilisateurs et, par ricochet, les leurs.

Séparez vos identifiants de votre code et sensibilisez toutes les personnes concernées à ce risque. Recherchez les fuites lors des revues de code et intégrez cette vérification à vos pratiques habituelles. Au-delà des processus, mettez en place les filets de sécurité décrits ci-dessus pour détecter les erreurs humaines. Enfin, si vous découvrez une fuite, gérez-la correctement : révoquez les jetons, prévenez vos utilisateurs et inspectez votre code à la recherche de traces malveillantes.