众所周知，被定义和跟踪为 CVE-2021-44228 ，也被称为 Log4Shell 的 Log4j 漏洞，允许攻击者在目标系统中执行任意代码。因此，如果您的应用正在使用Log4j的2.0-alpha1到2.14.1版的话，那么就应当尽快更新到其 最新的版本 (目前为2.16.0)。
对此，瑞士政府发布了一张能够很好地解释该漏洞的被攻击流程图，请参见下图：
下面，让我们根据上图，深入研究与其有关的缓解策略。
使用Maven的依赖项插件
在Maven项目中，您可以通过如下简单命令，在依赖项树(dependencies tree)中搜索log4j-core的相关依赖项，并检查该项目是否使用到了受影响的依赖项。
纯文本
mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core
该命令使用 Maven Dependency Plugin 来显示项目的依赖树(包括各种有传递关系的依赖项)。通过后面的参数，该命令过滤并输出了log4-core的依赖项。因此，如果您的项目正在依赖某个易受攻击的Log4j版本的话，那么您将会看到如下内容：
在这个例子中，由输出可知，该项目直接使用Log4j的2.14.1版。显然，它是易受攻击的。因此，本项目需要将如下依赖项：
XML
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.14.1</version> <!-- update this! -->
</dependency>
替换为：
XML
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.16.0</version> <!-- or newer version -->
</dependency>
同理，我在MariaDB数据库的JDBC连接器项目中，进行了如下测试，并得出了对应的结果：
庆幸的是，该项目并未使用Log4j，因此它不易受到Log4Shell的攻击。更多有关 MariaDB特定案例的信息，请参阅
--https://dzone.com/articles/is-the-mariadb-jdbc-driver-affected-by-the-log4j-v。
使用Maven的帮助插件
如果您想做进一步的调查，则需要检查有效的POM(Project Object Model，项目对象模型)，并搜索项目中使用的日志记录框架。让我们将目光转回刚才的MariaDB JDBC连接器项目，我使用 Maven的帮助插件 ，生成了有效的POM。由于我使用的是类Unix的操作系统(您可以通过截图看到，其实是macOS)，因此我使用如下grep命令(在Windows中，您可以使用findstr)来过滤输出：
纯文本
mvn help:effective-pom | grep log
并且得到了来自mvn的如下输出：
由输出可知，MariaDB JDBC驱动程序使用 Logback 作为日志记录框架。虽然Logback不会受到Log4Shell的影响，但是它带有 1.2.8和1.3.0-alpha11版本中的相关漏洞 。当然，其严重程度要轻得多，我们不必过于恐慌。我查看了其连接器(connector)所使用的版本，该版本号为1.3.0-alpha10。尽管Logback作为测试依赖项，被包含在MariaDB驱动程序中，但我在GitHub上发送了一个 拉取请求 ，以便对其予以更新。在此，我鼓励您也对自己手头的各种开源项目执行类似的操作，以尽早发现那些易受攻击的依赖项。
使用Syft和Grype
在包含了大量JAR文件的更复杂的项目中，您可以使用 Syft 和 Grype 之类的工具。其中Syft是一个CLI(命令行接口)工具和Go语言库，可被用于从容器镜像和文件系统中生成软件物料清单(Software Bill of Materials，SBOM)。Grype则能够通过多级嵌套，去扫描各个容器镜像和文件系统中的漏洞。两者可以协同使用。
使用LunaSec的工具
由开源的数据安全平台开发的 LunaSec 工具，可以通过扫描目录，以及匹配文件散列的方式，来发现是否存在Log4j依赖项的相关漏洞。该工具适用于Windows、Linux 和macOS系统。您只需在相关传递目录，通过如下命令触发该工具的扫描进程即可：
纯文本
log4shell scan your-project-dir
如果目标是一个易受攻击的项目，那么你将会得到如下输出内容：
纯文本
10:04AM INF identified vulnerable path fileName=org/apache/logging/log4j/core/net/JndiManager$1.class path=test/struts-2.5.28-all/struts-2.5.28/apps/struts2-rest-showcase.war::WEB-INF/lib/log4j-core-2.12.1.jar versionInfo="log4j 2.8.2-2.12.0"
使用log4j-scan
此外， FullHunt 团队也提供了一个名为 log4j-scan 的开源工具。作为一个自动且全面的扫描器，它可以被用于查找易受攻击的Log4j主机。也就是说，它能够方便团队扫描自己的基础架构，并测试各种可能导致代码执行的WAF(Web应用防火墙)绕过 攻击 。该工具虽然能够提供多个选项，但是其最基本的服务是，用户可以将待扫描的URL传递给该工具，以便直接获得有关被检测到的漏洞报告。例如，您可以使用如下命令：
纯文本
python3 log4j-scan.py -u https://log4j.lab.secbot.local
其扫描结果的输出为：
使用Huntress Log4Shell漏洞测试器
作为一个在线式开源工具， Huntress Log4Shell漏洞测试器 可以协助您检查，某个应用程序是否使用着Log4j的易受攻击版本。您可以将该工具生成的字符串，作为待检查应用的输入。例如，您可以在某个页面的文本输入框中使用它。该字符串可以包括针对LDAP服务器的JNDI(Java Naming and Directory Interface，Java命名和目录接口)查询。服务器会记录来自应用程序的各个请求，并显示发出此类请求的IP地址。具体操作细节，请参见 演示视频 。
小结
目前，有更多针对Log4j的工具正在涌现。作为安全从业人员，我建议您通过链接
--https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228，关注各类安全专家发布的相关内容。
正如我在上文中对 MariaDB的JDBC连接器 所进行的操作，我同样建议您将相关补丁，发送到任何正在使用Log4j的开源项目中，以及时发现并升级易受攻击的版本。
