log4j2漏洞复现及修复
log4j2漏洞复现及修复
1.漏洞复现
搭建简单maven项目，编写测试方法类：LoggerTest.java
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
/**
* @ClassName:LoggerTest
* @author:dongao
* @date 2021/12/14 13:03
*/
public class LoggerTest {
private static final Logger logger = LogManager.getLogger();
public static void main(String[] args) {
String msg = "${java:vm}";
logger.info("hello,{}",msg);
logger.info("Try${date:YYYY-MM-dd}");
}
}情景一
只引入log4j-core.2.11.1.jar包测试结果：
版本升级为2.15.0.jar包后测试结果：
情景二
只引入log4j-api.2.11.1.jar包会报如下错误：
ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console...报错处理后测试结果：
只升级log4j-api 版本为 2.15.0.jar包后测试结果：
只升级log4j-core 版本为 2.15.0.jar包后测试结果：
同时升级log4j-api、log4j-core 为 2.15.0 后测试结果：
情景三
搭建springboot项目引入log4j-core.2.11.1.jar
版本测试结果：
结果未出现log4j2漏洞问题 如果删除springboot相关jar包，再补充log4j2.xml配置文件，注释掉DemoApplication.java，此时再次测试结果：
此时的项目实际也不再是springboot项目。
2.项目审查
本部门的项目引用的springboot框架的项目，项目本身用的是springboot默认的logback日志，而上例中情景三搭建的springboot项目即使在引入存在安全漏洞jar包log4j-core的前提下,依然不曾检测到漏洞问题，回到项目中，项目ei-crm-admin也是logback日志输出的项目，且测试方法在项目中也未测出漏洞反应，测试结果如下图：
3.结论
1.项目中同时引入log4j-api、log4j-core,需同时升级为 2.15.0 版本jar包，如果只升级log4j-core会出现情景二中异常 2.项目中只是引入log4j-api,可以不用升级，但是如果将log4j2作为日志输出的话还是需要log4j-core，此时升级参考上一条 3.springboot项目即使引入有问题log4j-core版本的jar包也无法出现漏洞反应，而项目中logback和log4j2只能选一存在，springboot默认选择logback日志，而我们部门springboot项目也是logback日志，且验证的也没有问题，故虽然项目中第三方jar包的内部引用了低版本log4j2，但也应无安全问题，另公司内网服务器均已关闭了主动访问外网服务，综合而言应无此次漏洞引发的问题。
针对以上结论，各项目自测操作如下4.项目自测
首先引入测试方法类LoggerTest.java，直接执行查看结果，可能会有两种结果： 结果一：
2021-12-15 10:03:02 [main] INFO LoggerTest:17 - hello,Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
2021-12-15 10:03:02 [main] INFO LoggerTest:18 - Try2021-12-15结果二：
10:03:52.394 [main] INFO com.example.demo.LoggerTest - hello,${java:vm}
10:03:52.405 [main] INFO com.example.demo.LoggerTest - Try${date:YYYY-MM-dd}其中结果一即为log4j2漏洞反应输出，结果二为正常日志输出。
5.kafka
(1).测试环境kafka通过命令查看是否引入log4j2 jar包
kafka版本较低，无log4j-core jar包，log4j-api jar包版本不在漏洞版本范围内； (2).线上环境kafka版本通过运维查询得知kafka版本号为 2.10-0.8.2.1 本地下载对应版本kafka安装包解压后看到
故而线上kafka由于版本较低， 也无此次log4j2 漏洞问题
6.elasticsearch
测试环境、线上环境elasticsearch版本均是6.7.1，查看服务器jar可看到
引入了log4j-api-2.11.1.jar 、 log4j-core-2.11.1.jar 包，且用的是log4j2日志，考虑到直接升级elasticsearch版本或者升级 jar包有一定风险，参考elasticsearch官网解决方案：
Affected Versions:
Elasticsearch versions 5.0.0+ contain a vulnerable version of Log4j. Elasticsearch 5 is susceptible to both remote code execution and an information leak via DNS. We’ve confirmed that the Security Manager mitigates the remote code execution attack in Elasticsearch 6 and 7.
Solutions and Mitigations:
The simplest remediation is to set the JVM option -Dlog4j2.formatMsgNoLookups=true and restart each node of the cluster.
For Elasticsearch 5.6.11+, 6.4+, and 7.0+, this provides full protection against the RCE and information leak attacks.
Users may upgrade to Elasticsearch 7.16.1 or 6.8.21, which were released on December 13, 2021. These releases do not upgrade the Log4j package, but mitigate the vulnerability by setting the JVM option -Dlog4j2.formatMsgNoLookups=true and remove the vulnerable JndiLookup class from the Log4j package.链接elastic: https://discuss.elastic.co/?spm=a2c6h.12873639.article-detail.7.17f71700U0oHgC 也可参考其他处理方案：
Log4j 漏洞修复和临时补救方法 https://developer.aliyun.com/article/832609 其中 【1.设置jvm参数 “-Dlog4j2.formatMsgNoLookups=true” 2.设置“log4j2.formatMsgNoLookups=True”】 可操作性、安全性、改动也是最小的，风险较低，本地测试结果如下：
这样在改动最小，风险最低的情况下解决此次log4j2的漏洞风险。
7.logstash
测试环境、线上环境logstash版本均是6.7.1，查看服务器jar可看到
引入了log4j-api-2.9.1.jar、log4j-core-2.9.1.jar包，且用的是log4j2日志，官网也提供了logstash新版来解决当前问题，
Users should upgrade to Logstash 6.8.21 or 7.16.1 which were released on December 13, 2021. These releases replace vulnerable versions of Log4j with Log4j 2.15.0.但是贸然升级存在一定风险，且版本跨度较大，风险未知，若想通过更改jvm.options来增加参数 -Dlog4j2.formatMsgNoLookups=true来缓解logstash中的漏洞，此方法行不通，因为logstash是以标志无效的方式使用log4j的，同时官网也提供了以下解决方案：
The widespread flag -Dlog4j2.formatMsgNoLookups=true is NOT sufficient to mitigate the vulnerability in Logstash in all cases, as Logstash uses Log4j in a way where the flag has no effect. If the user cannot upgrade to Logstash 7.16.1 or 6.8.21, it is necessary to remove the JndiLookup class from the log4j2 core jar, with the following command (which is applicable for 5.x, 6.x, and 7.x):
zip -q -d <LOGSTASH_HOME>/logstash-core/**/*/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLookup.class删除JndiLookup.class文件
考虑到部分服务器可能没有zip命令，故可以本地删除后重新覆盖更新原有jar包。
更改完成后重新启动logstash即可。 从运维处得知本部门内网服务器满足【4.关闭对应应用的网络外连，禁止主动外连】均不会主动访问外网服务，故elasticsearch、logstash也可暂时不用操作。