问：有没有一个更根源的解决方案，不是加班写特征，周末测绕过，着急升软件？

发生了什么

流行的Java日志框架 Apache Log4j2漏洞在网上发布，漏洞发布之时甚至还没有CVE号，在2021年12月10日周五才有了正式的CVE号分配 — CVE-2021-44228。 这注定是一个载入史册的漏洞。原因有两点：

一、攻击简易收益极大。攻击者使用简单构造的字符串值，就可以实现非授权的远程代码执行 (RCE) ，控制整个受害主机。

二、危害面巨大。Log4J是一个垄断级的日志框架，大量的开源产品，闭源的商业产品，都在代码中使用了这个库，让受害面积无法估量。

所以最近很多公众号用 “史诗级，惊天，十分严重”这些形容词来形容这个漏洞，这还真不能算是博眼球的标题党。另外，0-day爆发之后的各大安全厂商也纷纷表示发现此问题并且实现了防护。相信做安全的朋友们这两天的朋友圈可以看到很多甲方乙方的程序员都在加班检查自己的软件是否有用该组件，并且在发现中招后忙于补救。（大量安全厂家的产品自身也会使用该组件）。也能看到安全部门在忙于配置对应的WAF/IPS/七层设备的特征库，但是又持续发现有新的变形攻击手段可以绕过自己刚写的特征库……

典型的0-day和供应链安全问题

这是一个典型的供应链安全问题。随着开源软件的爆发式增长和应用开发中对于持续交付的压力，开发者会为了实现功能，避免重复“造轮子”，大量在自己的代码中使用开源组件。所以一旦开源组件有了漏洞，依赖这个组件的软件都会受到牵连。本次漏洞就可以看到，攻击者只是利用一个日志记录的开源组件漏洞，就可以拿下各种重要业务软件的权限。

供应链安全会造成大量的潜伏在应用中的零日漏洞，所以这次漏洞只是以后安全事件的冰山一角，完全是热身的水平。 就像安全圈一直说的，漏洞一直在，只是我们不知道。

本次log4j漏洞的介绍

本次攻击是一种JNDI的注入型攻击，攻击分两个阶段.

Stage1阶段，黑客通过恶意构造的payload，让有使用log4j并命中漏洞的应用，执行JNDI查询。查询的目标地址为构造payload内指定的，由黑客控制的远端N/D服务。

Stage2阶段，远端服务会序列化恶意java代码，并传输回受害者应用，受害者应用解码后就会执行恶意代码。

针对这个攻击，我们期望在两个阶段都有对应的防护能力，让应用可以天然的抵御。总结一下我们认为现代应用应该有的安全能力：

1、运行时安全，我们期望安全防护是应用的一部分，像疫苗一样给予应用天然抵抗力。即使没有爆出这个漏洞，我们的应用也应该可以防护。

2、不依赖特征库，这是防护零日攻击的核心，传统的防护依赖特征库的识别。这种思路忽略了攻击本身其实是滥用了程序原本的意图，扭曲了程序的“语义”，如果我们的安全疫苗可以像程序的编译器一样，发现语义的安全威胁，直接针对这种行为做防护，那就可以举一反三，防护各种零日攻击。并且完全无视高级黑客对于特征库的巧妙绕过。

3、构建应用内生防线，传统安全专注于基础设施边界的统一过滤，但是现代应用的分布式架构让安全边界消失，如何能在应用内部构建防护边界。能够对程序自身的各种网络调用，系统调用提供应用内的安全边界，是我们需要的一个安全能力。

让我们看看，缔赛Styx疫苗服务系统如何按照上述思路，实现针对该攻击的默认防护，并在最后给大家提供一个完整的DEMO演示。

缔赛Styx疫苗服务防护原理

首先，缔赛Styx疫苗服务系统，可以针对java程序无缝的整合Styx RASP Agent，不需要修改源码。以无侵入的插件方式和应用完成融合。

其次，部署好Styx RASP的应用可以在stage1进行自动防护：

Styx RASP插件可以梳理出应用使用的第三方库，做漏洞管理。同时也能理解和监控组件对外部的系统调用和网络行为。针对一些异常的网络行为，Styx会直接进行阻断。所以在第一阶段，应用的log4J组件在执行恶意payload，对外部黑客的ND服务连接的时候，就会在发起网络调用时被Styx阻断，破坏黑客的攻击链。

最后，部署好Styx RASP的应用也可以对stage2的攻击进行自动防护:

如果Styx RASP策略在第一阶段放行了Log4J的对外请求，黑客远端ND服务响应了含有恶意代码的payload给应用程序。Styx内的LangSec专利算法模块会解析和分析传回的代码的语义，发现有语义的扭曲，也会直接进行阻断，防止远程代码的执行。

所以Styx可以无侵入的和应用共生，可以监听和阻断第三方组件的异常网络请求，也可以利用Langsec模块，对执行的代码进行语义安全分析，防止扭曲的语义代码被执行。利用综合的手段，让应用天然可以防护该零日漏洞的攻击。

Styx疫苗服务自动防护Demo(无需特征库)

缔赛安全非常关心已有客户的防护情况，为了帮助现有客户证明部署的缔赛Styx疫苗是有作用的，缔赛的安全人员在客户的预生产系统(测试系统)加班进行了POC测试，完美实现了本次POC的防护

无需额外配置

无需特征库

无需系统更新

视频如下，客户因为需要展示到底缔赛安全的Styx系统服务能否防住，所以辛苦@Ture同事加班完全模拟了一次自动的攻防护(无特征库，直接防护)

DepSecure Styx 让您的应用天然免疫apache-log4j(CVE-2021-44228)

来源：凤凰网科技

免责声明：本文来源于网络，仅代表作者本人观点，与TechWeb无关。凡来源非TechWeb的新闻（作品）只代表本网传播该消息，并不代表赞同其观点。TechWeb对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考，并请自行承担全部责任