Comment Snyk Social Trends vous aide à corriger les vulnérabilités critiques

Récemment, Snyk a ajouté Social Trends à ses données sur les vulnérabilités. Ce nouvel indicateur vous montre quelles vulnérabilités font parler d’elles afin de mieux prioriser leur correction. Notre équipe de recherche a constaté une forte corrélation entre les vulnérabilités qui font parler d’elles sur les réseaux sociaux et l’existence d’exploits susceptibles de nuire réellement à votre application.

Il est tout à fait logique de suivre les tendances concernant les vulnérabilités de sécurité. Lorsqu’une vulnérabilité suscite beaucoup d’intérêt sur les réseaux sociaux, sur Twitter par exemple, cela signifie que de nombreuses personnes connaissent le problème. Statistiquement, cela signifie aussi que davantage de personnes pourraient vouloir vous nuire. Il peut donc être important de porter une attention particulière aux vulnérabilités de votre système qui font parler d’elles sur les réseaux sociaux.

Voyons Snyk Social Trends (analyse des sentiments liés aux vulnérabilités) en action.

Un exemple de vulnérabilité tendance en Java

J’ai créé une petite application Java à partir d’une version obsolète de Spring Boot, 2.2.0-RELEASE. Après avoir connecté le dépôt GitHub à mon compte Snyk, j’ai trouvé la vulnérabilité suivante en tête de liste, car elle fait actuellement parler d’elle sur les réseaux sociaux.

Il s’agit d’une vulnérabilité d’exécution de code à distance (RCE) dans la version embarquée d’Apache Tomcat fournie avec le package Spring Boot Starter que j’utilise. En cliquant sur le bouton indiquant la tendance, j’ai trouvé de nombreux tweets faisant référence à cette vulnérabilité et à un exploit fonctionnel publié. J’y reviendrai plus tard, mais commençons par expliquer la vulnérabilité.

Explication de la vulnérabilité d’exécution de code à distance CVE-2020-9484

Je vais expliquer brièvement le fonctionnement de cette vulnérabilité RCE dans Tomcat. Elle existe dans toutes les versions de Tomcat, y compris la version embarquée fournie avec Spring Boot. Sachez également qu’une mise à jour corrigeant ce problème est déjà disponible pour toutes les versions.

Supposons que vous utilisiez PersistentManager avec un FileStore dans Tomcat. PersistentManager gère les sessions. Une session sert à préserver l’état entre les requêtes du client au serveur. Par défaut, Tomcat utilise StandardManager, qui conserve les sessions en mémoire. En revanche, PersistenManager déplace les sessions vers un espace de stockage lorsqu’elles sont inactives pendant quelques secondes. Il peut s’agir d’un disque avec FileStore ou d’une base de données avec JDBCStore.

Avec FileStore, Tomcat stocke les sessions à un emplacement prédéfini, sous la forme <JSESSIONID>.session. Si une nouvelle requête contenant un identifiant de session ne trouve pas la session en mémoire, PersistentManager recherche les sessions stockées sur le disque et, s’il en trouve une, désérialise l’objet de session stocké en mémoire.

Mais que se passe-t-il si mon identifiant de session ressemble à ceci : JSESSIONID=../../../../../../../foo/mysession ? En raison de la traversée de chemin, Tomcat recherchera mysession.session dans le répertoire foo. Si je parviens à téléverser un fichier sur ce système, je peux y déposer un fichier de session sérialisé. Ensuite, je peux déclencher sa désérialisation en définissant mon JSESSIONID sur l’emplacement correspondant. Selon l’objet sérialisé, la désérialisation déclenche une exécution de code à distance malveillante.

Pour en savoir plus sur les risques des vulnérabilités de désérialisation, consultez l’article de blog Sérialisation et désérialisation en Java : explication de la vulnérabilité de désérialisation Java.

Pour en savoir plus sur cette vulnérabilité dans Tomcat, consultez l’excellent article de redtimmy.com, qui l’explique plus en détail. Vous trouverez une preuve de concept de l’exploit dans ce dépôt GitHub :  https://github.com/masahiro331/CVE-2020-9484

Comment Snyk Social Trends vous aide à vous concentrer sur l’essentiel

Vous pourriez dire que cette vulnérabilité doit remplir plusieurs conditions préalables avant de pouvoir être exploitée.

1. PersistentManager doit être activé avec FileStore

2. Les attaquants doivent pouvoir téléverser un fichier arbitraire

3. Un gadget doit être disponible dans le classpath pour permettre l’attaque par désérialisation

Certaines personnes pourraient estimer que, compte tenu de ces conditions préalables, peu de cas sont réellement exploitables et écarter cette vulnérabilité. Pourtant, vu l’attention considérable qu’elle a suscitée sur Twitter, j’ai examiné la question de plus près et constaté qu’il n’était pas si difficile de remplacer le gestionnaire de session par PersistentManger avec FileStore. De plus, vu le nombre de dépendances que j’utilise dans mon application, il est tout à fait possible qu’un gadget s’y trouve.

Ainsi, si quelqu’un de mon équipe décide d’utiliser PersistentManger avec FileStore, il ne manque plus que la possibilité de téléverser des fichiers arbitraires. Étant donné que les failles de sécurité résultent presque toujours d’une chaîne d’événements menant à un désastre — et non d’un seul événement ou d’une seule vulnérabilité —, je ne pense pas qu’on puisse simplement écarter une vulnérabilité de ce type. Surtout lorsqu’il existe des correctifs.

Plus important encore, si une vulnérabilité fait parler d’elle, cela signifie que beaucoup de personnes la connaissent et en discutent, y compris des personnes mal intentionnées. Pour moi, c’est un signal qui m’incite à examiner cette vulnérabilité de plus près encore, afin de vérifier si je suis exposé aujourd’hui ou si je risque de l’être à l’avenir.

Dans l’interface Snyk, l’indicateur de tendance met la vulnérabilité en évidence et augmente également son score de priorité. Nous pensons donc que l’analyse des réseaux sociaux pour déterminer la popularité d’une vulnérabilité est un outil puissant, qui m’évite de passer à côté d’erreurs de sécurité évidentes et bien connues. Alors, lorsqu’une vulnérabilité porte le marqueur « tendance », nous vous encourageons à y regarder de plus près, même si vous l’aviez écartée auparavant.