Qu’ont de si particuliers les exploits observés dans la nature, et comment établir les priorités en conséquence ?

Toutes les vulnérabilités ne se valent pas.S’il est vrai qu’il ne faut jamais ignorer une vulnérabilité open source, certaines peuvent mettre du temps avant d’être exploitées pour pirater votre système. D’autres vulnérabilités connues, en revanche, présentent un risque élevé et immédiat.

Dans un monde où le nombre de vulnérabilités ne cesse d’augmenter, il est difficile de toutes les détecter et de les traiter assez rapidement. On peut imaginer que le volume à lui seul décourage de nombreux responsables de maintenance avant même qu’ils aient pu commencer.

Pour distinguer les différentes vulnérabilités et établir des priorités, nous devons évaluer le risque que chacune présente, déterminer le niveau de risque minimal que nous voulons traiter, puis commencer par là.

L’un des principaux facteurs de risque est la facilité avec laquelle une vulnérabilité spécifique peut être exploitée. Lorsqu’une personne montre comment tirer parti d’une vulnérabilité, on parle d’un exploit. Lorsqu’un exploit est largement diffusé, par exemple dans des articles de blog, sur des forums, sur exploit-db ou dans des frameworks d’exploitation comme metasploit, on parle généralement d’un exploit observé dans la nature.

Seul un faible pourcentage des vulnérabilités connues seront exploitées, autrement dit utilisées pour pirater un système. Les vulnérabilités les plus risquées sont celles qui ont le plus de chances d’être exploitées. Elles doivent donc être traitées en priorité, comme le montre le schéma :

Dans cet article, nous expliquons comment les exploits observés dans la nature accroissent les risques, comment évaluer ces risques et comment établir les priorités pour traiter rapidement vos vulnérabilités.

Apache Struts : un exploit observé dans la nature à l’origine d’une attaque bien réelle

Vous avez probablement entendu parler de la fuite de données chez Equifax, une grande agence d’évaluation du crédit qui a exposé les données hautement personnelles de 145,5 millions de ses clients. La fuite provenait d’une vulnérabilité connue dans un package Apache Struts, pour laquelle des exploits observés dans la nature avaient été publiés quelques jours seulement avant l’attaque. La disponibilité du code d’exploitation a permis aux pirates de s’introduire ensuite dans les systèmes d’Equifax, deux mois après sa publication. Les conséquences ont été dévastatrices. Découvrez les attaques visant Apache Struts dans la chronologie ci-dessous :

Qu’est-ce que la maturité du code d’exploitation, et quelle est son influence sur le risque lié à une vulnérabilité ?

Nous parlons de maturité du code d’exploitation (ou maturité de l’exploit) pour mesurer à quel point une vulnérabilité est exploitable en pratique, dans le monde réel, en fonction des éléments suivants :

• La publication de l’exploit (est-il « observé dans la nature » ?) ; et

• L’utilité réelle des exploits publiés, c’est-à-dire si ces publications permettent réellement d’exploiter plus facilement la vulnérabilité.

Autrement dit, en l’absence d’exploit, il sera probablement plus difficile de tirer parti d’une vulnérabilité. À l’inverse, même si un exploit est disponible, cela ne signifie pas non plus nécessairement que la vulnérabilité reste facile à exploiter.

Facteurs qui influent sur le risque posé par un exploit publié

Dans cet article, examinons deux des facteurs qui influent sur la maturité du code d’exploitation.

Facteur I : est-il facile d’exploiter cette vulnérabilité en pratique ?

Le premier facteur est l’écart entre la théorie académique et sa mise en pratique, ainsi que l’ampleur de cet écart. Pour comprendre les risques posés par un exploit observé dans la nature, nous devons déterminer s’il est :

• Applicable en pratique et utilisable dans le monde réel, ou s’il reste purement théorique ; et

• applicable dans tous les cas, ou limité par certaines conditions.

Un exploit qui n’a été évoqué qu’en théorie peut présenter un risque bien moindre qu’un exploit publié, testé et éprouvé. De même, un exploit qui ne s’applique qu’à 1 % des cas d’utilisation concernés par la vulnérabilité présente un risque bien moindre qu’un exploit montrant comment la pirater facilement quelles que soient les circonstances.

Facteur II : quel niveau d’expertise est nécessaire ?

Le deuxième facteur est le niveau d’expertise nécessaire pour exploiter réellement la vulnérabilité. Faut-il être un pirate expert pour en tirer parti, ou des débutants peuvent-ils aussi le faire ? Plus un exploit est facile à utiliser, plus il a de chances d’être utilisé.

Maintenant que nous avons mis les choses en perspective, il est plus facile de comprendre le lien entre la publication d’un exploit et les vulnérabilités qui finissent par être exploitées. Rien d’étonnant à ce quecette étude montre qu’une vulnérabilité pour laquelle un exploit a été publié a quatre fois plus de chances d’être réellement exploitée. D’autres études affirment même que la publication d’un exploit multiplie le risque par 7 !!

Si nous avons déjà le CVSS, pourquoi avons-nous aussi besoin de la maturité de l’exploit ?

Le Common Vulnerability Scoring System (score CVSS) prend déjà en compte plusieurs facteurs de risque, notamment la maturité du code, qui indique si un code d’exploitation public pertinent est disponible. Cependant, à mesure que le nombre de vulnérabilités connues augmente de façon exponentielle, le système de notation global ne reflète pas toujours le risque réel (ou l’absence de risque) que peut présenter une vulnérabilité donnée. Dans son article de blog publié plus tôt cette année, Liran Tal observait que, si le « score de vulnérabilité est déterminé par différents acteurs reconnus, le système complexe repose sur plus d’une douzaine de caractéristiques clés et, sans conseils, expérience et informations à l’appui, il est facile de se tromper ».

Établir les priorités en fonction de la maturité des exploits : une approche juste et efficace

En établissant les priorités en fonction de la maturité des exploits, nous pouvons repérer efficacement les vulnérabilités les plus risquées et réduire l’ensemble prioritaire à environ 10 % du total. Chez les clients de Snyk, seuls 4 à 12 % des vulnérabilités disposent d’un exploit mature, selon l’écosystème (voir le tableau ci-dessous). Ce résultat concorde avec d’autres chiffres, comme les statistiques présentées ici, qui indiquent que 5,5 % des vulnérabilités publiées font l’objet d’exploits observés dans la nature. 

La proportion de vulnérabilités exploitables parmi l’ensemble des vulnérabilités varie selon les écosystèmes et l’utilisation des packages. Le tableau ci-dessous présente les données moyennes d’un échantillon d’écosystèmes clés chez les clients de Snyk : 

Faut-il corriger les autres vulnérabilités ? Bien sûr. Toute vulnérabilité présente un risque, même si certaines sont plus risquées que d’autres, et il existe de nombreuses autres façons d’établir des priorités — nous les aborderons dans de futurs articles. En bref, puisque chaque vulnérabilité présente un risque, nous devons rester vigilants dans l’établissement des priorités. Pour commencer, le mieux est d’évaluer la maturité du code d’exploitation.

Comment savoir lesquelles de mes vulnérabilités font l’objet d’exploits observés dans la nature ?

Pour accompagner et protéger nos utilisateurs, nous leur permettons désormais d’établir des priorités parmi les vulnérabilités détectées dans leurs projets en fonction de la maturité des exploits !

Nous avons choisi trois niveaux, définis à partir de nos recherches et du CVSS :

• Mature : un code d’exploitation publié, facile à utiliser contre cette vulnérabilité, est disponible.

• Preuve de concept : une preuve de concept théorique publiée ou une explication détaillée montrant comment exploiter cette vulnérabilité est disponible.

• Aucun exploit connu : aucune preuve de concept ni aucun exploit n’a été trouvé pour cette vulnérabilité, ou ces éléments ne sont pas accessibles au public.

Vous pouvez désormais voir si une vulnérabilité donnée fait l’objet d’un exploit observé dans la nature lorsque vous consultez les vulnérabilités de votre projet. Vous pouvez aussi filtrer et hiérarchiser les résultats de vos scans, puis corriger les vulnérabilités en conséquence et consulter un rapport récapitulatif. Vous pouvez ainsi traiter en premier les vulnérabilités les plus importantes et les plus risquées.

Commencez dès maintenant !

Pour commencer, rien de plus simple :

1. Connectez-vous à Snyk et accédez à la page détailléeProjets de l’un de vos projets :

2. Les nouveaux filtres apparaissent sur la gauche :

3. Cliquez surMature pour afficher les vulnérabilités les plus risquées selon la maturité des exploits. Vous pouvez alors commencer à les corriger.

Consultez notre documentation pour en savoir plus.

Et ensuite ?

Maintenant que nous avons lancé la fonctionnalité permettant d’établir des priorités selon la maturité des exploits, nous continuerons à proposer d’autres méthodes de hiérarchisation des corrections de vulnérabilités afin d’aider nos utilisateurs à protéger efficacement leurs dépendances.