log4j-detector - A public open sourced tool. Log4J scanner that de

项目说明

<h1><img src=' alt='mergebase logo' /></a></h1>

<h1>Log4-detector</h1>

Scanner that detects Log4J to help teams assess their exposure to C (CRITICAL), C, C, and C. Can search for Log4J instances by carefully examining the complete file-system, including all installed applications. It is able to find Log4J instances that are hidden several layers deep. Works on Linux, Windows, and Mac, and e else Java runs, too!

Table of Contents

Introduction

Example Usage

More Example Usage

Understanding The Results

Usage

Build From Source

Testing

License

Frequently Asked Questions

- How Does It Work?
- This Scanner Only Reports Hits Against The log4j-core Library. What About log4j-api?
- Why Report About 2.10.0, 2.15.0, and 2.16.0 ?
- What are those "file1.war!/path/to/file2.zip!/path/to/file3.jar!/path/to/log4j.jar" results about?
- What About Log4J 1.2.x ?
- How Can I Be Sure This Isn't A Trojan Pretending To Be A Log4J Detector?

What Is MergeBase All About?

Introduction <a name="itemdetector"></a>

Currently reports log4j-core 2.3.2, 2.12.4, and 2.17.1 as \_SAFE\_, 2.3.1, 2.12.2, 2.12.3, 2.15.0, 2.16.0, and 2.17.0 as \_OKAY\_ and all other as \_\_
(although it does report pre-2.0-beta9 as \_POTENTIALLY_SAFE\_). It reports older log4j-1.x as \_OLD\_.

Can correctly detect log4j inside executable spring-boot jars/wars, dependencies blended
into uber jars, shaded jars, and even
exploded jar files just sitting uncompressed on the file-system (aka *.class).

We currently maintain a collection of log4j-samples we use for testing.

Example Usage: <a name="itemmore"></a>

Understanding The Results <a name="itemresults"></a>

\_\_ -> You need to upgrade or remove this file.

\_OKAY\_ -> We report this for Log4J 2.3.1, 2.12.2, 2.12.3, 2.15.0, 2.16.0, and 2.17.0. We recommend upgrading to 2.17.1.

\_SAFE\_ -> We currently only report this for Log4J 2.3.2, 2.12.4, and 2.17.1 (and greater).

\_OLD\_ -> You are safe from C, but should plan to upgrade because Log4J 1.2.x has been EOL for 7 years and has several known-.

\_POTENTIALLY_SAFE\_ -> The "JndiLookup.class" file is not present, either because your of Log4J is very old (pre 2.0-beta9), or because someone already removed this file. Make sure it was someone in your team or company that removed "JndiLookup.class" if that's the case, because attackers have been known to remove this file themselves to prevent additional competing attackers from gaining access to compromised systems.

Usage <a name="itemusage"></a>

Build From Source: <a name="itembuild"></a>

Testing: <a name="itemtesting"></a>

We maintain a collection of log4j samples here:

License <a name="itemlicense"></a>

GPL 3.0

Frequently Asked Questions <a name="faq"></a>

How Does It Work? <a name="itemwork"></a>

The Ja stores String literals directly in the compiled *.class files. If log4j-detector detects a file
named "JndiManager.class"
on your file-system, it then examines that file for this String: "Invalid JNDI URI - {}". Turns out that specific String
literal is only present in the patched of Log4J ( 2.15.0). Any of Log4J without that String are
.

This same technique of examining *.class files for String literals is further extended to accurately detect safe
2.3.2, 2.12.4, and 2.17.1.

This Scanner Only Reports Hits Against The log4j-core Library. What About log4j-api? <a name="itemapi"></a>

Many scanners (including GitHub's own Dependabot) currently report both "log4j-core" and "log4j-api" libraries as . These scanners are incorrect. There is currently no existing of the "log4j-api" library that can be exploited by any of these .

At MergeBase we pride ourselves on our scan accuracy. You're already busy enough patching and defending your systems. We don't want you to waste your time with false positives. That's why we don't report any hits against log4j-api.

Why Report About 2.3.1, 2.10.0, 2.12.2, 2.12.3, 2.15.0, 2.16.0, and 2.17.0 ? <a name="item2.10.0"></a>

2.10.0 is important because that's the first where Log4J's "message lookup feature" can be disabled configuration.

2.12.2 is important because it's a Java 7 compatible of Log4J that is not to C.

2.15.0 and 2.16.0 are important because these are the first where Log4J's default out-of-the-box configuration is not to C.

And 2.3.2, 2.12.4, and 2.17.1 are important because they are not to more recently discovered CVEs such as C and C.
Despite these being much less serious , we anticipate e will want to patch to one of 2.3.2, 2.12.4, or 2.17.1.

What are those "file1.war!/path/to/file2.zip!/path/to/file3.jar!/path/to/log4j.jar" results about? <a name="itemwar"></a>

The "!" means the log4j-detector entered a zip archive (e.g., *.zip, *.ear, *.war, *.aar, *.jar). Since zip files can
contain zip files, a single result might contain more than one "!" indicator in its result.

Note: the log4j-detector only recursively enters zip archives. It does not enter tar or gz or bz2, etc. The main reason
being that Ja are often configured to execute jars inside jars, but they are ne to execute other
file formats (that I know of!). And so a log4j copy inside a *.tar.gz is probably not reachable for a running Java
system, and hence, not a worth reporting.

2nd note: for zips-inside-zips our scanner does load the inner-zip completely into memory (using ByteArrayInputStream)
before attempting to scan it. You might need to give Java some extra memory if you ha large inner-zips on
your system (e.g., 1 GB or larger).

What About Log4J 1.2.x ? <a name="item1.2.x"></a>

Only of Log4J 2.x (from 2.0-beta9 to 2.14.1) are to C.

How Can I Be Sure This Isn't A Trojan Pretending To Be A Log4J Detector? <a name="itemtrojan"></a>

Great question! Since we include the complete source code here in Github (all 2500 lines of Java), as well as the steps
to build it, and since this tool has zero dependencies, it shouldn't take too long to carefully study the code to your
satisfaction. If you don't trust Maven you can go directly into the "src/main/java/com/mergebase/log4j" directory and
type "javac \*.java". That works, too!

We also sign the pre-compiled jar we keep in the root of the repository (./log4j-detector-2021.12.29.jar) with the
MergeBase code signing key. Please run "jarsigner - - log4j-detector-2021.12.29.jar" to confirm this.

What Is MergeBase All About? <a name="itemmergebase"></a>

!MergeBase

MergeBase is an SCA company (Software Composition Analysis) based in , Canada. We're
similar to companies like Snyk, Sonatype, Blackduck, etc., in that we help companies detect and manage
open-source libraries in their software. Check us out! We ha accuracy, great language support, and we're not too
expensi: mergebase.com/pricing.

We would be delighted if anyone takes a 2-week free trial of our SCA product! And if you email our CEO () with the subject "log4j-detector" we will extend your free trial to 4-weeks.

项目信息

开发语言：Java

Star 数：640

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕A public open sourced tool. Log4J scanner that detects vulnerable Log4J versions (CVE-2021-44228, CVE-2021-45046, etc) on your file-system within any application. It is able to even find Log4J instances that are hidden several layers deep. Works on Linux, Windows, and Mac, and everywhere else Java runs, too! TAG_OS_TOOL, OWNER_KELLY, DC_PUBLIC展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。