共计 2989 个字符，预计需要花费 8 分钟才能阅读完成。
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）或扫描下方二维码入群交换、答疑～