Apache Log4j2远程代码执行漏洞已爆发一周，安全厂商提供各类防御方案和检测工具，甲方团队连夜应急。

影响持续至今，网上流传的各种利用和绕过姿势还在层出不穷，影响面持续扩大。所有安全人都开始反思一个问题：当前的防御是否有效？针对这样的0day再次发生，什么是有效的手段？

阿里云安全团队此次参与了诸多客户应急，并从云平台自身防御总结经验，尝试抛出一些观点以供讨论。

首先，我们先来从技术层面分析一下为什么这次Log4j2这么难搞。

此次Log4j2漏洞有两个很棘手的特质：

1.可以实现任意远程代码执行

“懂规矩”的漏洞，危险大的利用门槛高，利用门槛低的危害小，还算符合自然规律。这个漏洞并不按常规出牌，不但影响面广，利用门槛低，危害还极大。三个因素重叠，到处被冠上“史诗级”的头衔。

Java的应用极其广泛且生态庞大，而Log4j作为日志处理的基础组件被几乎所有应用程序所使用。

通过JNDI注入的手段，可以实现任意远程代码执行，意味着攻击者可以在存在漏洞的服务器上为所欲为。

即使在内网环境中JNDI外联无法成功，攻击者也可以结合lookup特性去读取很多敏感信息（如数据库密码、JAVA环境变量等），再通过DNS协议把敏感信息带出内网。除非通过云防火墙“主动外联管控+DNS防火墙阻断解析外带信息” 这两重主动外联管控能力，可以阻止漏洞利用和“不出网”的信息泄露。

详情可见《警惕主动外联！云防火墙检测拦截勒索、Muhstik僵尸网络等 Log4j2漏洞利用》

2.流量特征隐蔽

某些场景下几乎没有可以跟正常请求区分开来的强特征。

本次漏洞PoC构造非常简单，漏洞触发的点广泛而灵活，配合各种变量和协议的嵌套绕过方式，导致流量特征非常复杂和隐蔽。Log4j2的lookup功能支持一些特殊的写法来对字符做二次处理，如${lower:j}Ndi、${upper:JN}di、${aaa:vv:cc:-j}ndi等写法，都能打破字符串的连续性，造成利用时候的流量特征极为不明显。

下图是一款专门用于混淆Log4j2利用的工具对Payload进行混淆后的结果，可以看到混淆后的结果是极具欺骗性的：

这是对所有基于流量特征安全防护产品的巨大挑战。

当流量特征不够明显时，基于流量特征的规则陷入尴尬：要么覆盖不到，要么产生严重误报。只能持续不断补充规则，在绕过和被绕过中循环往复。这种防御手段，能在0day爆发初期非常有效的为漏洞修复争取时间。但随着各种利用手段的变化越来越多，则很难保证没有被绕过或误报。

与Log4j2漏洞的某些“弱特征”甚至“0特征”利用方式类似的场景，还有加密流量、内存马等，这些手段都曾在大型攻防演练中大放异彩，难以检测的原理是类似的。

所以，有没有一种技术，可以无视漏洞利用手法在流量特征上的各种变化或隐藏，防御的更天然，甚至不依赖规则更新就可以防御这类0day？

RASP（Runtime Application Self-Protection），运行时应用自我防护，安全行业其实对其并不陌生，却因为传统印象而采纳不多。

这类技术的优势在于，以疫情类比，传统的边界防御类产品，类似口罩/防护服，而RASP则类似疫苗，会将自己注入到应用当中，伴随应用一起运行，通过hook关键函数实时检测应用执行的高危行为。

不同于基于流量特征的检测，RASP核心关注应用行为，而非流量本身。

当RASP发现一个应用，做了它正常不应该做的事情时，大概率意味着当前应用已经被攻击者利用漏洞攻陷并做了一些高危操作（比如命令执行、文件读取、文件上传、SSRF等）。

其第一个优势是：凡是被RASP防御的行为，都已经是真正可以被成功利用的攻击行为。

而应用的行为类型，相比于变幻无穷近乎无限的流量特征来说，往往是可以穷举的。从应用行为异常的角度去检测，范围可以大幅收敛到有限的类型，这是RASP可以**无视流量特征并且不依赖规则更新就可以防御几乎全部0day（包括加密流量和内存马）**的根本原因。

0day和一些弱特征漏洞利用方式之所以难以防御的原因，上文已经提及。但不管流量特征如何变化，漏洞利用的本质：还是要回归到让应用来做一些不安全的动作上——也就是应用行为或者企图。

以此次漏洞来看，RASP并不关注请求中的流量是否包含了恶意的Payload，而是去关注Log4j2究竟使用JNDI功能去做了什么。如果进行正常的JNDI 查询，就没有问题；但如果企图使用JNDI功能进行命令执行，就是一个显而易见的危险行为。

RASP正是在这个阶段发挥了极其重要的作用：在应用犯错之前将其“悬崖勒马”。

从这个角度上还可以引申出RASP的第二个优势：误报极低。

比如：如果应用压根没有使用Log4j2，基于Payload中的恶意特征上报攻击就意味着误报，一定程度上消耗安全人员的精力。

而由于RASP运行在应用内部，可以明确知道来自流量层的Payload是否成功进入了Log4j2的危险函数，所以不会存在“无效告警”。

近些年来，从weblogic到shiro、dubbo再到今天的Log4j2，由第三方组件导致的0day不断的大规模爆发。

因为这类组件的代码并不由使用它的应用的开发们维护，一旦漏洞爆发，安全人员第一时间首先需要投入大量的精力去排查哪些应用在使用存在漏洞的组件，这并不是一个容易的事情。特别是对应用众多、迭代快速的企业来说，自己也说不清楚哪些应用、在使用哪些组件的、哪些版本是非常正常的事情。

这里引出了RASP的第三个优势：第三方组件自查。

当一个0day出现时，可以第一时间排查到受影响组件的路径，如下图所示：

（通过阿里云RASP定位的Log4j组件路径）

对于历史上已经爆出过CVE漏洞的组件，RASP还可以自动检测并关联其对应的CVE漏洞编号、漏洞等级等信息，方便安全和开发人员及时修复。

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：因漏洞管理规定，文中图片漏洞细节通过马赛克做了模糊处理，敬请谅解