由于 Web 应用程序的复杂性和重要性, 导致其成为网络攻击的主要目标之一。攻击者在入侵一个网站后, 通常会植入一个 Webshell, 来持久化控制网站。但随着攻防双方的博弈, 各种检测技术、终端安全产品被广泛应用, 使得传统的以文件形式驻留的 Webshell 越来越容易被检测到, 内存型 Webshell 成为新的趋势。本文面向 Java 应用程序, 总结内存型 Webshell 的特征和原理, 构建内存型Webshell 威胁模型, 定义了高对抗内存型 Webshell, 并提出一种基于RASP(Runtime application self-protection, 运行时应用程序自我保护)的动静态结合的高对抗内存型 Webshell 检测技术。实验表明, 与其他检测工具相比, 本文方法检测内存型 Webshell 效果最佳, 准确率为 96.45%, 性能消耗为 7.74%,具有可行性, 并且根据检测结果可以准确定位到内存型Webshell 的位置。
目录
5 实验与分析
5.1 实验环境与数据
5.2 检测能力分析
5.3 案例分析
5.4 性能分析
6 总结与展望
5 实验与分析
通过内存型 Webshell 请求和正常请求对本文提出的基于 RASP 动静态结合的高对抗内存型Webshell 检测方法进行评估。从准确率、精确率、召回率、F1 值 4 个指标评估本文方法的检测能力, 并结合实际利用场景对两种类型 Webshell 的检测结果分析, 从时间开销和资源消耗两方面评估本文方法的检测性能, 最后对检测方法进行讨论。
5.1 实验环境与数据
测试环境使用 1 台服务器, 操作系统为 Ubuntu 20.04, 配置为双核处理器和 16G 内存。
实验采取的数据集来自于 GitHub 上的样本, 以及 Webshell 的管理工具, 例如冰蝎、哥斯拉等。样本覆盖组件类和Agent类的内存型Webshell, 组件类包括 Filter、Servlet、Listener、Valve、Controller、Interceptor 等。部分数据集来源如表 7 所示。
5.2 检测能力分析
实验对正常请求和内存型 Webshell 的请求分别测试。内存型 Webshell 请求分为两部分, 分别对其注入过程和利用过程进行测试。组件类是实时检测, 能够检测注入过程, Webshell 注入成功后会被再次访问, 所以包含注入过程和利用过程两部分。Agent 类是静态检测, 只包含利用过程。注入过程包括组件类的 31个样本, 利用过程包括组件类和Agent类的全部样本,共 40 个, 目前 Agent 样本比较少, 实验数据共 9 条。内存型Webshell共71个样本; 正常请求共70个样本,如表 8 所示。本次实验对 Tomcat 容器、Spring 框架、Weblogic 容器进行了测试。
准确率表示检测正确的结果占总样本的百分比,即预测正确的概率, 计算公式如下:
精确率是检测为 Webshell 的样本中实际为Webshell 的概率, 表示对 Webshell 检测的准确程度,计算公式如下:
召回率是实际为 Webshell 的样本中被检测为Webshell 的概率, 计算公式如下:
Precision和Recall都越高越好, 但两者是一对矛盾的度量, F 1 值是 Precision 和 Recall 的一种调和平均, 同时权衡这两个指标, F 1 值越高越好。计算公式如下:
通过对 71 个 Webshell 和 70 个正常请求的测试 ,4 个工具的检测结果如表 9 所示。
OpenRASP 是基于 RASP 的动态检测工具 , 目前只能在程序启动时指定 Java Agent 以 premain 的方式对程序进行检测 , 在程序运行时无法嵌入检测程序 ,因此运行时如果检测需要重启服务。该工具对于 Listener 、 Valve 组件的命令执行后的利用过程也检测不到 , 准确率和召回率较低。该工具只能通过触发后门的方式拦截并报警 , 本文将该工具对内存型Webshell 攻击的拦截报警认为是检测到了内存型Webshell, 因此精确率为 100% 。该工具只收集了目标程序的运行时信息 , 无法定位到存在后门的类。 F1值也较低。
Copagent 是一款基于规则匹配的静态检测工具。该工具无法对目标程序实时检测 ,无法对内存型 Webshell 的注入过程进行检测。该工具设定的字符串匹配比较单一 , 只针对 Webshell 常使用的字符串 , 所以精确率高。但设定的规则比较简单 , 无法检测到 Controller 、 Interceptor 、 Valve 类的内存型 Webshell, 并且实验可以绕过该工具匹配的字符串 , 该工具无法检测高对抗内存型 Webshell, 准确率、召回率、 F1 值都比较低。
5.3 案例分析
搭建内存型 Webshell 实际利用场景 , 分析本文检测方法对组件类和 Agent 类 Webshell 后门的检测过程案例分析。搭建反序列化漏洞的 Web 服务 , 测试对组件类内存型 Webshell 的检测过程 ; 搭建任意文件上传漏洞的 Web 服务 , 测试对 Agent 类内存型 Webshell 的检测过程。
(1) 组件类内存型 Webshell
搭建 Tomcat 环境和 Shiro 框架 , 利用 Shiro 的反序化漏洞注入组件类内存型 Webshell 。首先使用Shiro_Attack 工具 [39] 爆破密钥 , 然后使用反序列化攻击解除 Shiro 对 header 的长度限制 , 之后选择一个Filter 类内存型 Webshell, 对其进行序列化、 AES 加密、 base64 编码 , 最后将其作为 cookie 的字段值发送到目标应用程序中。
内存型 Webshell 调用的注册组件函数是 org.apache.catalina.core. Applica-tion-Context@addFilter, 注 册 的 组 件 类 名 为com.shiro.vu-ln.Controller.TomcatMemShellInject,Webshell 注入过程中的调用栈信息如图 9 所示。
(2) Agent 类内存型 WebShell
搭建 Tomcat 任意文件上传漏洞的测试环境 , 改造冰蝎中的 Agent 内存型 Webshell, 并注入混淆的高对抗代码 , 通过冰蝎上传改造后的 jar 包 , 注入Webshell 后门。注入成功后 , 可以访问到 Webshell后门 , 并且磁盘上不存在该文件。
用本文检测方法防御后 , 成功检测到被内存型Webshell 修改的系统类并发送邮件。结果显示内存型Webshell 存在的类是 org.apache.jasper.servlet.Jsp-ervlet, 高危类是 javax/servlet/Servlet 接口。如图 10所示。
5.4 性能分析
因为动态检测方法是在应用程序运行时进行检测 , 为了不影响用户的正常访问 , 性能评估尤为重要。检测方法和OpenRASP 进行性能测试分析和对比。使用 Apache公司的 JMeter性能测试工具进行测试。以 Tomcat 服务作为实验环境 , 每次请求将执行 1000 次哈希计算操作 , 使系统响应时间更加接近实际的用户体验度。在没有任何安全防护的情况下 ,测试服务的平均响应时间 , 然后在服务上部署本文检测方法和 OpenRASP 后分别测试服务的平均响应时间。
设置 JMeter 的线程数为 2000, Ramp-up period 为60s, 来模拟 2000 个用户在 60s 内随机进行访问 , 将此过程循环 10 次 , 总体请求数为 20000 个。假如运行检测工具前后的平均响应时间分别是
T 1 、 T 2 , 则性能消耗的计算公式 T 如下所示。
检测结果如表 11 所示。检测工具运行前系统的平均响应时间是 1.55s, 本文检测方法运行后的平均
响应时间是 1.67s, 平均响应时间延迟 0.12, 性能消耗是 7.74%, 在可接受范围。 OpenRASP 运行后的平均响应时间是 1.98s, 平均响应时间延迟 0.43s, 性能消耗是 27.74%, 较为明显。
由于 Copagent 工具和某工具无法检测高对抗内存型 Webshell, 为了测试其静态检测能力 , 只对部分Agent 类内存型 Webshell 改造为高对抗内存型Webshell 进行测试。受限于内存型 Webshell 样本的稀缺 , 无法达到更全面的检测效果。
6 总结与展望
对 Java 内存型 Webshell 进行了研究 , 分析两种类型的内存型 Webshell 原理 , 并提出高对抗内存型 Webshell 定义 , 设计了一种动静态相结合的方法检测高对抗内存型 Webshell 。从内存型 Webshell 的输入源、触发器、特征状态方面出发 ,利用 RASP 技术对输入源中的注册组件类函数 , 以及特权类函数进行监测 , 根据内存型 Webshell 的特性 , 针对不同的触发器场景分析 , 结合数据流分析技术进行动态检测 ; 针对攻击载荷改造的高对抗内存型 Webshell, 基于深度学习模型训练 , 进行静态文本特征的检测。对本文检测方法进行了实验评估 , 对71 个内存型 Webshell 样本和 70 正常样本进行测试 ,结果表明本文检测方法的准确率达到 96.45%, 性能消耗为 7.74%, 具有可行性。
下一步工作中 , 将完善针对 Java Web 内存型Webshell 的检测方案 , 本文检测方案中在内存型Webshell 注入过程中监测了注册组件类的函数 , 没有对内存型 Webshell 注入过程中的可利用漏洞处进行监测 , 后续将针对这部分内容进行补充 , 增加内存型 Webshell 在注入时的检测效率。另外研究其他语言 Web 服务的内存型 Webshell 检测技术。