Recrudescence de composants open source malveillants en 2024

Résumé de l’article :

L’écosystème de développement open source a vu une augmentation significative des logiciels malveillants, mettant les entreprises en état d’alerte face aux attaques sur la supply chain logicielle. Selon Sonatype, 80 % des applications vulnérables à cause de composants tiers infectés ne sont pas corrigées pendant plus d’un an, bien qu’il existe des alternatives plus sûres dans 95 % des cas.

Points clés :

• Augmentation des logiciels malveillants : Plus de 500 000 nouveaux paquets malveillants recensés depuis novembre 2023.
• Composants vulnérables : 80 % des applications vulnérables ne sont pas mises à jour rapidement.
• Exemple de Log4j : 13 % des téléchargements de Log4j concernent encore des versions vulnérables.
• Types de menaces : Hameçonnage, vol de données, protestware, et programmes de minage de crypto-monnaie.
• Gestion des vulnérabilités : Les délais de correction des vulnérabilités augmentent, dépassant parfois 500 jours pour les failles critiques.

Les entreprises doivent optimiser leurs politiques de sécurité et utiliser des outils automatisés pour gérer les dépendances et détecter les vulnérabilités en temps réel.

Détail de l’article :

L’écosystème de développement open source a connu une augmentation significative des composants logiciels malveillants. Ce qui met les entreprises en état d’alerte face aux attaques sur la supply chain logicielle.

Les logiciels malveillants s’infiltrent dans l’écosystème de développement des logiciels libres à un rythme alarmant, selon un nouveau rapport de Sonatype, spécialisée dans la gestion de la chaîne d’approvisionnement en logiciels. L’entreprise a recensé plus de 500 000 nouveaux paquets malveillants depuis novembre 2023 dans les registres Java, JavaScript, Python et .NET les plus populaires.

Les nouveaux composants représentent plus de 70% des quelque 700 000 paquets de logiciels malveillants suivis par l’entreprise depuis 2019, date à laquelle elle a commencé à inclure ces statistiques dans son rapport annuel sur l’état de la chaîne d’approvisionnement en logiciels (State of the software supply chain).

80% des composants vulnérables ne sont pas mis à jour rapidement

Cette vague de logiciels malveillants s’ajoute aux défis préexistants auxquels les organisations sont confrontées en ce qui concerne la qualité des composants open source intégrés dans leurs applications. Selon les données de Sonatype, chaque application d’entreprise comporte en moyenne au moins 180 composants tiers, un volume difficile à gérer.

En conséquence, l’éditeur a constaté que plus de 80 % des applications vulnérables du fait de ces dépendances à des composants tiers ne sont pas corrigées pendant plus d’un an, alors que 95 % d’entre elles pourraient l’être via le déploiement d’alternatives plus sûres. Même lorsque les mises à jour sont appliquées, dans 3,6 % des cas, les composants vulnérables sont mis à jour vers d’autres versions elles-mêmes non sécurisées.

« L’impossibilité de ralentir le devops »

Prenons l’exemple de Log4j. La bibliothèque de journalisation pour Java utilisée dans des millions d’applications présentait une vulnérabilité critique baptisée Log4Shell, découverte en décembre 2021. Cette faille et quelques autres qui ont suivi peu après ont fait l’objet d’une large publicité, mais près de trois ans plus tard, 13 % des téléchargements de Log4j à partir du répertoire Maven Central Java continuent de concerner des versions vulnérables.

« La gestion des risques liés aux logiciels libres nécessite l’optimisation des politiques et des pratiques de sécurité afin de suivre l’évolution rapide des bibliothèques OSS », écrit Sonatype dans son rapport. « Les organisations se heurtent à l’impossibilité de ralentir les processus DevOps pour procéder à des examens manuels des vulnérabilités, ce qui susciterait de la frustration chez les développeurs. »

Du composant militant au hameçonnage, en passant par le vol de données

À l’instar des menaces ciblant les ordinateurs de bureau, les composants malveillants téléchargés dans les dépôts de paquets open source peuvent avoir des objectifs différents et n’ont pas tous le même impact. Sonatype en classe près de la moitié dans la catégorie des « applications potentiellement indésirables » (PUA pour ‘potentially unwanted applications’), qui ne sont pour la plupart pas nocives en pratique, mais dont les fonctionnalités ne sont pas divulguées à l’utilisateur final. Il s’agit notamment de protestware, au sein desquels le créateur du composant inclut des messages de protestation ou des actions destinées à attirer l’attention sur une cause qui lui tient à coeur. Par ailleurs, 12% des composants sont signalés comme « security holding packages », ce qui signifie que les responsables de l’écosystème les ont signalés comme malveillants à un moment donné et les ont remplacés par un composant sain, afin d’attirer l’attention de ceux qui les utilisent.

Les autres menaces mises en lumière par Sonatype ont des conséquences assez graves qui peuvent compromettre la supply chain logicielle. Environ 14 % des paquets sont distribués par le biais de techniques d’hameçonnage, c’est-à-dire qu’ils utilisent la confusion régnant autour des dépendances pour se faire passer pour des paquets internes au sein des organisations afin de déposer d’autres logiciels malveillants sur les environnements de développement.

Environ 14 % des paquets malveillants sont, eux, conçus pour voler des fichiers et des données sensibles sur les machines, tels que des variables d’environnement, des jetons d’authentification, des fichiers de mots de passe et d’autres informations qui pourraient aider les attaquants à compromettre d’autres systèmes par la suite. Un sous-ensemble de 3% des composants vérolés cible également les informations personnelles identifiables tandis que 3% supplémentaires des menaces déploient des portes dérobées et des chevaux de Troie sur les machines.

Infiltrer un projet open source pour y implanter une backdoor

Parmi les autres types d’actions malveillantes, citons le dépôt de programmes de minage de crypto-monnaie (1,2 %), la corruption des systèmes de fichiers ou la compromission des environnements de développement utilisés par les développeurs.

Parmi les incidents récents liés à ces paquets indésirables, on peut citer un développeur qui a téléchargé environ 14 000 faux paquets sur NPM pour bénéficier d’un système de crypto-monnaie qui récompensait les contributions à l’Open Source. Ou encore des attaquants utilisant le typosquatting pour pousser un paquet Python avec un nom très similaire à une bibliothèque populaire déployant le malware de Windows Lumma (un infostealer). Sans oublier la porte dérobée ZX Utils, un exemple d’une attaque par infiltration courant sur plusieurs années au cours de laquelle un développeur malhonnête a ciblé un projet de développement avec l’intention d’empoisonner le code.

Certaines informations sur les vulnérabilités ne sont pas fiables

Sonatype estime que chaque application d’entreprise hérite en moyenne de 13 vulnérabilités critiques ou graves chaque année, provenant de ses dépendances. Ce qui souligne, pour l’éditeur, la nécessité de disposer d’outils automatisés capables de suivre toutes les dépendances directes et indirectes – les dépendances de dépendances – ainsi que les vulnérabilités qui y sont découvertes.

Problème, les sources d’information sur les vulnérabilités ne sont pas de qualité homogène. Par exemple, la base de données NVD (National Vulnerability Database) a un arriéré de plus de 17 000 vulnérabilités qui n’ont pas encore été traitées. Sonatype a constaté, dans la pratique, que plus de deux tiers des vulnérabilités initialement classées avec un score de gravité CVSS inférieur à 7 (un niveau de sévérité moyen) étaient corrigées à plus de 7 (élevé ou critique) lorsqu’elles étaient examinées plus en détail par un chercheur en sécurité.

En conséquence, selon la source d’informations sur les vulnérabilités qu’elles utilisent, les entreprises peuvent passer complètement à côté de vulnérabilités ou reporter leur remédiation, pensant qu’elles sont moins critiques qu’elles ne le sont en réalité. Et si le score d’une vulnérabilité est modifié après l’évaluation d’une application par la RSSI, il est difficile de savoir combien de temps s’écoulera avant qu’elle ne soit à nouveau analysée.

L’utilité du SBOM… et ses limites

« Il est possible de réduire les risques persistants en se concentrant sur des outils qui aident à gérer les dépendances et effectuent de la détection de vulnérabilités en temps réel », écrivent les chercheurs. « En fait, nous avons constaté que les projets utilisant un inventaire logiciel (SBOM, pour software bill of materials) pour gérer les dépendances open source ont permis de réduire de 264 jours le temps nécessaire à la résolution des problèmes par rapport à ceux qui ne l’utilisaient pas. »

La progression des normes SBOM et les réglementations qui les encouragent fortement ont poussé un nombre croissant de développeurs de logiciels libres à les adopter. Malheureusement, le taux d’adoption ne suit pas le rythme des nouveaux composants publiés. Près de 7 millions de nouveaux composants Open Source ont été publiés au cours des 12 derniers mois, 61 000 seulement étaient dotés de SBOM.

Correction de vulnérabilités : les délais s’allongent

Une autre tendance inquiétante réside dans l’augmentation du temps moyen nécessaire pour corriger les vulnérabilités, quelle que soit leur gravité. Pour les failles critiques, le temps moyen de correction se situait entre 200 et 250 jours, mais il dépasse désormais 500 jours dans certains cas. Les vulnérabilités de haute sévérité ont allongé leur délai de correction de 150 à 300 jours à plus de 400 jours ; les failles de faible sévérité ont maintenant un délai de correction de 500 à 700 jours, certaines montant jusqu’à 800.

« Cette forte augmentation suggère que les éditeurs sont débordés et qu’ils s’efforcent de faire face à la fois au volume des problèmes de sécurité et aux exigences permanentes en matière d’innovation et de développement de fonctionnalités », explique Sonatype.

Une erreur dans l’article?Proposez-nous une correction

Article rédigé par

Lucian Constantin, CSO (adapté par Reynald Fléchaux)