众所周知,被定义和跟踪为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
-
-
org.apache.logging.log4j -
log4j-core -
2.14.1 -- update this! -->
替换为:
- XML
-
-
org.apache.logging.log4j -
log4j-core -
2.16.0 -- or newer version -->
同理,我在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的开源项目中,以及时发现并升级易受攻击的版本。
原文标题:How to Check if a Java Project Depends on A Vulnerable Version of Log4j,作者:Alejandro Duarte
原文链接:https://developer.51cto.com/art/202112/696422.htm