jboss漏洞

2017年4月，安全圈炸了锅。CVE-2017-12149这个编号开始在各大漏洞平台上刷屏，JBoss Application Server的HTTP Invoker组件存在反序列化漏洞，攻击者可以构造恶意请求直接执行任意代码。那几天我正好在给一个客户做内网渗透测试，扫到一台JBoss服务器，版本号是6.x，心里咯噔一下——这玩意儿十有八九中招。

JBoss是什么？Red Hat旗下的开源Java应用服务器，早年国内很多企业拿它跑OA、ERP、甚至银行的一些外围系统。部署方便，功能全，但配置起来坑多，尤其是默认安装后一堆管理接口暴露在外。HTTP Invoker就是其中一个典型的“方便但危险”的组件，它允许通过HTTP协议调用Java方法，设计初衷是好的，可反序列化这块没做安全校验，等于给攻击者留了后门。

我那次测试用的工具是ysoserial，生成一个CommonsCollections链的payload，直接往/invoker/readonly这个路径发POST请求。不到三秒，服务器返回了DNSlog的请求记录——说明代码执行成功了。客户那边还蒙在鼓里，以为内网隔离就万事大吉。实际上JBoss这漏洞根本不需要什么高级技巧，一个curl命令就能打穿。

更麻烦的是，JBoss漏洞不止这一个。CVE-2017-12149只是冰山一角，还有CVE-2015-7501、CVE-2013-4810等等，都是反序列化或者JMX控制台的问题。有些老版本甚至默认管理账号密码是admin/admin，登录进去直接部署war包，拿shell跟喝水一样简单。我在一些资产测绘平台上搜过，直到2023年，互联网上还能找到大量暴露的JBoss管理端口，8080、9990、4447这些，很多连防火墙都没配。

为什么这么多JBoss漏洞反复出现？我的观察是，JBoss的版本迭代混乱，社区版和EAP版分支多，很多企业用了之后根本不升级。加上Java反序列化漏洞本身利用门槛低，工具成熟，黑产自然盯得紧。挖矿木马、勒索软件、僵尸网络，都爱拿JBoss当跳板。有一次应急响应，客户一台JBoss服务器被植入了挖矿程序，CPU跑满，排查发现攻击者用的就是2017年那个老漏洞，系统三年没打过补丁。

怎么防？别指望什么“安全加固指南”里那些套话。实际点说，第一，别把JBoss直接暴露在公网，内网也得做访问控制；第二，删掉或禁用HTTP Invoker，如果业务不用的话，直接干掉/invoker路径；第三，升级到最新版本，Red Hat早就发了补丁，但很多人懒得动；第四，上RASP或者WAF，能挡掉大部分反序列化流量，虽然可能误报，但比裸奔强。最后，定期扫一遍内网，看看有没有漏网的JBoss，别等中招了才想起来。

说实话，JBoss这玩意儿本身不差，性能稳定，生态也成熟。但安全这块，Red Hat的默认配置太信任内网了。搞技术的人都知道，内网早就不是安全边界了。一个漏洞放五年十年，还能在真实环境里打通，这不是技术问题，是人的问题。我见过太多运维，装完JBoss就不管了，端口开着，密码不换，补丁不打。等出了事，再找安全团队擦屁股。累。

所以下次你扫到JBoss，别犹豫，先测CVE-2017-12149。打不穿再说别的。打穿了，赶紧通知客户，别声张，先取证。这行干久了，你会发现，最危险的漏洞往往不是最复杂的那个，而是最老、最熟、最没人管的那一个。