Как проверить, установлен ли Log4j на моем сервере?

Я написал этот скрипт Python, чтобы найти уязвимые версии Log4j2 в вашей системе: https://github.com/fox-it/log4j-finder

Он работает, сканируя диск и внутри файлов Архива Java рекурсивно и ища известные плохие файлы.

Проверка установленных пакетов недостаточна, так как log4jможет быть установлен вручную некоторыми другими приложениями.

Для серверов Linux я использую следующее: find / -iname "*log4j*.jar"

Для серверов Windows можно использовать что-то похожее на это: dir C:*log4j*.jar /s(изменение C:на D:и так далее для других дисков).

Имена файлов обычно показывают версию библиотеки, но для двойной проверки вы можете открыть файл манифеста и прочитать поля версии/реализации.

Обратите внимание, что вышесказанного недостаточно, чтобы поймать встроенный log4j(например: в других jar-файлах). Для этого нужно прогреть соответствующую строку, но это довольно трудоемко и ресурсоемко, поэтому я предлагаю перейти к поиску файлов в качестве первого (но неполного) шага.

lsofпроверяет открытые файлы, размещенные Флорианом Ротомв твиттере:

ps aux | egrep '[l]og4j'
lsof | grep log4j

также две другие команды, но это резидентные команды поиска в памяти

Все попытки устранить уязвимости в log4j терпят неудачу. Вы не можете полагаться на команду locate, так как она выглядит только в наборе настроенных путей ( /etc/updatedb.confв Debian).

Программное обеспечение может устанавливаться в местах, не настроенных в updatedb.conf, и быть полностью пропущено заданием cron, которое обновляет базу данных местоположения.

Кроме того, обнаруживается, что поставщики программного обеспечения (например, Elastic) переупаковали уязвимую JndiLookup.class (например: elasticsearch-sql-cli-7.16.1.jar) в местах, которые ранее не были известны, что оставляет решения неполными, которые построены вокруг известных хэшей файлов, имен или путей.

@shodanshok здесь находится на правильном пути, но вместо того, чтобы явно искать log4j, необходимо заглянуть в каждый «.jar» в системе.

Это более полно, требуется zip-пакет. и продолжение ответа Шоданшока. Это просто покажет места, где находится код JndiLookup.class. Для удаления этих уязвимостей можно было бы добавить еще одну строку, но я бы предпочел оставить это на усмотрение администратора. Ссылка Elastic выше показывает, как:

for jar in $(find / -name '*.jar'); do
   unzip -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Found vulnerability in $jar"
done

Пример:

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

Будьте осторожны при запуске этого в системе с подключенными сетевыми файловыми системами, так как это может повлиять на производительность. В этих случаях необходимо выполнить команды на самом файловом сервере.