Apache Log4j2 远程代码执行漏洞已爆发一周，安全厂商提供各类防御方案和检测工具，甲方团队连夜应急。
影响持续至今，网上流传的各种利用和绕过姿势还在层出不穷，影响面持续扩大。所有安全人都开始反思一个问题：当前的防御是否有效？针对这样的 0day 再次发生，什么是有效的手段？
阿里云安全团队此次参与了诸多客户应急，并从云平台自身防御总结经验，尝试抛出一些观点以供讨论。
首先，我们先来从技术层面分析一下为什么这次 Log4j2 这么难搞。
Apache Log4j2 漏洞们的特质
此次 Log4j2 漏洞有两个很棘手的特质：
可以实现任意远程代码执行
“懂规矩”的漏洞，危险大的利用门槛高，利用门槛低的危害小，还算符合自然规律。这个漏洞并不按常规出牌，不但影响面广，利用门槛低，危害还极大。三个因素重叠，到处被冠上“史诗级”的头衔。
Java 的应用极其广泛且生态庞大，而 Log4j 作为日志处理的基础组件被几乎所有应用程序所使用。
通过 JNDI 注入的手段，可以实现任意远程代码执行，意味着攻击者可以在存在漏洞的服务器上为所欲为。
即使在内网环境中 JNDI 外联无法成功，攻击者也可以结合 lookup 特性去读取很多敏感信息（如数据库密码、JAVA 环境变量等），再通过 DNS 协议把敏感信息带出内网。
流量特征隐蔽
某些场景下几乎没有可以跟正常请求区分开来的强特征。
本次漏洞 PoC 构造非常简单，漏洞触发的点广泛而灵活，配合各种变量和协议的嵌套绕过方式，导致流量特征非常复杂和隐蔽。Log4j2 的 lookup 功能支持一些特殊的写法来对字符做二次处理，如 ${lower:j}Ndi、${upper:JN}di、${aaa:vv:cc:-j}ndi 等写法，都能打破字符串的连续性，造成利用时候的流量特征极为不明显。
这是对所有基于流量特征安全防护产品的巨大挑战。
当流量特征不够明显时，基于流量特征的规则陷入尴尬：要么覆盖不到，要么产生严重误报。只能持续不断补充规则，在绕过和被绕过中循环往复。这种防御手段，能在 0day 爆发初期非常有效的为漏洞修复争取时间。但随着各种利用手段的变化越来越多，则很难保证没有被绕过或误报。
与 Log4j2 漏洞的某些“弱特征”甚至“0 特征”利用方式类似的场景，还有加密流量、内存马等，这些手段都曾在大型攻防演练中大放异彩，难以检测的原理是类似的。
所以，有没有一种技术，可以无视漏洞利用手法在流量特征上的各种变化或隐藏，防御的更天然，甚至不依赖规则更新就可以防御这类 0day？
RASP 在此次事件中重回视野
RASP（Runtime Application Self-Protection），运行时应用自我防护，安全行业其实对其并不陌生，却因为传统印象而采纳不多。
这类技术的优势在于，以疫情类比，传统的边界防御类产品，类似口罩/防护服，而 RASP 则类似疫苗，会将自己注入到应用当中，伴随应用一起运行，通过 hook 关键函数实时检测应用执行的高危行为。
RASP 是哪一类 0day 的天敌
不同于基于流量特征的检测，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 漏洞编号、漏洞等级等信息，方便安全和开发人员及时修复。
云原生 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）或扫描下方二维码入群交流、答疑～
