上下文
log4j漏洞让业界渡过了难眠的两周,下到一线IT人员、安全人员,上到CTO、CSO。不管你是甲方大爷,还是乙方安全公司，都被折腾得辗转难眠!
蠕虫、勒索、APT、僵尸网络一个个如期而至，就像一个同事说的，这个东西不是打个补丁就完了,这是未来两年的战斗...
对于log4j漏洞的分析，业界有了太多的发声，说实话，作为骨子里的安全技术人员，对这些发声实在是不满意! 一个让业界上上下下如此狼狈的安全问题，不能这样糊弄过去了，实在是想要一吐为快!无奈自己长久没有写字，家中诸事缠身，也就凑活写几句吧~
首先, 我觉得所有人应该要知道的是这个漏洞在JAVA生态快整整8年了!
开源软件的好处就是可以让所有人看到这些记录，参考官方的发布日志(),先带大家来好好回顾一下关键时间节点:
业界应该记住2013年7月17日这一天，定个节日吧，就叫“717安全受难日”吧！以免像我这样的java初学者懵逼，我还是解释下717这天发生了什么！
717这天这个-313提案，是让官方在 Log4j 配置文件中添加了对 JNDI 查找功能的支持，引入了${jndi:xxx}这个 漏洞利用语法的支持，正式开启了JAVA生态一个文本字符串吊打生态的创举。
在2016年的上，分享了一个通过JNDI注入进行RCE利用的经典议题,这个研究JAVA安全的就不用多说了~微妙的是log4j官方可能在一年后意识到了安全问题，2017年11月9日开始讨论添加jndi 特性可配置开关的-2109()，最终官方发布了个2.10.0版本，可以用开关关闭JNDI这个后门！
你以为官方意识到了安全问题，那就大错特错啦，至始至终在配置开关的问题里都是为了解决“-905 能够完全禁用（日期）查找，与 Camel 等其他库的兼容性”这个功能性的兼容问题！
直到4年后的2021年11月24日, Log4j官方获悉阿里大哥再一次提醒的漏洞,并且展开了一场旷日持久的讨论! 是的，你没看错，不是你想的紧急修复漏洞,是讨论。
我无法细述开发者们争论的点!简单列一下官方提交的开发进度和问题吧~
简单解释一下,在这两周开发社区在做什么!开发社区在纠结中默认禁用、限制这个功能, 到发现被安全社区绕过再缝缝补补，再到被安全社区发现自定义配置又会触发漏洞继续缝缝补补~最终，补烦了，发现神奇的DOS漏洞，遂彻底放弃，一切回到8年前的起点,彻底删除这个功能!
我觉得从我述说的过程, 应该有不少人再次意识到了安全人员和开发人员脑子里想的完全是两码事！开发人员想要尽量保留强大的功能,让它可配置，哪怕它有安全漏洞，也舍不得删除它，除非你把一个偏执的开源社区逼到绝路！安全人员要意识到建设远比拆迁难,简单的发现安全问题是不行的，如果你不能参与建设它，安全这些过程只是治标不治本!
无名之火
笔者还和一位老朋友聊及了此事的性质，我说是皇帝的新衣，他说是灰犀牛，我笑称大家以为是无害的犀牛，最后却发现是一只哥斯拉。其实我心里是气愤的，这个事对于我来说关系不大，看看热闹吃个瓜就好，为什么老在纠结别人的事，同行不是相轻么，为什么要一直不停的说。其实是因为我看到了圈里、圈外各种妖魔鬼怪、懂王，事件越来越偏离，事件发展到整个圈子深井冰了，我看到了一群深井冰，我忍不了这事成了皇帝的新衣，忍不住安全圈因为这么个破B事给毁了价值观！
如此情境下，我想起了小学的一篇古文《扁鹊见蔡桓公》，你把扁鹊看成以阿里为代表的安全厂商，把蔡桓公看成及开源社区等等，你就会发现事情有多么讽刺！
蔡桓公有隐疾（漏洞）8年了，期间经历过很多医生，有看不到病的庸医，有看到病不在意的怂医。
有一天，来了个不知天高地厚的神医扁鹊给蔡桓公进言：“大王有个小安全漏洞，可能已经8年了，趁早治治吧，实在不行让太医们会诊下，给个方案”
蔡桓公（官方）说：“我知道了，我让太医们讨论一下，不过我觉得我的身体很好，什么病也没有。”
过了几天，扁鹊又来拜见蔡桓公，说道：“您的病已经发展到皮肉之间了，要不治还会加深。”
蔡桓公（官方）听了很不高兴，说：“我知道了，太医们已经在办了，你不用指手划脚”
原故事是又过了十几天，扁鹊老远望见蔡桓公，只看了几眼，就掉头跑了。
现实是扁鹊见没人理会，便登城呼告大王再不治就要死了，众生哗然...
大王身边的太医们：我们早知道的漏洞要你说！
大王身边的大臣：你为什么不早偷偷和我们说，你是大不敬！
这个国家的吃瓜群众：扁鹊是个大魔头，最好去菜市口砍掉脑袋！
最后log4j2漏洞，蔡桓公病死了~
防守窘境
这个其实是个很大的问题，不同经历的人会有不同答案。
经历过太多的人，每天我处理的漏洞是海量的，0day、nday、在野的不计其数，log4j这种漏洞会被淹没的。
专门做Java Web安全研究的人，2020年提交的代码扫描规则可以自动发现漏洞。这样的说法会让我哭笑不得，这样的人是时候该反省8年Java安全是不是白学了。不过从我的安全经验看这个漏洞也没那么特别容易，涉及到可变变量、攻击入口的判断，还有影响面的评估，这个就看经验和悟性了。有时候原理简单，能看破，会利用的少，知行很难合一。不过综合评估这个漏洞的门槛实在不高，这也是让我纠结的点，业界确实发现和重视得太晚了，做相关研究的同学是该复盘一下了。
最重要的一点是开源社区的认知，开源社区认为这不是漏洞，是个强大功能带上的副作用，并且提供可控制的开关，所以安全社区不去逼一逼，是允许这种问题存在8年的，这也是我从业这么多年感到最可怕的事，但是在很多同行身上找不到共识，也许很多人是真懂了妥协了吧，而我只感到害怕。
打补丁这个问题我觉得做Java开发的同学会很懂，不是把包删除升级就完事了，Java的开发模式决定组件互相引用是指数级的，特别是包可以有嵌套打包、包等形式，漏洞可能藏在Java生态的数万个包里面，这会让做防的人崩溃的，你并不知道你哪天引用开发的项目在不知不觉里踩地雷了，这又是内部安全开发流程、要重新关注的点，而这仅仅是暴露出来的一个问题，还有无数个类似还没有披露的漏洞怎么办？
最后，笔者开始自问自答！！
大公司部署的SCA安全软件对这个漏洞有没有帮助？
说实话，这是个我不愿意提及的问题log4j2漏洞，后知后觉，业界的很多安全产品、安全软件也受漏洞影响，局中人是该反省一下了，SCA软件自己就有SCA问题，安全产品自己就有RCE漏洞，这不讽刺么，这是唯一一个让我低下头的问题。
这个漏洞和永恒之蓝比起来谁更厉害？
永恒之蓝和漏洞不一样，一个是操作系统漏洞，一个是一门语言生态的基础库出安全漏洞了，基础库的互相引用影响是指数级的，这是对业界生态的打击，不能放在一起比较。
对这个漏洞有什么好的解决方案和措施？
这个问题我要感谢NUKE兄弟，一直在不遗余力的推荐CISA的SBOM（软件物料清单），SBOM 是描述软件包依赖树的一系列元数据，包括多种关键信息如提供商、版本号和组件名称的标准。我觉得每个组织机构经过log4j的洗礼后，应该要重视起来了，SBOM的构建对于分析开源软件漏洞是发挥着关键作用的。
最后
读到此处的人，感谢你耐心看完我的深井冰，我已经看透，并压下了这深井冰似的无名之火。
限时特惠:本站持续每日更新海量各大内部创业课程，一年会员仅需要98元，全站资源免费下载
点击查看详情
站长微信:Jiucxh
