log4j漏洞让业界渡过了难眠的两周,下到一线IT人员、安全人员,上到CTO、CSO.不管你是甲方大爷,还是乙方安全公司,都被折腾得辗转难眠!蠕虫、勒索、APT、僵尸网络一个个如期而至,就像一个同事说的,这个东西不是打个补丁就完了,这是未来两年的战斗...

对于log4j漏洞的分析,业界有了太多的发声,说实话,作为骨子里的安全技术人员,对这些发声实在是不满意! 一个让业界上上下下如此狼狈的安全问题,不能这样糊弄过去了,实在是想要一吐为快! 无奈自己长久没有写字,家中诸事缠身,也就凑活写几句吧~

首先, 我觉得所有人应该要知道的是这个漏洞在JAVA生态快整整8年了!

开源软件的好处就是可以让所有人看到这些记录,参考官方的发布日志(https://logging.apache.org/log4j/2.x/changes-report.html),先带大家来好好回顾一下关键时间节点:

2012年7月29日

log4j-core 2.0-alpha1发布,log4j 2版本生命周期开始

2013年7月17日

一位叫Woonsan Ko的大哥撺掇官方添加JNDILookup插件支持(https://issues.apache.org/jira/browse/LOG4J2-313)

2013年9月14日

log4j-2.0-beta9发布,正式支持JNDILookup功能

业界应该记住2013年7月17日这一天,定个节日吧,就叫“717安全受难日”吧!以免像我这样的java初学者懵逼,我还是解释下717这天发生了什么!

717这天这个LOG4J2-313请求,是让官方在 Log4j 配置文件中添加了对 JNDI 查找功能的支持,引入了${jndi:xxx}这个 Log4Shell 漏洞利用语法的支持,正式开启了JAVA生态一个文本字符串吊打生态的创举.

在2016年的BlackHat上，pwntester分享了一个通过JNDI注入进行RCE利用的经典议题,这个研究JAVA安全的就不用多说了~微妙的是log4j官方可能在一年后意识到了安全问题,2017年11月9日开始讨论添加jndi lookups特性可配置开关的LOG4J2-2109问题(https://issues.apache.org/jira/browse/LOG4J2-2109),最终官方发布了个2.10.0版本可以用开关关闭JNDI这个后门!

你以为官方意识到了安全问题,那就大错特错啦,至始至终在配置开关的问题里都是为了解决“LOG4J2-905 能够完全禁用（日期）查找，与 Camel 等其他库的兼容性”这个功能性的兼容问题!

直到4年后的2021年11月24日, Apache Log4j官方获悉阿里大哥再一次提醒的漏洞,并且展开了一场旷日持久的讨论! 是的,你没看错,不是你想的紧急修复漏洞,是讨论.

我无法细述开发者们争论的点!简单列一下官方提交的开发进度和问题吧~

LOG4J2-3198：默认情况下应禁用JNDI消息查找

LOG4J2-3201：限制 JNDI 可以使用的协议,并限制 LDAP协议

LOG4J2-3202：只允许在JNDI消息中查找，而不允许在参数中查找

LOG4J2-3208：默认禁用 JNDI

LOG4J2-3211：删除对JNDI消息查找的支持

简单解释一下,在这两周开发社区在做什么!

开发社区在纠纠结结中从默认禁用、限制这个功能, 发现被安全社区绕过,缝缝补补

再到被安全社区发现自定义配置又会触发漏洞.继续缝缝补补~

最终补烦了,发现DOS漏洞.遂彻底放弃,回到8年前的起点,彻底删除这个功能!

写到这,本想长篇大论,但实在没心思掰了,但是还是简单说两句!我觉得从我述说的过程, 应该有不少人再次意识到了安全人员和开发人员脑子里想的完全是两码事!开发人员想要尽量保留强大的功能,让它可配置,哪怕它有安全漏洞,也舍不得删除它,除非你把一个偏执的开源社区逼到绝路!

安全人员要意识到建设远比拆迁难, 简单的发现安全问题是不行的,如果你不能参与去安全的建设它,安全只能治标不治本!