Spark et la faille de Log4J

Si vous avez suivi l’actualité informatique de ces derniers jours, alors vous savez qu’une faille de sécurité extrêmement importante ☠️ a été découverte dans la bibliothèque de journalisation des logs Log4J 📁. Malheureusement, de très nombreuses applications l’utilisent aujourd’hui, dont Apache Spark. Il est donc nécessaire de comprendre et se prémunir de cette vulnérabilité au plus vite.

Qu’est-ce que la faille “Log4Shell” ?

La faille Log4Shell permet à un attaquant d’exécuter directement son propre code dans votre application utilisant Log4J pour écrire des logs. A partir ce stade, la personne malintentionnée est susceptible de faire ce qu’elle veut de votre application sans être authentifiée : récupérer les informations présentes dans votre base de données, dans vos serveurs HDFS, supprimer des données importantes, contrôler votre application, etc. Une fois l’attaquant introduit, les actions à sa disposition permettant de vous nuire seront nombreuses ❌.

Pour exploiter cette faille, l’utilisateur a besoin de savoir quelles sont les informations qu’il transmet qui sont logguées dans l’application. Cela peut être un nom d’utilisateur, un token ou un user-agent par exemple. Il peut bien évidemment tenter des actions de type brute force afin de finir par deviner quelles informations transitent par la bibliothèque.

Une fois ceci fait, la personne malveillante va introduire une chaine de caractères spéciales de ce type : {jndi:ldap:8888/classe}. A cause de cette partie jndi, il pourra forcer Log4J à réaliser un appel à l’url spécifié puis ce dernier chargera la classe demandée en mémoire via le système JNDI. Cette classe peut donc contenir n’importe quel type de code frauduleux destiné à nuire à votre application.

Comment s’en prémunir ?

Fort heureusement, la nouvelle a provoqué de telles réactions que les solutions ont rapidement été transmises à l’ensemble du monde informatique. De plus, certaines versions d’Apache Spark ne sont pas vulnérables à cette faille car la version de Log4J utilisée est inférieure à la 2.0, à partir de laquelle le système JNDI a été utilisé. Avant cela, la vulnérabilité n’existait pas.

Pour vous prémunir d’éventuelles attaque, si vous utiliser Spark (ou n’importe quel autre système utilisant Log4J), veillez à bien identifier la version de Log4J utilisée sur votre cluster (par exemple avec mvn dependency:tree si vous utilisez Maven ou avec `sbt "inspect tree clean"si vous utilisez SBT). Voici ensuite ce qu’il faut faire :

• Si la version est supérieure ou égale à 2.10.0 :
  - Mettez à jour la version de Log4J pour qu’elle soit supérieure ou égale à la 2.17.0 ✅
  - Sinon, vous pouvez également lancer l’application via spark-submiten spécifiant deux paramètres supplémentaires :conf “spark.executor.extraJavaOptions=-Dlog4j2.formatMsgNoLookups=True”`et “spark.driver.extraJavaOptions=-Dlog4j2.formatMsgNoLookups=True”. Cela fera en sorte qu’aucun appel JNDI ne soit réalisé. Cependant, la mise à jour vers la dernière version de Log4J est recommandée car l’attaquant pourrait quand même trouver un chemin alternatif afin de désactiver cette option ✅
• Si la version est comprise entre 2.0.0 et 2.10.0 : modifiez le format des Strings à logger en remplaçant %m par %m{nolookups} ✅
• Si la version est inférieure à 2.0.0, alors l’API de Log4J n’expose pas JNDI, mais il est peut tout de même être intéressant de vous remettre à jour !
• Certaines version de Java récentes permettent de prémunir de cette attaque car la valeur par défaut d’une propriété empêche l’exécution de code via JNDI. Il s’agit des versions situées après 6u211, 7u201, 8u191 et 11.0.1 ✅

Ouf !

Voilà, si vous avez bien suivi ces conseils, vous avez évité à votre entreprise ou votre application un potentiel incident très fâcheux ! Cet article n’a pas été écrit dans le but de vous faire peur, mais simplement de vous faire prendre conscience de la facilité de vous protégez d’une faille de sécurité très importante.

J’espère que ce post vous aura plu, n’hésitez pas à vous abonnez !

Je vous dis à bientôt dans un prochain article ! 👋