Comment vérifier si Log4j est installé sur mon serveur?

En m'excusant pour la référence à du matériel extérieur, j'espère que cela sera tolérable dans la situation actuelle.

Les informations que Lunasec.io a publiées sur les hashs de fichiers binaires Java .class vulnérables :

https://github.com/lunasec-io/lunasec/blob/master/tools/log4shell/constants/vulnerablehashes.go

Voir également leur blog : https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/

Si vous avez des hashs ordonnés (un par ligne) de classes suspectes dans un fichier hashes et que vous avez un fichier jar subject.jar ainsi que les commandes unzip, find et sha256sum, alors vous pouvez faire une comparaison avec les hashs connus grâce à :

JARFILE=subject.jar; DIROUT=$(mktemp -d); unzip -qq -DD "$JARFILE" '*.class' -d "$DIROUT" && find "$DIROUT" -type f -not -name "*"$'\n'"*" -name '*.class' -exec sha256sum "{}" \; | cut -d" " -f1 | sort | uniq > "$JARFILE"-hashes; rm -rf -- "$DIROUT"

comm -12 hashes subject.jar-hashes

Si comm affiche un résultat, alors il y a un hash correspondant.

Essayez syft. Il crée un inventaire des composants logiciels (SBOM), que vous pouvez ensuite rechercher pour d'anciennes versions de log4j (fonctionne même avec des images docker).

Quelque chose comme syft dir:/opt/foo-application | grep log4j recherche dans les déploiements conventionnels. syft dir:/ | grep log4j devrait fonctionner pour tout votre serveur.

Passer également vos images docker fonctionne:

# syft -q jacobalberty/unifi:5.13.29 | grep log4j
log4j-api                                 2.12.1                               java-archive
log4j-core                                2.12.1                               java-archive
log4j-slf4j-impl                          2.12.1                               java-archive
tomcat-embed-logging-log4j                8.5.2                                java-archive

Créer un script pour passer toutes vos images docker à syft ne devrait pas être trop difficile, mais vous pourriez trouver de l'inspiration dans ces scripts des miens: https://github.com/debuglevel/syft-grype-utils

John Hammond a publié avec d'autres un service de redirection LDAP hébergé pour que vous puissiez passer toutes ces manigances. https://log4shell.huntress.com/

Les instructions sont simples - Il génère un identifiant client pour vous (il est dans l'URL, ainsi que dans la chaîne d'injection) que vous pouvez poster à n'importe quel formulaire/demande/ou dérivé de demande web.

En général, si vous utilisez quelque chose qui "ne fonctionne pas avec cela car c'est un accès local" alors vous êtes de toute façon en sécurité car il n'y a aucun moyen de transférer à travers votre application basée sur Java.

À noter - Je crois que la majeure partie de la préoccupation devrait être placée au niveau du matériel de gestion réseau L2/L3; Surtout si vous traitez avec un Fournisseur d'Accès Internet ou si votre contenu est servi via un service d'hébergement.

Vérifier les packages installés n'est pas suffisant, car log4j peut être installé manuellement par d'autres applications.

Pour les serveurs Linux, j'utilise la commande suivante : find / -iname "*log4j*.jar"

Pour les serveurs Windows, on peut utiliser quelque chose de similaire : dir C:\*log4j*.jar /s (en changeant C: en D: et ainsi de suite pour d'autres disques).

Les noms de fichiers afficheront généralement la version de la bibliothèque, mais pour vérifier, vous pouvez ouvrir le fichier manifest et lire les champs version/implementation.

Veuillez noter que ce qui précède n'est pas suffisant pour détecter log4j intégré (par exemple : dans d'autres fichiers jar). Pour ceux-là, il faut rechercher la chaîne pertinente, mais cela demande beaucoup de temps et de ressources. Je suggère donc de commencer par une recherche de fichiers en premier lieu (mais incomplète).

Toutes les tentatives ici pour aborder les vulnérabilités dans log4j sont insuffisantes. Vous ne pouvez pas vous fier à la commande locate car elle ne recherche que dans un ensemble de chemins configurés (/etc/updatedb.conf sur Debian).

Les logiciels peuvent s'installer dans des emplacements non configurés dans updatedb.conf et être complètement manqués par la tâche cron qui met à jour la base de données locate.

De plus, on découvre que des fournisseurs de logiciels (comme Elastic) ont reconditionné le fichier JndiLookup.class vulnérable (par ex : elasticsearch-sql-cli-7.16.1.jar) dans des endroits qui n'étaient pas connus auparavant, laissant ainsi les solutions incomplètes qui sont basées sur des empreintes de fichiers, des noms ou des chemins connus.

@shodanshok est sur la bonne voie ici, mais au lieu de rechercher explicitement log4j, il faut examiner tous les '.jar' sur le système.

Ceci est plus complet, nécessite le package zip. et une extension de la réponse de shodanshok. Cela montrera simplement les emplacements où le code JndiLookup.class est trouvé. Une autre ligne pourrait être ajoutée pour supprimer ces vulnérabilités, mais je préfère laisser cela à la discrétion de l'administrateur. Le lien Elastic ci-dessus montre comment :

for jar in $(find / -name '*.jar'); do
   unzip -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Vulnérabilité trouvée dans $jar"
done

Exemple :

# for jar in $(find / -name '*.jar'); do
>    unzip -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Vulnérabilité trouvée dans $jar"
> done
Vulnérabilité trouvée dans /usr/lib/unifi/lib/log4j-core-2.13.3.jar
Vulnérabilité trouvée dans /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.2-SNAPSHOT/minecraft-server-1.15.2-SNAPSHOT.jar
Vulnérabilité trouvée dans /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.1-SNAPSHOT/minecraft-server-1.15.1-SNAPSHOT.jar
...

Soyez méfiant lorsque vous exécutez cela sur un système avec des systèmes de fichiers réseau montés car les performances peuvent être affectées. Dans ces cas, vous devez exécuter les commandes sur le serveur de fichiers lui-même.