Log4Shell威胁仍未消除，企业应如何治理应对？

思科Talos集团的研究人员在他们的年终报告中表示：“据我们了解，Log4j被利用后所带来的威胁，在2023年或往后仍然是组织要面临的挑战之一，Log4j在环境生态中的普遍存在使得修复变得越发困难。在如此广泛使用库的情况下，Log4j已被深深嵌入到了大型系统中，因此很难确定特定环境里所有软件漏洞的位置。”

根据漏洞扫描公司Tenable的数据显示，截至2022年10月1日，仍有72%组织的资产易受Log4Shell攻击，而自5月以来，这一比例提高了14个百分点，居高不下。数据还显示，平均每个组织的脆弱资产数量从2021年12月的10%下降到了2022年10月的2.5%，但Tenable发现，在进行漏洞修复之后，三分之一企业的资产还是出现了Log4Shell漏洞复发等问题。

软件供应链管理公司Sonatype的首席技术官Brian Fox表示：“据数据显示，拥有成熟开源程序的公司基本上已经得到了补救，而其他公司在这一年里仍表现为‘挣扎’。每天那些易受攻击的Log4j下载量多达数十万，在我看来，这意味着问题的根源并不在于开源维护者，而在于开源消费者，同时这也证明了许多公司根本不知道，他们的软件供应链中到底存在着怎样的漏洞和风险。”

Sonatype平时运行并维护着Maven Central Repository，Maven Central Repository是Java组件中最大并使用最为广泛的存储库，因此Sonatype能够跟踪任何组件（比如Log4j）的下载次数，并在日常维护包含Log4Shell信息和相关资源的统计报告。据Sonatype的报告显示，自2021年12月10日以来，三分之一被下载的Log4j版本都是那些易受攻击的。

国内安全专家对此表示，由于目前市场都讲究敏捷开发，所以会大量复用外部成熟的开源应用及组件，但是开源应用和组件本质上还是程序，是程序就有可能出现漏洞。所以，问题从本质来说更像是一个经济问题，因为在开发过程中“只重视安全”对于开发者、团队、企业来说并没什么收益，而基础设施上，比如开发语言、重要功能的组件之类还是要依赖于大量开源的成果，这才是其不可控性的根源所在。

因此才会有在职的专业人士说道：“在开发的时候，所使用的第三方开源的框架和服务，不存在绝对可信、完全不出问题的开源，我们能做的就只有常常小心、警惕，尽量针对一些服务的不稳定性去设计些熔断，或者做些其他的降级保护措施，以便给自己留下后路。”

2021年年底，当Log4Shell漏洞被公开披露后，Snort开源网络入侵检测系统的遥测数据显示，针对Log4Shell的攻击数量激增，2022年1月份达到了7000万次，直至4月份后才有所下降并保持相对稳定，每月约为5000万次攻击。这表明攻击者仍有兴趣在系统中利用此漏洞进行攻击。

管理检测和响应公司Arctic Wolf自2022年1月底以来，针对1025家组织（约占其客户群的四分之一）进行了调查，结果发现这些组织共发生了63313起漏洞利用未遂事件，而在非其客户的组织中，Arctic Wolf发现约有11%的组织在事件响应活动中将Log4Shell作为主要入侵源头。除此之外，Arctic Wolf指出，Microsoft Exchange中的ProxyShell（CVE-221-34473）漏洞对组织来说更是雪上加霜。

Cisco Talos事件响应团队的报告显示，2022年的上半年，包括Log4Shell在内，所有面向公众的应用程序中，漏洞利用和网络钓鱼被联系在了一起，成为了最大的感染媒介。而在2022年的第三季度，报告显示应用程序漏洞是第三大最常见的感染媒介，包括易受Log4Shell攻击的VMware Horizon服务器在内。

利用Log4Shell进行攻击的不法者们类型各异，既有部署加密货币矿工和勒索软件的网络犯罪分子，也有国家赞助的网络间谍组织。Arctic Wolf在今年调查的事件响应案例中发现，约有60%的安全事件归因于这三个勒索软件集团，它们分别为LockBit、Conti和BlackCat（Alphv）。据Arctic Wolf估计，应对此类安全事件的平均成本超过90000美元。

据Cisco Talos称，Log4Shell漏洞于2021年12月公开后不久，现已解散的Conti勒索软件集团便开始利用此漏洞了。之后，各种勒索软件集团在这一年中，不断利用这一漏洞进行攻击，而具体调查发现，加密货币挖矿团伙比勒索软件集团更早利用了Log4Shell，并且许多早期与该漏洞相关的扫描和开发活动，都由各种加密货币挖矿团伙所发起。

除此之外，整个一年中，思科Talos还发现了APT集团利用Log4Shell进行网络间谍活动的现象，包括朝鲜的Lazarus集团，与伊朗伊斯兰革命卫队有关联的威胁行为者，以及与中国相关联的Deep Panda和APT41集团。

思科Talos的研究人员表示：“Log4j仍然是一种易受攻击的感染媒介，可供不法者们利用，我们预计不法者们将会尽可能长时间地滥用这些易受攻击的系统。尽管这些不法者具有良好的适应性和‘破坏斗志’，但如果还能成功利用已知漏洞进行攻击，那他们就没有必要花费更多的资源去开发新的攻击手段。”

国内外都有这样的共识，即开源已成为云计算、大数据、人工智能、工业互联网等新兴领域的主要开发模式，操作系统、数据库、中间件、应用软件、设备固件等开发、编译、测试都越来越多的采用开源代码，软件供应链的开源化趋势越来越明显，但同时软件供应链也越来越趋于复杂化和多样化，软件供应链的安全风险不断加剧，针对软件供应链薄弱环节的网络攻击就会随之增加，因此，软件供应链将成为影响软件安全的关键因素之一。

开源软件的引入在减少开发时间的同时，增加了软件供应链安全的复杂度，类似Log4j2这样应用广泛的基础组件，在供应链的各阶段均存在深入的影响；大型项目中依赖关系数量与依赖层级数量的复杂度，增加了厂商对漏洞的排查难度；上游软件供应链产品中漏洞累积的影响，最终会在下游应用场景中浮现。

因此，企业在管理上要先收集信息，加强这类资产的检测、登记、整理，让安全团队知道用了哪些类型和版本的系统，方便第一时间响应漏洞和事件，也方便长期的风险关注、升级、替换。对于风险较高、出现问题较多的应该尽量淘汰。

而在技术上，企业除了管理方面的技术手段外，剩下的就是要考虑存在风险之后的二层防御问题。比如新出现了漏洞或相关的攻击事件，就要有这种异常的检测手段或拦截手段来防治损失，而在请求数据和前端代码层面的动态防护技术就是一种拦截手段。如果企业在SDL的投入上比较重视的话，可以在开发层面做到更加严谨的防护，尤其是那些关键业务功能或涉及风险组件的业务，加强前面的校验、过滤机制，可以降低0day的攻击面。要假设自己用的某些组件就是存在漏洞的，想想攻击的入口能有哪些，从利用途径去下手。

就像国内知名安全专家所指出的那样：“开发人员选择组件的时候，往往会优先考虑熟悉的、好用的组件，安全看得不重，有部分原因是因为对这些风险不了解，不直观，供应链也终究会出现安全方面的优胜劣汰，现在我们把它放大了是好事情，我们可以聚焦起来，把供应链的风险更直观的曝光出去，多宣传，让业内都知道，谁的风险比较高，谁经常出漏洞，谁的口碑比较好，让大家选择这些开源供应链的时候，能看到它在安全方面的优缺点。”

对于Log4Shell是否仍然是巨大威胁，对此安全人员又该做些什么，国内安全专家如此建议。

网络安全专家叶翔认为，Log4Shell所带来的影响正在逐渐变小，它和其他的高危漏洞已经没有什么太大的区别了，一个高危漏洞的利用期，最开始可能会存在一个峰值，因为大家都还没有对此做过防护。随着时间的推移，基本上所有对安全重视的企业都会去修补这个漏洞，修补完之后，暂时可算为安全，就怕有的公司一两年都不修补漏洞，等到做等保时才临时抱佛脚，如果所有企业都是这样的安全态度，那可以影响他们的漏洞多了去了，也就不仅仅是Log4Shell的问题了。

叶翔表示，在面对这样的高危漏洞时可以分两个方面来处理，首先在高危漏洞的爆发期要做好应急处理，其次日常的修补工作又是另外一个课题，这两点都非常重要，而像Log4Shell这样的漏洞可以放到日常监控、监测的范畴里。

而对于日常的漏洞处理，叶翔觉得可以分为几个方面，首先是准入，比如新的系统建好了肯定是要有相对较为全面的扫描，“不可让新系统带着漏洞进来”是一个非常重要的理念，因此在新系统上线前一定要有一个完善的测试，从研发到运维，都需要经过严格的测试流程。而之后就是持续性的安全运营问题了，需要明确的是，漏洞永远是修不完的，所以如果企业主管IT部门的人对安全不是很熟悉，就可以请一个安全行业的监理来协助，这是很有必要的，因为监理可以帮助甲方管理好乙方，防止乙方摸鱼。

某金融行业安全经理姚俊先认为，此漏洞在各行各业都有着不同的情况。姚俊先说，Log4Shell到目前为止已经出现了一年多的时间，对于银行、金融等安全控制比较严格的行业和单位来说，应该已经不具备较大的威胁。而目前比较大的挑战，是有大量的开源或者边缘的系统底层用了这类组件，并且这类系统到目前为止也没进行漏洞的修复，另外一个就是在内网的渗透中可能也会被攻击者进行利用。所以姚俊先建议，应更加重视软件供应链的安全，定期排查软件产品，特别是互联网系统中所使用的组件的漏洞影响，应给予及时的修复。

某金融行业安全专家陈传鹏指出，Log4Shell确实仍是个巨大威胁，其带来的挑战主要体现在软件质量管理上，而软件质量管理的难点不单单是一个安全问题，bug可能是安全漏洞，也可能会导致业务连续性问题，这是另一个大的领域，包含了安全。而对软件质量管理来说，devsecops可以是一种尝试。

对此陈传鹏建议道，企业应该将安全前置，加强标准与法规方面的引导，同时要做好软件质量管理，包括供应链全过程的系统风险闭环管理。关于闭环管理，更多的应该是领导层重视和考核，由安全人员执行。

而某金融行业安全专家孙钢认为，Log4Shell仍然是巨大的威胁，其具有以下特征：

①排查难度大：Log4j2是一个相当底层的开发组件，开发人员可以直接调用，但更多的是第三方组件的嵌套调用。

②影响范围广：影响springboot、struts等主流开发框架，vcenter、elasticsearch等主流产品，还有海量的第三方组件jar包。

③利用难度小：Log4shell漏洞探测简单，利用方便，堪称入门级漏洞，目前互联网上已有利用工具可自动检测、利用。

④危害性大：Log4shell不仅可以实现命令执行，还可以打入内存马，实战性极强。

⑤暴露面多：不同于永恒之蓝漏洞攻击的SMB服务，Log4shell是一个作用于应用系统的web安全漏洞，受影响应用通常直接面向公网开放。

基于以上几点特征，孙钢认为，不论从危害性还是整改难度上来看，Log4shell都可能是一个超越永恒之蓝漏洞的核弹级安全漏洞，且从他所在单位参与的各项攻防演练活动的情况来看，即使Log4shell漏洞爆发已有一年时间，还是有大量的企业、事业单位、政府机构的网络资产存在Log4shell漏洞，其中不乏知名上市企业、国家级部委机关和事业单位，所以目前来看Log4shell的威胁仍未消除，存在巨大安全隐患。

孙钢指出，一个企业或单位若想要完全解决Log4shell漏洞带来的挑战，至少需要以下几点能力：

①全面细致的开发组件管理能力：组件引入台账需要细致到某个具体系统，还需要借助SCA分析等技术层面能力来解决第三方包嵌套调用问题。

②完善的供应商管理能力：针对采购的商业产品或使用的开源产品要有完善的资产台账，以应对供应链层面传递过来的影响。

③强大的网络资产管理能力：迅速确认互联网暴露面，及时增加防护措施。

除此之外，孙钢还额外建议道：

①企业需要重视应用安全建设，做好各开发环节资产管理，建立第三方组件管理能力。

②企业还需要重视供应链安全，做好供应链资产管理。

③最后，企业还要加强网络资产管理能力。