Il faut bien, à un moment ou à un autre, rendre compte à son DSI bien-aimé et lui expliquer si la dernière faille à la une de tous les sites d’information est grave ou pas. La création d’un beau document PowerPoint animé restera à la charge du lecteur, qu’il adaptera en fonction des goûts de son DSI. Seuls les plus audacieux tenteront la note de service en Word, format en voie de désuétude dans les grandes DSI – « ça prend trop de temps de lire ton truc, là, fais-moi ça en 3 slides ».  

Exemples à la pelle 

Faisons l’exercice en (quasi) direct et prenons une faille à laquelle les chercheurs ont pris soin de donner un joli nom : text4shell. Déjà, on remarque une similitude sémantique avec log4shell, on imagine que ça peut y ressembler. Comme nous partons de zéro, le premier réflexe est de googleliser le mot pour voir ce qu’on a. Tout autre moteur de recherche sérieux fera également l’affaire. Vous pouvez également vous entrainer avec openSSL qui vient d’être mise au jour.

Au moment de l’écriture de cet article, la vulnérabilité n’a que quelques jours et déjà nous trouvons tout un tas d’images illustratives que vous pourrez facilement coller (en respectant les droits d’auteur et les copyrights) dans votre PPT. Rien qu’à la vue de ces images, nous en apprenons beaucoup sur cette faille :  

• Elle est située dans un composant nommé « Apache Common Text » de la fondation Apache, ce qui n’est pas rien, et ce qui laisse présager d’un usage assez répandu ; 
• Elle a un identifiant standard CVE-2022-42889, sur lequel on va vite revenir ; 
• On voit qu’elle est probablement déjà exploitée : un article sur medium.com « Text4Shell exploit Walkthrough », qu’on peut traduire par « procédure d’exploitation de Text4Shell » ; 
• Des éditeurs de solutions de sécurité ont déjà communiqué sur la faille et proposent des conseils ou des scanners de vulnérabilité (ben tiens). 

Et tout cela en une seule recherche sur internet… C’est un bon début, mais ce n'est pas tout : nous disposons d’une petite base d’informations générales, creusons un peu.  

Un identifiant standard : CVE

Il est évident que si chacun donne un petit nom à cette vulnérabilité, tout le monde va se retrouver face à un b$# ! sans nom. Une organisation à but non lucratif américaine (MITRE) s’est chargée d’ordonner tout cela dans un référentiel public, en respectant des règles de nommage ainsi qu’un code de conduite. Chaque vulnérabilité est donc identifiée par un numéro CVE (Common Vulnerabilities and Exposures) unique, ce qui facilite le partage d’information. Ce numéro est composé d’un préfixe « CVE » suivi de l’année d’inscription puis d’un numéro de séquence.

Plus précisément, différents organismes sont autorisés à gérer des CVE sous le contrôle du MITRE. Chaque organisme est appelé CNA (CVE Numbering Authority) et doit respecter un certain nombre de règles dont l’engagement de disposer d’une politique de divulgation suffisamment responsable pour que cela ne se transforme pas en marché pour pirate en herbe. Parmi ces CNA, on trouve de DHS (Department of Homeland Security) via le CISA (Cybersecurity & Infrastructure Security Agency) aussi bien que l’agence européenne ENISA et des sociétés privées comme HackerOne ou Rapid7. Il y en a actuellement environ 250.

Comme nous disposons déjà d’un numéro CVE, allons faire un tour sur le site du MITRE à la recherche de la CVE-2022-42889.

On sait maintenant quelles versions sont touchées (les versions à partir de 1.5 jusqu’à 1.9, la version 1.10.0 corrigeant le problème). On dispose également d’une liste de liens fournissant des informations sur cette CVE.

Le premier lien est celui de l’éditeur (la fondation Apache) qui explique techniquement la faille. Vous pouvez regarder, et c’est encore une histoire de lookup, comme dans log4shell. Le site de netapp.com nous communique de nouvelles informations :

On y voit les impacts possibles (en gros : fuite d’information, modification d’informations, déni de service) et un score. On retrouve les mêmes informations sur le site de SonicWall, mais avec une précision supplémentaire de CWE (« CWE-94 »). Nous détaillerons tout cela plus bas.

SonicWall étant un éditeur de solutions qui utilise Apache Text Commons, ses équipes de sécurité ont commencé à établir les impacts de cette vulnérabilité sur leurs produits.

L’analyse de SonicWall

En quoi est-ce important ? Tout simplement parce qu’en tant qu’utilisateur (ou en tant que DSI), vous n’êtes pas nécessairement informé que les produits SonicWall utilisent cette bibliothèque et donc qu’ils peuvent être à leur tour vulnérables. Par contre vous êtes censé savoir si vous utilisez ou pas des produits SonicWall…

Il peut donc s’avérer utile d’aller fouiller sur les sites des éditeurs des produits informatiques que vous utilisez pour savoir si cette faille les concerne (et donc vous concerne) ou pas, le plus difficile étant d’avoir à l’avance à disposition l’inventaire de toutes vos ressources. Ce point est loin d’être anecdotique : comment peut-on espérer défendre correctement un système si vous ne savez pas de quoi il est composé ? On ne répètera jamais assez que la première étape cruciale de la défense d’un système informatique est de connaître les actifs utilisés.

C’est quoi ton genre ?

Avant d’aller sur le score, regardons le CWE. Les CWE sont une liste des problèmes génériques de sécurité pouvant affecter les systèmes informatiques. Et il se trouve qu’un référentiel de ces CWE (Common Weakness Enumeration) est également centralisé par le MITRE ! Ici, la faille est rattachée à la CWE-94, qui s’appelle « contrôle inapproprié de la génération de code, ou injection de code » (« Improper Control of Generation of Code, or Code Injection » in Shakespeare’s language).

Cette information est extrêmement utile, car elle nous donne la nature du problème et donc peut nous orienter vers différentes solutions. En effet, certaines vulnérabilités ne peuvent être corrigées que par l’éditeur, alors que d’autres peuvent faire l’objet de mesures palliatives, plus ou moins efficaces en fonction du contexte. Il ne faut donc pas négliger cette information, malgré son caractère générique. Si votre maturité en sécurité informatique est élevée, vous pourriez même savoir dès ce moment si vous êtes prémunis contre ce genre d’attaque ou si une solution palliative simple peut être mise en œuvre en attendant la correction de l’éditeur.

Pour cette catégorie de vulnérabilité, on dispose d’un catalogue (générique) de « mitigations » (on parle de contre-mesures en français) :

Extrait du référentiel MITRE pour la CWE-94

Parmi les recommandations, on trouve la réécriture de code afin d’éviter une génération dynamique de code, l’utilisation de sandboxes, et bien d’autres. Une contre-mesure est particulièrement intéressante : la validation des entrées. En effet, cette validation devrait être faite du côté du logiciel (et donc de l’éditeur), mais il est également possible d’établir un filtrage en amont, avant qu’on n’arrive au composant impacté, et cette action est réalisable par votre département informatique s’il dispose d’un pare-feu applicatif par exemple, et cela sans attendre la publication du patch éditeur. Ainsi, l’exploitation de la faille sera beaucoup plus difficile et cela sans attendre !

On trouve également des schémas d’attaque (« Related Attack Patterns »), qui est également un autre référentiel géré par le MITRE avant de nous renseigner encore mieux sur les méthodes d’attaques.

Pour notre faille, il y a trois grandes façons de faire :

• • CAPEC-242 : injection de code dans un champ d’entrée de l’application ;

• • CAPEC-35 : modification d’un fichier non exécutable (comme un fichier de paramètre), pour injecter de façon permanente le code voulu (par exemple) ;

• • CAPEC-77 : modifier une variable utilisateur (PHP en prend d’ailleurs un bon petit coup pour son grade dans l’exemple choisi pour illustrer cette méthode).

Dangerosité mesurée

Attardons-nous maintenant sur le score de base de notre CVE. Il s’agit d’une note sur 10 établie à partir de plusieurs critères. Plus on est proche du 10, plus la faille est dangereuse, et on n’en est pas loin ici avec un beau 9,8. Cette note n’est pas attribuée par un CNA mais par le NIST (pour tout simplifier).

La note du NIST pour la CVE-2022-42889

Penchons-nous sur le détail.

Détail du score

Ce score CVSS nous donne encore plus d’informations sur la nature et la dangerosité de la faille. Le charabia CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H est une codification de plusieurs indicateurs (expliquée ici), et nous allons décortiquer le « score de base » pour la CVE-2022-42889 :

• • CVSS: Version du  Common Vulnerability Scoring System (CVSS) utilisée pour calculer le score. La 3.1 dont le cas présent, qui est la dernière en date (depuis juin 2019) ;

• • AV : Vecteur d’attaque. Ici c’est le réseau (N, network) ;

• • AC : Complexité d’attaque, qui peut être low ou high. Ici c’est L (low) et donc cela signifie que l’exploitation de l’attaque est plutôt facile ;

• • PR : Privilèges requis. N signifie None, donc aucun privilège n’est requis pour l’attaque, ce qui est assez embêtant ;

• • UI : Interaction utilisateur. Là aussi la valeur est None, donc aucune interaction n’est nécessaire pour conduite l’attaque (pas même un clic utilisateur) ;

• • S : Scope. Les valeurs sont C (changed) ou U (unchanged). C signifie que l’attaque peut permettre d’aller ailleurs, c’est-à-dire que le périmètre de l’attaque peut s’étendre. Heureusement ici ça n’est pas le cas (U).

Viennent ensuite les évaluations d’impacts sur la confidentialité, l’intégrité et la disponibilité. Les valeurs sont N pour None, L pour Low et H pour High. Et pas de chance : ici, pour ces 3 critères les impacts peuvent être très importants (les 3 sont à H).

Nous avons donc une belle vulnérabilité bien embêtante, relativement facile à mettre en œuvre, et aux impacts potentiellement élevés. Il ne reste plus qu’à se défendre, car pour paraphraser Guillaume Poupard, la meilleure défense reste… la défense ! Mais avec un bon argumentaire, c’est toujours plus facile.

Cet article a été publié à l'origine dans notre Mag#4. Il est maintenant accessible à l'ensemble de nos abonnés.