探寻Tomcat文件上传流量层面绕waf新姿势

探寻Tomcat文件上传流量层面绕waf新姿势
2022-6-19 13:50:24 Author: y4tacker.github.io(查看原文) 阅读量:20 收藏

无意中看到ch1ng师傅的文章觉得很有趣，不得不感叹师傅太厉害了，但我一看那长篇的函数总觉得会有更骚的东西，所幸还真的有，借此机会就发出来一探究竟，同时也不得不感慨下RFC文档的妙处，当然本文针对的技术也仅仅只是在流量层面上waf的绕过

1	Avoid including the "\" character in the quoted-string form of the filename parameter, as escaping is not implemented by some user agents, and "\" can be considered an illegal path character.

简单做个总结如果首位是"(前提条件是里面有\字符)，那么就会去掉跳过从第二个字符开始，并且末尾也会往前移动一位，同时会忽略字符\，师傅只提到了类似test.\war这样的例子

还是在org.apache.catalina.core.ApplicationPart#getSubmittedFileName当中，一看到这个将字符串转换成map的操作总觉得里面会有更骚的东西(这里先是解析传入的参数再获取，如果解析过程有利用点那么也会影响到后面参数获取)，不扯远继续回到正题

首先它会获取header参数Content-Disposition当中的值，如果以form-data或者attachment开头就会进行我们的解析操作，跟进去一看果不其然，看到RFC2231Utility瞬间不困了

Asterisks ("*") are reused to provide the indicator that language and character set information is present and encoding is being used. A single quote ("'") is used to delimit the character set and language information at the beginning of the parameter value. Percent signs ("%") are used as the encoding flag, which agrees with RFC 2047.
Specifically, an asterisk at the end of a parameter name acts as an indicator that character set and language information may appear at  the beginning of the parameter value. A single quote is used to separate the character set, language, and actual value information in the parameter value string, and an percent sign is used to flag octets encoded in hexadecimal.  For example:
Content-Type: application/x-stuff;
         title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

结合注释可以看到标准格式@param encodedText - Text to be decoded has a format of {@code <charset>'<language>'<encoded_value>},分别是编码，语言和待解码的字符串，同时这里还适配了对url编码的解码，也就是fromHex函数,具体代码如下，其实就是url解码

1
2


{"Big5","Big5-HKSCS","CESU-8","EUC-JP","EUC-KR","GB18030","GB2312","GBK","IBM-Thai","IBM00858","IBM01140","IBM01141","IBM01142","IBM01143","IBM01144","IBM01145","IBM01146","IBM01147","IBM01148","IBM01149","IBM037","IBM1026","IBM1047","IBM273","IBM277","IBM278","IBM280","IBM284","IBM285","IBM290","IBM297","IBM420","IBM424","IBM437","IBM500","IBM775","IBM850","IBM852","IBM855","IBM857","IBM860","IBM861","IBM862","IBM863","IBM864","IBM865","IBM866","IBM868","IBM869","IBM870","IBM871","IBM918","ISO-2022-CN","ISO-2022-JP","ISO-2022-JP-2","ISO-2022-KR","ISO-8859-1","ISO-8859-13","ISO-8859-15","ISO-8859-2","ISO-8859-3","ISO-8859-4","ISO-8859-5","ISO-8859-6","ISO-8859-7","ISO-8859-8","ISO-8859-9","JIS_X0201","JIS_X0212-1990","KOI8-R","KOI8-U","Shift_JIS","TIS-620","US-ASCII","UTF-16","UTF-16BE","UTF-16LE","UTF-32","UTF-32BE","UTF-32LE","UTF-8","windows-1250","windows-1251","windows-1252","windows-1253","windows-1254","windows-1255","windows-1256","windows-1257","windows-1258","windows-31j","x-Big5-HKSCS-2001","x-Big5-Solaris","x-COMPOUND_TEXT","x-euc-jp-linux","x-EUC-TW","x-eucJP-Open","x-IBM1006","x-IBM1025","x-IBM1046","x-IBM1097","x-IBM1098","x-IBM1112","x-IBM1122","x-IBM1123","x-IBM1124","x-IBM1166","x-IBM1364","x-IBM1381","x-IBM1383","x-IBM300","x-IBM33722","x-IBM737","x-IBM833","x-IBM834","x-IBM856","x-IBM874","x-IBM875","x-IBM921","x-IBM922","x-IBM930","x-IBM933","x-IBM935","x-IBM937","x-IBM939","x-IBM942","x-IBM942C","x-IBM943","x-IBM943C","x-IBM948","x-IBM949","x-IBM949C","x-IBM950","x-IBM964","x-IBM970","x-ISCII91","x-ISO-2022-CN-CNS","x-ISO-2022-CN-GB","x-iso-8859-11","x-JIS0208","x-JISAutoDetect","x-Johab","x-MacArabic","x-MacCentralEurope","x-MacCroatian","x-MacCyrillic","x-MacDingbat","x-MacGreek","x-MacHebrew","x-MacIceland","x-MacRoman","x-MacRomania","x-MacSymbol","x-MacThai","x-MacTurkish","x-MacUkraine","x-MS932_0213","x-MS950-HKSCS","x-MS950-HKSCS-XP","x-mswin-936","x-PCK","x-SJIS_0213","x-UTF-16LE-BOM","X-UTF-32BE-BOM","X-UTF-32LE-BOM","x-windows-50220","x-windows-50221","x-windows-874","x-windows-949","x-windows-950","x-windows-iso2022jp"}

同样的我们也可以进行套娃结合上面的filename=""y\4.\w\arK"改成filename="UTF-16BE'Y4tacker'%00%22%00y%00%5C%004%00.%00%5C%00w%00%5C%00a%00r%00K"

在此基础上我发现还可以做一些新的东西，其实就是对org.apache.tomcat.util.http.fileupload.ParameterParser#parse(char[], int, int, char)函数进行深入分析

在获取值的时候paramValue = parseQuotedToken(new char[] {separator });，其实是按照分隔符;分割，因此我们不难想到前面的东西其实可以不用"进行包裹，在parseQuotedToken最后返回调用的是return getToken(true);，这个函数也很简单就不必多解释

既然调用parse解析参数时可以不被包裹，结合getToken函数我们可以知道在最后一个参数其实就不必要加;了，并且解析完通过params.get("filename")获取到参数后还会调用到org.apache.tomcat.util.http.parser.HttpParser#unquote那也可以基于此再次变形

通过查询官方文档，可以发现从Servlet3.1开始，tomcat新增了对此的支持，也就意味着简单通过javax.servlet.http.HttpServletRequest#getParts即可，简化了我们文件上传的代码负担(如果我是开发人员，我肯定首选也会使用，谁不想当懒狗呢)

早上起床想着昨晚和陈师的碰撞，起床后又看了下陈师的星球，看到这个不妨再试试Spring是否也按照了RFC的实现呢（毕竟Spring内置了Tomcat，可能会有类似的呢）

而spring处理文件上传逻辑的具体关键逻辑在org.springframework.web.multipart.support.StandardMultipartHttpServletRequest#parseRequest，抄个文件上传demo来进行测试分析

其中关于org.springframework.web.multipart.support.StandardMultipartHttpServletRequest#parseRequest的调用也有些不同

也是随便来个新的springboot2.6.4的，来看看spring5的，小版本间差异不测了，经过测试发现spring5和spring4之间也是有版本差异处理也有些不同，同样是在parseRequest

很明显可以看到这一行filename.startsWith("=?") && filename.endsWith("?=")，可以看出Spring对文件名也是支持QP编码

如果是filename*后面的处理逻辑就是else分之，可以看出和我们上面分析spring4还是有点区别就是这里只支持UTF-8/ISO-8859-1/US_ASCII，编码受限制

attr-char     = ALPHA / DIGIT
                  / "!" / "#" / "$" / "&" / "+" / "-" / "."
                  / "^" / "_" / "`" / "|" / "~"
                  ; token except ( "*" / "'" / "%" )

文章来源: https://y4tacker.github.io/2022/06/19/year/2022/6/%E6%8E%A2%E5%AF%BBTomcat%E6%96%87%E4%BB%B6%E4%B8%8A%E4%BC%A0%E6%B5%81%E9%87%8F%E5%B1%82%E9%9D%A2%E7%BB%95waf%E6%96%B0%E5%A7%BF%E5%8A%BF/
如有侵权请联系:admin#unsafe.sh