[WUSTCTF2020]TRAIN YOURSELF TO BE GODLY WP

[

质量非常高的一道题,由于不太熟悉 JSP,所以比赛的时候没怎么用心看,题目上了 BUU 之后发现复现起来比较困难,就写个 wp 帮助下其他师傅(骗骗流量)。

tomcat 目录穿越

Orange 师傅在 BlackHat 上有个议题(DEF CON 26 – Orange Tsai – Breaking Parser Logic Take Your Path Normalization Off and Pop 0Days Out,强烈推荐大家去看看),大意就是由于中间件的一些特性,导致了一些神奇的目录穿越现象。比如:

针对于本题的环境,题目是由 Nginx 做反向代理,真实的后端中间件是 Tomcat,两种中间件识别的路径不同,就会造成解析不一致的情况。引用上面 Orange 师傅的总结:

上图可知,Nginx 会解析 /a;evil/b/,并认为这是一个合法的目录请求,而 Tomcat 做解析的时候会自动忽略掉脏数据 ;.*,所以 Tomcat 对此的解析是 /a/b/。也就是说我们从可以通过写 ;+脏数据的方式绕过 Nginx 的反向代理,从而请求本不应该能请求到的非法路径。对于本题来说,我们可以构造路径 /..;/,Nginx 会认为我们要访问服务器的 /..;/ 目录下的内容,从而将这个请求视为合法请求发送给后端的 Tomcat 解析,Tomcat 接受之后认为 ; 是脏数据,从而过滤掉,解析的路径就变成了 /../ 也就是上级目录。所以访问 /..;/manager/html 之后我们就成功进入了后台界面。

TOMCAT 管理后台弱口令

进入后台界面之后需要登录,一般来说生产环境管理界面 /manager/html 都是要删除的,如果可以访问一般都是默认口令或者弱口令。Tomcat 有两个默认的后台用户,用户名分别是 tomcat 和 role1,用 tomcat 作为用户名爆破,可以得到弱口令 tomcat / tomcat。(默认密码 tomcat / manager)

后台上传 war 木马

使用这个仓库的 jsp 木马,用 jar 打包成 war 包(嫌麻烦的打包成 zip 把后缀名改成 war 也可以),在管理界面上传,会发现返回 404,仔细一看 url 会自动加上 exampls 目录,于是我们用 burp 抓包,整理一下 url,再次发送,这次返回 401:

搜索资料可知,401 是因为 header 中没有 Authorization 导致的。Authorization 的格式:

Authorization: Basic base64-encode(username/password)

针对于这道题目,username 和 password 都是 tomcat,对应的 Authorization 信息就是:

Authorization: Basic dG9tY2F0OnRvbWNhdA==

加上 Authorization 头,继续上传 war 包文件,发现这回 403 了:

有些奇怪,但是遇到这种情况最好的处理结果是自己搭一个环境看看哪里出了问题。自己搭环境可以顺利上传 war 包,diff 下两个包:

可以明显看到除了 host 之外的信息,最大的区别就是本地的包有个 JSESSIONID,推测是由于没有 cookie 验证,所以导致我们没权限。直接访问 ..;/manager/html 发现里面有个 session 值,于是果断拿来一用,果不其然还是 403,干死出题人!再仔细看看 SetCookie 的内容:

好像有个 path,可能我们仍然 403 的原因是没有访问到合法的路径,那么怎么才能正常上传呢?

对于 Cookie 的理解

请你现在闭上眼睛,不要思考,回答这个问题:Cookie 是 C 端还是 S 端控制的?

什么?S 端?再好好想想?

平时我们做题,遇到改 cookie 的时候总是毫不留情、重拳出击,需要什么值就改成什么值,所以 JWT 才不得不用密钥加密 Cookie,所以才有 php 只把 SessionID 暴露给 Cookie,而把值放在服务器上。所以仔细一想,Cookie 这个东西其实是完全本地可控的,只不过一般情况下我们只关心 Cookie 的值,其实 Cookie 的 Path、Domain、Expires 等等属性都是完全可控的,那么问题又来了,我们该如何控制或者如何修改 Cookie 的属性呢?

再琢磨一下 Cookie 是怎么到我们手中的。如果我们直接访问服务器,那么服务器帮我们 Set,我们拿到 Cookie,这时可以通过浏览器的相关功能进行修改;如果我们使用 burp 代理,那么流程就变为先把请求发送给 burp,burp 在发送给服务器,服务器把 cookie 信息返回 burp,burp 再传回本地,在这个流程中,我们可以通过修改 burp 返回给本地的 response 包来打到控制 cookie path 的目的(没错,修改 response 包)。

首先我们要对 burp 进行一些设置,如下图:

这样我们再抓一个 set-cookie 的包,通过修改他返回给本地的 response 包的 cookie path,使我们上传 war 包合法。

最后添加上这个 session id 上传 war,终于返回状态变成了 200:

在看看 manager 页面的内容,果然已经有了我们上传的项目文件夹:

访问 上传的文件名/压缩包里的文件,就是我们的木马啦,我是吧 1.jsp 压缩成了 123.war,因此访问 ./123/1.jsp 就是我们的 shell,快去拿 flag 吧!

最后总结一下这题的坑:

  • 上传会自动加 examples 文件夹,需要手动删除
  • 需要自己添加 Authorization 和 cookie 两个 header 信息,其中 cookie 还需要魔改
  • 由于上传点有 csrf check,所以只能上传包只能现抓现用,建议不要放到 repeater 里
  • 有的部分旧版 win10 系统可能上传 war 之后会报错,不自动运行,对于这种情况,换台电脑打就好啦!

Imagin 丨 京ICP备18018700号-1


Your sidebar area is currently empty. Hurry up and add some widgets.