CI/CD : GitHub décline son arsenal pour limiter les attaques de type « Pwn Request »

Une réponse directe à Shai-Hulud et Mini Shai-Hulud

Par exemple, le millier de paquets npm infectés par Shai-Hulud et Mini Shai-Hulud l’ont été à travers GitHub Actions. Les cyberattaquants ont exploité de mauvaises configurations de la plateforme CI/CD. Ce schéma identifié il y a cinq ans par l’équipe cyber de la filiale Microsoft, a été nommé Pwn Request.

Pour les attaquants, il s’agit de chercher des dépôts publics utilisant le déclencheur pull_request_target, puis de les forker. Ils y injectent du code malicieux puis soumettent une pull request au dépôt originel. Du fait des propriétés de l’événement, le flux de travail est considéré comme privilégié dans le système de GitHub.

Le problème, selon GitHub, venait d’un accès partagé en écriture au cache, basé sur la branche d’exécution du flux de travail. C’est le moyen d’enclencher l’escalade de privilège. Les attaquants accèdent aux permissions d’écriture, revoient les tags associés aux commits dans le dépôt, pour rediriger les consommateurs vers du code malveillant.

Là, les attaquants peuvent accéder aux secrets, aux jetons d’écriture (GITHUB_TOKEN) et à la zone d’exécution de confiance. Si l’attaque n’est pas détectée, ces dépendances vérolées peuvent affecter les dépôts Git d’entreprises.

Ces dépôts publics sont souvent utilisés pour héberger des projets open source ou des éléments servant plus largement de dépendances à l’échelle de l’écosystème logiciel. Les entreprises peuvent s’appuyer sur ces paquets pour actualiser leurs piles logicielles.

Pour contrer un tel schéma d’attaque, GitHub entend renforcer sa logique du moindre privilège.

GitHub a d’abord introduit un checkout pour bloquer l’utilisation de pull_request_target par un contributeur externe.

Le 2 décembre prochain, l’éditeur désactivera par défaut l’accès à pull_request_target pour tous les dépôts publics. Les administrateurs souhaitant utiliser cette fonctionnalité devront l’autoriser explicitement dans les options de GitHub Actions.

« Dans le cas où un cache aurait été empoisonné, les producteurs disposent désormais d’outils permettant aux workflows privilégiés de s’exécuter de manière bien plus sécurisée », ajoute Gregory Ose.

Le 10 septembre dernier, l’éditeur a donc dévoilé la disponibilité générale du mode cache. Celui-ci « fournit des autorisations au niveau des workflows et des tâches pour les workflows Actions, ainsi qu’une politique Actions permettant de déterminer précisément qui et quoi peut déclencher des flux de travail ».

L’accès au cache peut être en lecture, en écriture, en lecture seule ou totalement bloqué. Si les administrateurs accordent un accès en écriture à pull_request_target, la plateforme envoie un avertissement lors d’une requête. Autrement, les consommateurs non autorisés reçoivent une erreur.

Les rulesets permettent de définir les permissions à l’échelle du dépôt, de l’organisation ou de l’entreprise.

Verrouiller les fichiers de dépendance

Contre la substitution de tags, GitHub met en place les « lockfiles », disponible sous la forme d’extension à travers la CLI. Ces fichiers de verrouillage « enregistrent les dépendances que chaque flux de travail intégré utilise » et « vers quel commit chacune de ces références se résout ».

Il associe une clé SHA de commit à chaque action du flux de travail plutôt qu’à un tag.

Le système prend en compte les dépendances transitives (donc les actions utilisées par les actions), doit faciliter la relecture des fichiers de travail et enregistre l’identité du dépôt source.

« L’avantage des fichiers de verrouillage, c’est qu’ils garantissent la reproductibilité. Si j’exécute un workflow aujourd’hui, il utilisera les mêmes versions de ces actions demain, alors qu’auparavant, si l’on pointait vers une balise de version majeure, la version de cette action aurait pu avoir changé », affirme Steve Glass, responsable produit senior chez GitHub.

Les flux de travail réutilisables peuvent disposer de fichiers de verrouillage distinct, précise la documentation de GitHub, en association avec un SHA de commit complet.

Ces lockfiles sont idéalement mis à jour avec Dependabot, l’outil de gestion des correctifs et de la sécurité. Ils pourront également servir à protéger les flux de mise à jour des dépendances enclenchés par l’outil de machine learning.

Des changements cassants à anticiper (et difficiles à imposer)

Pour l’instant, les fichiers de verrouillage ne protègent que les consommateurs des actions, les entreprises donc. L’éditeur veut mettre en place des actions immuables pour mieux protéger les producteurs (les mainteneurs des dépendances), clarifier les messages d’erreur (échec, protection) liés aux lockfiles et découpler leur création de son outil CLI.

Enfin, en préversion technique, développe un pare-feu compatible avec les runners Linux, censé protégé les dépôts et leurs fichiers. Il s’agit d’éviter les exfiltrations de données en s’appuyant sur des politiques précises concernant les domaines et adresses IP autorisées, les méthodes HTTP permises et des configurations spécifiques du protocole TLS. « Notre objectif avec le pare-feu est de garantir que, lors de vos exécutions CI, Actions ne communique qu’avec les destinations approuvées avec lesquelles vous souhaitez que vos équipes travaillent. Et si une URL ou un domaine n’a pas été approuvé par votre équipe de sécurité, nous vous donnons les moyens de le faire vous-même », présente Steve Glass.

Tous ces dispositifs réclament des changements de taille en matière de gestion des pipelines CI/CD. D’où la recommandation des porte-parole de GitHub qui prêchent pour une adoption progressive de ces mesures par les mainteneurs des projets open source et par les entreprises. En d’autres termes, ce sont des changements cassants.

« Nous ne sommes pas certains que toutes les différentes politiques et protections d’exécution soient adaptées à vos dépôts et à vos workflows. Nous vous invitons donc à étudier attentivement ces politiques et à réfléchir à la manière dont vous pouvez, grâce à elles, réduire la surface d’attaque de vos automatisations CI/CD », souligne Gregory Ose.