RASP技术进阶系列（三）：重大漏洞自动化热修复

 

在上篇文章《RASP技术进阶系列（二）：东西向Web流量智能检测防御》中提到，在企业日常安全运营以及HW场景下，应用漏洞攻击应急响应和恶意流量溯源分析是安全团队的重点工作。在恶意流量溯源方面，指向攻击来源的流量追踪以及指向缺陷成因的代码片段定位的RASP技术特点也已经在上篇文章中有了详细介绍。本篇主要介绍在应急响应过程中RASP如何加快工作流程并为重大漏洞紧急修复争取宝贵时间。

应急响应的目的是尽可能地减小和控制住网络安全事件的损失，提供有效的响应和恢复指导，并努力防止安全事件的发生。《中华人民共和国网络安全法》针对建立网络安全监测预警与应急处置制度专门列出一章作出规定。2017年6月，中央网信办公布了《国家网络安全事件应急预案》来指导各级各类网络安全预案的制定。

信息收集

当前，企业发现0Day漏洞的手段除了主动收集威胁情报外，主要是依靠HIDS、EDR等主机侧检测与响应工具被动发现。RASP与上述工具相同，都是在最终执行敏感操作、敏感文件读取等行为时进行响应的。但不同的是，RASP相比前两款工具，具备更强的溯源与风险定位能力，除了能跟踪到跨节点之间的调用链路外，还具备代码级别的缺陷定位能力。

值得一提的是，在未知重大漏洞的检测与防护原理上，RASP与HIDS、EDR等工具都不是直接对缺陷本身进行检测或防护，而是对成功利用漏洞后的后续敏感行为进行响应的。以Log4Shell漏洞举例，在恶意请求进入Log4j2缺陷代码逻辑时，鲜有工具能直接发现其中存在被利用的可能。但是攻击者利用漏洞后的最终目的一定会落在执行命令/代码、读写敏感文件/数据。所以只要在足够底层进行监控，一定能检测或者拦截到具有风险的行为。

当前，蓝队的应急排查工具箱中主要覆盖的是网络流量以及操作系统层面，例如：tcpdump、wireshark、process-check等以及一些日志分析工具。而对与应用层面的检查和分析工具却掏不出来。这就导致在Log4Shell这样核弹级供应链安全漏洞爆发时，大家发现自己之前想好的应急处置预案派不上用场，只能求助研发团队进行自查。RASP凭借其技术特点，从应用程序内部，为企业提供了新解题思路。相比其它主机侧解决方案，RASP不仅能提供调用栈级别的缺陷定位，还可以提供代码级别的热修复补丁。此外，通过代码疫苗技术，还可以根据代码调用逻辑发现应用中自研代码以及引用的第三方组件中的缺陷，并提供详细的定位信息。

风险评估

根据前期信息收集确定风险类型和级别，并确定受影响范围。

风险定级

当收到一条RASP告警后，根据以下三个步骤可快速完成风险定级：

1. 根据URL对应的业务模块以及RASP策略命中的危险参数来判断攻击者是在进行攻击前尝试还是正在进行实际攻击，如图1所示：

图1 对同一代码片段的利用尝试记录

2. 通过代码调用栈，可以快速定位到漏洞是来自于自研代码缺陷还是由开源组件引入的风险，如图2所示：

图2 漏洞定位

3. 根据业务的重要程度、风险的通用程度以及漏洞的利用难度即可快速确定风险等级。

确定影响范围

● 若是自研代码中的缺陷，则影响范围通常是某个业务模块；

● 若是由开源组件引入的风险，则可以根据软件成分分析，迅速定位到风险组件关联的应用，从而快速确定受影响的范围。RASP探针可以从应用中收集到其引用的第三方依赖信息，当某个组件发现漏洞后，就可以通过组件和应用的关联关系快速找到受影响的应用。如下图所示，根据fastjson:1.2.23找出了6个引用它的应用。

图3 组件成分分析-关联应用展示

通过以上步骤，可以快速确定风险级别和受影响的范围。

制定修复方案

应用的修复方案也分为“冷”修复和“热”修复。“冷”修复即通过迭代和重新发布来修复风险。这样的好处是可以通过内部测试完整验证漏洞是否已经被修复。并且在修复的过程中，可以重新梳理在其他模块中是否仍有类似的问题，可以一并被修复。但是，修复的周期可能会被拉长，风险被利用的可能性也会成倍增长。并且由于需要重启，有些业务可能无法接受。

如果无法将受影响的应用及时下线进行修复，则可以使用RASP应用热修复功能给应用打上一个临时“补丁”。

热修复技术目前较为成熟的应用是在移动端，Android平台较为出名的有Tinker、AndFix以及Robust等，但都需要在研发阶段就进行配置。RASP技术主要用于Web Server，且不需要修改代码，直接通过动态自动化修改的方式提供防护，RASP通常提供了两类自动化热修复方式：一类是流量级的，例如URL、请求、响应等；另一类是代码级的，例如函数入参、函数返回值、代码调用栈等，如下图所示。匹配方式主要包括值匹配、正则匹配、是否包含、是否为空等方式。

图4 RASP应用热修复类型

流量级别的应用热修复与传统WAF规则的差异主要在RASP可以获取到解密后的流量，这在一些场景下可以减少WAF的开销，而在其他方面二者几乎没有差别，本文也不再举例赘述。

代码级别的热修复主要分为两类，一类是直接禁止某些函数/方法执行，另一类则需要深入函数内部，根据传参、返回值、调用栈等信息来判断是否需要进行处理。下面分别对这两类热修复的应用场景进行介绍。

禁止函数/方法执行

如果在组件中发现了一些包含风险的方法，而项目中又没有用到这些方法，就可以尝试通过热修复的方式禁用这些方法。

例如CVE-2021-44228 Log4j2远程代码执行漏洞，其主要原因是lookup错误处理了${jndi://}数据，导致了远程代码执行的风险。这种情况下，可以直接根据RASP获得的代码调用栈信息，直接拦截此方法。

图5 Log4j函数调用栈

图6 禁止方法执行配置示例

深入函数内部进行判断

当发现的风险方法是需要被调用时，情况可能会复杂一些，需要根据业务需要进行定制。

例如下述代码中，因为业务需要，应用程序需要接收用户输入来执行一些命令，但是在编写代码时却没有以白名单的形式来控制可执行命令的范围。

图7 命令执行缺陷代码示例

这时，就可以通过RASP应用热修复对方法入参进行判断，不允许白名单以外的命令被执行：

图8 定义函数参数白名单对缺陷进行修复

在特定场景下，可能需要多种逻辑组合判断，通过对多个条件的组合来完成应用热修复规则的编写。

在制定完成应急处置方案后，要迅速采取措施，抓紧对受影响对应用进行修补，减少损失，尽快恢复正常工作。

在重大漏洞应急响应过程中，借助悬镜云鲨RASP可以快速定位到风险来源与影响范围，并通过应用热修复能力为应用提供临时防护。不仅提高了企业对应用风险的宏观掌控能力，也从微观层面为企业提供了应用漏洞应急的新方案。融入了运行时SCA、敏感信息追踪、应用运行时威胁免疫等技术的代码疫苗技术将更好赋能企业在云原生场景下进行应用漏洞的运营与供应链威胁的治理。