周五的时候感觉整个安全圈都炸了，没想到打个log还能暴露出漏洞来，真的是活见鬼了。不过在我看来，这真的没有什么了。（本人见惯风雨）。

Log4j2提供了lookup功能，该功能允许开发者通过一些协议去读取相应环境中的配置。但是对输入并未进行严格的判断，造成了可以被利用的风险。

详细的内容可以参考： https://www.lunasec.io/docs/blog/log4j-zero-day

喜欢用docker的同学也可以体验一把，定个小目标，怎么去那个打log的机器先放个文件 https://github.com/christophetd/log4shell-vulnerable-app

 

我周五反正是搞到了凌晨三点多，一方面是本地测试一下，看看这个漏洞是怎么玩的。本地搭好了之后就是测试一下那些所谓的暴露条件是不是真实有效的：

 

比如说 Log4j 2.0 到 2.14.1 都有问题

在比如说 JDK 版本大于 6u211, 7u201, 8u191, 11.0.1 也可以避免问题

 

随机测试了几个，确实是这样的。  接下来是看看这样的问题对本公司所造成的影响到底有多大。那么好， 我们就去github搜索 对应的log4j的版本吧， JDK也看了一下， 对应的update不行。也就是说一旦用了Log4j 2.0 到 2.14.1就可能有问题了。

然后是各种代码审阅。。。可以确定的是，即使你打log了， 只要你所打的log对应的变量里边不可能被黑客通过任何手段传入 jndi:ldap// 或着 jndi:rmi// 的话， 其实也还是安全的。 总之看了一圈，没发现什么问题。懒惰有时候也是好事情， 我们很多log4j都还在1.X版本。（不过也是存在另外一个high基本的漏洞 - CVE-2019-1757） 汗颜啊， 也是一个远程代码执行。。。不过不是撞在现在的风头了 （就是那种脸上， 你看， 都已经存在N年了，怎么去改？已知问题敷衍了事）

 

接下来觉得可能还不够保险， 去对应Jfrog的管理里边去查看一下对应的log4j2包所被引用的构建。然后才放心了。当然这种放心是不够彻底的。最好的做法还是应该先来个断后，网上已经有对应的解决方案：

 

1. 修改jvm Dlog4j2.formatMsgNoLookups=true

2. 修改配置 log4j2.formatMsgNoLookups=True

3. 系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS = true

检测方案还有DNSLog域名请求的拦截，让远程call找不到回家的路。还有日志系统里边去查询 jndi:ldap: 或者 jndi:rmi等字符来判断被攻击的指数。

 

安全问题真的是动态的，所有道高一尺魔高一丈。同时也觉得似乎大家对安全的重视还不够，即便是很资深的程序猿也很有可能去忽视这方面的问题。作为公司的管理层，其实真的要把安全定位在很高的程度。否则真的不知道什么时候楼就塌了。