log4j漏洞如何修复（log4j2低版本jndi漏洞修复及测试）

本文目录

• log4j2低版本jndi漏洞修复及测试
• 大数据组件Log4j2漏洞升级
• 分布式 | log4j2 漏洞修复方案
• 怎么检查有没有Apache Log4j漏洞
• Spring-Boot-strater-log4j2怎么修复漏洞
• 由log4j远程执行漏洞说起
• Apache Log4j2远程代码执行漏洞
• 腾讯安全刚刚给出了Log4j2核弹级漏洞线上修复方案！紧急修复
• 烽火狼烟丨Apache Log4j2远程代码执行漏洞（CVE44832）通告

log4j2低版本jndi漏洞修复及测试

参考：

PS:小于2.16还需要检查${{ctx:xxx}}删除

由于低版本(《2.10)的log4j2不支持log4j2.formatMsgNoLookups配置，设置后不会生效。

低版本除了升级版本、修改log4j2的类外，还可以通过简单的修改配置临时解决。

修复方法主要是指定日志不做转义，需要修改log4j2的Layout，即在%m %msg %message后加{nolookups}

修改前为

修改后为

如果有公网可以申请DNSLOG通过DNSLOG的解析记录验证，如果在内网无法访问公网可以启动rmi服务远程调起计算器【这里选择的是Tomcat的一个，可以根据自己的JDK版本选择】
参考： 《JDK 8u191之后的JNDI注入(RMI)》_公众号shadow sock7-CSDN博客

这里简单写个demo打印用户输入参数：

***隐藏网址***

请求后可以看到应用日志中参数已经被转成了ELProcessor对象且计算器被运行了

按照修复方法进行修复后，重新运行应用：

重新执行curl，参数被原样打印：

处理日志信息的类：org.apache.logging.log4j.core.pattern.MessagePatternConverter在初始化时会判断nolookups参数：

在处理日志时，会根据noLookups判断是否处理${}

2.10以后的版本也大致相同：

这个环境变量在2.15后被废弃了,默认是nolookups.

大数据组件Log4j2漏洞升级

方案思路是，在初始化主机的时候加上防火墙策略，集群间开启白名单，对外开放我们需要用到的端口， firewall 可能要用到的语句如下：

其实一些像Zookeeper和Kafka这些用的Log4j是没有啥影响的，但是合作商需要你升级，因为一个漏洞就要把对应组件版本升级不太实际，组件的版本升级我们还需要做版本调研和适配，所以采用的方案是更换 jar包 重新打包，目前基于Java的组件如下： Zookeeper 、 Kafka 、 Flink 、 Elastiserch 、 Neo4j 还有自身的基于SpringBoot基础平台服务。

SpringBoot升级对应log4j2版本即可。

删除jar包

添加jar包

log4j.properties 文件

添加JVM配置，其中 log4j.configurationFile 用于指定log4j2的日志配置文件， zookeeper.jmx.log4j.disable 用于关闭jmx。

删除jar包

添加jar包

删除jar包

添加jar包

删除jar包

添加jar包

Neo4j 我们的版本没有影响，可以参考官方 《Apache Log4j Security Vulnerability》
像 Hadoop 、 Hbase 、 Hive 、 Spark 这些组件我们目前不做调整，有做过适配的欢迎推荐参考资料，因为不排除后期也要做升级处理。

分布式 | log4j2 漏洞修复方案

dble 运行依赖许多组件的 jar 包，当遇到某个组件有漏洞时，需要紧急修复。

***隐藏网址***

***隐藏网址***

：下面介绍的2，3步骤是临时缓解步骤，不排除有其他问题

dble版本：2.19.07.x - 3.21.10.x版本，2.19.07.x之前的版本需要自行尝试替换方案，官方不再提供支持

影响：需要重启 dble

步骤：

1.1 停止 dble

1.2 将 dble 服务器上 log4j 的 jar 包进行备份并 mv 至 /tmp/ 目录下

/path/to/dble/lib 下有四个 jar 包分别是：（操作前需要确认一下）

执行下面的操作：

1.3 将 log4j 2.16.0 版本的相关 jar 包，上传到该路径下/path/to/dble/lib，并变更权限
***隐藏网址***

1.4 重复1.2，1.3步骤升级其余三个jar包

1.5 启动dble

dble版本：理论上全版本dble适配

影响：需要重启dble

步骤：

在 dble 配置文件 /path/to/dble/conf 下添加配置文件 log4j2.component.properties

修改文件权限：

添加如下配置：

验证方式：

开发环境验证该变量重启后被加载，不重启情况下，不会被加载。

dble版本：适用于dble版本 《 3.20.07.0

3.20.07.0及之后的dble版本由于对 JVM 参数进行了限制，因此不支持此种方式，会在近期修复。

影响：需要重启dble

步骤：

在 dble 配置文件/path/to/dble/conf/wrapper.cof 中添加如下配置，并重启dble。

配置：

原环境中是否存在 wrapper.java.additional 的参数，下面配置中的14在原环境中按需替换

执行以下命令判断是否使用该参数启动：

不推荐

怎么检查有没有Apache Log4j漏洞

1、人工检测
jar解压后是否存在org/apache/logging/log4j相关路径结构，判断是否使用了存在漏洞的组件，若存在相关Java程序包，则很可能存在该漏洞。
应用程序能引用 org.apache.logging.log4j的包，很大概率存在漏洞
如果应用程序引用了 log4j-core-2.xx.xx.jar 或 log4j-api-2.xx.x.jar 很大概率存在漏洞。
如果pom文件引用了以下
***隐藏网址***
《dependency》
《groupId》org.apache.logging.log4j《/groupId》
《artifactId》log4j-core《/artifactId》
《version》2.xx.x《/version》
《/dependency》
***隐藏网址***
《dependency》
《groupId》org.apache.logging.log4j《/groupId》
《artifactId》log4j-api《/artifactId》
《version》2.xx.xx《/version》
《/dependency》
也是存在漏洞。
修复方法：
官方补丁
***隐藏网址***
临时解决方案
1. 设置jvm参数 “-Dlog4j2.formatMsgNoLookups=true”
2. 设置“log4j2.formatMsgNoLookups=True”
3. 系统环境变量“FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS”设置为“true”
————————————————
版权声明：本文为CSDN博主「非ban必选」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
***隐藏网址***

Spring-Boot-strater-log4j2怎么修复漏洞

步骤如下：升级springboot到最新v2.5.8和v2.6.2以及后续版本，确保安全；如果单独依赖了log4j2日志，请强制使用最新版本v2.17.1换切换其他日志系统或者追加参数-Dlog4j2.formatMsgNoLookups=true

由log4j远程执行漏洞说起

这几天让IT从业人员忙的不可开交的头等大事便是Log4j的远程执行漏洞了，我们先看一个简单的PoC：

先前往dnslog网站，申请一个子域名，假如是“subdomain.dnslog.cn”。

然后执行java Main ${jndi:ldap://subdomain.dnslog.cn/any}，我们在dnslog网站上刷新请求记录，便会看到申请的子域名被访问了。

如果你是一个开发者，你会知道我们的代码里面毫无疑问充斥着大量这种用法。如果你是一个安全人员，自然知道当恶意访问人员输入时可不只是访问个域名就完事，很有可能把主机密码就传到指定网站了。

那解决的办法在各大厂、安全公司等也已经公布了，无非以下几种：
WAF或防火墙规则，我们先不聊，这个大公司都会做，但并不能完全解除问题。

我们把升级JDK、升级logback、替换成logback以及移除log4j的JNDI相关类都可以看作类库升级。一方面，这些方案都需要一个应用一个应用去执行（甚至有些需要一个一个实例去处理），重复劳动，投入较大；另一方面，兼容性存疑，在升级前必然要做一定的回归测试。此处的兼容性，可以略举一些例子：比如代码里写死了log4j的实现类，而不是slf4j的api时，想要直接替换成logback就不现实。有人可能会说代码规范不允许，但他们忘了，规范和执行是2个相关的事情，但不是必然的因果关系。比如一些只做维护的老系统，存在时间比很多人工龄都长，还有一些是外包产商开发维护的系统，这种情况就是稳定重于一切。

其余几个都是修改配置，但其中略有差异。比如环境变量影响操作系统上所有的应用，如果某个应用JDK版本较高，又刚好需要这个特性，那么就容易产生bug了。修改PatternLayout容易遗漏，比如通常在自己应用的log4j配置文件，但也有可能内部框架做了封装，在jar包有配置，甚至在代码里做了配置。而在log4j2.component.properties添加配置同修改PatternLayout，也还是需要重新打包构建（除非有统一配置中心，并魔改log4j）。

综上来看，我们要避免开发人员修改、避免再次构建，只做重启的话，只能是修改环境变量或添加启动参数了。当然，每个公司有它自己的体系，某些时候大众意义的不好用对于它而言，反而是最简单的。比如，没有自动化（尤其是k8s）的公司，想要改启动参数，运维一个个实例去修改，那简直痛不欲生。

如果我们是log4j的开发人员，当产品经理提出一个需求，即碰到由“${”开头、“}”结尾的日志时，自动做替换，这个需求我们要不要做，怎么做。

刚入行的我是不会问要不要做的，只会想着怎么做，那自然是匹配、解析了。

有一定经验的我则会问这个需求为了解决什么问题，有没有比产品经理提的刚恰当的方式来解决（产品经理资历较浅，或者对产品不够熟悉时）。那我们可以看下log4j这个需求的提交记录最早可以追溯到2013年了，提交记录较多，可以通过代码反向推测需求：类似slf4j，将日志中的占位符替换成真实值，真实值可以延迟计算，计算来源支持扩展。

从代码看，目前已有的扩展包括ctx（日志事件的上下文）、date（日志事件产生的时间）、env（系统环境）、jndi（JNDI上下文获取）、map、sd（结构化事件类型中获取）、sys（系统属性）、web（从web.xml等取ServletContext）

需求是实现了，那还有吗？

如果是一个资深的研发人员就会问了，有预计的使用频率吗，如果使用频率非常高，性能就需要注意不能拖后腿；这个特性如果出现问题，需要关闭，最好能动态关闭；这个特性实际使用了多少次，耗时多少，报错多少；这个是否会在多线程环境下执行，这段代码是否线程安全；用户的输入能否对服务器产生破坏，保存后对其他用户是否产生安全问题。

在一个成熟的企业中，需要考虑诸如此类的问题。当然，很多东西可以模板化，减少开发人员心智，比如CI/CD实践中的自动化测试和DevSecOps。

为什么这次的影响这么大，因为它是基础库，比如dubbo、kafka、flink等很多框架和中间件都用到了它。同时，这从侧面说明log4j2是一个比较值得选取的日志库。

那回到技术选型，以日志为例，我们需要考虑哪些方面呢？

功能。功能是否契合企业需求，缺失功能是否在未来计划，或者扩展实现难度。如果功能都不满足，那自然pass。log4j、logback、log4j2都提供了将日志输出的功能，功能上都能满足，细节根据各企业自身情况而定了。

性能。性能自然是非常重要的，生产是没法debug的，只能通过日志来跟踪某一个事务的情况，如果日志耗时太多，TPS自然受影响，用户体验变差，还可能导致硬件成本上升。log4j2的性能就比logback要出色，logback比log4j要出色。

群众基础和易用性。如果没人会用，使用起来也困难，大概率很难被接受，也很难流行。文档是否介绍了架构设计，也有使用文档，文档是否支持多种语言（本土语言）。log4j2的配置就比较多，特别是想要较高性能时，配置更是复杂。

稳定性与活跃度。生产上使用，肯定要求稳，不可能三五天做一次修复升级。如果功能还未按计划完全实现，那么迭代升级过程中会碰到诸多问题，需要有较多的人提前使用反馈意见做改进，出现问题时，能够通过搜索引擎或其他社群解决。

开源协议。如果不开源，那么使用时心中便会有诸多不安，万一哪个地方有雷都不知道，出了问题，自己能解决的概率也极低。比如MySQL的双协议，要求要么交费，要么开源改动，不如Apache Licence等宽松，导致很多公司开始选择PostgreSQL。

生态。与企业的整套框架是否有冲突，开发流程上是否需要做额外的事情。比如很多框架用了log4j2，贸然引进logback，势必多出工作量来排除log4j2的依赖。比如开发流程工具只支持logback（当然这种场景基本没有），那么使用log4j2就需要再仔细想想了。

架构设计与代码质量。如果代码的架构设计较差，扩展性没设计好，那么企业内部做扩展（二次开发）时，只能修改代码，与源头分叉，后续几乎没法合并，无法反哺开源社区，企业内部后续升级也十分困难。如果代码质量太差，一步一坑，大家直接用脚投票的。

前瞻性。架构设计要有一定的前瞻性，以应对未来的变化。功能建设上也要有一定的前瞻性，实现、验证、上线三者之间还是需要一定时间的。比起等待，大部分人都是想我现在要。

Apache Log4j2远程代码执行漏洞

一、情况分析

近日，监测发现互联网中出现 Apache Log4j2 远程代码执行漏洞。攻击者可利用该漏洞构造特殊的数据请求包，最终触发远程代码执行。由于该漏洞影响范围极广，建议广大用户及时排查相关漏洞。

Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。大多数情况下，开发者可能会将用户输入导致的错误信息写入日志中。此次漏洞触发条件为只要外部用户输入的数据会被日志记录，即可造成远程代码执行。

由于Apache Log4j2在JAVA应用中使用量大，目前已知受影响的组件应用有：Apache Struts2、Apache Solr、Apache Druid、Apache Flink，但问题不仅仅局限在这些项目，用Java开发的系统都有可能用此日志框架。

二、影响范围

Apache Log4j 2.x 《= 2.14.1

三、处置建议

***隐藏网址***

2、升级已知受影响的应用及组件，如spring-boot-start-log4j2/Apache Solr/Apache Flink/Apache Druid

排查方法：到服务器搜索排查Java应用是否引入 log4j-api , log4j-core 两个jar包，影响版本：Apache Log4j 2.x 《= 2.14.1

参考链接

***隐藏网址***

***隐藏网址***

腾讯安全刚刚给出了Log4j2核弹级漏洞线上修复方案！紧急修复

2月9日晚，Apache Log4j2反序列化远程代码执行漏洞细节已被公开，Apache Log4j-2中存在JNDI注入漏洞，当程序将用户输入的数据进行日志记录时，即可触发此漏洞，成功利用此漏洞可以在目标服务器上执行任意代码。

Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。大多数情况下，开发者可能会将用户输入导致的错误信息写入日志中。

因该组件使用极为广泛，利用门槛很低，危害极大，腾讯安全专家建议所有用户尽快升级到安全版本。

高危，该漏洞影响范围极广，利用门槛很低，危害极大。 CVSS评分：10（最高级）

Apache log4j2 》= 2.0,

Apache log4j2 2.15.0

综合国内机构意见，目前针对Apache Log4j漏洞的主要应对方法如下：

1.Apache Log4j 官方已经发布了解决上述漏洞的安全更新，建议受影响的用户尽快升级到安全版本：

安全版本 ：log4j-2.15.0-rc2

官方安全版本下载可以参考以下链接：

***隐藏网址***

2.建议对 Apache Struts2/Apache Solr/Apache Flink/Apache Druid 等已知受影响的应用及组件进行升级

1.设置jvm参数 -Dlog4j2.formatMsgNoLookups=true。

2.设置log4j2.formatMsgNoLookups=True。

3.设置系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 为 true。

4.采用 rasp 对lookup的调用进行阻断。

5.采用waf对请求流量中的${jndi进行拦截。

6.禁止不必要的业务访问外网。

腾讯安全服务解决方案： ***隐藏网址***

烽火狼烟丨Apache Log4j2远程代码执行漏洞（CVE44832）通告

漏洞概述

近日，WebRAY安全服务部监测到编号为CVE-2021-44832的Apache Log4j2远程代码执行漏洞。攻击者可以通过修改配置文件中JNDI 动态及远程获取数据库源处插入恶意代码，造成远程代码执行漏洞，但想要成功利用该漏洞需要攻击者有权限修改Log4j2的配置文件，利用难度较高。WebRAY安全服务部建议相关用户采取安全措施防止漏洞攻击。

Apache Log4j2是Log4j的升级版本，该版本与之前的log4j1.x相比性能显著提升；在修复了一些存在于Logback中固有的问题的同时，提供了很多在Logback中可用的性能。Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影响。

影响范围

2.0-beta7 《= Log4j2《= 2.17.0（不包括安全修复版本 2.3.2 和 2.12.4）

漏洞等级

WebRAY安全服务部风险评级：中危

修复建议

建议用户及时升级到Log4j 2.3.2（适用于Java 6）、2.12.4（适用于Java 7）或 2.17.1（适用于 Java 8 及更高版本），官方下载地址：

***隐藏网址***

注：从2.17.1版本（适用于 Java 8 及更高版本）、2.12.4（适用于Java 7）、2.3.2（适用于Java 6）开始，已删除对LDAP协议的支持，并且 JNDI 连接仅支持JAVA协议。启用JNDI的属性已从“log4j2.enableJndi”重命名为三个单独的属性：log4j2.enableJndiLookup、log4j2.enableJndiJms和log4j2.enableJndiContextSelector。

参考链接

***隐藏网址***

***隐藏网址***

***隐藏网址***