谁应该为Log4j2 RCE漏洞负责？

其实现在这个时候来谈这个问题是有点不合适的，因为漏洞还在继续，应该把跟多的关注点集中在漏洞应急修复等工作上，当然到现在这个阶段经过了一个大周末的集中处理，一线的人员多少有点卷了，周一来了轮到其他人上场了... 但是看到了不少“言论”及“观点”感觉比较尴尬，所以还是打算简单聊一下

1、被低估的漏洞

在《关于这次Apache Log4j2漏洞 简单说几点》里我就提到了这个漏洞开始可能是被低估了的，当然我这个也算是我的yy吧，因为我一开就低估了它，我当时关注点在于通用组件的调用，简单按经验认为需要看具体应用的调用，当然我意识到这个可能影响很多很多通用程序，但是没有意识到直接参数提交这个方式，直到我们小伙给我发了一张百度搜索框触发dnslog的截图～～ 然后一发不可收拾啥icloud、亚马逊 ... 然后整个安全圈子就开始疯了，疯狂的找各种搜索框，毫不忌讳地说我们ZoomEye也有人测试（触发没成功，事后证明ZoomEye是受漏洞影响的，只是因为我们的改动没有出触发）

这里我认为是这种“简单”、“暴力”、“直接”的参数提交利用方式是失控的很重要的一个点

2、漏洞的扩散

这个漏洞是阿里的小伙发现并报告的，应该是在11月份，这个可以从官方coomits 

https://github.com/apache/logging-log4j2/pull/608/commits 

是11月30号创建的，所以这个漏洞肯定是在这个日期之前就报告了，细心的朋友可能看过我们的文章：《谁是超级骇客！从创宇盾感知Apache Log4j2 曝光前后惊魂24小时态势》  里提到：

漏洞应急响应后回溯分析发现在11月25日就已有攻击者利用该漏洞进行攻击，该攻击被创宇盾智能引擎拦截，攻击失败。

知道创宇云防御，公众号：创宇云防御谁是超级骇客！从创宇盾感知Apache Log4j2 曝光前后惊魂24小时态势

根据当时“攻击者”使用的payload 分析后可以得到如下2点：

* 这个“攻击者”意识到了参数注入的攻击方式* 使用本地的ldap的IP地址，由此推断这个应该算是一个纯手抖误操作 （跟粘贴板里信息直接发错群里的那种情况差不多）

然后直到12月9号开始出现攻击，在这个角度上来看，实际上我个人认为可以说明阿里的小伙是没有扩散的相关细节的。那么在12月9号发生了什么呢？最大的一种可能就是有人根据官方github上的代码更新复现了漏洞，并很可能在某些小圈子群里做了分享，很可能也是没意识到这个漏洞“简单”“暴力”的方式，再加上觉得补丁已经发布了就没想那么多 ... 随即就被扩散 ... 直到有人随手测试了下百度 ...

3、“马后炮”式的评价

后来大家看到的啥“史诗级”、“核弹级”等评价，这些都算是“马后炮”式的思维，也就是因为这个影响大了成为了事实后的评价，而不是在漏洞报告及补丁更新时候的评价！如果没有意识到这个问题很容易陷入“先入为主”的思维陷阱。如果在这个基础上作出的推测甚至“扣帽子”那多少都有点尴尬！这里我在举一个前几月刚发生影响很大一系列关于SonarQube事件，事实上我们知道创宇404实验室在2020年的7月29日就进行漏洞应急及预警，直到1年后的前个月大规模爆发泄露事件 ...

从本次国外社区的表现也能很好的说明这个问题，我可能是第一个在推特上呼吁老外关注这个漏洞人，所以被老外媒体看到了

当时的很多老外都是一脸懵逼，因为连个CVE都没有，我只给出了一个Log4j2的更新，同样这些人也没当回事，因为他们不懂中文，不用微信，不能混大天朝的安全圈子看不到那些刷屏的dnslog截图，直到我转发

了一个项目：

https://github.com/YfryTchsGD/Log4jAttackSurface/ 

然后老外们疯了...

这些都说明一个问题：“安全事件”仍然是网络安全的第一推动力，所以本次Log4j2是因为产生那么多的安全事件影响到那么多的国际大厂，才在最短的时间里得到爆发实现了“史诗级”、“核弹级”的评价。我们也可以YY一下如果这些事情都没有发生，我敢肯定大部分的那些在朋友圈、微博里吐槽骂娘的加班的同学们也不会去关注一个默默无闻的“咔咔锅过”那个卑微的Log4j2组件，那些超级大厂网站后面依然运行着存在漏洞的Log4j2，可能直到有一天各大网站的数据库被5毛比特币在一个叫RF的论坛上出售，当然这个算是后果最轻的yy了 ...

4、开源的原罪

这个问题我也在《关于这次Apache Log4j2漏洞 简单说几点》里提到了，讲道理我对apache的开源社区是完全没啥好感的，比如有一次Strusts2的一个漏洞，直接把攻击代码也给“开源”了，当然咯这次倒是没有直接放POC/EXP。不能直接接这个锅，我说的开源的问题是：现在开源的整个社区都没有考虑到一个问题，就是安全补丁的代码是基本算是“透明”的，很容易通过查看diff定位漏洞并复现漏洞，相比同时用户在看到补丁更新，需要测试兼容性需要去一个一个部署，尤其是log4j这种基础的通用组件，不可能提供一个自动更新的接口，他们的更新依赖那些开发者及调用这种组件的通用程序的开发者，这个是需要大量的时间、大量的空间的，我想这次很多大厂的技术有着深刻的感受。

我们开源的一套系统WAM https://github.com/knownsec/wam 就是基于这个逻辑实现的，我记得当时数字公司推出的漏洞收购计划来弥补通用漏洞防御能力，那时候我基本是不慌的，主要是对我们自己的漏洞能力比较放心，另外一个就是我们有WAM系统，你的每次发钱收购的漏洞，都要提交给官方，那我们只要监控官方代码更新就能快速的定位漏洞输出防御规则，所以当时我们一直都能做到快速的响应。

当然回头一想这个问题实际上没有很好的解决办法，所以我说是“原罪”，只能“祈祷”了！也就是说“定时炸弹”一定是会爆炸的，就看定在啥时候了！虽然是无解，但是还是可以做一些事情的，比如不要跟strust2那种直接把exp给开源了，比如漏洞相关的补丁方式不那么“直接”增加点门槛啥的，在比如漏洞更新的时候能认真对待，比如这次那么多年CVE都没有一个,当然很多开源维护者是不具备安全能力的。

所以网上又有人开始吐槽甩锅给Log4j2的维护者，结果被人看到了事实：“Apache Log4j项目由三名志愿者业余时间维护。请不要嘲弄他们，因为市值数十亿美元的公司正在使用他们的工具，却连投入 1000美元都不屑一顾。” 看到这个时候大家平和了很多，很多人想起了老罗当年给Openssl的捐款！在这里我有呼吁下有钱的大佬可以支持大赏一下：

https://github.com/sponsors/rgoers

5、到底是谁的“锅”？

“菩提本无树，明镜亦非台，本来无一物，何处惹尘埃。”

漏洞是真实存在并确实被发现了，漏洞正常报告，官方确实也给了修复方案了（虽然漏洞点存在绕过，但是默认配置还是很安全），这些都已经成为既定事实！绝大部分场景下被明目张胆的“黑”比被偷偷“黑”带来的后果要小很多。“正视漏洞，加强防御，积极应对”才是王道。

（以上观点均属于我个人观点，与其他人及组织无关）

原文始发于微信公众号（黑哥说安全）：谁应该为Log4j2 RCE漏洞负责？