Le Vendredi Saint, le développeur Microsoft Andres Freund a lancé une bombe de Pâques. Alors qu'il résolvait des problèmes de performances apparemment inoffensifs sur un système Debian Linux, il est tombé sur ce qui a été décrit comme l’attaque de chaîne d’approvisionnement « la mieux exécutée » jamais vue.

Cela aura des implications majeures pour les équipes de sécurité informatique et sur la façon dont elles géreront les risques open source à l’avenir.

Qu'est-il arrivé?

L’attaque était incroyablement complexe. Mais il semble qu’il s’agisse d’une tentative parrainée par l’État d’insérer une porte dérobée dans un composant open source populaire connu sous le nom de xz Utils. L'utilitaire de compression de données peut être trouvé sur presque tous les systèmes Linux. La porte dérobée et la vulnérabilité associée, CVE-2024-3094, sont conçues pour injecter du code malveillant dans un serveur OpenSSH (SSHD) exécuté sur la machine d'une victime. Il y a plus de détails ici, mais le problème est que cela permettrait à des attaquants distants en possession d'une clé privée spécifique de pirater à distance une machine ciblée.

En bref, c'est aussi sérieux que possible, c'est pourquoi le CVE a reçu un score CVSS de 10.0. Heureusement, l'attaque a été repérée avant que la mise à jour malveillante de xz Utils ne soit fusionnée dans les principales distributions Linux. À ce stade, il aurait pu donner à l’acteur menaçant derrière lui un accès à distance à un nombre inconnu de machines mondiales.

La sophistication et la planification patiente de cette attaque indiquent le soutien de l’État-nation. Nous pouvons en déduire car :

  • La porte dérobée elle-même comporte une chaîne d’exécution complexe comprenant plusieurs étapes
  • La porte dérobée a été introduite lors de plusieurs commits
  • Ces commits n'étaient inclus que dans les versions tarball du code source plutôt que poussés vers le référentiel git public – afin de les garder cachés de tout examen minutieux.
  • L’opération a duré au moins deux ans. C'est à ce moment-là que le « développeur » malveillant connu sous le nom de « Jia Tan » a rejoint le projet open source.
  • Il semble que le groupe derrière Jia Tan ait délibérément fait pression sur le responsable d'origine, Lasse Collin, pour qu'il intègre Tan. De faux personnages probables, notamment « Jigar Kumar » et « Dennis Ens », ont tous mis la pression en bombardant Lasse de demandes de fonctionnalités et de plaintes de bugs.

Le défi de la sécurité Open Source

La mauvaise nouvelle est que Jia Tan est connu pour avoir travaillé sur plusieurs autres projets open source. On ne sait pas si un code malveillant a déjà été inséré secrètement dans ces derniers et quel pourrait en être l'impact.

L’open source est ici à la fois le problème et la solution. Son approche « à plusieurs yeux » du développement logiciel devrait, en théorie, signifier que les problèmes sont repérés à temps. Mais comme le montre cette attaque, les acteurs malveillants font de grands efforts pour introduire du code malveillant dans les projets.

Le défi pour les équipes de sécurité et les développeurs utilisant des composants open source réside dans les dépendances intransitives qu'ils introduisent souvent involontairement dans le code – comme le souligne le La saga Log4j. Selon Jamie Scott, chef de produit fondateur chez Endor Labs, il est essentiel d'avoir une visibilité sur de tels risques.

"Lorsque vous faites confiance à un package Maven, en moyenne, il y a 14 dépendances supplémentaires auxquelles vous faites implicitement confiance", explique-t-il à ISMS.online. « Ce nombre est encore plus important dans certains écosystèmes logiciels tels que npm, où vous importez en moyenne 77 autres composants logiciels pour toutes les personnes en qui vous avez confiance. Cette relation de confiance est établie avec tous les responsables de tous les composants logiciels.

Alors quelle est la réponse ? D’un côté, les gouvernements, les grands éditeurs de logiciels qui utilisent l’open source et la communauté open source elle-même doivent faire davantage.

« L'industrie et la communauté open source doivent travailler plus étroitement pour sécuriser l'écosystème logiciel de cybersécurité au sens large », a déclaré Chris Hodson, CSO de Cyberhaven, à ISMS.online. « La frontière entre les logiciels commerciaux et open source est opaque. Il est dans l’intérêt de tous de faire mieux. »

Scott d'Endor Labs ajoute que l'industrie pourrait aider en adoptant la signature d'artefacts.

« La signature d'artefacts offre une certaine résilience à ce type d'attaque en garantissant que seuls les pipelines autorisés peuvent produire des artefacts valides et signés », affirme-t-il.

"Bien que cela ne fournisse pas une protection parfaite, cela augmente considérablement le coût pour un adversaire d'adopter des packages malveillants, et contribue également à une réponse efficace aux incidents en permettant aux intervenants de bloquer rapidement et précisément l'utilisation du package malveillant une fois qu'il est identifié."

D'autres initiatives industrielles indispensables incluent l'adoption par défaut de métadonnées de sécurité telles que les factures de matériel logiciel (SBOM) et les niveaux de chaîne d'approvisionnement pour les artefacts logiciels (SLSA), qui peuvent aider les RSSI à mieux comprendre les risques dans leurs chaînes d'approvisionnement. Il y a également plus de financement pour des organisations comme OpenSSF, qui à leur tour financent d'importantes initiatives de sécurité.

Prochaines étapes pour les équipes de sécurité

En fin de compte, pour les RSSI et les équipes DevSecOps, la clé est de gagner en visibilité sur leur code open source, en particulier sur les dépendances intransitives, selon Hodson.

« Il est important que les RSSI apprécient la chaîne de confiance et les interdépendances d'une bibliothèque logicielle et d'un exécutable. Xz Utils, pris isolément, semble être un composant logiciel à faible risque, mais les adversaires chercheront à exploiter ce logiciel pour atteindre leur objectif », affirme-t-il. « Les RSSI doivent mieux comprendre leur chaîne d'approvisionnement – ​​pas seulement les fournisseurs qu'ils utilisent pour leurs logiciels commerciaux, mais aussi les composants open source de leurs applications et services. Sans parler de ceux de leurs tiers.

Andrew Rose, CSO de SoSafe, partage cette liste de tâches pour gérer les risques, avec ISMS.online :

  • Créez une bibliothèque de logiciels et d'actifs approuvés pour garantir des garde-fous clairs aux développeurs et limiter le code et les logiciels non approuvés. Le logiciel doit être validé et approuvé, peut-être par des fournisseurs dont les risques ont été évalués
  • Créez de faux lacs de données à des fins de test et mettez en œuvre la segmentation du réseau. Cela signifie que tous les environnements de développement, ou les lieux avec des builds non contrôlés, ne devraient pas avoir accès aux données réelles, ni aux systèmes et services de production.
  • Utilisez uniquement les versions approuvées et publiées en production et examinez-les régulièrement pour garantir que toute activité suspecte est surveillée.
  • Les RSSI doivent rester connectés aux communautés de développeurs pour connaître les vulnérabilités, les portes dérobées et les problèmes à mesure qu'ils surviennent.
  • Analysez régulièrement les environnements, même après que les RSSI ont nettoyé la maison. Un modèle « du bétail, pas des animaux de compagnie » doit être appliqué pour gérer les services ou les logiciels, ce qui signifie une évaluation et une reconstruction continues pour garantir que les bonnes versions approuvées sont utilisées.

 

Scott d'Endor Labs ajoute les conseils de défense approfondis suivants pour réduire le risque d'exploitation en cas de compromission d'une chaîne d'approvisionnement logicielle :

  • Implémenter le moindre privilège : dans le cas de xz Utils, une approche de moindre privilège pour la configuration du serveur et du conteneur aurait été utile. Les clés SSH de porte dérobée vous permettent d'accéder à SSH lorsque les services SSH sont accessibles. Veuillez ne pas exposer les ports SSH à Internet
  • Créer des politiques de gouvernance pour l'utilisation de l'open source : celles-ci peuvent aller de « Épingler toutes les versions de logiciels open source utilisées afin de ne pas toujours télécharger la dernière version » à « Ne pas utiliser de versions de logiciels open source datant de moins de 60 jours ».
  • Supprimez les logiciels inutilisés pour réduire les risques liés à la chaîne d'approvisionnement : les logiciels inutilisés peuvent créer une surcharge inutile dans votre logiciel et introduire des risques dans la chaîne d'approvisionnement au fil du temps. Ce n'est qu'une question de temps avant que la prochaine attaque de type xz Utils ne soit découverte. En prenant davantage de précautions dès maintenant, les organisations peuvent renforcer leur résilience de manière proactive et garantir que leur chemin vers le rétablissement sera plus rapide et moins traumatisant.