Tomcat漏洞详解_黑客技术
记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华
*作者：Blood_Zer0
*Mottoin原创投稿
Tomcat可能是我们使用比较多的一个Java Web Server系统了，对于它的漏洞，个人觉得还是比较少的，但是它的弱口令问题真的让人心痛啊！来张图压压场子：
0x00 Tomcat 基本配置
进入正题，首先看看Tomcat的端口
8005 Server Shutdown Port
8080 HTTP/1.1 Connector Port
8009 AJP/1.3 Connector Port
其次Tomcat 默认有许多重要的配置文件，下面我将对不同版本的这些文件做一个概述；
tomcat5 默认有两个角色：tomcat和role1。其中账号both、tomcat、role1的默认密码都是tomcat。不过不具备部署应用的权限，默认需要manager权限才能够直接部署war包；（备注：图片中的admin admin用户是我添加的）
tomcat6 默认没有配置任何用户以及角色，没办法用默认账号登录；（备注：图片中的admin admin用户是我添加的）
tomcat7 与6类似（备注：图片中的admin admin用户是我添加的，大家一定要注意添加用户的roles）
Tomcat8 其实从6开始，tomcat就将默认的用户去掉了，所以在后文提到的弱口令经常出现在tomcat版本5以及更低的版本中；
Tomcat9：目前是tomcat的最高版本（这里没有讨论小版本的变化）
其他文件：
content.xml：Tomcat默认的数据源在这里配置，一般存放连接数据库的信息；
server.xml：Tomcat访问端口、域名绑定和数据源在这里配置；
web.xml：Tomcat项目初始化会去调用的文件；
0x01 Tomcat 口令爆破
首先测试tomcat6，我们直接在tomcat-user.xml中添加一个账户，权限全部放开； （一定要注意最后有个斜线，我郁闷了半天）
Tomcat6 conf/tomcat-user.xml我们需要爆破tomcat manager，我们就需要知道爆破的请求时怎么样的，通过抓包发现
就是在头中加入了一个Authorization认证，爆破tomcat管理后台，Metasploit中集成了一个脚本：
use auxiliary/scanner/http/tomcat_mgr_login
我们可以看一下这个脚本
msf auxiliary(tomcat_mgr_login) & edit
因为对ruby不是很熟悉，就不献丑了；验证是否成功是这里段代码我这里写了2个脚本，一个脚本是生成tomcat-manager爆破的字典，另外一个是爆破脚本；会在文章最后贴出来！
然后测试一下tomcat7，也是添加用户，但是大家注意一下我这里添加用户的配置，如果按照上面6那样配置，会发现访问manager/html页面会出现403
tomcat7 conf/tomcat-user.xml注意9也有可能出现403，修改webapps\manager\META-INF\content.xml这里我就用我自己写的脚本来进行爆破，会发现爆破不成功，于是找找问题，我们会发现通过
http://192.168.11.144:8080/
这个网页点击过去登录时没有问题的，但是直接访问
http://192.168.11.144:8080/manager/html
登录就会一直不成功，是不是校验了Referer呢？我在脚本中加入Referer，发现还是爆破不成功，这是为什么呢？我们看一下Tomcat的日志
这下大家就明白为什么不能进行爆破了吧！那么它的验证在什么位置呢，我们根据日志报错信息去找到 conf/server.xml 文件中找到下图这一段
这就是限制错误次数的代码（大家一定不要尝试注释这段代码，因为注释以后，你会发现登录不上去了），关于这段代码大家可以看看官方文档：
http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html
这个时候我们可以去看看Tomcat6中会发现 只是对Realm 中的子域进行了限制；所以针对Tomcat7.0以后的manager/html就不能进行爆破了。
当然也有一种情况是可以爆破的，如图：不过估计很少会有人这么配置吧，第一个参数控制错误次数，第二个参数控制锁定时间；（引发思考是不是可以用来加固Tomcat呢）
如果像上图这样配置，我们使用之前的爆破脚本（不用加Referer）
tomcat从版本7开始就有了上诉的这种验证，而且验证默认是开启的，所以7版本后的爆破大家就不要去想了，社工可以考虑；
这里放上我写的两个脚本：
/c66KAWcyj7aH3 访问密码 526a
脚本还有待完善，目前来说并发问题没有解决后期解决了或更新在github上。
0x02 Tomcat 部署WebShell
在tomcat的管理页面
:8080/manager/html
有一个“war file to deploy”也就是war文件部署；上传一个包含木马的war文件点击start，这样就可以获取webshell了；相当的Deploy directory or WAR file located on server这种很少利用；
题外话：构建war格式webshell
使用myeclipse或eclipse中新建web项目，将shell放到web项目目录，导出为war格式即可；或者将新建项目中的index.jsp文件内容替换掉！
0x03 Tomcat 8009端口另用
这一节出自以前某大牛在乌云写过一篇文章“Tomcat的8009端口AJP的利用”但是文章比较老了是13年写的，经过测试，我发现按照原文会有一些问题，所以这里重新对这篇文章进行梳理；
ajp协议：Apache Jserv Protovol 是定向包协议，因为性能的缘故，使用二进制格式来传说可读性文本；一般来说有些网站会采用前端apache，后端tomcat，通过ajp协议访问性能优于http，随着并发量的提升，效果也会更加明显；
利用场景：当服务器使用tomcat，但是没有开放8080端口时候（当然我们这里也跟前文一样，主要针对tomcat6 及其以下的版本，因为还是利用tomcat后台爆破进入后台部署Webshell）。
条件：需要使用apache 的 mod_jk 模块，模块的官方文档：http://tomcat.apache.org/connectors-doc/ 对于这个模块，作用就是：ISAPI重定向，NSAPI重定向，对于我的理解：在原理上类似端口转发，实际上看最后的分析；
实验开始，我这里的测试主机是：192.168.11.128（centos7的系统） Tomcat服务器是：192.168.11.144（与服务器没有什么关系，只要服务器开放了8009端口就可以）；测试主机配置如下
重启服务，我们就可以成功了！systemctl restart httpd.service
这里说两个错误：
访问测试机显示503：说明Tomcat 8009端口没有开放；
其他5xx就说明：测试机的配置文件写的有问题；
正常访问Tomcat的8080端口：
正常访问Tomcat的8009端口：
通过apache 的 mod_jk 模块利用ajp协议转发，访问我们的测试机的80端口：
使用前文说到的爆破脚本（注意这里的tomcat是6.0，如果是7就不能爆破），爆破用户名密码，进入后台获取WebShell；
最后就是分析一下，这样到底是怎么实现的（利用wireshark抓包分析 ip.src == 192.168.11.128 and ip.dst == 192.168.11.144 and ajp13）：
这是直接访问时的整个数据包结构：（因为我这里是使用的虚拟机进行的实验，挥发性的RADDR是我的虚拟网卡的地址，如果有两天主机来进行测试的话，应该是Tomcat的IP地址），可以看到Code这里就是转发请求；
再看一下我们同ajp登录时的数据包：
我们会发现其实跟正常的登录没有太大的区别；
这里在贴上一张我们在部署WebShell的数据包图：
第一条是请求数据包，接下来的几条都是数据包的内容；
Tomcat 是我们在选择Java Web服务器中比较多的一款，相对于其他的它的漏洞更少，经常都是出在弱口令上，但是只要管理员在设置密码时稍微注意一下，在使用现在的7、8、9等新版本，我们就可以一定程度上保护好我们的Tomcat服务器，当然万事无绝对，漏洞都是人在挖掘的！
本文虽然分成了两篇，但是可以理解为就是Tomcat 在8080端口上的弱口令问题，其实关于后台的部署，那只是Tomcat的功能，不过被恶化了而已，欢迎交流！
*作者：Blood_Zer0@原创投稿，未经许可禁止转载
阅读:331493 | 评论:0 | 标签:
想收藏或者和大家分享这篇好文章→
?微信扫一扫,快速掌握黑客技术?2397人阅读
APACHE 的httpd.conf文件&&&&&&路径：&vi ./conf/httpd.conf
　　Options Indexes MultiViews　 ← 找到这一行，将“Indexes”删除
　　Options MultiViews 　 ← 变为此状态（不在浏览器上显示树状）
AllowOverride None
Order allow,deny
Allow from all
&/Directory&
TOMCAT修改conf/文件
&servlet-name&default&/servlet-name&
&servlet-class&org.apache.catalina.servlets.DefaultServlet&/servlet-class&
&init-param&
&param-name&debug&/param-name&
&param-value&0&/param-value&
&/init-param&
&init-param&
&param-name&listings&/param-name&
&param-value&false&/param-value& // 这里改为false 重启就好了
&/init-param&
&load-on-startup&1&/load-on-startup&
&/servlet&
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：30170次
排名：千里之外
原创：19篇
转载：81篇
(2)(6)(3)(7)(3)(9)(2)(2)(7)(15)(10)(12)(14)(1)(2)(1)(4)许多的Web应用程序一般会有对服务器的文件读取查看的功能，大多会用到提交的参数来指明文件名形如：/getfile=image.jgp
当服务器处理传送过来的image.jpg文件名后，Web应用程序即会自动添加完整路径，形如&d://site/images/image.jpg&，将读取的内容返回给访问者。
初看，在只是文件交互的一种简单的过程，但是由于文件名可以任意更改而服务器支持&~/&，&../&等特殊符号的目录回溯，从而使攻击者越权访问或者覆盖敏感数据，如网站的配置文件、系统的核心文件，这样的缺陷被命名为路径遍历漏洞。在检查一些常规的Web应用程序时，也常常有发现，只是相对隐蔽而已。
发现路径遍历漏洞路径遍历漏洞的发现，主要是对Web应用程序的文件读取交互的功能块，进行检测，面对这样的读取方式：&/test/downfile.jsp?filename=fan.pdf&
我们可以使用 &../&来作试探，
比如提交Url：&getfile=/fan/fan/*53.pdf&，而系统在解析是&d://site/test/pdf/fan/fan/../../*53.pdf"通过&../&跳转目录&/fan&，即&d://site/test/pdf/*53.pdf&，返回了读取文件的正常的页面。
路径遍历漏洞隐藏一般在文件读取或者展示图片功能块这样的通过参数提交上来的文件名，从这可以看出来过滤交互数据是完全有必要的。恶意攻击者当然后会利用对文件的读取权限进行跨越目录访问，比如访问一些受控制的文件，&../../../../../../../etc/passwd&或者&../../../../boot.ini&，当然现在部分网站都有类似Waf的防护设备，只要在数据中会有/etc /boot.ini等文件名出直接进行拦截。
遍历路径攻击变异路径遍历漏洞是很常见的，在Web应用程序编写过程，会有意识的对传递过来的参数进行过滤或者直接删除，存在风险的过滤方式，一般可以采用如下方式进行突破：以下是一些绕过的方法，当然在实际运行过程中，可以组合使用。
(1) 加密参数传递的数据；
在Web应用程序对文件名进行加密之后再提交，比如：&downfile.jsp?filename= ZmFuLnBkZg- &，在参数filename用的是Base64加密，而攻击者要想绕过，只需简单的将文件名加密后再附加提交即可。所以说，采用一些有规律或者轻易能识别的加密方式，也是存在风险的。
(2) 编码绕过，
尝试使用不同的编码转换进行过滤性的绕过，比如Url编码，通过对参数进行Url编码提交，&downfile.jsp?filename= %66%61%6E%2E%70%64%66&来绕过。
(3) 目录限定绕过；
在有些Web应用程序是通过限定目录权限来分离的。当然这样的方法不值得可取的，攻击者可以通过某些特殊的符号&~&来绕过。形如这样的提交&downfile.jsp?filename=~/../boot&。能过这样一个符号，就可以直接跳转到硬盘目录下了。
(4) 绕过文件后缀过滤；
一些Web应用程序在读取文件前，会对提交的文件后缀进行检测，攻击者可以在文件名后放一个空字节的编码，来绕过这样的文件类型的检查。例如：../../../../boot.ini%00.jpg，Web应用程序使用的Api会允许字符串中包含空字符，当实际获取文件名时，则由系统的Api会直接截短，而解析为&../../../../boot.ini&。在类Unix的系统中也可以使用Url编码的换行符，例如：../../../etc/passwd%0a.jpg如果文件系统在获取含有换行符的文件名，会截短为文件名。也可以尝试%20，例如: ../../../index.jsp%20
(5) 绕过来路验证。Http Referer : HTTP Referer是header的一部分，当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的
在一些Web应用程序中，会有对提交参数的来路进行判断的方法，而绕过的方法可以尝试通过在网站留言或者交互的地方提交Url再点击或者直接修改Http Referer即可，这主要是原因Http Referer是由客户端浏览器发送的，服务器是无法控制的，而将此变量当作一个值得信任源是错误的。
防范遍历路径漏洞在防范遍历路径漏洞的方法中，最有效的是权限的控制，谨慎的处理向文件系统API传递过来的参数路径。主要是因为大多数的目录或者文件权限均没有得到合理的配置，而Web应用程序对文件的读取大多依赖于系统本身的API，在参数传递的过程，如果没有得严谨的控制，则会出现越权现象的出现。在这种情况下，Web应用程序可以采取以下防御方法，最好是组合使用。(1) 数据净化，对网站用户提交过来的文件名进行硬编码或者统一编码，对文件后缀进行白名单控制，对包含了恶意的符号或者空字节进行拒绝。(2) Web应用程序可以使用chrooted环境访问包含被访问文件的目录，或者使用绝对路径+参数来控制访问目录，使其即使是越权或者跨越目录也是在指定的目录下。总结路径遍历漏洞允许恶意攻击者突破Web应用程序的安全控制，直接访问攻击者想要的敏感数据 ，包括配置文件、日志、源代码等，配合其它漏洞的综合利用，攻击者可以轻易的获取更高的权限，并且这样的漏洞在发掘上也是很容易的，只要对Web应用程序的读写功能块直接手工检测，通过返回的页面内容来判断，是很直观的，利用起来也相对简单。
还有一种目录遍历 那就是因为这个web服务器的配置不当造成的
index of /
我们可以直接利用百度语法来寻找此形式的目录遍历漏洞
intitle:index of
随意找一个演示下
阅读(...) 评论()Apache Tomcat 信息泄露漏洞存在于所有版本
CVE(CAN) ID:&更新日期：重要程度：重要受影响的版本：Apache Tomcat 9.0.0.M1 to 9.0.0.M13Apache Tomcat 8.5.0 to 8.5.8Apache Tomcat 8.0.0.RC1 to 8.0.39 (new)Apache Tomcat 7.0.0 to 7.0.73 (new)Apache Tomcat 6.0.16 to 6.0.48 (new)描述：Connector 代码重构引入了一个在 NIO HTTP 连接器发送文件的错误处理代码中的回归，因此处理发送文件错误导致当前处理器对象被多次添加到处理器高速缓存，这意味着处理器可以用于并发请求，共享处理器可导致请求之间的信息泄漏，包括但不限于会话ID和响应体。该错误首先在8.5.x版本中出现，似乎 8.5.x版本的Connector代码的重构更可能发生错误。，但进一步的调查表明，该错误存在于当前支持的所有Tomcat版本中。解决方案：安装了受影响版本的 NIO HTTP 连接器的用户可以采取以下方法解决：切换到BIO HTTP，NIO2 HTTP或APR HTTP连接器禁用发送文件升级到Apache Tomcat 9.0.0.M15或更高版本（Apache Tomcat 9.0.0.M14有修复，但没有发布）升级到Apache Tomcat 8.5.9或更高版本Apache Tomcat 8.0.40或更高版本发布后进行升级Apache Tomcat 7.0.74或更高版本发布后进行升级Apache Tomcat 6.0.49或更高版本发布后进行升级更多详细内容请点击。
Tomcat 的详细介绍：
Tomcat 的下载地址：
转载请注明：文章转载自 开源中国社区
本文标题：Apache Tomcat 信息泄露漏洞存在于所有版本
本文地址：