Vent de panique dans le monde de la sécurité informatique : une faille zero-day dans l'utilitaire Java de journalisation open source Log4j a été révélée publiquement la semaine dernière (jeudi 9 décembre) et est actuellement en train d'être massivement exploitée dans le monde, permettant aux hackers une prise de contrôle total sur les serveurs et environnements impactés.
La vulnérabilité "Log4Shell", qui pour la petite histoire a été identifiée pour la première fois dans le célèbre jeu Minecraft, a rapidement été recensée dans le CVE (Common Vulnerabilities and Exposures), un dictionnaire des informations publiques relatives aux vulnérabilités de sécurité.
La faille est confirmée et classée comme sévère par l'organisme américain, celle-ci permettant l'exécution de code à distance sans nécessiter d'authentification là où l'outil Log4j se retrouve utilisé. La vulnérabilité est d'autant plus préoccupante du fait de l'omniprésence de l'utilitaire de gestion de logs dans la majorité des applis et serveurs d'entreprise reposant sur la techno Java.
Les chercheurs de la plateforme LunaSec, a qui revient la découverte et le nom de la faille Log4Shell, tiennent également à alerter sur le fait que tout projet embarquant le framework Apache Struts (qui permet la création d'applis web en JEE en fonctionnement MVC) est "très probablement vulnérable".
Parmi les services touchés par cette faille majeure, les grands noms de la tech ne sont pas épargnés : à ce jour, Log4Shell a déjà impacté les environnements d'Apple (notamment son service iCloud), Amazon, Cloudflare, Twitter, Steam, Baidu ou encore Elastic, sans qu'aucune preuve d'exploitation de la faille n'ait encore pu être relevée dans certains cas.
Dans le détail, les systèmes impactés sont ceux embarquant Apache Log4j dans ses versions 2.0 à 2.14.1. De nombreux organismes de sécurité appellent ainsi à effectuer une migration de toute urgence vers la version 2.15.0 de Log4j.
Afin de savoir si elle sont affectées par cette vulnérabilité, les entreprises peuvent examiner leurs fichiers de logs générés par les versions de Log4j concernées, et vérifier la présence d'éventuelles chaînes de caractères contrôlées par l'utilisateur (par exemple : "jndi:ldap").
Si la migration n'est pas réalisable dans l'immédiat, il est possible de limiter l'étendue de la faille en passant le paramètre log4j2.formatMsgNoLookups à true via l'ajout de l'option qui suit au lancement de la JVM :
-Dlog4j2.formatMsgNoLookups=true
Pour plus de documentation sur cette faille, vous pouvez consulter le bulletin d'alerte publié vendredi dernier et tenu à jour ce week-end par le CERT français (centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques).
Et bien évidemment, force à toutes celles et tous ceux d'entre vous qui vont avoir un peu de boulot cette semaine pour gérer ces migrations et checker les logs.
