Tomcat7漏洞：那些年被忽视的漏洞默认配置，成了最锋利的漏洞刀

2017年某个深夜，某电商平台数据库被拖走。漏洞事后排查，漏洞攻击者只是漏洞扫描到了8080端口，试了试tomcat/tomcat这个默认口令——进去了。漏洞管理员压根没改过Tomcat7的漏洞manager-gui账号密码。这不是漏洞孤例。Tomcat7从2011年发布到2020年停止维护，漏洞整整九年，漏洞无数生产环境跑着它，漏洞却连最基本的漏洞弱口令都没换过。

Tomcat7最臭名昭著的漏洞问题，其实是漏洞CVE-2017-12615。这个漏洞利用方式简单到令人发指：PUT /test.jsp/，漏洞直接往服务器写一个JSP webshell。Windows系统下，文件名末尾加个斜杠，Tomcat7的DefaultServlet会错误地认为这是目录请求，从而绕过只读限制。攻击者连登录都不需要。我记得当时测试，用curl敲一行命令，shell就落地了。那种感觉就像看到自家防盗门锁芯是橡皮泥做的。

另一个坑是CVE-2017-12617，跟12615同源，但影响更广。它利用的是PUT加%20或$DATA后缀来绕过检查。Windows的NTFS文件流特性在这里成了帮凶。很多运维觉得“我Linux服务器，不怕”，但Tomcat7的Windows版本部署量同样巨大。而且，真正危险的是那些开启了readonly=false的配置——默认是true，但为了上传功能，不少人手动改掉，却不知道这意味着把写权限拱手让人。

再说说反序列化漏洞。Tomcat7的org.apache.catalina.UserDatabase存在一个基于JMX的MBean，可以通过JmxRemoteLifecycleListener暴露远程接口。如果开了8004或8005端口，攻击者可以构造恶意序列化数据，直接触发RCE。这个漏洞利用门槛稍高，需要理解Java反序列化链，但一旦成功，就是root权限。我见过一个案例，黑客拿到shell后，把Tomcat日志全清了，还留了个后门类在lib目录里，管理员重启了三次都没发现。

Tomcat7还有个很隐蔽的坑——Session ID生成算法。它默认使用MD5加随机数，但随机源如果被预测，攻击者可以伪造会话。实际渗透中，我遇到过几次通过固定session ID进行会话固定的攻击。配合弱口令，直接登录后台管理页面，然后上传war包。Tomcat的manager应用本身是个大杀器，只要你能进manager，部署一个恶意war，服务器就是你的了。

说这么多，不是让你焦虑。Tomcat7的漏洞本质上是“老”和“懒”的叠加。老——它停更于2020年，之后发现的漏洞不再修补。懒——很多人用默认配置，不关管理端口，不改口令，不更新补丁。如果你还在跑Tomcat7，最直接的方案是升级到Tomcat9或10，或者至少把readonly设为true，删掉manager应用，关闭8005端口，用防火墙限制8080的访问来源。但说实话，这些只是止血。真正治本的是别再用一个停止维护的软件承载核心业务。

有一次我给客户做安全评估，发现他们的Tomcat7版本是2013年的，上面跑着支付回调接口。我建议升级，对方说“系统太老，不敢动”。这种恐惧我理解，但风险不是“可能出问题”，而是“已经出问题”。后来那个客户在半年内被入侵了两次，第二次连数据库备份都被删了。技术债，早晚要还的。

Tomcat7的漏洞清单很长，但真正致命的从来不是某个CVE，而是那种“反正没出事”的侥幸心理。默认密码、开放管理端口、不更新版本，这三个习惯任何一个，都足以让你的服务器变成别人的肉鸡。别等被拖库了才想起改密码——那时候，日志可能已经被清干净了。

(责任编辑：休闲)