jboss 漏洞

2017年4月，安全圈炸了。一个叫“jboss”的Java应用服务器被曝出反序列化漏洞，编号CVE-2017-12149。当时我在一家小公司做运维，凌晨三点被电话叫醒，客户的生产环境被入侵，服务器上多了个挖矿程序。排查到天亮，根源就是JBoss的HttpInvoker组件没做任何过滤，攻击者构造一个恶意序列化数据包，直接就能远程执行代码。那台机器连防火墙都没开，端口8080裸露在公网。

JBoss是Red Hat旗下的中间件，全称JBoss Application Server，后来改叫WildFly。国内不少政企系统、老银行项目还在跑JBoss 4.x、5.x、6.x。这些版本有个通病：默认配置太“大方”。比如JBoss 4.x的jmx-console，默认账号密码是admin/admin，很多人装完根本不改。你访问`http://ip:8080/jmx-console/`，输入admin/admin就能进去，里面有个“jboss.system:service=MainDeployer”的MBean，直接上传一个WAR包，shell就到手了。这甚至不算漏洞，是配置失误。但现实是，2010年之前部署的JBoss，十个里有八个能这么打进去。

更隐蔽的是反序列化。JBoss的HttpInvoker组件（路径`/invoker/readonly`）接收序列化数据时，没有做类型白名单。攻击者用ysoserial工具生成一个CommonsCollections链的payload，往那个接口一POST，服务器就执行任意命令。CVE-2017-12149影响JBoss 5.x和6.x，CVSS评分9.8。当时全球暴露在公网的JBoss实例超过3万台，国内占比不小。我见过一个案例，某地级市的水务系统，JBoss 5.1.0跑在Windows Server 2003上，被入侵后攻击者留了个远控木马，还改了管理员密码。运维人员压根不知道JBoss有漏洞，以为内网就安全。

JBoss漏洞的利用门槛低得吓人。一个刚学安全的新手，用现成的exp脚本，半小时就能拿下一台。2018年有个叫“JBossMiner”的僵尸网络，专门扫描8080端口，识别到JBoss就尝试反序列化攻击，成功后植入门罗币挖矿程序。它甚至不需要交互，全自动。这种自动化攻击让很多老旧系统在毫无察觉的情况下变成矿机。我曾在一次应急中看到，服务器CPU跑满，风扇狂转，但top命令里看不到明显进程——挖矿程序改了进程名，伪装成`[kworker]`。查了半小时才发现是JBoss的java进程在跑恶意class。

修复方式其实不复杂。升级到WildFly 10以上，或者打补丁。但现实是，很多系统不能升级，因为业务代码绑死了老版本。那就只能做缓解：删除HttpInvoker组件、关闭jmx-console、加WAF规则、限制8080端口只允许内网访问。最怕的是那种“三无”环境——无运维、无监控、无备份。JBoss漏洞只是表象，根子在于资产管理和补丁流程的缺失。我见过一个单位，JBoss服务器放在机房角落，三年没人登录过，直到被勒索软件加密了数据库才发现。

说个细节。JBoss反序列化利用成功后，攻击者通常会在`/tmp`目录下留一个`.jboss`的隐藏文件，里面是base64编码的payload。清理的时候如果只删了进程，没删这个文件，重启后又会复活。这个技巧很多应急手册没写，但实战中坑过不少人。另外，JBoss的日志默认在`server/default/log/server.log`，如果被入侵，日志里会有大量`java.io.InvalidClassException`异常，那是反序列化失败留下的痕迹。看到这个，基本可以确定有人在打你。

现在云原生流行，JBoss用得少了。但老系统还在跑，漏洞就不会消失。2023年Shodan上还能搜到上万台JBoss，其中不少带着已知漏洞。安全这件事，很多时候不是技术问题，是人的问题。你永远叫不醒一个装睡的运维，但攻击者可以。