Le voyage vers 300 000 vulnérabilités : le bon, le mauvais et le bizarre

Récemment, notre équipe VulnDB a franchi une étape importante dans notre recherche des meilleures informations sur les vulnérabilités : l’agrégation de notre 300 000e divulgation de vulnérabilités. Bien qu’il s’agisse d’une réalisation importante et d’un motif de célébration, c’est aussi un sombre rappel de ce à quoi les équipes de sécurité sont confrontées chaque jour.

Au lieu de rappeler constamment aux responsables des vulnérabilités et aux équipes de sécurité de l’information à quel point les logiciels peuvent être mauvais, nous voulons montrer le chemin parfois étrange que nos recherches nous ont emprunté. Voici quelques-uns de les divulgations de vulnérabilité les plus intéressantes et les plus colorées que nous ayons rencontrées.

Vulnérabilité zéro : l’histoire d’origine

Lorsque beaucoup pensent à l’industrie de la sécurité informatique, ils ont tendance à croire qu’elle est relativement jeune. Cependant, il a en fait plus d’un siècle! Dans un article précédent, nous avons plongé dans les plus anciennes vulnérabilités du monde affectant le télégraphe sans fil de Guglielmo Marconi. Et bien que ces problèmes datent de plus de cent ans, il y a encore quelque chose à apprendre.

Les deux premières vulnérabilités enregistrées ont entraîné la première interception Man-in-the-Middle (MitM) au monde, les vulnérabilités de Marconi étant des transmissions de messages non cryptées qui peuvent être interceptées de manière triviale, et une faiblesse d’usurpation de message due à l’absence d’authenticité établie. Mais en regardant maintenant, ce même type d’attaque a été vu aussi récemment que le 29 septembre 2002, où une divulgation détaillée des problèmes MitM affectant plusieurs produits Mitsubishi Electric.

Le second, l’usurpation de message due à un manque de vérification d’authenticité, peut être observé dans une variété de problèmes d’usurpation allant de la vérification incorrecte des certificats SSL/TLS à l’utilisation, par exemple, d’adresses IP comme vérification d’authenticité. Plus de 120 ans plus tard, de nombreux vendeurs ne tiennent toujours pas compte des leçons que Marconi a vécues d’une manière aussi grandiose, quoique embarrassante.

Injections SQL et scripts intersites : des fruits à portée de main

Au début des années 2000, le monde a été témoin d’une migration massive vers les applications Web en tant qu’interface souhaitée pour les utilisateurs et les passionnés d’informatique. L’accès au Web était facile et la popularité d’Internet a permis de créer une application unique conçue pour accéder à une variété incroyablement large de systèmes et de ressources. Mais avec cette nouvelle technologie, de dures leçons d’écriture de code sécurisé ont conduit à un nombre important de vulnérabilités d’applications Web telles que les scripts intersites (XSS) et l’injection SQL (SQLi).

Étant donné que les failles XSS sont sans doute les plus faciles à trouver, il n’est pas surprenant que nous ayons vu des chiffres significatifs dans la décennie après 2000, et un autre pic significatif en 2012 :

Failles XSS de 2005 à 2013

L’injection SQL, facile à déclencher une faille potentielle, a également décollé en 2005 et un deuxième pic significatif en 2008. De nombreux chercheurs, notamment néophytes, saisiraient un seul caractère pour tenter de déclencher une erreur SQL avant de déclarer définitivement avoir trouvé une erreur. vulnérabilité. Ce message d’erreur indique une faille potentielle d’injection SQL, mais il n’est certainement pas définitif. Il était donc difficile pour la majorité des bases de données de vulnérabilités d’éliminer ce qui était légitime, mais pas VulnDB.

Vulnérabilités d’injection SQL de 2004 à 2013

Pour compléter cela, nous avons constaté des pics importants dans la divulgation de failles de falsification de requêtes intersites (CSRF) dans les applications Web en 2010 et 2012. Ces failles sont relativement faciles à découvrir et jusqu’en 2010, il n’y avait aucune connaissance significative du problème dans les cercles de développeurs. On pourrait dire qu’il en est toujours ainsi compte tenu de la prévalence des failles CSRF, même dans certaines des applications et des produits les plus en vue.

Failles de falsification de requête intersite (CSRF) de 2004 à 2012

Mégavulns : Log4Shell, POODLE, Spectre, etc.

Dans VulnDB, nous avons des entrées tout simplement incroyables. Souvent, les vulnérabilités aux noms familiers tels que Log4Shell, POODLE, Spectre ou Heartbleed pour n’en nommer que quelques-unes, contiennent des milliers de références et plusieurs milliers de produits concernés. Nous avons surnommé ces “mégavulnes” en raison de la taille que chacun représente et de leur prévalence.

En examinant ces mégavulns par nombre de produits concernés, Log4Shell arrive en première place, suivi de POODLE, Spectre v2, Spectre et SWEET32. Bien que le nom soit plus courant que certains répertoriés, Heartbleed n’arrive qu’au numéro douze. En regardant les 30 principaux mégavulns par produit affecté, 10 sont dans le noyau Linux, cinq sont dans OpenSSL, quatre sont dans Oracle Java, quatre sont dans plusieurs fournisseurs de processeurs et trois dans les bibliothèques Apache. Depuis ce blog, Log4Shell est désormais le roi de toutes les vulnérabilités avec le plus de références, de produits uniques, de fournisseurs uniques et de combinaisons fournisseur/produit.

Dans le cadre d’une base de données de vulnérabilités, ces entrées sont difficiles. Lorsqu’on leur donne un nom qui devient populaire en raison de la couverture médiatique qui s’y rattache, davantage de fournisseurs se sentent obligés d’émettre leurs propres avis. Au fur et à mesure que de plus en plus de fournisseurs le font, nous devons agréger toutes ces données et constamment mettre à jour ces entrées. Parfois, nous nous retrouvons toujours à mettre à jour les entrées de mégavuln cinq ans plus tard.

Bizarreries amusantes

En cours de route, nous avons vu des divulgations de vulnérabilité intéressantes, c’est le moins qu’on puisse dire. Il y a vingt-quatre ans, le groupe r00t a publié un avis d’humour noir à Bugtraq avertissant d’une situation de concurrence sérieuse dans un produit LitterMaid. Le bac à litière automatisé pour chat, ont-ils dit, pourrait écraser le chat.forçant l’administrateur à trouver un nouveau meilleur ami.Bien qu’il s’agisse d’un avis parodique, il se démarque toujours comme étant assez amusant.

En plus de la liste des bizarreries, au fil des ans, il y a eu des divulgations liées à Red Star OS, une distribution Linux nord-coréenne. Apparemment, le système d’exploitation souffre de problèmes d’autorisation par défaut, de problèmes d’exécution de code côté client et bien d’autres.

En dehors de cela, d’une manière ou d’une autre, nous voyons toujours des fournisseurs inclure des mots de passe par défaut pour les appareils nouvellement installés plutôt que de forcer un administrateur à en définir un unique lors de l’installation. Pire encore, nous voyons toujours de nouveaux produits sortir avec des mots de passe codés en dur qui ne peuvent pas être modifiés par l’administrateur. Avec tant de choses qui passent à l’approche « Internet des objets » (IoT), celles-ci incluent les systèmes d’irrigation, les thermostats, les éoliennes, les systèmes de contrôle des bâtiments, etc.

Mythes et NAV

Au moment de la publication, VulnDB a officiellement franchi le seuil des 300 000 vulnérabilités légitimes. Bien que nous ayons annoncé que VulnDB avait atteint 300 000 entrées de vulnérabilités, les praticiens doivent être conscients qu’une source complète de renseignements sur les vulnérabilités recueille également des divulgations “illégitimes”. L’inclusion de ces types d’entrées est précieuse pour les clients et ne doit pas être interprétée comme une tactique pour gonfler les chiffres. En incluant les entrées “Mythe/Faux” ou “Pas une vulnérabilité”, alias NAV (un bogue de stabilité valide, mais pas une vulnérabilité), nos clients peuvent rapidement déterminer que nous avons évalué le problème et l’avons clairement marqué comme tel, avec des raisons telles que pourquoi, les empêchant de perdre leur temps.

Cela vaut la peine de revenir brièvement sur ces divulgations illégitimes, car elles font partie intégrante de notre vie. Le premier que nous avons répertorié, un débordement de buffer local dans le programme ‘su’ sur Slackware Linux, remonte à août 1998. Après la révélation, le modérateur de Bugtraq a fait remarquer que personne n’avait pu le reproduire, et depuis l’exploit code était dérivé de quelque chose qu’il avait publié, il était considéré comme une source faisant autorité de deux manières. Depuis lors, le problème des divulgations invalides est devenu énorme.

Numéros arbitraires et informations sur la façon dont nous sommes arrivés ici

Avant de terminer ce voyage amusant à travers le bon, le mauvais et le bizarre, nous partagerons quelques chiffres arbitraires et d’autres bribes d’informations sur la façon dont nous en sommes arrivés là. Certains peuvent se demander quelle vulnérabilité est en fait la première à apparaître dans VulnDB. Ce seraitColdFusion Application Server exprcalc.cfm Paramètre OpenFilePath Divulgation arbitraire de fichiers“. Beaucoup verront ColdFusion et auront divers sentiments, y compris du mépris, en particulier les administrateurs chargés des systèmes de sécurité avec lesquels il est installé.

L’entrée 300 000 de VulnDB a fini par êtreLinux Kernel SCSI WRITE SAME Command NDOB Bit Handling NULL Pointer Dereference Local DoS“. Un petit secret à propos de l’équipe VulnDB : nous faisons de notre mieux pour nous assurer que les vulnérabilités étranges, amusantes ou très médiatisées se retrouvent sur de grands nombres. À l’origine, nous avions choisi une vulnérabilité dans “Oracle Unbreakable Linux” pour notre 300 000e entrée, mais un examen ultérieur a montré qu’il s’agissait plutôt d’une vulnérabilité dans le noyau Linux. Déjoué à nouveau.

VulnDB est la source la plus complète d’informations sur les vulnérabilités disponible, détaillant plus de 300 000 vulnérabilités affectant toutes sortes de bibliothèques et dépendances informatiques, OT, IoT et tierces. Grâce à VulnDB, les équipes de sécurité disposent de tout ce dont elles ont besoin pour identifier les vulnérabilités connues affectant leurs actifs déployés et les corriger ou les atténuer. Inscrivez-vous pour un essai gratuit dès aujourd’hui.

Leave a Comment

Your email address will not be published. Required fields are marked *