问：有没有一个更根源的解决方案，不是加班写特征，周末测绕过，着急升软件？
发生了什么
流行的 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)
http://mpvideo.qpic.cn/0bc33qacmaaab4ai6ifvlnqvbxgde3oaajqa.f10003.mp4?dis_k=a9c6c87b26908093ea0b111c6c5b0788&dis_t=1639558176&vid=wxv_2176058132429373441&format_id=10003&support_redirect=0&mmversion=false
