Dans le sillage de la porte dérobée dans le projet XZ Utils, la question était posée : d’autres projets open source étaient-ils concernés par ce type de manœuvre ? Dans une communication du 15 avril, les fondations Open Source Security et OpenJS répondent par l’affirmative, au moins trois projets JavaScript ayant été ciblés par des individus non identifiés.
L’affaire XZ Utils a fait beaucoup de bruit. Imaginez : un projet open source, une brique essentielle de l’environnement Linux et, plus généralement, de l’infrastructure d’Internet, un nouveau mainteneur providentiel, des modifications semblant légitimes, une porte dérobée en embuscade, une découverte presque par hasard par un ingénieur de Microsoft, une réaction rapide de la communauté et des éditeurs de distribution…
Que l’on puisse introduire aussi « facilement » une porte dérobée dans une brique aussi importante avait de quoi susciter bien des interrogations. Dont la principale : d’autres projets étaient-ils concernés ? La question a rapidement tourné dans les conversations. D’autant que dans le cas de XZ Utils, les signes pointaient sur une organisation digne d’une attaque soutenue par un État (APT, pour Advanced persistent threat), car témoignant d’une planification sur au moins deux ans.
Il n’aura pas fallu longtemps pour trouver d’autres signes de compromission. C’est le message adressé par les fondations Open Source Security (OpenSSF) et OpenJS aux développeurs, appelés à faire preuve de vigilance sur les sources des modifications dans les projets.
Au moins trois projets JavaScript concernés
Comme l’explique son Cross Project Council, la fondation OpenJS a reçu une série d’emails décrite comme suspecte. Leurs messages étaient similaires, « implorant » la fondation de prendre rapidement des mesures pour mettre à jour un projet très populaire afin de « remédier à toute vulnérabilité » critique.
Dans un modus operandi rappelant fortement l’affaire XZ Utils, le ou les auteurs des emails demandaient à se voir confier la gestion du projet pour corriger le tir. Il y avait cependant deux différences importantes avec XZ Utils. D’abord, la fondation OpenJS avait relevé un faible niveau de participation du ou des auteurs, là où Jia Tan (du nom que se donnait la personne ayant mis la main sur XZ Utils) s’était un peu plus fait connaitre. Ensuite, et surtout, Jia Tan apparaissait comme providentiel, face au créateur de XZ Utils qui souhaitait laisser la maintenance de son projet à quelqu’un d’autre, pour des raisons de « santé mentale ».
La fondation OpenJS n’a accordé aucun accès privilégié, se doutant d’une tromperie. Elle indique que le projet concerné (qui n’est jamais nommé) a mis en place de nouvelles règles de sécurité.
De plus, un « schéma suspect similaire » a été détecté dans deux autres projets JavaScript non gérés par la fondation. Les gestionnaires ont été avertis, de même que la CISA (l’agence américaine pour la cybersécurité et la sécurité des infrastructures), qui fait elle-même partie du ministère de la Sécurité intérieure.
Ingénierie sociale : des modèles suspects
La fondation Open Source Security en profite pour lister les comportements et « patterns » qui devraient alerter les personnes concernées quand elles sont visées par une attaque par ingénierie sociale.
Elle évoque par exemple la « poursuite amicale, mais agressive et persistante, du responsable ou de son entité hébergée (fondation ou entreprise) par des membres relativement inconnus de la communauté ». Peut y être accolé un faux sentiment d’urgence, surtout quand celle-ci réclame a priori de court-circuiter certaines vérifications, de réduire la rigueur d’un examen ou de contourner un contrôle. C’est d’autant plus vrai quand les personnes faisant la demande sont soutenues par d’autres, relativement inconnues, et qui peuvent constituer autant de marionnettes.
D’autres sont plus techniques, comme une déviation « des pratiques habituelles de compilation, de construction et de déploiement du projet qui pourrait permettre l'insertion de charges utiles malveillantes externes ». Le code source pourrait en outre être obscurci ou rendu intentionnellement plus difficile à comprendre.
Il faut également pouvoir détecter des problèmes de sécurité qui s’aggraveraient dans le temps. Dans le cas de XZ Utils, la première modification était un remplacement de safe_fprintf() par fprintf(). Assez anodin en apparence, mais il s’agissait d’un test pour vérifier le niveau de réaction. L’auteur (ou les auteurs) ont pu introduire ensuite – et graduellement – des modifications de plus en plus importantes.
« 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. Soyez attentif à ce que les interactions vous font ressentir. Les interactions qui créent un doute de soi, 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 », ajoute la fondation.
Des mesures à prendre pour réduire les risques
Aucune technique ne peut remplacer la vigilance humaine quand il s’agit d’ingénierie sociale, surtout quand l’attaque est persistante et joue à « qui va craquer en premier ». Il existe cependant plusieurs méthodes pour réduire les risques.
La fondation revient ainsi sur l’authentification forte et tout ce qui l’accompagne : activation de l’authentification à deux ou à multiples facteurs, utilisation d’un gestionnaire de mots de passe sécurisé, conservation des codes de récupération dans un endroit « sûr » (si possible hors ligne) et unicité des mots/phrases de passe.
Elle recommande également de toujours activer la protection de branches et les commits signés, de demander à un second développeur (quand c’est possible) de revoir le code avant de le fusionner, de s’assurer que les pull requests ne sont pas obscurcies, de limiter les droits de publication npm ou encore d’appliquer les guides de sécurité existants, comme ceux publiés par l’OpenSSF.
Celle-ci recommande aussi de bien connaître les participants aux projets, autant que faire se peut et quels que soient leurs rôles. Par exemple, en notant leur présence lors d’éventuels évènements ou de réunions de groupes de travail. Elle renvoie également vers le guide publié par la CISA pour lutter contre les attaques par ingénierie sociale.
La grande question du soutien
Les deux fondations, en partenariat avec la Linux Fundation, attirent enfin l'attention sur la manière dont ces projets sont financés : « En matière de sécurité, nos fondations open source ont constaté qu'une meilleure approche efficace consiste à fournir une assistance technique et un soutien direct aux projets open source ».
Le projet Alpha-Omega de l'OpenSSF, qui a pour projet de sécuriser les projets et écosystèmes critiques, reçoit par exemple des financements d’Amazon, Google et Microsoft. Selon la fondation OpenJS, son efficacité a été démontrée dans Node.js et jQuery.
Le Sovereign Tech Fund allemand est également cité, puisqu’il fournit un « financement important » à la fondation OpenJS. Les trois fondations plaident pour un élargissement de ce type de fonctionnement et des investissements publics mondiaux.
La situation est loin d’être anodine. Le fameux dessin de xkcd, cité dans notre article sur XZ Utils, reflétait bien la situation. De nombreux petits projets, parfois maintenus par une seule personne, sont essentiels au quotidien, ne serait-ce que pour Internet. Ces personnes ne sont pas nécessairement formées à la sécurité, ou manquent de temps et de moyens pour respecter toutes les étapes d’une bonne sécurité.
Il est probable que dans les semaines et mois qui viennent, d’autres projets signalent que des comportements troublants ont été détectés. L’insertion d’une porte dérobée dans un projet d’envergure entraînerait des conséquences catastrophiques. Pour l’exemple cité d’ailleurs, Omkhar Arasaratnam, directeur général de la fondation Open Source Security, a indiqué à Reuters que le paquet correspondant « faisait l'objet de dizaines de millions de téléchargements par semaine ».
Commentaires (16)
#1
#2
#2.1
Eh bien je te remercie de la précision car, comme tu le soulignes, cette expression "santé mentale" je l'avais mal comprise dans les articles précédents!
#2.2
Visiblement, il souffre de dépression et / ou de burn out avec des retraits réguliers d’internet.
Et ça serait bien qu’on arrête de considérer négativement les maladies mentales, ca permettrait qu’elles soient mieux traitées !
Historique des modifications :
Posté le 17/04/2024 à 21h34
Lasse a bien utilisé le terme « longterm mental health issues » et à noter qu’il est de Finlande et non d’Amérique du Nord.
Visiblement, il souffre de dépression et / ou de burn out avec des retraits réguliers d’internet.
Et ça serait bien qu’on arrête de considérer négativement les maladies mentales, ca permettrait qu’elles soient mieux traitées !
#3
#4
Historique des modifications :
Posté le 17/04/2024 à 20h41
À ce propos, je partage ce bon article de blog du créateur/mainteneur de Curl, Daniel Stenberg : https://daniel.haxx.se/blog/2024/04/10/verified-curl/
#5
#5.1
Phrase dans la source :
#5.3
Et oui, comme le dit Furanku plus bas, obscurcie est bien en référence à obscurcissement, la traduction d'obfuscation utilisé en anglais.
#5.2
Je n'ai pas très bien compris le sens du terme non plus.
Edit : grilled.
Historique des modifications :
Posté le 18/04/2024 à 10h05
De l'obfuscation peut-être ? Ou des techniques pour noyer le poisson dans une PR conséquente (j'opterais plus pour cette seconde option) ?
Je n'ai pas très bien compris le sens du terme non plus.
Edit : grilled.
#5.4
#6
- se baser sur les archives venant réellement du code source et non d’archives mises à dispo du mainteneur,
- des sécurités sur la compilation dont des générations d’erreurs au lieu d’ignorer certaines choses (le cas du point ajouté juste après l’entête…)
- sécurisation de systemd…
Pas mal de détails sont dispo ici (en anglais)
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Le logiciel propriétaire n’est pas du tout à l’abris de ce genre de problème d’autant plus qu’il se base de plus en plus sur des briques libres sans forcément contribuer aux briques en question…
Et pour l’installation de trucs, zarb à l’insu des personnes, que dire de l’installation de copilot sur du windows server ? Microsoft vient d’indiquer que « oups » c’est une erreur… :
https://www.bleepingcomputer.com/news/microsoft/microsoft-copilot-app-on-windows-server-mistakenly-added-by-edge/
#7
Et pour illustrer le dessin de xkcd, le projet openSSL (qui a eu une influence déterminante sur le développement d'internet en permettant des communications sécurisées) n'était maintenu que par un seul développeur à plein temps au moment de l'apparition de la vulnérabilité HeartBleed.
#7.1
#7.2
Généralement, les entreprises vont vouloir prendre un produit vendu par un éditeur tout simplement pour le support. Même si celui-ci est ridiculement inutile, inefficace, coûteux, et que les équipes internes du client sont 100x plus compétentes que le chatbot scripté du support.
Mais ce qui motive surtout, c'est forcément la contractualisation, donc le juridique. Signer avec un éditeur, quand on lit ses contrats évidemment, c'est aussi chercher à avoir des garanties ou des engagements avec potentiellement matière à exiger des contreparties en cas de problème. Chose qu'on a pas avec un produit open source puisque c'est livré en l'état et demerden sie sich. C'est aussi notamment pour ça que le SaaS a percé en entreprise et que nombre des solutions métier le sont désormais (ITSM, RH, comptabilité, bureautique, etc).
Quand bien même les produits SaaS soient des vieux monolithes historiques moisis Cloudifiés à la truelle bourrés de faille. Genre Atlassian qui passe pas un trimestre sans avoir une news sur une faille critique sur les versions on-premise de leurs produits. Moi ça me rassure pas sur leur Claude.
Historique des modifications :
Posté le 18/04/2024 à 20h53
Entre l'open source et le propriétaire, pour moi il n'y a qu'une seule différence : le juridique.
Généralement, les entreprises vont vouloir prendre un produit vendu par un éditeur tout simplement pour le support. Même si celui-ci est ridiculement inutile, inefficace, coûteux, et que les équipes internes du client sont 100x plus compétentes que le chatbot scripté du support.
Mais ce qui motive surtout, c'est forcément la contractualisation, donc le juridique. Signer avec un éditeur, quand on lit ses contrats évidemment, c'est aussi chercher à avoir des garanties ou des engagements avec potentiellement matière à exiger des contreparties en cas de problème. Chose qu'on a pas avec un produit open source puisque c'est livré en l'état et demerden sie sich. C'est aussi notamment pour ça que le SaaS a percé en entreprise et que nombre des solutions métier le sont désormais (ITSM, RH, comptabilité, bureautique, etc).
Quand bien même les produits SaaS soient des vieux monolithes historiques moisis Cloudifiés à la truelle bourrés de faille. Genre Atlassian qui passe pas un trimestre sans avoir une news sur une faille critique.
#8
Historique des modifications :
Posté le 23/04/2024 à 20h17
C'est Pavel Durov, patron de Telegram, qui racontait dans une interview récente à 18:15 entre autres infos hallucinantes (c'est une entreprise de 30 ingénieurs seulement par exemple...) qu'un service étatsunien avait approché dans son dos un de ses ingénieurs, d'une part pour se renseigner sur les projets opensource utilisés dans Telegram, d'autre part pour inciter à utiliser certains outils opensources. Dommage qu'il ne donne pas les noms mais il devait y avoir quelque chose autour de la sécurité de ces bibliothèques et outils qui arrangeait les services de l'empire.