Tomcat 内存马检测
随着HW、攻防对抗的强度越来越高,各大厂商对于webshell的检测技术愈发成熟,对于攻击方来说,传统的文件落地webshell的生存空间越来越小,无文件webshell已经逐步成为新的研究趋势。
三月底针对tomcat内存马的检测写了一个demo,但由于对Maven打包理解不深,整个项目结构比较糟糕。
国庆前研究了LandGrey师傅的copagent项目,在该项目基础上进行了重构,并于本文中记录了检测思路,以及部分核心代码。
作者: jweny @360云安全
0x01 Java内存马简介
关于JAVA内存马的发展历史,这里引用下 c0ny1师傅的总结 。早在17年n1nty师傅的《Tomcat源码调试笔记-看不见的shell》中已初见端倪,但一直不温不火。后经过rebeyond师傅使用agent技术)加持后,拓展了内存马的使用场景,然终停留在奇技淫巧上。在各类hw洗礼之后,文件shell明显气数已尽。内存马以救命稻草的身份重回大众视野。特别是今年在shiro的回显研究之后,引发了无数安全研究员对内存webshell的研究,其中涌现出了LandGrey师傅构造的Spring controller内存马。
从攻击对象来说,可以将Java内存马分为以下几类:
为方便学习,webshell demo已整理至github。
0x02 整体思路
无论是以上哪种攻击方式,影响的均为加载到tomcat jvm中的类。
从防守方的角度来说,可以通过java instrumentation机制,将检测jar包attach到tomcat jvm,检查加载到jvm中的类是否异常。
整体检测思路为:
1.获取tomcat jvm中所有加载的类
2.遍历每个类,判断是否为风险类。这里把可能被攻击方新增/修改内存中的类,标记为风险类(比如实现了filter/servlet的类)
3.遍历风险类,检查是否为webshell:
检查高风险类的class文件是否存在;
反编译风险类字节码,检查java文件中包含恶意代码
0x03 获取jvm中所有加载的类
1.遍历java jvm,查找所有的tomcat jvm
2.通过java instrumentation,将agent attach到每个tomcat jvm。由于可能存在多个tomcat进程的场景,因此每个tomcat jvm均检测一遍
3.遍历tomcat jvm 加载过的类
0x04 风险类识别
最理想的做法是把所有加载的类都认定为风险类。但在绝大多数情况下jvm加载的都是正常的类,每次检查时,都dump所有加载的类,对于tomcat来说开销有点大。
比较实际的做法是,根据已知内存马要新增/修改的类生成特征。
对于内存中的每一个类,检查其自身,并递归检查其父类,如果命中特征,就标记为风险类。
这里借鉴了LandGrey师傅的黑名单,将内存马的目标类的类名、继承类、实现类、所属的包、使用的注解均设置黑名单。
1. 实现类黑名单
检测类是否实现javax.servlet.Filter / javax.servlet.Servlet / javax.servlet.ServletRequestListener接口类。
2. 继承类黑名单
3. 注解黑名单
通过clazz.getDeclaredAnnotations() 获取所有注解,如果类使用了spring注册路由的注解,则标记为高风险。
4. 类名黑名单
5. 包名黑名单
6. 基于mbean的filter/servlet风险类识别
这里分享另一种filter/servlet的检测,检测思路是通过mbean获取sevlet/filter列表,内存马的filter是动态注册的,所以web.xml中肯定没有相应配置,因此通过对比可以发现异常的filter。
不过这种方式有较大的缺陷。首先,mbean只是资源管理,并不影响功能,所以在植入内存马后再卸载掉注册的mbean即可绕过;其次,servlet 3.0引入了 @WebFilter 可以动态注册,这种也没有在web.xml中配置,会引起误报,因此仅可作为一个查找风险类的参考条件。
0x05 检测是否为内存马
遍历风险类列表,并检测以下规则:
内存马,对应的ClassLoader目录下没有对应的class文件
反编译该类的字节码,检查是否存在危险函数
结果输出参考:如果没有class文件,可将该类风险等级标为high。如果包含恶意代码,将该类风险等级调至最高级。
0x06 小结
本文仅对Tomcat内存马的检测提供了一些思路,但并未提及查杀,查杀将在下一篇详细分享。
以上所有方法的黑名单列表仅供参考,可自行更改、扩充。
再次感谢 fnmsd、c0ny1、LandGrey 师傅们的大力支持。
0x07 参考文章
最后更新于
这有帮助吗?