Smartbi 的程命远程命令执行漏洞，我第一次是令执在一个客户内网里撞见的。当时用 nmap 扫到 8080 端口跑着 Smartbi，行漏顺手试了一下公开的洞测利用链，结果直接弹回来一个 whoami 的试结结果——nt authority\system。那一刻的程命感觉挺复杂，既觉得这漏洞也太好用了，令执又替那些把 Smartbi 暴露在公网上的行漏单位捏把汗。

这个漏洞的洞测核心出在 Smartbi 的某个接口对用户输入过滤不严，攻击者可以构造特定请求，试结让服务器执行任意系统命令。程命具体来说，令执问题点在 `/smartbi/vision/RMIServlet` 这类接口上，行漏它本来是洞测用来做远程调用的，但没做好权限校验和输入清洗。试结我实际测试时用的 payload 并不复杂，一个 POST 请求，body 里塞进经过序列化的恶意对象，服务器就会在反序列化过程中触发命令执行。

测试环境是 Windows Server 2016，Smartbi 版本是 V9 还是 V10 我记不太清了，反正补丁没打全。执行 `whoami` 返回 system 权限后，我又试了 `ipconfig` 和 `dir C:\`，都正常回显。这说明漏洞不仅能执行命令，还能拿到命令输出，利用门槛很低。后来换到 Linux 环境测，同样成功，`id` 命令返回 uid=0(root)。

有意思的是，这个漏洞的利用方式不止一种。除了反序列化那条链，还有通过 `getShell` 接口直接上传 webshell 的路径。我在另一台机器上试了上传 jsp 文件，虽然 Smartbi 默认不解析 jsp，但配合目录穿越把文件写到 Tomcat 的 webapps 目录下，照样能访问。这种组合利用让漏洞的危害又上了一个台阶。

从测试结果看，Smartbi 的补丁响应还算及时。官方在后续版本里加了权限验证和输入过滤，但问题在于很多用户根本不升级。我扫过几个公网 IP，发现仍有大量老版本在跑，有的甚至直接暴露在 443 端口上。这些系统一旦被攻击者盯上，基本就是秒破。

说点个人观察。Smartbi 这类国产 BI 工具，功能做得挺全，但在安全设计上往往偏弱。开发团队可能更关注业务逻辑和报表性能，对输入验证、权限控制这些底层安全机制不够重视。远程命令执行漏洞在 Java 应用里不算新鲜，但出现在商业 BI 产品里，而且利用链这么直接，说明代码审计环节存在明显缺失。

测试过程中我还注意到一个细节：漏洞触发后，服务器日志里几乎看不到异常记录。也就是说，攻击者可以悄无声息地执行命令，管理员如果不主动排查，根本发现不了。这种隐蔽性让漏洞的实际风险更高。

如果你手头有 Smartbi 环境，建议尽快升级到最新版本，或者至少把那个 RMIServlet 接口的访问权限限制掉。实在不行，就在前面加个 WAF，把反序列化相关的流量拦一拦。别觉得内网就安全，我这次测试的入口就是从内网一台普通办公机开始的。

漏洞测试本身不复杂，复杂的是怎么让客户相信这事真的会发生。我后来给那个客户演示了一遍，从发送请求到拿到 system 权限，前后不到十秒。他们看完沉默了一会儿，然后问：能不能帮我们把所有 Smartbi 都查一遍。我说可以，但你们得先答应我，这次一定把补丁打上。