内存的检测与排查

内存🐎的检测与排查

查杀Java Web filter型内存马

0x01 内存马简历史

其实内存马由来已久，早在17年n1nty师傅的《Tomcat源码调试笔记-看不见的shell》中已初见端倪，但一直不温不火。后经过rebeyong师傅使用agent技术加持后，拓展了内存马的使用场景，然终停留在奇技淫巧上。在各类hw洗礼之后，文件shell明显气数已尽。内存马以救命稻草的身份重回大众视野。特别是今年在shiro的回显研究之后，引发了无数安全研究员对内存webshell的研究，其中涌现出了LandGrey师傅构造的Spring controller内存马。至此内存马开枝散叶发展出了三大类型：

1. servlet-api类

• • filter型
• • servlet型

1. spring类

• • 拦截器
• • controller型

1. Java Instrumentation类

• • agent型

0x02 查杀思路

利用Java Agent技术遍历所有已经加载到内存中的class。先判断是否是内存马，是则进入内存查杀。

0x03 内存马的识别

1.filter名字很特别【弱特征】

内存马的Filter名一般比较特别，有shell或者随机数等关键字。这个特征稍弱，因为这取决于内存马的构造者的习惯，构造完全可以设置一个看起来很正常的名字。

2.filter优先级是第一位【弱特征】

为了确保内存马在各种环境下都可以访问，往往需要把filter匹配优先级调至最高，这在shiro反序列化中是刚需。但其他场景下就非必须，只能做一个可疑点。

对于一个web工程的filter过滤器，一般有两种方式放入项目中：

1、在web.xml里面配置

之前我们控制多个filter的执行顺序是通过web.xml中控制filter的位置来控制的，放在上面的会比放在下面的先执行，如下“用户登录检查过滤器”会比“接口日志过滤器”先执行。

<!-- 用户登录检测过滤器 -->
<filter>
	<filter-name>UserLoginFilter</filter-name>
	<filter-class>net.tfgzs.demo.filter.UserLoginFilter</filter-class>
</filter>
<filter-mapping>
	<filter-name>UserLoginFilter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>
<!--接口日志过滤器-->
<filter>
	<filter-name>ApiLog</filter-name>
	<filter-class>net.tfgzs.demo.filter.ApiLog</filter-class>
</filter>
<filter-mapping>
	<filter-name>ApiLog</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

2、@WebFilter注解

注解里面没有提供可以控制执行顺序的参数，通过实践发现如果想要控制filer的执行顺序可以 通过控制filter的文件名的首字母来 来控制。

比如：

UserLoginFilter.java 和 ApiLog.java 这两个文件里面分别是“用户登录检查过滤器”和“接口日志过滤器”，因为这两个文件的 首字母A排U之前 ，导致每次执行的时候都是先执行“接口日志过滤器”再执行“用户登录检查过滤器”。

3.对比web.xml中没有filter配置【强特征】

内存马的Filter是动态注册的，所以在web.xml中肯定没有配置，这也是个可以的特征。但servlet 3.0引入了@WebFilter标签方便开发这动态注册Filter。这种情况也存在没有在web.xml中显式声明，这个特征可以作为较强的特征。

4.特殊classloader加载【弱特征】

我们都知道Filter也是class，也是必定有特定的classloader加载。一般来说，正常的Filter都是由中间件的WebappClassLoader加载的。反序列化漏洞喜欢利用TemplatesImpl和bcel执行任意代码。所以这些class往往就是以下这两个：

• com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl$TransletClassLoader

• com.sun.org.apache.bcel.internal.util.ClassLoader

这个特征是一个特别可疑的点了。当然了，有的内存马还是比较狡猾的，它会注入class到当前线程中，然后实例化注入内存马。这个时候内存马就有可能不是上面两个classloader。

5.对应的classloader路径下没有class文件【强特征】

所谓内存马就是代码驻留内存中，本地无对应的class文件。所以我们只要检测Filter对应的ClassLoader目录下是否存在class文件。

private static boolean classFileIsExists(Class clazz){
    if(clazz == null){
        return false;
    }

    String className = clazz.getName();
    String classNamePath = className.replace(".", "/") + ".class";
    URL is = clazz.getClassLoader().getResource(classNamePath);
    if(is == null){
        return false;
    }else{
        return true;
    }
}

6.Filter的doFilter方法中有恶意代码【强特征】

我们可以把内存中所有的Filter的class dump出来，使用fernflower等反编译工具分析看看，是否存在恶意代码，比如调用了如下可疑的方法：

• java.lang.Runtime.getRuntime

• defineClass

• invoke

• …

不难分析，内存马的命门在于5和6。简单说就是Filter型内存马首先是一个Filter类，同时它在硬盘上没有对应的class文件。若dump出的class还有恶意代码，那是内存马无疑。

0x04 内存马的查杀

java-memshell-scanner

通过jsp脚本扫描并查杀各类中间件内存马，比Java agent要温和一些。

未注入内存马之前：

注入内存马后：

点击kill，杀掉内存马

再次访问已经无法执行命令

tomcat有一个work目录，里面存放了页面的缓存，访问的jsp都会编译（从 work里进入Catalina后的如localhost站点文件夹下的项目，我们可以看到那些jsp页面会被编译成应该是servlet文件，下次再来 访问时，就直接运行servlet类就可以向客户端反应响应页面了，所以有的博客说第一次访问时会比较慢，是因为新发布上去的页面在第一个人访问时，会先 编译成servlet文件，所以慢了，一旦编译好，那么除非jsp页面修改，不然下次访问直接运行servlet就可以响应用户，所以快），编译后的文件都会存储在work目录下。而tomcat显示的目录，都会从这个缓存里找编译后的jsp对应的class文件。所以当清空了work目录后，该过程将会从新来过。