Alerte sur les prises de contrôle de projets open source via ingénierie sociale

OpenJS et OpenSSF émettent une alerte sur le risque d'attaques d'ingénierie sociale visant les projets open source

• La récente tentative de porte dérobée XZ Utils (CVE-2024-3094) n'est peut-être pas un incident isolé.
• La Fondation OpenJS ayant bloqué une tentative similaire de prise de contrôle reposant sur la confiance suggère qu'il ne s'agit peut-être pas d'un cas isolé.
• OpenSSF et la Fondation OpenJS exhortent tous les mainteneurs open source à se méfier des tentatives de prise de contrôle par ingénierie sociale, à repérer les signes précoces de menaces et à mettre en place des mesures pour protéger les projets open source.

Tentative de prise de contrôle échouée

• Le Cross Project Council de la Fondation OpenJS a reçu une série d'e-mails suspects avec des messages similaires.
• L'émetteur des e-mails insistait pour qu'OpenJS prenne des mesures afin de mettre à jour l'un des projets JavaScript populaires afin de « résoudre des vulnérabilités importantes », sans préciser les détails.
• Bien que l'émetteur n'ait pratiquement jamais touché au code auparavant, il demandait d'être nommé nouveau mainteneur du projet.
• Cette méthode est très proche de la manière dont Jia Tan s'est positionné dans la backdoor XZ/liblzma.
• Aucun accès n'a été accordé à ces personnes sur les projets hébergés par OpenJS.
• Le projet dispose d'une politique de sécurité comprenant, entre autres, un aperçu général présenté par le groupe de travail sécurité de la fondation.
• L'équipe OpenJS a également repéré des schémas suspects similaires dans deux autres projets JavaScript populaires non hébergés par la fondation, puis a immédiatement signalé les risques potentiels à chaque responsable OpenJS concerné et à la CISA (Cybersecurity and Infrastructure Security Agency), agence du DHS (Department of Homeland Security), aux États-Unis.

Signaux d'une prise de contrôle par ingénierie sociale suspectée

• Signaux :

  • Un membre de la communauté relativement peu connu qui contacte de manière amicale mais agressive et persistante un mainteneur ou un hébergeur (fondation ou entreprise).
  • Une demande pour promouvoir une personne nouvelle ou inconnue au rôle de mainteneur.
  • Le soutien d'autres membres de la communauté, eux aussi peu connus, qui pourraient utiliser de fausses identités (les « sock puppets »).
  • Des PR incluant des blobs comme artefacts.
  • Du code source volontairement obfusqué ou difficile à comprendre.
  • Un problème de sécurité de plus en plus grave.
  • La possibilité d'insérer des charges utiles malveillantes externes dans des blobs, des archives ZIP ou d'autres artefacts binaires, hors des pratiques habituelles de compilation, build et distribution du projet.
  • Cela se produit tout particulièrement lorsque le mainteneur est poussé, sous pression, à réduire la profondeur de revue ou à contourner les contrôles.

• Ces attaques d'ingénierie sociale tirent parti du sens du devoir des responsables envers le projet et la communauté pour les manipuler.

• Soyez attentif à l'impression laissée par les interactions.

  • Les interactions qui provoquent du doute sur soi, un malaise ou le sentiment de ne pas contribuer suffisamment au projet peuvent être partie d'une attaque d'ingénierie sociale.

• Les attaques d'ingénierie sociale observées dans XZ/liblzma ont été prévenues avec succès par la communauté OpenJS.

• Parce que ce type d'attaque exploite une violation de confiance via l'ingénierie sociale, il est difficile de le détecter ou de s'en défendre de manière programmatique.

• À court terme, partager de façon claire et transparente des activités suspectes comme celles décrites ci-dessus aidera les autres communautés à rester vigilantes.

• Le soutien solide aux mainteneurs est la mesure dissuasive la plus importante contre ce type de prises de contrôle par ingénierie sociale.

Mesures pour la sécurité des projets open source

• Envisagez de suivre des pratiques de sécurité de référence de l'industrie, telles que le guide OpenSSF.
• Utilisez une authentification forte : 2FA, gestionnaire de mots de passe, stockage sûr des codes de récupération, et ne réutilisez pas les mots de passe/identifiants sur des services différents.
• Élaborez une politique de sécurité incluant le processus de "Coordinated disclosure".
• Appliquez les meilleures pratiques lors de la fusion de nouveau code :
  • Activez la protection de branche et les commits signés.
  • Dans la mesure du possible, demandez qu'un second développeur révise le code avant fusion, même si la PR provient d'un mainteneur.
  • Exigez des critères de lisibilité pour éviter que les nouvelles PR soient obfusquées et minimisez l'usage d'artefacts binaires opaques.
  • Limitez les personnes habilitées à publier sur npm.
  • Identifiez et révisez périodiquement les committers et mainteneurs. Par exemple, les avez-vous déjà vus en réunion de groupe de travail ou rencontrés lors d'événements ?
• Si vous exploitez un dépôt de paquets open source, envisagez d'adopter les principes de Package Repository Security.
• Consultez les ressources de la CISA pour éviter les attaques d'ingénierie sociale et de phishing et/ou le document de l'ENISA sur ce qu'est l'ingénierie sociale.

Actions de l'industrie et des pouvoirs publics pour la sécurité des infrastructures open source essentielles

• La pression pour maintenir des projets open source stables et sécurisés met une pression sur les mainteneurs.
• Des ressources à grande échelle seront nécessaires grâce à la coopération internationale entre secteur privé et secteur public.
• De nombreuses organisations, dont les Open Source Foundations, le Sovereign Tech Fund, conduisent déjà un excellent travail.
• Pour offrir un filet de sécurité aux projets open source, il faut des efforts d'organisations comparables aux fondations de la famille Linux.
• Il est encourageant que le gouvernement allemand investisse dans des infrastructures open source critiques par l'initiative Sovereign Tech Fund.
• En soutenant davantage d'investissements publics mondiaux, nous pouvons renforcer des initiatives de type Sovereign Tech Fund comme celle de l'Allemagne.

Le point de vue de GN⁺

• Les attaquants exploitent habilement le sens du devoir des mainteneurs pour perturber les développeurs. Il faut donc aussi prêter attention aux changements émotionnels que les mainteneurs peuvent ressentir à l'égard du projet.
• Je conviens qu'il faut accroître les investissements pour la sécurité, mais, au fond, la culture de développement doit changer pour prioriser la sécurité ; la sécurité doit s'infiltrer naturellement dans l'ensemble du processus de développement.
• Puisque les attaquants exploitent la confiance de la communauté, les projets open source doivent également mener des efforts continus pour renforcer la confiance entre membres. Se rencontrer en face à face peut constituer un bon départ.
• Des projets investissant réellement dans l'amélioration des vulnérabilités, comme le projet Alpha-Omega, devraient être davantage créés et soutenus. C'est ainsi que le niveau de sécurité des projets open source pourra réellement s'améliorer.

[GN⁺]

Avis Hacker News

Résumé :

• En tant que mainteneur de projet open source, je me méfie davantage des pull requests des nouveaux contributeurs.
  • Même si tout semble en apparence correct, il faut garder à l’esprit qu’il peut y avoir une intention cachée.
• Au fil des années, l’ajout de fonctionnalités rend les logiciels de plus en plus complexes.
  • Le code devient difficile à comprendre au point que seuls quelques-uns peuvent vraiment l’appréhender.
  • Quand des développeurs chevronnés prendront leur retraite, une grande partie risque de ne plus être comprise.
• Il faut un système de reporting des changements de mainteneurs pour les grands projets.
  • Il doit être synchronisé avec npm.js ou les paquets Debian au moment des versions/releases.
  • Comme dans le cas d’une banque européenne, des organismes de plusieurs pays devraient pouvoir surveiller.
• Il faut se méfier du scénario d’Eve Online : gagner la confiance en devenant un contributeur précieux, puis trahir.
• Le 2FA/MFA doit être utilisé uniquement avec des systèmes auto-hébergés.
  • Dans un système tiers, perdre son second facteur peut conduire à un verrouillage permanent.
  • L’hébergement direct du projet évite de perdre le contrôle.
• Une discussion délicate entre inclusion et sécurité à long terme se produira probablement dans l’open source.
  • Des développeurs venant d’Iran, de Russie, de Chine et d’autres pays sont déjà soupçonnés.
  • Il peut être préférable de forker et de contribuer avec des alliés.
  • Un acteur hostile peut merger des modifications dans la source sans se soucier des questions de licence ou de copyright.
• Chaque projet doit définir ses propres standards, et éliminer rapidement les dépendances non maintenues.
  • Il peut être judicieux d’évaluer aussi la sensibilité du projet.
• Après l’attaque XZ, je me suis demandé à quel point ce type d’attaque pourrait être fréquent.
  • L’open source peut être plus vulnérable que le logiciel propriétaire.
  • Parce que n’importe qui peut écrire du code et qu’il peut avoir des motivations malveillantes.
• Il semble difficile de revoir rétrospectivement le comportement des projets open source existants.
• On a depuis longtemps plaidé pour se concentrer sur une architecture simple et l’amélioration des standards de code.
  • Pourtant, les gens continuent d’augmenter les dépendances inutiles avec TypeScript, React, etc.
  • Les adversaires se moquent de notre ignorance et de notre naïveté.
  • L’ensemble de l’industrie, voire le système politique, a pu être compromis.
• Les gens auraient dû privilégier les projets avec peu de code et de dépendances.
  • Les projets propres sont privés d’attention et d’opportunités, tandis que des projets excessivement conçus prennent le devant de la scène.
  • Désormais, ils sont devenus des cibles faciles pour des acteurs malveillants.
  • C’est bien trop facile de dissimuler des vulnérabilités dans la complexité.