Log4Shell : une faille de taille découverte dans un plugin Java d'Apache

Vu l’importance que représente un serveur web, avoir des logs — c’est-à-dire des fichiers d’historique des actions effectuées par le logiciel — est une chose quasi indispensable. Et, dans le genre, la bibliothèque Log4J développée par Apache est un incontournable. Open source, écrit en Java et polyvalente, son rôle est tout simplement d’effectuer ces actions d’archivage, possiblement en réseau via l’API JNDI et le support du protocole LDAP.

Découverte a priori de par son exploitation sur un serveur Minecraft, la vulnérabilité se nomme CVE-2021-44228 ou, plus humainement, Log4Shell et fait partie des pires dans le domaine, car offrant la possibilité d’exécuter du code arbitraire sur la machine distante. Pour cela, il suffit de régler son user agent - une information chargée d’identifier l’application accédant à une ressource web en HTTP à une chaine de caractère spécifique contenant du code valide, et voilà que le serveur vulnérable se met à exécuter tout tranquillement ces instructions.

Bien qu’un premier patch — log4j2.15.0 — ait rapidement vu le jour, ce dernier s’est trouvé également troué sur certaines configurations spécifiques, menant à une nouvelle vulnérabilité, 2021-45046 CVE, dans le cas où l’option noMsgFormatLookups ou la commande set % m {nolookups} est activé. Dans ce cas, c’est à la rustine 2.16 qu’il faudra faire confiance : pas facile, tout ça ! Notez que les premières traces d’une exploitation de la faille remontent au premier décembre, et, depuis, des bots scannent le net à la recherche de machines vulnérables. Aïe !

Pour colmater la brèche, une seule solution : mettez à jour immédiatement (les versions concernées étant entre la 2.0 et la 2.14) ! Néanmoins, la popularité de Log4J a mené à son intégration de manière plus ou moins visible dans tout un tas d’autres suites logicielles, dont Apache Struts2, Apache Solr, Apache Druid, and Apache Flink : il est donc nécessaire pour les boîtes privées d’auditer complètement leur infrastructure software afin de vérifier qu’une brebis galeuse ne s’est pas faufilée parmi la multitude des dépendances requises. De plus, du fait de la date récente de la brèche et de la durée limitée entre son officialisation et son patch, des exploitations en masses ont pu avoir lieu — la firme Checkpoint Research annonçant avoir protégé pas moins de 1 272 000 tentatives. Un bon cauchemar pour les sysadmins ! (Sources : Diverses, dont ArsTechnica)