Après des années passées à essayer d’éduquer les développeurs à utiliser pull_request_target en toute sécurité, la plateforme implémente enfin des valeurs par défaut plus strictes.
Piqué par une recrudescence des cyberattaques qui se sont déchaînées dans les environnements de développement, GitHub a renforcé la sécurité pour bloquer les attaques « pwn request » qui exploitent une utilisation non sécurisée du déclencheur de workflow pour exécuter le code d’un attaquant avec tous les privilèges du workflow.
Annoncée le 18 juin, la v7 bloque et fait désormais échouer automatiquement les flux de travail lorsqu’ils sont utilisés à l’intérieur ou des événements lors d’une tentative de récupération de code de demande d’extraction de fork non révisé.
À partir de maintenant, la seule solution pour ces contrôles sera pour les développeurs de mettre en œuvre une option de désinscription en ajoutant un élément explicite à , a déclaré GitHub dans son journal des modifications V7.
Ce changement marque le début d’une nouvelle ère de « sécurité par défaut » dans laquelle la sécurité sera définie par le système GitHub plutôt que d’être laissée à la discrétion des développeurs. Dans le cadre de cet effort, le 16 juillet, les nouvelles valeurs par défaut seront rétroportées sur toutes les versions majeures prises en charge.
« Les flux de travail épinglés sur une balise majeure flottante (par exemple, actions/checkout@v4) prendront automatiquement en compte la modification. Les flux de travail épinglés sur une version SHA, mineure ou de correctif spécifique ne sont pas affectés par le rétroportage et devront être mis à niveau à l’aide de Dependabot ou via des processus de mise à niveau établis », a expliqué GitHub.
Cependant, étant donné que les attaques par requête pwn peuvent se produire d’autres manières, « un renforcement supplémentaire des événements supplémentaires pourrait être exploré dans les versions futures », ajoute le journal des modifications.
Angle mort
S’il y a une critique qui peut être adressée à GitHub à ce sujet, c’est qu’il a fallu beaucoup de temps pour remédier à une faiblesse connue depuis des années.
Le problème vient de GitHub Actions, qui permet aux déclencheurs d’exécuter des flux de travail, y compris ceux qui traitent des forks tiers sans donner accès à des secrets tels que des clés API, des jetons de service et des informations d’identification. L’inconvénient est que cette restriction empêche certaines automatisations de fonctionner, c’est pourquoi les développeurs se tournent vers un déclencheur alternatif, qui accorde l’accès requis.
À un moment donné, les attaquants ont réalisé que là où il était configuré négligemment pour extraire du code fork non fiable, il offrait une porte dérobée vers les référentiels et leurs secrets.
En d’autres termes, la faiblesse ne réside pas dans le déclencheur lui-même, qui est légitime et sûr lorsqu’il est utilisé correctement, mais dans son utilisation incorrecte. Comme le dit le journal des modifications de GitHub : « L’extraction du début d’une demande d’extraction non examinée à partir d’un fork à l’intérieur de l’un de ces workflows permet généralement au code contrôlé par un attaquant de s’exécuter avec tous les privilèges du workflow. »
L’arrivée de la v7 devrait cependant rendre cela plus difficile, bloquant automatiquement les workflows à risque quelle que soit leur configuration.
Malheureusement, de nombreux dégâts ont déjà été causés. Les référentiels open source ont récemment fait l’objet d’attaques soutenues de la part du groupe de piratage TeamPCP, utilisant diverses techniques, notamment les requêtes pwn.
Un exemple notable est son attaque du mois dernier, qui a compromis 170 packages de gestionnaires de packages de nœuds (npm), y compris l’écosystème TanStack Router, grâce à un exploit de requête pwn. Malheureusement, lors d’un autre incident n’impliquant pas de requête pwn, GitHub lui-même a été piraté et les attaquants ont exfiltré le code source d’environ 3 800 référentiels internes de l’entreprise.
Mieux vaut tard que jamais, GitHub est passé à l’action, préparant une série de réformes de sécurité sur la plate-forme, notamment, plus tôt ce mois-ci, en limitant l’exécution automatique des scripts d’installation dans npm.
