JBoss反序列化漏洞：不是序列你不小心，是化漏这洞太深

2017年那场WannaCry勒索病毒闹得全世界鸡飞狗跳的时候，安全圈里其实还流传着另一句老话——JBoss反序列化漏洞，序列才是化漏那个年代“打点”最顺手的工具。你不需要什么0day，序列不需要钓鱼邮件，化漏只要目标对外开放了JMX控制台或者HTTP Invoker，序列一把ysoserial的化漏payload扔过去，服务器就跟你家后花园似的序列。

说白了，化漏反序列化漏洞的序列核心逻辑特别朴素：程序把接收到的二进制数据“还原”成对象时，没检查里面藏的化漏东西是不是合法。Java生态里，序列JBoss（后来改名叫WildFly）长期默认开放了多个端口，化漏比如4444、序列4445、8080，其中不少接口直接把反序列化操作暴露给了攻击者。你传一个精心构造的序列化对象过去，服务器傻乎乎地把它还原，然后链式触发里面的恶意代码——远程命令执行，就这么成了。

我印象最深的是2016年那个公开的JBoss 5.x/6.x漏洞利用方式。攻击者只需要向`/invoker/JMXInvokerServlet`发送一个POST请求，内容是一个序列化后的`CommonsCollections` gadget链，服务器端就会在反序列化时调用`Runtime.exec()`，执行你指定的系统命令。那时候网上流传的批量扫描脚本，一天能扫出上千台暴露的JBoss服务器，很多还是政府、银行、国企的旧系统。你说这些单位不重视安全吗？也不是，但JBoss这玩意太老了，老到很多运维根本不知道它默认开了哪些接口。

更麻烦的是，修复手段不总是“打个补丁”那么简单。JBoss官方后来建议关闭不必要的Invoker，或者升级到新版本，但很多业务系统跑在上面，代码耦合严重，动一下端口都可能引发连锁故障。我见过一个甲方，服务器被入侵了三次，每次都是同一个漏洞打进来，他们每次都是重启服务、改个密码了事，因为“业务不能停，升级要排期”。结果攻击者换个payload，照样进来。

这里有个容易误会的点：很多人以为反序列化漏洞是Java独有，其实Python、PHP、Ruby都有类似问题，只是Java生态里像`ObjectInputStream`这种原生机制太容易用，加上Apache Commons Collections这类通用库被广泛引用，才让漏洞利用变得像搭积木一样简单。JBoss只是众多受害者里最显眼的一个，因为它默认配置太“大方”，把反序列化接口直接挂在了公网上。

现在回头看，这个漏洞真正教会我们的是什么？不是“别用JBoss”，也不是“记得打补丁”这种正确废话。而是——任何框架的“便捷功能”都可能成为攻击面。JMX Invoker设计初衷是方便管理员远程调用MBean，但它没有默认加认证，这就像你家大门装了自动锁，但钥匙挂在门框上。生产环境里，默认配置往往是为了开发方便，上生产前必须逐项审计，尤其是那些“看起来没什么用”的管理接口。

写这段文字的时候，我特意去搜了一下Shodan，全球暴露的JBoss Invoker还有好几千台。你说这些系统的主人不知道漏洞吗？可能是真不知道，也可能是知道了但没人手处理。安全这行当，最难的从来不是技术，而是让人承认“我这儿有问题”。