Trouver la lib log4J avec PowerShell – Log4Shell

Bonjour à tous, je n’aime pas commenter l’actualité d’habitude mais bon là mon Tweeter est en train de faire une overdose alors je me dis que ça pourra servir à certains si je vous donne de quoi trouver la lib log4J avec PowerShell sur vos système Windows.

Déjà c’est quoi log4Shell ? Alors pour ceux qui ont passé le weekend dans une grotte, Log4Shell est le nom donné à une jolie vulnérabilité sortie vendredi dernier (10/12/2021) qui touche la bibliothèque log4j d’Apache. Les problèmes sont :

1. La vuln est très simple à exploiter (quelques dizaines de caractères bien choisi dans un champs texte, exemples),
2. L’exploit n’est pas du tout aléatoire et que la bibliothèque est très très utilisée dans plein de produits (commerciaux comme open source)…
3. Comme elle est souvent « packagée », elle n’est pas forcément simple à repérer dans son SI.

Je vous laisse faire un tour sur le Github de SwitHak pour avoir une petite idée de l’ampleur du problème.

C’est tellement la fête du slip que No Limit Sécu a (probablement) bousculé son planning de publication et a sorti un épisode dédié sur le sujet hier soir. Il est très intéressant (bien qu’un brin inquiétant) et je vous invite à aller jeter une oreille dessus !

Bref, moi je vous voulais juste vous donner 2 moyens de repérer la présence de bibliothèque sur vos systèmes Windows et dont je me suis servi ce matin :

Version 1 : Trouver la lib log4J par le fichier.

Dans cette version on cherche « bêtement » les noms de fichier correspondant à la bibliothèque sur le système :

> get-childitem C:\log4j*.jar -Recurse

    Directory: C:\path\to\mmyapp\module\lib

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-ar--          26/02/2021    16:01         273454 log4j-api-2.12.2.jar
-ar--          26/02/2021    16:01        1667294 log4j-core-2.12.2.jar

Version 2 : Trouver la lib log4J par le nom de la classe.

Du coup avec la recherche au-dessus, on ne chopera que le fichier qui ont le bon nom. Si le développeur a travaillé « comme un gros sale » et a repackagé la lib. (ou simplement renommé le fichier) : on ne verra rien. Alors , on peut imaginer une deuxième version un peu plus maline qui va chercher le nom de la classe Java qui pose problème dans la bibliothèque directement dans le fichier :

> Get-ChildItem 'D:\' -rec -force -include *.jar -ErrorAction SilentlyContinue | foreach {select-string "JndiLookup.class" $_} | Select-Object -exp Path Path
D:\path\to\mmyapp\module\lib\log4j-core-2.12.2.jar
D:\path\to\mmyapp\module\lib\log4j-core-2.12.2.jar

Bilan

Bref, méfiez-vous, celle-ci elle risque de faire mal (si vous ne faite pas gaffe) ! Et elle fait partie des vulnérabilités dont on va entendre parler quelques temps. Je vous donne une méthode pour évaluer votre exposition :

1. Repartez de la liste de SwitHak.
2. Identifiez les produits présents chez vous.
3. Contrôlez si vos versions de produits sont concernées, en commençant par les services exposés sur Internet puis ceux accessibles uniquement depuis interne.
4. Patchez ! ou mitigez temporairement en désactivant la résolution des « lookups » si possible.
5. Déployez ou mettez à jour l’antivirus qui inclus les signatures fichiers et HIPS, voir au niveau de vos IPS et WAF en réseau.
6. Contrôlez vos autres produits présents sur votre SI (et pas forcément dans la liste), pour éviter d’en louper un.

Pour finir, retenez que ce n’est pas la fin du monde, on en a vu d’autre, genre EternalBlue. Et comme Trouver la lib log4J avec PowerShell n’est pas si compliquée ça va bien se passer. Mais je vous confirme qu’il va falloir vous en soucier là… :’-)

Voilà Gros bisous à tous et loguer bien !