中间件漏洞总结

去年帮一个朋友看他的电商后台，刚扫了两下就发现 WebLogic 的漏结 T3 协议端口大剌剌开着，版本还是洞总 10.3.6。我问他这服务器多久没动过了，中间他说“买来就这样，漏结一直跑着挺稳的洞总”。三天后，中间那个反序列化漏洞就被挂上了自动化利用工具。漏结这事让我觉得，洞总中间件漏洞这东西，中间不出事的漏结时候像空气，出了事就是洞总窒息。

中间件不是中间单一软件，它夹在操作系统和业务应用之间，漏结Tomcat、洞总Nginx、WebLogic、JBoss、Apache、IIS 这些都算。它们处理 HTTP 请求、管理连接池、做负载均衡，也正因如此，一旦出问题，影响面直接覆盖上面跑的所有业务。我见过一个 Nginx 配置失误导致整个集群的静态资源被恶意替换，也见过 Tomcat 的 manager 弱口令被爆破后，攻击者直接部署 WAR 包拿到服务器权限。

反序列化是中间件漏洞里的重灾区。WebLogic 的 T3、IIOP 协议，JBoss 的 HttpInvoker，还有 Shiro 那种虽然不算严格中间件但经常搭配使用的框架，都在这上面栽过。原理不复杂：Java 对象序列化后通过网络传输，服务端反序列化时如果没做校验，攻击者就能构造恶意链，在目标机器上执行命令。2015 年 WebLogic 那个 CVE-2015-4852，利用工具满天飞，打进去就是 root。后来 Oracle 补了又补，但每次补丁出来，总有绕过方式。去年还有个 CVE-2023-21839，T3 协议又中招，远程加载恶意类。我试过在本地环境复现，从发送 payload 到反弹 shell，不到五秒。

文件上传和解析漏洞也常见。Apache 的多后缀解析问题，test.php.jpg 在某些配置下会被当成 PHP 执行。IIS 6.0 那个分号截断，test.asp;.jpg 直接绕过上传限制。Nginx 更微妙，fastcgi_split_path_info 配错，/upload/test.jpg/x.php 这种路径就能让 PHP-FPM 去解析 jpg 里的代码。我见过一个真实案例，攻击者上传了一个看似正常的图片，里面嵌了 PHP 一句话，利用 Nginx 的解析漏洞拿到 webshell，然后内网横移，三天后域控沦陷。

配置不当是另一大类。Tomcat 的 manager 和 host-manager 默认页面，很多人装完就不管，弱口令 tomcat/tomcat 一试就进。进去之后能部署 WAR，等于直接给攻击者一个后门。还有 Nginx 的目录遍历，autoindex on 没关，整个目录结构暴露，备份文件、配置文件随便下载。JBoss 的 jmx-console 未授权访问，能直接调用 MBean 部署木马。这些漏洞技术上不复杂，但覆盖面极广，因为太多人装完中间件就扔那儿了。

HTTP 请求走私算比较隐蔽的一类。利用前端代理和后端服务器对 Content-Length 和 Transfer-Encoding 解析不一致，把恶意请求夹在正常请求里。Nginx 和 Tomcat 组合、Apache 和 WebLogic 组合，都出过这种问题。我测试过一个环境，前端 Nginx 转发到后端 Tomcat，构造一个 Transfer-Encoding: chunked 加 Content-Length 的请求，后端把第二个请求当成了第一个请求的 body，结果绕过了前端的权限校验。这种漏洞利用门槛高，但一旦成功，危害极大。

中间件漏洞的修复，很多时候不是打补丁那么简单。WebLogic 的补丁经常引入新问题，有次打完补丁 T3 协议直接不通了，业务中断两小时。Tomcat 的 manager 可以删掉，但有些运维图方便留着，那就得改强密码加 IP 白名单。Nginx 的解析漏洞，要么升级，要么改配置把 fastcgi_split_path_info 写严谨。我的习惯是，每上一个中间件，先跑一遍 nmap 和 nikto，看看默认页面和端口，然后对照 CVE 列表查版本。别等出事再查，那时候日志可能都被清了。

说到底，中间件漏洞的根源就两个：一是代码写得不严谨，二是部署的人太懒。前者靠厂商修，后者只能靠自己。我见过最离谱的，一台服务器上跑着 WebLogic 10.3.6、Tomcat 7、Nginx 1.4，全是老版本，问就是“升级怕影响业务”。后来被挖矿了，CPU 跑满，才急着找人。中间件是地基，地基裂了，上面装修再漂亮也没用。