Intel est notre flux de menaces de sécurité open-source alimenté par l'IA et notre équipe de recherche interne. Intel surveille et découvre les vulnérabilités des logiciels libres avant qu'elles ne soient divulguées. Beaucoup ne le sont jamais.
67 % des failles logicielles corrigées silencieusement n'ont jamais été divulguées
Les logiciels libres alimentent le monde, littéralement. Cependant, la sécurité des logiciels libres est également un domaine qui suscite d'énormes préoccupations en matière de sécurité. Les outils open-source, comme tout le reste, peuvent introduire des failles de sécurité. Celles-ci peuvent être utilisées par des pirates pour exploiter votre application. Les vendeurs de logiciels sont ainsi exposés à des attaques dont ils ne sont pas responsables. La sécurité des logiciels libres est donc un sujet très important.
Nous comptons non seulement sur la communauté des logiciels libres pour construire et entretenir ces outils, mais aussi sur elle pour corriger toutes les failles de sécurité connues. Il est important de noter que nous comptons également sur ces mainteneurs pour signaler publiquement les vulnérabilités lorsqu'elles sont découvertes. La divulgation publique des vulnérabilités par la communauté constitue le fondement de la sécurité des logiciels libres.
Le patching silencieux, ou patching fantôme, est l'application d'un correctif de sécurité (patching) qui n'est jamais divulgué. Il s'agit d'un problème important car cela signifie que les vendeurs peuvent utiliser des logiciels vulnérables sans être conscients du risque.
Nous lançons Aikido Intel pour faire sortir de l'ombre les logiciels silencieusement corrigés qui pourraient vous affecter. Avec Aikido Intel, nous pouvons avertir les développeurs le plus tôt possible si nous trouvons des vulnérabilités susceptibles de les affecter et d'améliorer la sécurité des logiciels libres.
Qu'est-ce que l'Aikido Intel ?
Aikido Intel est une initiative d'AI et de notre équipe de recherche interne visant à améliorer la sécurité des logiciels libres en découvrant les vulnérabilités dans la chaîne d'approvisionnement des logiciels libres le plus tôt possible. Avant même qu'elles ne soient divulguées dans une base de données de vulnérabilités. Pour ce faire, nous utilisons des LLMs formés sur mesure pour examiner les changements dans les paquets et identifier quand un problème de sécurité a été corrigé.
Comme tous les logiciels, les logiciels libres conservent un journal des modifications apportées à chaque nouvelle version. Intel utilise l'intelligence artificielle pour lire tous ces journaux de modifications publics et ces notes de version afin de trouver des exemples de correctifs apportés à des problèmes de sécurité. Ces informations sont ensuite comparées à cinq bases de données de vulnérabilités pour vérifier si le problème a été signalé. Si ce n'est pas le cas, un ingénieur en sécurité analyse et évalue la vulnérabilité, lui attribue un numéro de vulnérabilité Aikido et une gravité, puis l'annonce publiquement afin que vous sachiez si vous êtes concerné. Vous trouverez plus de détails à ce sujet un peu plus loin.
Checkout Aikido Intel maintenant
Aikido Intel en chiffres
Depuis son lancement en janvier, Aikido, Intel a découvert 511 vulnérabilités qui ont été corrigées mais n'ont pas été rendues publiques, ce qui représente une menace réelle pour tous ceux qui utilisent ces logiciels.
Il peut parfois s'écouler un certain temps entre le moment où une vulnérabilité est corrigée et celui où un numéro CVE est attribué au problème. Chaque semaine, Aikido réévalue l'état des vulnérabilités précédentes pour voir si un numéro CVE leur a été attribué. Nous pouvons révéler que 67% des vulnérabilités que nous avons découvertes n'ont jamais été divulguées publiquement dans une base de données de vulnérabilités !
S'il n'est pas surprenant que les vulnérabilités de faible gravité soient plus souvent corrigées silencieusement, il est tout de même choquant de constater que plus de 50 % des vulnérabilités importantes et critiques ne sont jamais divulguées. Cela crée un énorme angle mort pour les développeurs et les vendeurs de logiciels.
Je sais que certains d'entre vous vont se tortiller sur leur siège en se disant qu'il s'agit peut-être de petits projets open-source, pas très populaires, avec des politiques de sécurité limitées, mais en fait, vous auriez tort. Nous avons trouvé des vulnérabilités non divulguées dans de très grands projets. .
Axios, un client HTTP basé sur des promesses pour le navigateur et node.js avec 56 millions de téléchargements hebdomadaires et 146 000 dépendances et plus a corrigé une vulnérabilité pour un prototype de pollution en janvier 2024 qui n'a jamais été divulguée publiquement.
Fait amusant à propos de cette vulnérabilité : Il s'agit en fait de la première vulnérabilité découverte par Aikido Intel (voir le numéro 2023-10001).... Elle n'a toujours pas été révélée à ce jour !
Axios n'est pas le seul, il y a quelques autres noms qui méritent une mention spéciale. Apache a silencieusement corrigé une vulnérabilité dans le logiciel echarts pour le cross-site scripting qui n'a jamais été divulguée.
Un autre exemple intéressant que nous avons découvert est une vulnérabilité critique de traversée de chemin dans le Chainlit qui a été corrigée en septembre, mais la vulnérabilité n'a jamais été divulguée publiquement.
Les vulnérabilités les plus courantes
Les scripts intersites constituent la vulnérabilité non divulguée la plus courante (14,8 %), suivie de l'exposition d'informations sensibles (12,3 %). Dans l'ensemble, nous avons détecté 90 types différents de vulnérabilités, ce qui a donné lieu à une longue série de résultats, dont voici quelques-uns des plus courants.
Les vulnérabilités les plus courantes découvertes
Si l'on se limite aux vulnérabilités cuticulaires et aux vulnérabilités élevées, le tableau est légèrement différent, l'exécution de code à distance occupant la première place de la liste.
Les vulnérabilités les plus courantes découvertes - critiques et élevées seulement
Délai de divulgation
Alors qu'au moment de la rédaction de cet article, 67 % des paquets n'ont jamais révélé leurs vulnérabilités, 31 % l'ont fait, que ce soit de la part des responsables ou des chercheurs en sécurité (bravo à eux). Parmi les paquets qui ont révélé leurs vulnérabilités, il s'est écoulé en moyenne 27 jours entre le moment où le correctif a été publié et celui où un CVE a été attribué. Le délai le plus court que nous ayons observé est de 1 jour et leplus long de 9 mois !
Comment fonctionne Intel (en détail)
Je sais que nous en avons tous assez des nouvelles conneries sur l'IA, mais Intel est une initiative de l'équipe de recherche en sécurité d'Aikido et l'équipe d'IA d'Aikido utilise l'IA avec un humain dans la boucle pour fournir un flux de menaces public afin d'améliorer la sécurité des sources ouvertes.
Intel travaille en lisant tous les changelogs et notes de version disponibles publiquement pour comprendre si des correctifs de sécurité ont été apportés mais n'ont pas été divulgués. Pour ce faire, deux modèles LLM sont utilisés, l'un pour filtrer les données et supprimer tout contexte inutile afin que le second LLM puisse se concentrer sur l'analyse des vulnérabilités. Un ingénieur en sécurité humain examine ensuite les découvertes du LLM, valide les résultats et publie un Intel lorsqu'une vulnérabilité est confirmée.
Cette méthode est très efficace car elle consomme beaucoup moins de puissance de calcul que l'analyse de tous ces systèmes à la recherche de vulnérabilités. Pourtant, il a fallu plus d'un an pour obtenir de nombreux résultats concrets.
Comment les Changelogs sont vus par Aikido Intel
Les listes de modifications sont des documents conservés dans les projets open-source qui enregistrent les mises à jour, les corrections de bogues, les ajouts de fonctionnalités et les correctifs. En voici quelques exemples CHANGELOG.md les messages de validation et les notes de version de GitHub.
L'Intel LLM identifie les entrées suggérant des changements liés à la sécurité en recherchant les éléments suivants :
- Mots clés : "vulnérabilité", "sécurité", "correction", "exploit", "validation d'entrée", etc.
- Indices contextuels : "Correction d'un bogue critique", "Correction d'un débordement de mémoire tampon", "Résolution de problèmes d'authentification".
Exemple d'entrées signalées par le LLM :- Correction d'un problème de vérification des entrées dans le gestionnaire de connexion.
- Résolution d'une fuite de mémoire pouvant entraîner des attaques par déni de service.
- Correction d'une vulnérabilité de traversée de chemin dans la fonctionnalité de téléchargement de fichiers.
Sécurité des logiciels libres, comment les vulnérabilités sont divulguées correctement
Comme indiqué précédemment, la divulgation publique est un élément important de la sécurité des logiciels libres. Plusieurs bases de données différentes sont utilisées pour divulguer les vulnérabilités d'un logiciel. La principale base de données est la National Vulnerability Database (NVD) (base de données nationale sur les vulnérabilités) gérée par le gouvernement américain. Cette base de données n'est pas seulement utilisée par les entreprises pour vérifier leur chaîne d'approvisionnement, mais aussi par les logiciels de sécurité qui vérifient les projets par rapport à cette base de données et à d'autres (logiciel SCA). Il existe de nombreuses autres bases de données, dont la base de données Mitre Common Vulnerabilities and Exposures database (CVE) de Mitrede Mitre, la base de données des avis de GitHub, et bien d'autres encore. Au total, Aikido vérifie 5 bases de données différentes. Mais ce que la plupart de ces bases de données ont en commun, c'est qu'elles exigent que les vulnérabilités soient divulguées publiquement, généralement après qu'un correctif ait été publié.
Pourquoi les vulnérabilités ne sont-elles pas divulguées ?
C'est une bonne question et je voudrais commencer par dire qu'il n'y a aucune bonne raison de ne pas divulguer les vulnérabilités. La raison la plus courante est peut-être le risque de réputation, le fait que votre logiciel puisse être considéré comme non sécurisé, mais je dirais qu'il y a beaucoup plus à perdre à ne pas divulguer qu'à divulguer.
Pourquoi le "shadow patching" est un problème pour la sécurité des logiciels libres
Ne pas divulguer publiquement les vulnérabilités de votre logiciel crée un risque énorme pour vos utilisateurs. Comme le dit le proverbe, si ce n'est pas cassé, ne le réparez pas, et cela s'applique souvent aux logiciels.
La mise à jour des composants de votre logiciel peut souvent créer des problèmes de performance et de convivialité ou tout simplement casser votre application. C'est pourquoi il n'est pas toujours courant de mettre à jour les paquets dès qu'une nouvelle version est disponible.
Cependant, lorsqu'un composant présente un problème de sécurité, il est important de le savoir car cela modifie l'urgence avec laquelle vous mettez à jour vos composants open-source et tiers. Ne pas divulguer cette information signifie que les utilisateurs sont moins susceptibles de mettre à jour, ce qui signifie qu'ils auront des failles de sécurité dans leurs outils qu'ils ne connaissaient pas, d'où le problème du "shadow patching".
Ne laissez pas des vulnérabilités cachées compromettre votre sécurité.
Associez-vous dès aujourd'hui à Aikido Security pour protéger votre chaîne d'approvisionnement et gagner en tranquillité d'esprit.
.svg)
.jpg)
.jpg)
.jpg)
.jpg)
