Impact
Tout ce qui utilise le framework de journalisation d’Apache nommé Log4J est susceptible d’être impacté. Les applications concernées sont généralement reconnaissables au fait qu’elles possèdent le fichier log4j-core.jar.
Les versions déclarées concernées comme faillibles de log4j-core sont :
- De la version 2.0-beta9 à la version 2.12.1 (Java7)
- De la version 2.13.0 à la version 2.15.0 (Java8)
Toutefois, je ne vous recommande pas de vous fier à ces valeurs, car la classe réellement en défaut (JndiLookup.class) est embarquée. J’ai constaté que certains éditeurs avaient repris une version de JndiLookup.class faillible dans un core non répertorié comme faillible.
Quelque soit la version de log4j-core que vous utilisez, je vous recommande de tester et de mitiger. De plus ne cherchez pas seulement si vous utilisez log4j-core mais aussi si vous utilisez directement JndiLookup.class.
Comment chercher si le fichier en défaut est présent sur votre système ?
Sur un système Linux, recherchez tous les .jar log4j-core et vérifiez la présence de JndiLookup.class. Cela ne vous dira pas si vous l’utilisez, mais si vous le possédez. Donc si vous êtes susceptible de l’utiliser.
find / -type f -name "log4j-core-*.jar" -exec unzip -l "{}" \; 2>/dev/null | grep -i JndiLookup.classVérifiez aussi les fichiers .ear, ils peuvent contenir le jar log4j-core.
find / -type f -name "*.ear" -exec unzip -l "{}" \; 2>/dev/null | grep -i log4j-coreLes fichiers .war, :
find / -type f -name "*.war" -exec unzip -l "{}" \; 2>/dev/null | grep -i log4j-coreEt enfin, vérifiez la présence directe de JndiLookup.class.
find / type f -name "JndiLookup.class"log4shell.bash
Voici check_log4shell.bash, un script maison pour scanner vos serveurs Linux.
- Inspecte les fichiers ear, war, class et jar
- 3 modes : default / suspicious / paranoid pour inspecter log4j-core*.jar, *log4j*.jar ou *.jar
- Inspecte les fichiers jar contenus dans les fichiers war
- Inspecte les fichiers META-INF contenus dans les fichiers ear
- Possibilité de changer le chemin de la recherche
- Filtrage des évènements : infos, warnings, errors, statistiques
- Statistiques
Produits impactés
Voici une liste non exhaustive de produits que l’on sait impactés par cette faille :
- RedHat, par le biais d’Openshift et de certains JBoss
- Jenkins, si vous utilisez le plugins Log4J
- Apache SOLR
- VMWare
- Citrix
- Atlassian
- NetApp
- SonarQube
Ce n’est pas parce que vous avec un fichier log4j que vous êtes concerné !!! Encore une fois, la faille est dans la classe JndiLookup.class.
Vérifiez dans le jar la présence du fichier JndiLookup.class avant de paniquer, un .jar est un .zip, utilisez votre décompresseur préféré.
Proof of Concept (POC)
Pour comprendre comment et pourquoi mitiger, il est nécessaire de comprendre le POC.
Celui qui me semble le plus facile à mettre en œuvre et à lire est celui-ci : nw_log4jcheck.py
Il vous faudra Python3 pour l’exécuter. Vous devez changer la valeur de HOSTNAME dans le script avant de vous en servir :
Vous devez aussi créer le répertoire, voire le fichier dans lequel le script écrira ses logs :
mkdir -p /var/log/named
> /var/log/named/query.logCherchez ensuite tout les ports WEB ouverts (Java, httpd, etc.) sur votre plateforme :
netstat -tulpn
Dans cet exemple, l’on peut voir différents ports qui méritent d’être vérifiés :
Les ports 8005 et 8081 (java) ainsi que le port 443 (httpd).
Utilisez le script sur chacun des ports :
python3 ./nw_log4jcheck.py https://siteperso.info:443
Le port 443 est délivré sur ce serveur par Apache (httpd). En regardant les logs générés par le test je peux voir ceci :
"[16/Dec/2021:10:46:29 +0100]" "7499" "HTTP/1.1" "-" "python-requests/2.26.0" "/${jndi:ldap:/56549fb9-f720-455f-a0c0-c40b55693bec.siteperso.info/test.class}" "15.188.192.249" "+" "403" "1147" "GET /$%7Bjndi:ldap://56549fb9-f720-455f-a0c0-c40b55693bec.siteperso.info/test.class%7D HTTP/1.1" "siteperso.info:443" "GET" "-" "-" "-" "-" "TLSv1.3" "TLS_AES_256_GCM_SHA384" "-"En rouge, l’on peut voir l’URL appelée par le POC, il essaie de contacter le service jndi:ldap. On peut observer que le serveur a répondu avec un code HTTP 403 : Forbidden.
Commencez à sérieusement vous inquiéter si vous avez un code HTTP 200.
Les URLS attaquables ne commencent pas uniquement par $jndi:ldap, le POC est focalisé sur ceci mais en voici la liste complète :
- ${jndi:ldap:/}
- ${jndi:ldaps:/}
- ${jndi:rmi:/}
- ${jndi:dns:/}
- ${jndi:iiop:/}
Evidement, selon la technologie du port ouvert, vous devrez aller dans les logs adéquats pour voir ce résultat.
Comment se protéger
L’action prioritaire est de mettre à jour Log4J vers la version 2.16.0, via les gestionnaires de paquets habituels ou via un téléchargement direct depuis https://logging.apache.org/log4j/2.x/download.html.
Il est aussi possible de réduire le degré d’exploitabilité de la vulnérabilité en mettant la variable d’environnement LOG4J_FORMAT_MSG_NO_LOOKUPS à true. Cette contremesure ne fonctionne cependant que pour les versions de Log4J supérieures ou égales à 2.10.
Vous pouvez aussi complètement supprimer la classe du fichier .jar :
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Il n’y a pas de solution propre à ce jour pour corriger si vous êtes en Java7. Supprimez la classe comme ci-dessus, mitigez avec l’option JAVA, protégez les URLS…