Java内存shell：Tomcat回显

2020-10-10

Tomcat回显与 Java内存shell有什么关系？

在java漏洞利用中如何获取到执行结果？这是Tomcat回显的最原始需求，具体可以参考【4】中的许多手法，这里不展开

其中提到一种思路，获取response，然后直接操作response以http形式返回。而Java内存shell中，很重要的一点就是获取request从而获取上下文cotext，其中获取request的思路相似通用可借鉴。

历史背景

参考【1】中李三师傅总结了之前比较经典的tomcat回显方式，写的很好，直接复用：

《基于内存 Webshell 的无文件攻击技术研究》，观星大哥的文章，通杀spring，能解决实战只能够遇到的大部分情况了。
《Tomcat中一种半通用回显方法》，kingkk师傅的，这篇文章讲了通过反射修改ApplicationFilterChain参数来让tomcat再下一次请求的时候在线程中缓存req和resp，不足之处在于shiro无法回显。
《基于tomcat的内存 Webshell 无文件攻击技术》，threedr3am师傅的，通过上一篇的方法获取到req进一步获取context，然后动态注册filter，不足之处在于使用的是上一篇的获取req的思路所以也无法shiro回显。
《基于全局储存的新思路 | Tomcat的一种通用回显方法研究》，这篇文章通过currentThread.getContextClassLoader()获取StandardContext，进一步获取到response，解决了shiro回显的问题，不足在于tomcat7中无法获取到StandardContext。
《基于Tomcat无文件Webshell研究》，总结上面文章的方法，不足之处在于无法解决tomcat7+shiro的问题。

之后还有几段有意思的思路：

《tomcat不出网回显连续剧第六集》，而李三师傅在以上的基础上，提出了与前文不同的获取RequestInfo思路，是一条通过registry&Mbean全新的链，是目前见到最通用的方式了，适合tomcat7&shiro。
《半自动化挖掘 request 实现多种中间件回显》 ,c0ny1师傅提出的，自动化遍历搜索全局request，一锤定音，算是Tomcat回显的终章了。

以下来一一复现分析这些文章提到的姿势

kingkk的ApplicationFilterChain利用链

这个应该是kingkk师傅首次在参考【5】中提到的方法，参考【6】中使用的也是这个方法

原理思路

引用Litch1 的总结

通过反射修改控制变量，来改变Tomcat处理请求时的流程，使得Tomcat处理请求时便将request,response存入ThreadLocal中，最后在反序列化的时候便可以利用ThreadLocal来取出response。

发现的过程感觉很神奇:

ApplicationFilterChain有一个静态参数，lastServicedRequest，类型为ThreadLocal，在一定条件下会保留上一次访问的request

upload successful

攻击流程

反射修改ApplicationDispatcher.WRAP_SAME_OBJECT 为true
internalDoFilter进入else流程，初始化lastServicedRequest和lastServicedResponse两个变量
从lastServicedRequest中获取当前请求request，从而获取到context

其中使用Java反射更改私有静态final字段，原理详见https://cloud.tencent.com/developer/ask/195780

Litch1的Thread&StandardService 利用链

其实目的都是为了寻找存储了request的对象，Litch1在此基础上手动追溯了Tomcat全局存储中的request。

原理思路

跟踪的过程比较复杂，而且需要对Tomcat启动流程要有一定了解，详情还是参考【8】（照着追了下，知其然不知其所以然，对Tomcat还是不够了解）

最后的利用路径

WebappClassLoaderBase ->
	ApplicationContext(getResources().getContext()) -> 
		StandardService ->
			Connector#getProtocolHandler() ->
				AbstractProtocol$ConnectoinHandler ->
                	global ->
						RequestInfo ->
							Http11Processor#getRequest() -> 
								AbstractProcessor#getRequest() ->
									Request#getResponse() ->
										Response

李三师傅的MBean&Registry的利用链

原理思路

参考【2】

上节中，是通过Connector入手拿到ProtocolHandler。其实再仔细看一下Connector类的依赖树就可以发现其实所有的参数并非是单独存放在这些类中的一个属性中的，而是都被注册到了MBeanServer中的：

最后的利用路径

Registry.getRegistry(null, null).getMBeanServer() ->
	JmxMBeanServer.mbsInterceptor ->
		DefaultMBeanServerInterceptor.repository ->
			Registory#query ->
				RequestInfo ->
					Http11Processor#getRequest() -> 
						AbstractProcessor#getRequest() ->
							Request#getResponse() ->
								Response

c0ny1的半自动化挖掘思路

这个当属大牛级思路了，人工分析调用链可能有疏漏，直接内存搜索相关的对象，简单直接，可以说是终结了全局搜索request思路（当然kingkk的改变了tomcat处理流程的链是找不到的），膜拜。

具体参考【7】，代码思路原文都挺详细，就不班门弄斧了

小结

本文只能算是对于以上师傅们挖Tomcat回显文章的学习总结，一篇篇文章读来，感觉有师傅们在华山论剑的味道。姿势固然奇妙，更奇妙的是师傅们找各种猥琐姿势的思路，获益匪浅。