L’année dernière a vu apparaître des problèmes logiciels affectant les systèmes d’exploitation et les bibliothèques de logiciels extrêmement populaires.
Problèmes aux effets potentiellement dévastateurs, souvent classés comme exploitable à distance. Cette condition indique comment un attaquant peut tirer parti de ces lacunes sans nécessairement être physiquement proche du système, mais uniquement en avoir une visibilité depuis le réseau ou la logique.
Dans cet article, j'essaie de mieux clarifier certaines différences importantes entre des termes spécifiques, trop souvent utilisés de manière interchangeable (et inappropriée) dans le but de faire sensation ou d'accrocher des clics sur Internet.
Commençons par quelques vérités absolues qu’il me semble important de retenir.
La première est une citation de Gene Spafford, sommité de la cybersécurité : « Le seul système véritablement sûr est celui qui est éteint, déconnecté, enfermé dans une cage en titane, dans un bunker en béton rempli de gaz neurotoxique et gardé par des gardes armés très bien payés. Même dans ce cas, je ne parierais pas ma vie là-dessus. »
La seconde vérité, décidément plus simple à énoncer, réitère plus simplement que "Aucun logiciel n'est parfait".
Définissez-les points de départ, essayons de clarifier la différence importante entre un bug, une vulnérabilité et un exploiter; pour terminer par clarifier l'importance des conditions nécessaires pour pouvoir profiter de ces éléments.
Loin du monde de l'entomologie dont est issu le terme, le bug o Bacchus du logiciel peut être défini comme une imperfection du code due à une erreur de code commise lors du développement. Cette erreur se produit uniquement lorsque certaines conditions sont remplies.
Curiosité connue de tous et certainement de ceux qui persistent à appeler cette erreur buco logiciel est la genèse de ce terme dans le domaine informatique : il dérive en fait de l'époque où les logiciels étaient codés sur des cartes perforées et où les ordinateurs étaient d'énormes armoires souvent situées au sous-sol d'un immeuble ; dans ces armoires métalliques, les différents composants étaient tout sauf miniaturisés et l'espace permettait - sous certaines conditions - la prolifération de petits animaux qui pouvaient se nourrir de cartes perforées comme une chenille se nourrirait d'une pomme mûre croquante. C'est précisément dans ces contextes que l'expression est née bug logiciel qui est resté inébranlable pendant plus d'un demi-siècle en couleur (et un peu ballot) monde des développeurs.
De sorte que d'un bug Cependant, si une vulnérabilité est générée, certaines conditions importantes doivent exister.
La première est que la séquence d'événements qui mène à la bug se montrer au monde, générant les effets néfastes de l'erreur initialement commise par le développeur. Non seulement il est profondément erroné d’utiliser le terme bug et vulnérabilité de manière interchangeable, mais même un bug connu n’est pas synonyme de vulnérabilité.
Pour mieux comprendre cette nuance, essayons d'examiner comment une vulnérabilité est signalée - en nous inspirant de l'organisation américaine d'analyse des menaces MITRE. Parmi les innombrables activités de MITRE, il y a en effet la gestion et la mise à jour d'une base de données de vulnérabilités appelée CVE (Common Vulnerabilities and Exposures).
Vous trouverez ci-dessous un exemple de la façon dont une vulnérabilité est représentée auprès du grand public :
Il apparaît immédiatement que la description du contexte en dit bien plus que les manières possibles d'exploiter le bug sans toutefois donner d'exemples sur le terrain. comme dans la pratique: par exemple, il nous informe que le modèle Omada ER605 du fabricant TP-Link a un problème de débordement de tampon : cela signifie qu'en raison d'une erreur de développement, la mémoire de l'appareil accepte plus de données qu'elle ne pourrait en contenir ; nous indique qu'il n'est pas nécessaire d'être authentifié pour écrire dans cette mémoire ; nous montre comment l'exploitation de ce crépa peut également avoir lieu à distance, avec la qualification de Exécution de code à distance.
Le rapport de vulnérabilité ne dit jamais comment l'exploiter, pour plusieurs raisons valables.
Tout d'abord, cela mettrait en danger ceux qui n'ont pas encore eu le temps de remédier à la situation, si cela était possible, par exemple avec l'application d'une mise à jour logicielle du fabricant ou d'un pièce.
Deuxièmement, le tâche rendre une vulnérabilité exploitable relève de la responsabilité de l'auteur exploiter.
L'exploiter représente un code et/ou une procédure qui, s'il est exécuté, provoque l'erreur qui exploite le bug laissé dans le code du développeur.
En résumé: bug, vulnérabilité ed exploiter ce sont trois entités distinctes, voire conséquentes mais certainement pas synonymes.
La pratique d'analyser les caractéristiques des vulnérabilités, les procédures de remédiation, la disponibilité éventuelle d'une pièce par le fabricant constitue un processus faisant partie des mesures de cybersécurité de chaque entreprise - appelé Gestion de la vulnérabilité et c’est l’un des objectifs les plus ambitieux d’une bonne politique de cybersécurité d’entreprise.
