Confronté à une recrudescence des cyberattaques qui sévissent dans les environnements de développement, GitHub monte d'un cran sa sécurité. En l'occurrence celle de son action de vérification de dépôt de code (actions/checkout) pour bloquer les attaques de type pwn request. Celles-ci exploitent une utilisation non sécurisée du déclencheur de workflow pull_request_target laissant les pirates exécuter du code malveillant avec l’ensemble des privilèges. Ce type de déclencheur est effectué dans des cas nécessitant une interaction dans laquelle des informations sensibles sont concernées. Annoncée récemment, la v7 d’actions/checkout permettant d'extraire un dépôt de code de fork dans l'exécuteur du workflow, refusera par défaut les schémas de requêtes d'intrusion courants. Désormais, le seul moyen pour les développeurs de contourner ces contrôles sera ainsi de mettre en place une option de désactivation en ajoutant explicitement la directive allow-unsafe-pr-checkout à actions/checkout, a expliqué Github dans son billet de blog.

Ce changement marque le début d’une nouvelle ère de « sécurité par défaut », dans laquelle la protection sera définie au niveau de l'administration Github plutôt que laissée à la discrétion des développeurs. Dans le cadre de cette initiative, les paramètres par défaut seront intégrés le 16 juillet à toutes les versions majeures prises en charge. « Les workflows épinglés par exemple à actions/checkout@v4 intégreront automatiquement cette modification. Les workflows épinglés à un SHA (secure hash algorithm), une version mineure ou une version de correctif spécifiques ne sont pas concernés et devront être mis à jour à l’aide de Dependabot ou via les processus de mise à jour établis », fait savoir GitHub. Toutefois, comme les attaques de type pwn request peuvent se produire par d’autres moyens, un renforcement supplémentaire de la sécurité pour d’autres événements pourrait être envisagé dans les prochaines versions, peut-on lire dans le billet de la plateforme de partage de code.

Un effet collatéral au blocage des attaques

Si l’on peut reprocher quelque chose à GitHub à ce sujet, c’est d’avoir mis autant de temps à remédier à une faille connue depuis des années. Le problème concerne Actions, qui permet à des trigger d’exécuter des workflows, notamment « pull_request », qui traite les forks tiers sans donner accès à des informations confidentielles telles que les clés API, les jetons de service et les identifiants. L’inconvénient est que cette restriction empêche certaines automatisations de fonctionner, ce qui explique pourquoi les développeurs se tournent vers un déclencheur alternatif, pull_request_target, qui accorde l’accès requis. A un moment donné, des attaquants ont compris que lorsque pull_request_target était configuré de manière imprudente avec actions/checkout pour récupérer du code de fork non fiable, cela offrait une porte dérobée vers les dépôts et leurs secrets. En d’autres termes, la vulnérabilité de pull_request_target ne réside pas dans le déclencheur lui-même - qui est légitime et sécurisé lorsqu’il est utilisé correctement -, mais dans son utilisation incorrecte. Comme l’indique le journal des modifications de GitHub : « Extraire un pull request non révisé à partir d’un fork au sein de l’un de ces workflows permet généralement à du code contrôlé par un attaquant de s’exécuter avec tous les privilèges liés au workflow. »

L'arrivée d'actions/checkout v7 devrait toutefois rendre cela plus difficile, en bloquant automatiquement les workflows à risque, quelle que soit leur configuration. Malheureusement, le mal est déjà fait. Les dépôts open source ont récemment fait l'objet d'attaques soutenues de la part du groupe de cybercriminels TeamPCP, qui a utilisé diverses techniques, notamment des requêtes pwn. Un exemple notable est l’attaque menée le mois dernier, qui a compromis 170 paquets du gestionnaire de paquets Node (npm), dont l’écosystème TanStack Router, grâce à une faille d’exploitation de type pwn request. Fait embarrassant, lors d’un autre incident n’impliquant pas de pwn request, GitHub lui-même a été piraté et les attaquants ont exfiltré le code source d’environ 3 800 dépôts internes de l’entreprise. Mieux vaut tard que jamais : GitHub s’est mobilisé et a mis en place une série de mesures de sécurité sur la plateforme, notamment, au début du mois, la limitation de l’exécution automatique des scripts d’installation dans npm.