Введение

В настоящее время сообщает версии log4j-core 2.3.2, 2.12.4 и 2.17.1 как _SAFE_, 2.3.1, 2.12.2, 2.12.3, 2.15.0, 2.16.0 и 2.17.0 как _OKAY_ и все остальные версии как _VULNERABLE_ (хотя для версий до 2.0-beta9 сообщается _POTENTIALLY_SAFE_). Старые версии log4j-1.x помечает как _OLD_.

Корректно обнаруживает log4j внутри исполняемых spring-boot jar/war, зависимостей, смешанных в uber jars, затенённых (shaded) jar, и даже распакованных jar-файлов, просто лежащих на файловой системе (т.е. *.class).

Мы поддерживаем коллекцию log4j-samples, которую используем для тестирования.

Пример использования:

Понимание результатов

_VULNERABLE_ -> Вам необходимо обновить или удалить этот файл.

_OKAY_ -> Мы сообщаем это для версий Log4J 2.3.1, 2.12.2, 2.12.3, 2.15.0, 2.16.0 и 2.17.0. Рекомендуем обновиться до 2.17.1.

_SAFE_ -> В настоящее время мы сообщаем это только для версий Log4J 2.3.2, 2.12.4 и 2.17.1 (и выше).

_OLD_ -> Вы защищены от CVE-2021-44228, но следует запланировать обновление, так как Log4J 1.2.x находится в статусе EOL уже 7 лет и содержит несколько известных уязвимостей.

_POTENTIALLY_SAFE_ -> Файл "JndiLookup.class" отсутствует: либо из-за очень старой версии Log4J (до 2.0-beta9), либо кто-то уже удалил этот файл. Убедитесь, что это сделал кто-то из вашей команды или компании, если это так, поскольку злоумышленники, как известно, сами удаляют этот файл, чтобы предотвратить доступ других конкурирующих атакующих к скомпрометированным системам.

Использование

Сборка из исходников:

Тестирование:

Мы поддерживаем коллекцию образцов log4j здесь: https://github.com/mergebase/log4j-samples

Лицензия

GPL версии 3.0

Часто задаваемые вопросы

Как это работает?

Компилятор Java сохраняет строковые литералы непосредственно в скомпилированных файлах *.class. Если log4j-detector обнаруживает файл с именем "JndiManager.class" в вашей файловой системе, он затем проверяет этот файл на наличие строки: "Invalid JNDI URI - {}". Оказывается, этот конкретный строковый литерал присутствует только в исправленной версии Log4J (версия 2.15.0). Любые версии Log4J без этой строки уязвимы.

Тот же метод анализа файлов *.class на предмет строковых литералов дополнительно расширен для точного обнаружения безопасных версий 2.3.2, 2.12.4 и 2.17.1.

Этот сканер сообщает только о попаданиях по библиотеке log4j-core. А как насчёт log4j-api?

Многие сканеры (включая Dependabot от GitHub) в настоящее время сообщают как о библиотеках "log4j-core", так и "log4j-api" как об уязвимых. Эти сканеры неверны. В настоящее время не существует версии библиотеки "log4j-api", которая могла бы быть использована любой из этих уязвимостей.

В MergeBase мы гордимся точностью нашего сканирования. Вы и так достаточно заняты исправлениями и защитой своих систем. Мы не хотим, чтобы вы тратили время на ложные срабатывания. Именно поэтому мы не сообщаем о попаданиях на log4j-api.

Почему сообщается о версиях 2.3.1, 2.10.0, 2.12.2, 2.12.3, 2.15.0, 2.16.0 и 2.17.0?

Версия 2.10.0 важна, поскольку это первая версия, в которой уязвимая "функция поиска сообщений" Log4J может быть отключена через конфигурацию Log4J.

Версия 2.12.2 важна, так как это совместимая с Java 7 версия Log4J, которая не уязвима для CVE-2021-44228.

Версии 2.15.0 и 2.16.0 важны, поскольку это первые версии, в которых конфигурация Log4J по умолчанию не уязвима для CVE-2021-44228.

А версии 2.3.2, 2.12.4 и 2.17.1 важны, поскольку они не уязвимы для недавно обнаруженных CVE, таких как CVE-2021-45046 и CVE-2021-45105. Несмотря на то, что это гораздо менее серьёзные уязвимости, мы ожидаем, что все захотят обновиться до одной из версий 2.3.2, 2.12.4 или 2.17.1.

Что означают результаты вида "file1.war!/path/to/file2.zip!/path/to/file3.jar!/path/to/log4j.jar"?

"!" означает, что log4j-detector вошёл в zip-архив (например, *.zip, *.ear, *.war, *.aar, *.jar). Поскольку zip-файлы могут содержать zip-файлы, один результат может содержать более одного символа "!" в своём результате.

Примечание: log4j-detector рекурсивно входит только в zip-архивы. Он не входит в tar, gz, bz2 и т.д. Основная причина в том, что Java-системы часто настраиваются на выполнение jar внутри jar, но они никогда не настраиваются на выполнение других форматов файлов (насколько мне известно!). Поэтому копия log4j внутри *.tar.gz, вероятно, недоступна для работающей Java-системы и, следовательно, не является уязвимостью, о которой стоит сообщать.

2-е примечание: для zip-внутри-zip наш сканер загружает внутренний zip полностью в память (используя ByteArrayInputStream) перед попыткой его сканирования. Возможно, вам потребуется выделить Java дополнительную память, если в вашей системе есть очень большие внутренние zip-файлы (например, 1 ГБ и более).

А что насчёт Log4J 1.2.x?

Только версии Log4J 2.x (от 2.0-beta9 до 2.14.1) уязвимы для CVE-2021-44228.

Как я могу быть уверен, что это не троян, маскирующийся под детектор Log4J?

Отличный вопрос! Поскольку мы включаем полный исходный код здесь, на Github (все 2500 строк Java), а также шаги по его сборке, и поскольку этот инструмент не имеет зависимостей, вам не потребуется много времени, чтобы тщательно изучить код для вашего удовлетворения. Если вы не доверяете Maven, вы можете перейти прямо в каталог "src/main/java/com/mergebase/log4j" и набрать "javac *.java". Это тоже работает!

Мы также подписываем предварительно скомпилированный jar, который находится в корне репозитория (./log4j-detector-2021.12.29.jar), ключом подписи кода MergeBase. Пожалуйста, выполните "jarsigner -verbose -verify log4j-detector-2021.12.29.jar", чтобы подтвердить это.

Что такое MergeBase?

MergeBase — это компания в области SCA (Software Composition Analysis), базирующаяся в Ванкувере, Канада. Мы похожи на такие компании, как Snyk, Sonatype, Blackduck и т.д., в том, что помогаем компаниям обнаруживать и управлять уязвимыми библиотеками с открытым исходным кодом в их программном обеспечении. Загляните к нам! У нас отличная точность, отличная поддержка языков, и мы не слишком дороги: mergebase.com/pricing.

Мы будем рады, если кто-нибудь воспользуется 2-недельной бесплатной пробной версией нашего продукта SCA! И если вы напишете нашему генеральному директору ([email protected]) с темой "log4j-detector", мы продлим вашу пробную версию до 4 недель.