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…

• XZ Utils : comment une porte dérobée dans un composant de Linux a fait craindre le pire

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 ».