Apache Log4j2远程代码执行漏洞爆发已经一周了。 安防厂商提供了各种防御方案和检测工具，甲队连夜应急。
影响至今仍在持续，网络上各种各样的利用和迂回姿态层出不穷，影响面还在继续扩大。 所有安全人员都开始反思当前防御是否有效的问题。 对于这种0day的复发，有效的手段是什么？
AlibabaCloud (阿里巴巴云)安全团队此次参与了众多客户的应急工作，试图从云平台自身的防御中总结经验，并提出一些观点进行讨论。
首先，让我们从技术上分析一下为什么这次的Log4j2这么难。
Apache Log4j2漏洞们的特质这次的Log4j2漏洞有两个棘手的特质：
实现任意远程代码执行的“懂规则”漏洞，高风险使用门槛高，使用门槛低，危害小，符合自然规律。 这个漏洞并不是照常出牌，不仅影响范围广，利用门槛低，危害也极大。 三要素叠加，处处被冠以“史诗级”称号。
Java的应用极其广泛，生态也很庞大，但Log4j作为日志处理的基础组件被大多数APP应用。
通过JNDI注入手段实现任意远程代码执行，意味着攻击者可以在有漏洞的服务器上为所欲为。
即使在内部网环境下JNDI外部网不成功，攻击者也可以结合lookup特性读取很多机密信息(数据库密码、JAVA环境变量等)，进而通过DNS协议将机密信息从内部网带出
根据流量特征隐藏场景的不同，几乎没有可以区别于一般要求的强特征。
此次漏洞PoC结构非常简单，漏洞触发点广泛灵活，配合各种变量和协议的嵌套迂回方式，流量特征非常复杂且隐蔽。 Log4j2的lookup功能支持l o w e r : j N d i、{lower:j}Ndi、l o w e r : j N d i、{upper:JN}di、${AAA3360v3366}等特殊格式
这是对基于所有流量特性的安全防护产品的巨大挑战。
如果流量特征不够明显，基于流量特征的规则会变得尴尬。 无法覆盖，或者会发生严重的误报。 只能不断补充规则，在迂回和被迂回中循环往复。 该防御手段可以在0day爆发初期非常有效地为漏洞的修复争取时间。 但是，随着各种利用手段的变化，很难保证没有被绕开或被误报。
与Log4j2具有脆弱性的“弱特征”和“0特征”的利用方法相似的情况是还有加密流量、内存马等，这些手段都在大型攻防演习中大放异彩，但检测困难的原理相似。
因此，有无视漏洞利用方法的通信特性的各种变化和隐藏，防御更天然，不依赖规则更新就能防御这样的0天的技术吗？
RASP在这次事件中恢复了rasp (runtimeapplicationself-protection )，在运行时适用自我防护。 安全行业实际上鲜为人知，但由于传统形象，很少被采用。
这类技术的优势在于疫情类比，传统边界防御类产品类似口罩/防护服，而RASP像疫苗一样，将自己注入APP定位，与APP定位一起运行，通过hook关键函数实时APP定位执行的高危行为
与基于流量特征的检测不同，RASP是什么类型0天的天敌，RASP的中心关注的是APP行为而不是流量本身。
当RASP发现APP应用，并做了它通常不应该做的事情时，高概率意味着当前的APP应用被攻击者利用漏洞攻击，执行一些高危操作(命令执行、文件读取、文件上传
其第一个优势是：凡是被 RASP 防御的行为，都已经是真正可以被成功利用的攻击行为。
另一方面，与接近无限的流量特性相比，适用的行为类型多为可以穷举。 从应用行为异常的角度检测，范围可以大大收敛于有限的类型，这是RASP能够达到无视流量特征并且不依赖规则更新就可以防御几乎全部0day（包括加密流量和内存马）的根本原因。
0day和一些弱特征漏洞利用方式难以防御的原因已经阐述。 但是，无论通信特征如何变化，漏洞利用的本质是在让APP应用进行不安全的动作方面返回——，也就是APP应用的行动和企图。
在此漏洞中，RASP关注的是lo，而不是请求中的流量是否包含恶意payLoad
g4j2 究竟使用 JNDI 功能去做了什么。如果进行正常的 JNDI 查询，就没有问题；但如果企图使用 JNDI 功能进行命令执行，就是一个显而易见的危险行为。RASP 正是在这个阶段发挥了极其重要的作用：在应用犯错之前将其“悬崖勒马”。
从这个角度上还可以引申出 RASP 的第二个优势：误报极低。
比如：如果应用压根没有使用 Log4j2，基于 payload 中的恶意特征上报攻击就意味着误报，一定程度上消耗安全人员的精力。
而由于 RASP 运行在应用内部，可以明确知道来自流量层的 payload 是否成功进入了 Log4j2 的危险函数，所以不会存在“无效告警”。
近些年来，从 weblogic 到 shiro、dubbo 再到今天的 Log4j2，由第三方组件导致的 0day 不断的大规模爆发。
因为这类组件的代码并不由使用它的应用的开发们维护，一旦漏洞爆发，安全人员第一时间首先需要投入大量的精力去排查哪些应用在使用存在漏洞的组件，这并不是一个容易的事情。特别是对应用众多、迭代快速的企业来说，自己也说不清楚哪些应用、在使用哪些组件的、哪些版本是非常正常的事情。
这里引出了 RASP 的第三个优势：第三方组件自查。
当一个 0day 出现时，可以第一时间排查到受影响组件的路径，如下图所示：
（通过阿里云RASP定位的Log4j组件路径）
对于历史上已经爆出过 CVE 漏洞的组件，RASP 可以自动检测并关联其对应的 CVE 漏洞编号、漏洞等级等信息，方便安全和开发人员及时修复。
云原生 RASP，架构优势加速落地2014 年，Gartner 就将 RASP 列为应用安全的关键趋势，但实际上 RASP 在生产环境中大规模落地一直比较缓慢，目前也只有少数头部的互联网公司做到了。究其原因，最大的阻碍在于 RASP 技术对应用自身的入侵性，开发人员会非常担忧产生性能、稳定性、兼容性下降等问题。
阿里巴巴集团从 2015 年开始部署自研的 RASP 产品，多年实践已完成在生产网的大规模部署，并且经历了生产网超大流量业务的实战检验，在性能、稳定性和安全性（自我保护）控制方面实现最佳表现。不得不说，这其中的确需要大量时间来沉淀经验和教训，不断调优，这也是甲方安全团队自建 RASP 最大的难点。
阿里云安全团队将 RASP 最佳实践尝试输出，去年推出更通用、更适合用户场景的 RASP 版本，并在多个金融、教育用户的生产网中部署和应用。今年，打通云架构优势，实现云原生 ARMS 产品应用一键接入 RASP 的丝滑体验（开启路径：阿里云 ARMS-应用安全菜单），极大降低云上用户使用 RASP 防御能力的门槛。
近期事件接入 RASP 的用户中，阿里云安全团队观测到非常凶猛的 Log4j2 漏洞利用和危险行为。以某金融用户为例，接入 2 天，RASP 检测并拦截了涉及 8 个 Java 应用的 184 次真实攻击，其中包含 43 次命令执行和 141 次 DNS 漏洞探测。如果缺少 RASP 的防御一环阻拦，这些是极大可能真实执行成功的攻击。
当前版本免费公测，应急的安全同志们可以接入 RASP 再从容升级。如果需保护应用暂时没有上云，也可以联系我们部署线下版 RASP。
PS：因漏洞管理规定，文中图片漏洞细节通过马赛克做了模糊处理，敬请谅解
点击*此处*，了解更多ARMS相关信息！
对 ARMS 感兴趣的同学，可以钉钉搜索群号（34833427）或扫描下方二维码入群交流、答疑～