Une erreur de configuration dans le service de création de code d'AWS aurait pu compromettre un nombre considérable de référentiels de code GitHub et d'applications clés d'AWS, selon des chercheurs de Wiz qui ont découvert le problème. La vulnérabilité provenait d'une faille subtile dans la manière dont était déclenché les pipelines d'intégration continue (CI) de CodeBuild. « Il suffisait de deux caractères manquants dans un filtre regex pour donner à des attaquants non authentifiés la possibilité d'infiltrer l'environnement de build et de divulguer des informations d'identification privilégiées », ont déclaré les experts dans un blog. Le filtre regex (expression régulière) au cœur du problème est une règle de correspondance de motifs automatisée qui analyse les logs sortants à la recherche de secrets et les masque pour éviter toute fuite.

Ce problème aurait pu déboucher sur la prise de contrôle totale des principaux référentiels GitHub d'AWS, en particulier JavaScript SDK, une bibliothèque centrale qui alimente la console du fournisseur cloud. « Cela montre la puissance et le risque des vulnérabilités de la supply chain », a déclaré Yuval Avrahami, coauteur du rapport sur le bug, à CSO, « c'est exactement la raison pour laquelle ce type d'attaques est en augmentation : une petite faille peut conduire à une attaque aux conséquences désastreuses. »

Aucun impact signalé par AWS

Pour rassurer les clients, AWS a déclaré à CSO qu'il « n'avait constaté aucun impact sur la confidentialité ou l'intégrité des environnements clients ou des services ». Il a également conseillé aux développeurs de suivre les meilleures pratiques lors de l'utilisation de CodeBuild. Mais les chercheurs de Wiz ont averti les codeurs utilisant le produit de prendre des mesures pour protéger leurs projets contre des problèmes similaires. La société de sécurité a découvert le problème en août dernier après une tentative d'attaque sur l'extension Amazon Q VS Code. Un pirate a exploité un projet CodeBuild mal configuré pour compromettre le référentiel GitHub de l'extension et injecter du code malveillant dans la branche principale. Ce code a ensuite été inclus dans une version téléchargée par les utilisateurs. Bien que la charge utile du pirate ait finalement échoué en raison d'une faute de frappe, elle s'est exécutée sur les machines des utilisateurs finaux, démontrant clairement le risque lié aux pipelines CodeBuild mal configurés.

Les chercheurs de Wiz ont enquêté et ont découvert le cœur du problème, un contournement de l'identifiant de l'acteur malveillant dû à des expressions régulières non ancrées, et en ont informé AWS. En moins de 48 heures, cette faille a été comblée, a déclaré le groupe dans un communiqué. La société a également renforcé la sécurité, notamment en ajoutant des protections supplémentaires à tous les processus de compilation contenant des tokens Github ou tout autre identifiant en mémoire. Elle a aussi déclaré avoir également audité tous les autres environnements de compilation publics afin de s'assurer qu'aucun incident de ce type n'existait dans l'ensemble de ses ressources open source. Tout comme les logs de tous les référentiels de compilation publics, ainsi que les journaux CloudTrail associés. Elle a ainsi pu déterminer « qu'aucun autre acteur n'avait tiré parti du problème d'expressions régulières non ancrées mis en évidence par l'équipe de recherche de Wiz. »

Des environnements de développement à protéger

Kellman Meghu, directeur technique chez Deepcove Cybersecurity, une société canadienne spécialisée dans la gestion des risques, a déclaré que cela ne poserait pas de problème majeur pour les développeurs qui n'exposent pas publiquement CodeBuild. Mais il a ajouté : « si les gens ne font pas preuve de diligence, je vois comment cela pourrait être utilisé. C'est astucieux. » Et de rappeler que les entreprises doivent veiller à ce que les développeurs n'exposent pas les environnements de développement, a déclaré M. Meghu. « L'utilisation de services hébergés publics tels que GitHub n'est pas appropriée pour la gestion et le déploiement de codes d'entreprise », a-t-il ajouté.

« Disposer d'un service GitLab/GitHub privé, voire de votre propre serveur de dépôt git, devrait être la norme pour les entreprises, rendant cette attaque impossible si [les acteurs malveillants] ne peuvent pas voir le dépôt dès le départ. C'est l'entreprise qui doit être propriétaire du référentiel ; [il ne doit] pas s'agir d'un élément que vous laissez simplement vos développeurs configurer selon leurs besoins. » En fait, a-t-il déclaré, ce sont les responsables informatiques ou de la sécurité de l'information qui devraient configurer les référentiels de code. Les développeurs « devraient être des utilisateurs du système, et non ses propriétaires ultimes ». Wiz recommande vivement à tous les utilisateurs de CodeBuild de mettre en œuvre les mesures de protection suivantes afin de protéger leurs propres projets contre d'éventuelles compromissions.