maciek905 - stock.adobe.com

Recrudescence d’attaques d’ingénierie sociale contre des projets Open Source

À la suite de la récente alerte concernant XZ Utils, les responsables d’un autre projet open source se sont manifestés pour dire qu’ils avaient peut-être été victimes d’attaques similaires d’ingénierie sociale.

L’Open Source Security Foundation (OpenSSF) et l’OpenJS Foundation, qui soutiennent de nombreux projets Open Source basés sur JavaScript, ont averti que la tentative d’ingénierie sociale observée plus tôt en avril 2024 contre la bibliothèque de compression de données XZ Utils pourrait ne pas être un incident isolé.

Dans le cadre de l’attaque XZ Utils, un acteur connu sous le nom de JiaTan s’est infiltré dans le projet XZ Utils sur une période de plusieurs années, gagnant la confiance des responsables du projet et apportant des mises à jour légitimes au logiciel avant d’essayer d’introduire en douce une vulnérabilité de porte dérobée, CVE-2024-3094, qui aurait pu causer un carnage sans l’intervention rapide d’un chercheur à l’œil aiguisé.

Aujourd’hui, l’OpenSSF et l’OpenJS appellent tous les contributeurs principaux à être vigilants face à des tentatives de prise de contrôle similaires, après que le conseil du projet OpenJS Cross a reçu plusieurs courriels suspects demandant une mise à jour d’un de ses projets pour remédier à des pseudos vulnérabilités critiques sans citer de détails spécifiques.

Robin Bender Ginn, directeur exécutif de la Fondation OpenJS, et Omkhar Arasaratnam, directeur général de l’OpenSSF, ont déclaré que les auteurs des courriels, qui portaient des noms différents, mais provenaient de comptes associés à GitHub se chevauchant, voulaient être désignés comme mainteneurs du projet malgré leur faible implication préalable, de la même manière que JiaTan a pu se faufiler dans le projet XZ Utils.

Ils ont ajouté que l’équipe d’OpenJS a également pris connaissance d’un schéma similaire dans deux autres projets JavaScript largement utilisés, qu’elle n’héberge pas elle-même, et a signalé le risque de sécurité potentiel aux responsables respectifs d’OpenJS, ainsi qu’aux autorités américaines chargées de la cybersécurité.

« Aucune de ces personnes n’a reçu d’accès privilégié au projet hébergé par OpenJS », ont écrit Bender Ginn et Arasaratnam dans un billet de blog commun décrivant l’attaque, mais au ton rassurant. « Le projet a mis en place des politiques de sécurité, y compris celles définies par le groupe de travail sur la sécurité de la Fondation. »

« Les projets open source accueillent toujours les contributions de n’importe qui, n’importe où, mais accorder à quelqu’un un accès administratif au code source en tant que responsable nécessite un niveau plus élevé de confiance méritée, et ce n’est pas donné comme une “solution rapide” à n’importe quel problème », ont-ils déclaré. « En collaboration avec la Fondation Linux, nous souhaitons sensibiliser tous les responsables de projets open source à cette menace permanente et leur proposer des conseils pratiques et des ressources provenant de notre vaste communauté d’experts en sécurité et en open source. »

Ce qu’il faut savoir

Les membres des projets OSS doivent notamment être attentifs à la recherche amicale, mais agressive et persistante, du statut de contributeur principal par tout nouveau membre ou membre relativement inconnu de la communauté, aux nouvelles demandes d’élévation et à l’approbation d’autres membres inconnus de la communauté, qui peuvent potentiellement être des comptes « sockpuppet ».

Les membres doivent également être attentifs à un certain nombre d’indices :

  • aux pull requests (PR) qui contiennent des blobs en tant qu’artefacts (la porte dérobée XZ était un fichier illisible par l’homme, et non du code source) ;
  • au code source intentionnellement obscurci ou difficile à comprendre ;
  • aux problèmes de sécurité qui semblent s’aggraver lentement (l’attaque XZ a commencé par un amendement de test relativement inoffensif) ;
  • aux écarts par rapport aux procédures de compilation, de construction et de déploiement typiques du projet ;
  • et à un faux sentiment d’urgence, en particulier si quelqu’un semble essayer de convaincre un responsable de contourner un contrôle ou d’accélérer une révision.

« Ces attaques d’ingénierie sociale exploitent le sens du devoir des mainteneurs vis-à-vis de leur projet et de leur communauté afin de les manipuler », expliquent Bender Ginn et Arasaratnam. « Prêtez attention à votre perception des interactions. Les interactions qui provoquent un doute, un sentiment d’inadéquation, de ne pas en faire assez pour le projet, etc. peuvent faire partie d’une attaque d’ingénierie sociale ».

Les attaques par ingénierie sociale peuvent être difficiles à détecter et il est difficile de se protéger par des moyens programmatiques, car elles s’appuient sur les émotions humaines et la confiance. À court terme, il est donc également important de partager autant d’informations que possible sur d’éventuelles activités suspectes, sans honte ni jugement, afin que les membres de la communauté puissent apprendre à mettre en place des stratégies de protection.

Chris Hughes, responsable de la sécurité chez Endor Labs et chercheur en cyberinnovation à la Cybersecurity and Infrastructure Security Agency (CISA), explique de son côté ne pas être surpris d’entendre que les attaques d’ingénierie sociale sont plus répandues contre le monde de l’open source. En outre, étant donné la publicité autour de l’attaque XZ, il est probable que d’autres acteurs malveillants tenteront des tactiques similaires à l’avenir.

« La plupart des projets open source sont incroyablement sous-financés et gérés par un seul individu ou un petit groupe de mainteneurs. Il n’est donc pas surprenant qu’ils fassent l’objet d’attaques par ingénierie sociale. »
Chris HughesResponsable de la sécurité, Endor Labs et chercheur en cyberinnovation à la CISA

« Nous pouvons soupçonner que nombre d’entre elles sont déjà en cours et qu’elles ont peut-être déjà réussi, mais qu’elles n’ont pas encore été révélées ou identifiées », affirme Chris Hughes. « La plupart des projets open source sont incroyablement sous-financés et gérés par un seul individu ou un petit groupe de mainteneurs. Il n’est donc pas surprenant qu’ils fassent l’objet d’attaques par ingénierie sociale et, compte tenu de la vulnérabilité de l’écosystème et des pressions que subissent les mainteneurs, il est probable qu’ils accueilleront volontiers l’aide dans de nombreux cas. »

Si les attaquants s’y prennent bien, il peut être difficile pour les responsables de la maintenance de déterminer si l’implication provient de personnes réellement désireuses de collaborer et de contribuer à des projets ou de personnes ayant des intentions malveillantes.

Plus généralement, avertit Chris Hughes, cela pose un risque important pour la communauté Open Source en général, puisqu’environ un quart de tous les projets n’ont qu’un seul responsable et 94 % en ont moins de 10. Ils sont souvent en quête de soutien et prompts à accepter de l’aide. Ce risque se répercute ensuite sur les organisations plus vastes, mais qui utilisent de nombreux composants open source dans leurs propres logiciels.

Pour Chris Hughes, « cela permet de prendre conscience du problème plus large de l’opacité de l’écosystème des logiciels open source (…) Les composants et les projets qui font fonctionner l’ensemble de l’infrastructure IT sont souvent maintenus par des alias inconnus et des individus dispersés dans le monde entier. En outre, de nombreux projets open source sont donc gérés par une seule personne ou un petit groupe de personnes, souvent pendant leur temps libre, dans le cadre d’un passe-temps ou d’un projet de passionnés, et généralement sans aucune forme de rémunération. »

L’écosystème est donc particulièrement vulnérable aux acteurs malveillants qui s’appuient sur ces réalités et profitent de mainteneurs attentifs, mais débordés par une communauté qui exige d’eux des mises à jour rapides, « sans se préoccuper de fournir une compensation réelle en échange de leur travail acharné et de leur engagement à maintenir un code dont le monde dépend », déplore pour conclure Chris Hughes.

Pour approfondir sur Open Source

Close