Tomcat弱口令到getshell：从原理拆解到安全加固实战

每次做授权范围内的安全演练我都会先让人去碰Tomcat管理后台。原因很简单Tomcat弱口令getshell这条链路是典型的“入门看着容易、实际一碰全是细节”的题目。它包含端口发现、服务指纹识别、HTTP基础认证、应用部署权限、恶意应用投放、命令执行落地六七个环节几乎把渗透测试入门需要掌握的关键概念全部串起来了。这篇笔记不是把网上现成工具跑一遍就完事而是把我自己在本地靶场里从环境搭建、弱口令场景构造、攻击链复盘到加固整改的完整过程一步一步拆开来讲。目的就是让准备攻这块硬骨头的朋友弄明白为什么弱口令会发展到getshell中间每一环都在干什么以及作为防守方应该怎么堵。1. 这个实战笔记到底在练什么1.1 标题里三个关键词的份量先说Tomcat。Tomcat是国内大量Web应用在用的Java应用服务器尤其是一些业务系统、数据平台、内部管理系统跑了七八年都没换过版本。它本身是开源软件功能非常成熟但历史包袱也重早期的默认配置、历史遗留的管理接口、为方便开发而保留的样例应用都可能成为安全隐患。再看弱口令。所谓弱口令并不仅仅指123456这种简单密码。它还包括默认账号、长期不更换的固定密码、多环境共用的同一套口令以及直接写在文档或者配置注释里的明文密码。Tomcat管理后台的弱口令往往代表着整个服务器还处于“裸奔”状态因为管理后台一旦能被登录接下来基本就是代码层面的完全控制。最后是getshell。这个英文词在安全圈里指的是攻击者通过漏洞拿到了目标主机上执行命令的能力。通俗点说就是原本只能在Web页面上点来点去现在可以直接在服务器操作系统里执行命令。到了这一步问题性质就变了——从“Web服务被入侵”升级为“主机被控制”。1.2 适合谁来啃这块硬骨头如果你是刚接触渗透测试的初学者这篇笔记能帮你建立一条完整的攻击链认知。如果你是Web开发转安全方向这篇文章可以让你理解Tomcat的认证、授权、部署机制本身就是在配置层面决定了安全边界。如果你是运维人员这篇笔记更有现实意义因为Tomcat加固清单里的每一条都可能直接影响线上服务的风险等级。不同基础的人读这篇文章获取到的层次不一样。有基础的人可以直接看第5节的加固实操和第7节的排查速查表新手则建议从头到尾读一遍尤其是第2节的身份认证机制和第4节的攻击链逻辑这部分搞懂了后面很多所谓“高深”的漏洞本质上都是同一套思维。1.3 必须先说清楚的合规边界在进入正文之前必须把最重要的一条原则放在开头所有这类验证操作只能在你自己拥有合法控制权的环境中进行。比如自己搭的本地靶场、实验虚拟机、公司明确授权测试的服务器、各类竞赛提供的靶标环境这些都属于“授权范围之内”。没有授权就对一个陌生人系统做密码尝试、应用部署、命令执行触碰的是法律红线不是技术问题。我后面提到的所有操作路径都默认读者是在自己的靶场环境里完成验证。安全意识不是学了几招之后去挑战真实系统而是清楚地知道哪些边界绝对不能越。2. 理解弱口令的本源从认证到授权2.1 Tomcat的认证体系如何工作Tomcat的身份认证基于JAAS体系简化的理解方式是系统里维护一份用户列表每个用户拥有若干角色然后不同的Web应用根据URL规则来要求访问者必须具备某个角色。用户和角色的配置集中在conf目录下的tomcat-users.xml文件里。这部分配置负责给Tomcat这个服务器本身定义一批“操作员”包括谁来登录管理页面、谁来发布应用、谁来管理虚拟主机。Tomcat的管理接口主要有两块。第一块是manager对应路径是/manager/html用于管理Web应用的部署、卸载、启动、停止。第二块是host-manager对应路径是/host-manager/html用于管理虚拟主机。两个接口的目的完全不同但许多管理员会为了省事把用户同时赋予两个接口的权限这就扩大了攻击面。manager接口的角色细化也很有意思。Tomcat区分了manager-gui、manager-script、manager-jmx和manager-status四种角色。前两种是日常用得最多的manager-gui用于网页图形界面操作manager-script用于通过命令行或脚本调用部署接口。后两种分别面向JMX监控和管理API一般业务系统用不上。2.2 所谓“弱口令”其实是流程问题在实验环境里我见过很多Tomcat部署弱口令出现的原因归根结底有两种。第一种是部署阶段图方便。安装完Tomcat之后开发或运维人员为了调试接口直接在tomcat-users.xml里加了一个admin用户密码顺手写成admin或者123456项目上线后忘了删除。第二种是密码管理混乱多个服务器共用同一套账号密码或者把密码写进内部文档、提交到代码仓库里。这里有一个很多人忽略的细节Tomcat用户的强度问题往往不是什么技术漏洞而是配置管理和流程规范的漏洞。明明可以通过角色分离来降低风险却因为图省事把所有权限捏在一个账号里明明可以在网络层限制来源IP却因为懒得上防火墙规则而全部裸奔。我复盘过几次类似问题几乎没有一次是攻击者用了多么高深的技术都是利用管理员的疏忽。2.3 管理权限与普通访问权限的差异为什么Tomcat弱口令如此危险根本上是因为管理接口的权限等级太高。普通Web用户访问的是一个应用里的具体页面能调用的只是这个应用暴露出的业务功能。但如果你能登录manager接口那么你看到的是整个Tomcat服务器上部署的所有应用清单包括它们的路径、运行状态、内存消耗以及一个“部署新应用”的入口。这就相当于一个普通访客拿到了物业总控室的钥匙。钥匙本身可能只是一把普通的钥匙但对应的是整个楼宇的配电房、网络机房和设备层。同样道理Tomcat的弱口令账号如果被赋予了manager-script或者manager-gui权限攻击者就可以通过管理接口放置一个应用包然后用这个应用包在服务器上执行自己的代码。这个逻辑一定要想清楚不是密码太弱导致getshell而是“密码太弱”加上“管理接口暴露”再加上“部署权限过大”三个条件同时成立最终才形成了getshell的完整通路。三个条件缺一个整条链路的风险等级都会明显下降。3. 搭一个模型靶场观察问题路径3.1 用容器快速升起Tomcat要在授权环境里观察这条攻击链最快的方式不是找一台物理机去装JDK、解压Tomcat、配环境变量而是直接用容器在本地拉起一个隔离的实验环境。我用docker的方式做过很多次好处是快、可重复、用完即毁不会污染本机环境。大致操作流程是这样的docker run -d -p 8080:8080 --name tomcat-lab tomcat:9.0 docker exec -it tomcat-lab bash执行完这两条命令之后容器内部的Tomcat就跑起来了。默认情况下Tomcat镜像里的webapps目录下会有examples、docs、ROOT等自带应用。对于实验来讲这些自带内容先留着没问题等后面观察完整条链路之后再按照加固方案去清理。这里有一个特别值得说的点容器的端口映射只把8080暴露出来千万不要顺手把8009和8006那些内部端口也映射出去。因为Tomcat有内部通信端口暴露在多网卡环境下会导致一些协议级别的探测风险。做实验环境也要养成最小暴露面的习惯这和正式服务器是一个道理。3.2 生成一个“弱口令环境”默认的Tomcat镜像里manager和host-manager应用是存在的但tomcat-users.xml里通常没有可用的账号。我们需要手工往里面添加用户和角色。我建议的做法是进入容器打开conf/tomcat-users.xml在tomcat-users标签内部添加一个角色和用户让它贴近真实环境里最常见的错误配置。这一步添加出来的账号就是为了模拟开发调试阶段遗留的弱口令而不是为了线上环境使用。添加完配置之后重启Tomcat容器直接访问http://127.0.0.1:8080/manager/html浏览器就会弹出HTTP基本认证的登录框要求输入用户名和密码。到这里弱口令场景就构造完成了。我自己的习惯是在这个阶段先不急着进行任何尝试而是把容器当前的配置、端口状态、默认应用列表全部截图或者记录下来。这样后面做完整个流程复盘才能清楚每一步改动带来的变化。3.3 网络隔离与数据记录实验环境的网络隔离看起来是小事但出过问题的次数反而不少。我见过有人在自己电脑的Docker里做了靶场但是业务网卡走了公司的办公网络结果扫描行为被安全设备记录下来最后还得花时间解释来源。做这类实验我个人坚持两个原则。第一个原则是端口最小暴露只对127.0.0.1做端口映射不对外网暴露。第二个原则是实验环境必须与真实业务环境彻底分开不在生产机器上装实验工具不拿生产配置来练习。数据记录方面我建议实验过程中打开浏览器开发者模式把登录请求头、响应状态、后续操作的URL都留底。因为弱口令测试看起来简单实际排查时要还原当时发生了什么缺了记录会很痛苦。4. getShell的实现逻辑以及为什么它这么经典4.1 攻击者拿到弱口令后的思维路径当我们把视角切到攻击者这一侧整个思维路径是非常清晰的。第一步是确定目标通过端口扫描或者服务探测确认对方这台主机上存在Tomcat服务。Tomcat的默认端口是8080但如果管理员改过端口就需要通过HTTP响应头、错误页面特征或者特定路径的返回内容来识别服务指纹。第二步是找管理入口对常见的Tomcat路径做访问尝试比如/manager/html、/host-manager/html。正常情况下这两个路径会返回401状态码提示需要认证。这种401响应反而告诉了攻击者管理后台是存在的只差有效账号密码。第三步是弱口令尝试这一步可以借助自动化工具也可以手工尝试。常见的管理员账号组合、默认密码、配置文件中暴露过的密码都是优先尝试的对象。如果tomcat-users.xml里从来没有被清理过那这里就成了一扇没有上锁的门。第四步是验证权限登录成功后管理页面会展示部署应用的功能。到这一步攻击者已经拥有了发布和卸载应用的权利。4.2 管理权限到代码执行的通道从管理权限到代码执行的关键通道是Tomcat的WAR包部署机制。Tomcat部署Web应用最常用的方式就是把应用打成WAR包通过manager接口上传然后Tomcat自动解压并部署到运行环境中。WAR包本来是一个用于发布Web应用的归档格式里面可以包含Servlet、JSP页面、依赖库和配置文件。在正常情况下WAR包里是业务代码。但在异常情况下攻击者会制作一个包含恶意JSP后门或Servlet的WAR包通过管理接口上传后这个恶意应用就成为了Tomcat里的一个合法Web应用。攻击者只要访问这个应用的特定URL就会触发一段代码在服务器上执行系统命令。这整个过程说白了就是你给了攻击者“部署应用”的权限等于允许他把代码放到你的服务器上跑起来。getshell就是这样落地的——一个合法的部署功能被用作非法代码的投递通道。4.3 自动化工具为什么不能替代手工理解很多刚入门的朋友会问既然弱口令可以直接用扫描器跑账号密码那为什么还要手工理解这条链路我的经验是工具能帮你找到“哪里有问题”但很难告诉你“为什么有问题”以及“问题波及的范围有多大”。自动化扫描器通常只会验证某个端口是否存在弱口令它不会告诉你这个Tomcat上承载了多少业务系统。比如同一个Tomcat下部署了三个应用登录管理后台后可以分别把三个应用停下来再部署替换版本这种操作在自动化工具的结果里根本体现不出来。更关键的是如果不对整条链路有清晰理解拿到工具报告之后也不知道下一步该做什么。有人看到一个弱口令结果只知道把密码改掉却不知道应该同时检查管理接口的访问来源是否被限制、账号的权限是否过大、日志里有没有已经发生的异常部署行为。所以工具可以辅助但替代不了思维。4.4 在实验靶场里如何安全验证链路如果要在自己的靶场里完整观察这条链路建议不要直接在公网环境测试而是在本地容器环境里操作。我自己实验时用的是本地电脑上的Docker容器。先通过网络扫描工具确认8080端口开放再用浏览器手动请求manager路径获取401响应然后尝试弱口令登录登录成功后查看部署页面最后上传自己打的测试WAR包来验证代码执行是否成立。这里必须强调测试WAR包里的内容只应该包含一条输出系统当前用户或当前路径的简单命令目的是验证执行能力不是用来做破坏性的操作。验证完毕之后容器直接删除重建所有环境痕迹随之清理。5. 反制与加固把风险关回笼子5.1 账号与角色配置先解决身份问题既然弱口令是整条链路的起点账号加固就是第一道防线。首先删除所有不必要的历史账号尤其是那些只用于调试的临时账号。Tomcat的tomcat-users.xml是纯文本配置你要养成一个习惯所有账号增删都要走变更记录不把明文密码放在配置里。其次将不同角色的权限拆开。manager-gui是管理页面的图形化操作权限manager-script是脚本化部署权限host-manager是虚拟主机管理权限。实际生产环境里这三类权限应该分配给不同的人或流程而不是用一个超级管理员账号全部覆盖。再次密码本身要满足复杂度要求。这里说的不是装模作样的14位字符串而是每台服务器独立生成不跨环境复用。如果担心忘记可用密码管理工具来存不要因为怕麻烦就退回123456。以下是一个可供参考的tomcat-users.xml加固配置片段role rolenamemanager-script/ user usernamedeploy-ops password独立强密码 rolesmanager-script/这段配置的含义是只给部署运维人员一个manager-script权限不开放manager-gui和manager-jmx。这样即使账号泄露通过页面操作查看整个服务器应用列表的能力也被降低了。5.2 管理接口的网络层限制账号加固做得再好也不能保证密码永远不会泄露。因此网络层必须再设一道闸门。Tomcat可以通过配置Valve来实现来源IP限制。最简单的方式是在manager应用自己的META-INF/context.xml里配置RemoteAddrValve只允许运维跳板机的IP访问。配置思路是这样的Context Valve classNameorg.apache.catalina.valves.RemoteAddrValve allow127.0.0.1|192.168.10.0/24 denyStatus403/ /Context这段配置的效果是只有来自本机或指定内网网段的请求才能访问manager应用其他来源一律返回403。这样即使攻击者拿到了密码因为来源IP不在白名单里请求依然会被拒绝。很多朋友会问是不是改了默认端口就不用做IP限制了答案是否定的。端口扫描可以发现非默认端口指纹识别也能通过HTTP标头抓出Tomcat类型。真正有效的防护不是隐藏端口而是一层一层地叠加访问控制。5.3 清理不必要的应用与样例Tomcat安装后自带的样例应用被很多人忽略。webapps目录下的ROOT、docs、examples这些目录原本是用于展示功能和帮助文档的但里面可能包含一些可以被利用的示例Servlet或JSP文件。建议在生产环境里把webapps目录下不需要的样例应用全部删除只保留自己业务需要部署的实际应用。目录清理之后如果不需要host-manager也一并把对应的部署包移走。清理的过程要记住一个原则先备份再清理最后验证。有些系统对Tomcat路径有相关监考依赖贸然删除可能导致监控脚本报错。清理完成后重新访问一次Tomcat默认页确认哪些路径已经不可用。5.4 日志审计与异常行为发现即使做了前面所有加固日志审计仍然不能省。Tomcat的日志主要分几类catalina.out是Tomcat运行主日志localhost.log记录本地应用访问manager应用的日志单独记录部署行为。异常行为的发现核心关注这两个点。第一是登录失败记录短时间内大量401响应说明有人在尝试弱口令。第二是部署行为记录如果有人成功登录manager并上传了WAR包这个操作会对应一条部署记录并且webapps目录下会新增一个陌生应用目录。检查日志不能只看有没有报错还要看有没有异常的成功操作。我看到过一些案例攻击者成功部署后会自动删除日志中的敏感记录但webapps目录里多出来的应用不会被自动清理。所以周期性检查已部署应用清单是简单而有效的排查手段。6. 实战中容易忽略的细节6.1 授权边界是原则问题不是技术问题之前我反复提授权边界这里再展开讲一遍。很多人觉得“我就试试又不搞破坏”但未经授权扫描、尝试口令、上传文件哪怕什么也没发生本身就已经是越界行为。在安全行业里能否守住授权边界是区分职业操守的关键标准。成熟的从业者会在动手前反复确认测试范围和授权证明会约束自己不去触碰授权范围之外的设备会在测试结束后彻底清理自己引入的测试应用和临时文件。如果你是学习者最好的做法是把练习场景限定在本地靶场。现在有很多开源的靶场项目可以一键搭建出包含Tomcat弱口令漏洞的训练环境完全可以在自己电脑上完成学习需求不需要去联网探测。6.2 证据记录与复盘方法做技术复盘时很多人容易急躁想赶着进入下一个步骤结果回头看时才发现关键细节没有记录下来。我自己做实验复盘时常用的方式是在本地记录一个时间线文档按时间顺序记录每个操作、对应URL、状态码、页面返回内容。比如几点几分请求了manager路径返回了401几点几分使用某账号登录成功几点几分部署了什么应用几点几分访问了后门页面。这个习惯在实战排查时极其有用。因为很多问题不是当时就能判断的等过了一段时间再翻日志如果没有时间线很难把分散的记录串联起来。6.3 由Tomcat弱口令想到的延伸风险Tomcat弱口令不是孤立的风险。一个Tomcat实例上突发的审计往往会带出同一网络位置上的其他问题。比如同一个服务器上很可能同时运行着其他Web服务这些服务的管理后台也可能存在类似的弱口令。再比如如果Tomcat配置了管理员账号而这个账号在同一个内网里被其他系统复用那么这次弱口令波及的范围就不仅仅是Tomcat自身了。所以处理Tomcat弱口令问题不能只看Tomcat本身的配置还要顺带梳理一遍账号复用情况、管理接口暴露范围、网络边界访问控制策略。把单点问题放到全局视角里看才能避免“堵了一个洞旁边还有一堆洞”的情况。7. 常见问题速查表7.1 忘记本机Tomcat管理密码怎么恢复这种情况通常出现在开发环境管理员自己把密码忘记了。操作上可以通过编辑conf/tomcat-users.xml重新设置账号密码保存后重启Tomcat。但要注意这只能在自己掌握服务器控制权的前提下进行并且操作前必须备份原配置文件。如果是生产环境还要考虑变更窗口和影响范围。直接重启Tomcat会导致业务中断应当提前安排维护窗口。更重要的是恢复密码之后马上检查一下是否还存在其他残留的调试账号一并清理。7.2 改了端口就安全了吗不安全。端口只是一个网络入口标识改端口只在最浅层增加了扫描成本。通过访问HTTP响应头、识别Tomcat默认错误页面样式、探测常见路径比如/manager/html的返回状态仍然可以快速确认目标类型。防护的关键在于身份认证强度和访问控制而不是端口是否默认。7.3 日志中出现异常登录怎么排查看到日志里出现大量401或者成功登录记录要先稳住不能慌按以下顺序排查。先把manager应用自己的日志打开查看请求来源IP、时间范围、尝试次数。然后看tomcat-users.xml检查是否存在不认识的账号尤其是有manager-gui或manager-script权限的账号。接着查看webapps目录对比已部署应用清单看是否出现了陌生目录或者未记录在案的WAR包。最后把相关账号密码立刻轮换管理员接口的来源IP限制打开对已发现的异常应用做备份后下线。整个排查过程要做好记录形成一份完整的事件说明而不是改完密码就当没事发生。这篇笔记写到这里我最想强调的还是那句话Tomcat弱口令getshell之所以被称为入门必啃的硬骨头不是因为它难而是因为它把攻击链的完整环节压缩到了一个很小的场景里。我在本地靶场里反复做过很多次类似的验证最初也犯过只顾着跑工具、不关注链路原理的毛病。后来把认证机制、部署权限、代码执行路径一条条拆开来看才真正理解为什么一个看起来简单的弱口令最后会造成那么大的破坏力。如果你看完这篇笔记准备动手练习我的建议是先从搭靶场开始亲手把环境配置出来再按着管理接口、登录验证、应用部署这条线走一遍。等整条链路在脑子里跑通了再去研究端口扫描、指纹识别、流量排查这些外围技术你会发现自己对安全这件事的理解扎实了很多。